Rebuild transit layer by walking way relations (and avoid features like platforms)

[rmglennon]

tl;dr

• Rebuild transit layer by walking ways, relations, and master relations
• Include service property, like the roads layer

===

This came in through support (see Desk 454)

Currently I am working with the vector tiles of yours. And I think I’ve found a bug in the transport layer of tilezen. The platforms for lightrails (and some subway stations?) aren’t tagged as platforms; so if I just want to display a line of a subway or a tram, their platforms get displayed also - but I would like to filter these platforms out. I attached a screenshot (out of the Maputnik Editor); this is the position at Openstreetmap: http://www.openstreetmap.org/#map=19/52.50483/13.44873"

[nvkelso]

Tilezen uses a shortcut to display the transit lines in the transit layer. When we import OpenStreetMap data into PostGIS it's possible to ask for the lines themselves as relations directly instead of walking each way to see if it's part any one transit relation. This improves performance, but has several visual downsides, including the case the customer reports where these particular ways are correctly tagged in OSM as being part of 2 different relations as platform. You'll occasionally also see this bug on station buildings, too.

We'd like to add line offset information (tracked in https://github.com/tilezen/vector-datasource/issues/1189, bad pun), and doing that would allow us to fix this bug (because we'd have to walk individual ways and could filter out platforms and buildings).

[nvkelso]

From https://github.com/tilezen/vector-datasource/issues/606:

• What did you see? The N-Judah in SF to have a "blue" color. The "route_master" feature it's part of does have blue set, and the other child relation also has "blue" set (manually by me).
• What did you expect to see? The color was missing from the route feature. Should we ask people to edit the color in the route or the route_master? In this case it's an "inbound" and an "outbound, so they'd need to enter it twice (one for each direction). Which isn't terrible, but just needs to be documented.
• What map location are you having problems with?
  • route: https://www.openstreetmap.org/relation/3435877
  • route_master: https://www.openstreetmap.org/relation/3435884
• Screenshot?

...

Which @zerebubuth replied:

Doing this kind of "relation exploring" is costly. I've hand-waved about it before and dismissed the cost on the basis that stations are rare features, but we're including stations ever-earlier, and the transit routes are also much more common (in terms of being included in more tiles). This is possible, but it won't be nice and could significantly impact tile performance.

This kind of processing would be more efficiently and cleanly done "upstream" either in osm2pgsql or NEAT (nea RAWR).

[nvkelso]

@zerebubuth said in https://github.com/tilezen/vector-datasource/issues/548#issuecomment-193766298:

The roads and transit layers have very different information in them:

• The roads layer has short, individual segments of physical rail, with service properties including crossover, siding, yard, etc... and other physical attributes including bridge, tunnel, and so on. This is very much about the physical infrastructure, and comes from the ways in the database, such as one of the crossovers in your example.
• The transit layer has long, merged (multi)linestrings of "logical" rail. These are, in OSM jargon, "route relations", although it has been pointed out that in transit jargon they're closer to "lines". The crossover in the previous paragraph is part of one of these route relations, hence why it appears in the transit layer. Crossovers are not always part of route relations, for example this crossover is not part of any. The route relation (multi)linestring is not split up into sections, and therefore does not have separate properties for each section such as bridge or tunnel. Although there is a service tag on these routes, it doesn't mean the same thing as service on the physical infrastructure. On routes, service is the type of train service, e.g: high_speed, commuter, regional.

I've pulled an example from my North America extract for something like the roads and transit queries, which you can find in transit_service_example.zip. Hopefully that will make the difference between infrastructure ways and route relations clearer.

[nvkelso]

Also from @zerebubuth in https://github.com/tilezen/vector-datasource/issues/548#issuecomment-191170548:

The transit layer currently contains the route / "line" relations, which cover the whole length of the route / named service / "line". The service attribute might be different from what you expect, especially if you're looking for short segments to drop. From my North America extract, here's a table of the count of features with distinct route and service values:

   route    |    service    |  num  
------------+---------------+-------
 train      | regional      | 13853
 railway    |               |  8167
 train      | high_speed    |  6768
 train      | long_distance |  3092
 train      |               |  2347
 light_rail |               |   908
 subway     |               |   444
 tram       |               |   366
 train      | commuter      |   218
 train      | international |    68
 train      | car           |    23
 light_rail | commuter      |    21
 train      | tourism       |     3
 railway    | yard          |     3
 railway    | spur          |     2
 railway    | excursion     |     2
 railway    | tourism       |     1
 tram       | tourism       |     1
(18 rows)

99% of the features are covered by service IN ('regional', 'high_speed', 'long_distance') OR service IS NULL. The values will be different in the rest of the world, but this suggests that it won't contain short segments suitable for dropping.

Do you have examples of the kind of short segments and/or less important features that you'd want to drop?