transit layer needs to indicate service

nvkelso commented 8 years ago

For rail features in the roads layer, we know the service level and can thin out crossover and other tiny rail elements. But we currently don't have that fines in the transit layer.

/cc @sensescape

zerebubuth commented 8 years ago

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?

nvkelso commented 8 years ago

Example in London:

When just looking at rail features in the roads layer, the service:crossover line segments can be selected and thin'd:

But the transit layer doesn't include this information, so the service:crossover gets the same thicker line style as the main line:

zerebubuth commented 8 years ago

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 commented 8 years ago

Explanation is very helpful, and I think will make #471 more straight forward to implement.

How does it work for OSM road relations? We project the attributes of the route onto the individual ways? Is that the only other option to trim the way's tagged service=crossover from the route relation geom?

That sounds like a ton of work for not a lot of gain...

zerebubuth commented 8 years ago

Yup, sounds like #471 is just making the service attribute available on those routes, if we're not already doing that. (And perhaps calling it something less easy to confuse with road-type service.)

How does it work for OSM road relations? We project the attributes of the route onto the individual ways?

Yes. We currently grab the first network tag on the relation (if any) for roads and railways in the roads layer. We could do a similar thing for projecting the names of the routes onto the railways in the roads layer, but that might end up bulking out the data by quite a bit.

Is that the only other option to trim the way's tagged service=crossover from the route relation geom?

To do that would probably either mean reconstructing all of osm2pgsql's route relation building logic, or implementing this in osm2pgsql itself. The latter would be nice from a reusability point of view, but would mean either a database reload or some potentially error-prone finagling of the database internals.

It would help to know what the route relation data would be used for. Given that there can be many of these on a single stretch of railway, probably too many to label by name, would we be looking to put shields on them in a similar manner to highways? Are we looking to draw them individually coloured / patterned to get something resembling a metropolitan transit map?

nvkelso commented 8 years ago

Let's not mess with the innards of osm2pgsql at this time; let's table adding the railway:service crossover stuff for now.

About the other stuff:

Yes, I'm interested in putting shields on lines. Tangram doesn't support shields yet, so for roads we've been setting the label text to source from the ref property for low- and mid-zooms, then setting it to the name property. Multiple lines aren't a problem right now for that, though eventually it would be nice to know about a single "line" and which of multiple "routes" run along it both for labeling and for doing offset line rendering (also an unsupported Tangram feature).

nvkelso commented 8 years ago

Sounds like if we wanted to "layer" transit features like road layer features, or indicate is_tunnel or is_bridge then same constraints apply.

bcamper commented 8 years ago

You can offset text above/below a line with offset, or do you mean something else?

On Tuesday, March 8, 2016, Nathaniel V. KELSO notifications@github.com wrote:

Let's not mess with the innards of osm2pgsql at this time; let's table adding the railway:service crossover stuff for now.

About the other stuff:

Yes, I'm interested in putting shields on lines. Tangram doesn't support shields yet, so for roads we've been setting the label text to source from the ref property for low- and mid-zooms, then setting it to the name property. Multiple lines aren't a problem right now for that, though eventually it would be nice to know about a single "line" and which of multiple "routes" run along it both for labeling and for doing offset line rendering (also an unsupported Tangram feature).

— Reply to this email directly or view it on GitHub https://github.com/mapzen/vector-datasource/issues/548#issuecomment-194032474 .

zerebubuth commented 8 years ago

I think @nvkelso meant offset lines, as are commonly used in metro maps (e.g: SF muni). However, being able to draw offset lines is only a part of the solution, it is also necessary to calculate unique offsets for each line - per segment, as these offsets may change depending on which lines are joining/leaving the "bundle" at each station.

Yes, I'm interested in putting shields on lines.

If we can assume a small number of properties for each line (e.g: osm_id, ref, colour) then we can collect a list of those from the relations and project them onto the individual railways in the roads layer (possibly filtering out service railways in the process). Since shields are essentially zero-length, then having the whole route/line relation merged together in one (multi)linestring isn't important?

bcamper commented 8 years ago

Ah yes, got it, offset lines, not offset line labels :) It's on the list!

nvkelso commented 6 years ago

It looks like service tag can also be used to take "train" relations that are actually "subway" lines and recast them.

http://wiki.openstreetmap.org/wiki/Public_transport#Railways

For routes with extra service=commuter tag we'd need to plumb that thru, and we'd add logic to recast them as subway?

nvkelso commented 5 years ago

Closing in favor of https://github.com/tilezen/vector-datasource/issues/1247.

tilezen / vector-datasource

transit layer needs to indicate service #548