Page MenuHomePhabricator

Kartographer's maplink/mapframe ExternalData should render super-relations
Closed, DuplicatePublic

Description

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).

Event Timeline

Jc86035 created this task.Jan 22 2017, 7:35 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 22 2017, 7:35 AM

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.

Yurik added a comment.Jan 23 2017, 4:49 AM

@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?

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.