Should we have osm2pgsql.relation_member_ids similar to osm2pgsql.way_member_ids?

[caspg]

I've created in my lua config relation_member_ids based on osm2pgsql.way_member_ids.

Should I open PR with this addition or is there any specific reason why it's not present already?

[joto]

Two-stage processing does not work for relations, so I don't see why we would need that?

[caspg]

I've used it inside function osm2pgsql.process_relation(relation). Wanted to store member relation ids inside relation for further processing.

If that's not a common use case then maybe it's not needed inside osm2pgsql.

[joto]

It would certainly be nice if osm2pgsql could handle relations in relations. But so far nobody I am aware of has looked into what would be needed/sensible for that. What is your use case?

[caspg]

I'm working on a cycling app. Some of the routes in OSM are "super routes" (relations in relations with few level of nesting).

• EuroVelo 10 top super relation OSM waymarkedtrails
• EuroVelo 10 part Poland super relation OSM
• EuroVelo 10 part Poland 3 OSM

I want to filter out those "sub routes" and only find super relations. Also I need to build geometry of those super relations.

[joto]

There is currently no way to do this with osm2pgsql. So you'll have to import them all into the database and do some post-processing there. We have always been shying away from implementing super relations (or any other thing where relations of relations are involved) due to the complexity of the processing. Especially when updates are involved. Or nesting several levels deep.

[caspg]

Yup, this is quite complex task and I couldn't find any tool to handle that. Also it's probably quite niche use case, mostly for cycling and hiking long distance trails.