In Kartographer's maplink/mapframe, rendering the MTR Airport Express metro line through ExternalData does not work, as the relation it is in only contains other relations. OSM guidelines indicate that all wikidata=* tags should be unique, so this prevents us from rendering a lot of public transport relations (unless there's a much more complicated way which I don't know about).
Description
Description
Related Objects
Related Objects
- Mentioned In
- T156433: Geoline/geoshape does not work with relations other than multipolygon/route/boundary
T155923: Kartographer maplink/mapframe ExternalData should render all geolines and/or geoshapes in an OSM relation regardless of continuity or whatever it is (it's not working properly, basically)
Event Timeline
Comment Actions
osm2pgsql (and most/all data converters) cannot form geometries from relations composed of relations, so this would require a database other than a rendering database.
fwiw, public transport relations are ill-designed for rendering, but this impacts other things like route relations.
Comment Actions
@Pnorman what would you recommend the best way for OSM editors to create such objects? Or should there be a software solution on the server side?
Comment Actions
what would you recommend the best way for OSM editors to create such objects
I'm not sure what best practices are for wikidata tags on objects yet, and they're probably still developing.
The idea that in general you can go from a relation ID to single sensible geometry interpretation is wrong.
In this particular case, it's a type=route_master relation, which is used to tie together multiple type=route relations. Beyond that, I'm not the most qualified to say, as I find the public transport schema almost designed to be unrenderable, and therefore don't have much to do with it.
Or should there be a software solution on the server side?
Well, any changes will be on the server side, but which server/component are you thinking of?
Realistically with some working going into a pause because it would require changes to the database geometries are pulled from and changes to the tools used to build geometries. My 5 minute stab at building a roadmap for a solution would to start with a pgsnapshot database and build the geometries from it. But recursing to handle relations as members of relations needs thought and non-trivial queries.
The other option would be an overpass database and appropriate overpass QL to get what's needed.