Calculate line offset for transit route relations

[nvkelso]

Description from forward dup:

• What did you see? Transit lines overlap each other.
• What did you expect to see? They should be offset from each other. This might require a new "topological" alternative to the existing transit layer (and could also include topology from the transit stations & etc).
• What map location are you having problems with? San Francisco, New York, global.
• Screenshot?

I see:

I want to see:

Original description:

In San Francisco, New York, London, Paris, Tokyo, and other important transit markets multiple transit "lines" travel along the same "tracks".

Right now in the transit layer we export duplicative features per relation, and in the roads layer we have just the track geometry. To offset the lines client-side in Tangram we'd need a single geometry per track part (like in the roads layer), with an ordered list of relations that hang off that geometry.

To allow the Tangram team to prototype I propose we hang an ordered list of transit "lines" (relations) off the roads layer geometry with just the line name, color and optionally operator, line shield text (ref), and transit mode (e.g. subway, light rail, rail).

Update: All we need here is a relatively stable offset indicator on the existing individual route relation features in the transit layer.

When we brainstormed calculating the offset on Friday it was:

• Operator, then
• Line color, then
• Line name (for when there is no color)

[nvkelso]

/cc @bcamper

[bcamper]

We can prototype with existing data, so no rush there (we can hardcode a few layers with different offsets). But for the "real" feature, it's going to be much easier to implement on the client side with separate geometries for each line (even if that means they're duplicated). With separate lines, we can apply an offset to each, using a JS style function that translates a line index number into an offset in pixels. But making the client "multiply" a single geometry into several others based on a feature property would be a significantly greater change to the processing pipeline. While you can currently draw the same feature multiple times, that's based on static layers. There's no facility for dynamically replicating a feature based on arbitrary logic.

[nvkelso]

@bcamper Thanks, that's even easier :) I've updated the main issue description.

[zerebubuth]

Does the offset have to be unique within the tile, or unique "globally"? I had thought that we would assign offsets at junctions, but I'm not sure how we'd encode that into the tile.

Some detailed examples of the output that we want would be very helpful.

[bcamper]

We can make a diagram of what I was hoping to have for Tangram.

cc @meetar

On Fri, Apr 7, 2017 at 8:38 AM Matt Amos notifications@github.com wrote:

Does the offset have to be unique within the tile, or unique "globally"? I had thought that we would assign offsets at junctions, but I'm not sure how we'd encode that into the tile.

Some detailed examples of the output that we want would be very helpful.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/tilezen/vector-datasource/issues/1189#issuecomment-292571270, or mute the thread https://github.com/notifications/unsubscribe-auth/AABBXWes1QQ2PMgZC0TeVl49sBd_F1fUks5rtlh-gaJpZM4MyQK1 .

[zerebubuth]

A diagram would be very helpful, thanks!

[nvkelso]

On the Tangram side @meetar has proposed a PR to add support to JS in https://github.com/tangrams/tangram/pull/547. The assumption there is there are different line geoms (like vector tiles have today) for the different lines, but if an offset is available it'll push the line away. There's some followup to determine if shader versus geom preprocessing is the way to go (more like Mapbox does it).

When Brett was in the SF office last week we made the following sketches, with make a few assumptions:

• Reuse existing transit layer in a backwards compatible way
• Replace existing relation geometry with ways (more like we do in the roads layer)
• For each way:
  • Walk the relations to rebuild all the line attributes we have now, and
  • Calculate the line offset for each way:
    • Line offset for the "middle" of the line, and ideally also
    • Line offsets for the "start" and "end" of the line.
• Out of scope for v1:
  • Deduplicating inbound and outbound relations for same line
  • Collapsing parallel tracks (basically only calculate for ways at all zoom levels, not derivative topologies customized for lower zooms)
  • Minimizing line crossings would require more of a global build (versus per tile).

@zerebubuth can you review the sketches and provide comments, please?

[zerebubuth]

That's very helpful, thanks!

Taking the example a bit further, how would we assign the [start, center, end] offset values for something like this pair of junctions?

The grey dashed boxes would represent "bundles" of geometries for the same way, but duplicated for each transit line. Assigning offsets along the bundle (the center value) seems pretty straightforward. But how would we want to do it at the junction? The geometry there is basically point-like, although it's likely that the geometries would already be physically offset somewhat if they arrive at different platforms, this offset might be small at mid zooms.

If we're able to offset from the "junction point", then could we assign the offsets around a box (or octagon) at the point? E.g: something like:

Or is that kind of geometry manipulation not possible?

[nvkelso]

   \ /    ||
=== + === + ===
    /     |

• Where the start and end offsets are calculated as "nodes", and the middle is for the "way".
• For the start and end "nodes" we'd need to calculate the relations and offsets for that adjoining way, and record it for that "node".

For the LEFT dark grey box as if it were a node:

• L1 = left 1
• L0 = left 2
• TL = top left
• TR = top right
• R0 = right 0
• R1 = right 1
• R2 = right 2

For the right dark grey box as if it were a node:

• L0 = right 0
• L1 = right 1
• L2 = right 2
• T0 = right 0
• T1 = right 1
• R0 = right 0
• R1 = right 1
• BO = bottom 0

[nvkelso]

@bcamper and @meetar Can you comment on @zerebubuth's diagram in https://github.com/tilezen/vector-datasource/issues/1189#issuecomment-295657520, please? Is that feasible in Tangram for v1?

[nvkelso]

I talked with @bcamper a bit today and will followup here with some more diagrams.

[nvkelso]

Update from the tiles meeting today:

For v1 release in May we're going to limit work in this issue just the "center" offset and punt the "start", "end", and line joining pieces to a future v2 implementation in https://github.com/tilezen/vector-datasource/issues/1221.

[bcamper]

👍 I think being able to build working demos with the center offsets first will help us design the best follow-up (on both client and tiles)

[nvkelso]

For v1 we should only calculate line offsets for not railway, not train transit lines (they would always default to 0). This will help avoid situations where too many double and triple rainbows try to stack along the same right-of-way – and even though trains have colors generally we want to reserve the colour offsets for subway and light_rail / tram.

[nvkelso]

To clarify https://github.com/tilezen/vector-datasource/issues/1189#issuecomment-296407127...

• If a route is railway, then they should all get the same relative offset.
• But if a route is train (e.g. passenger service), they should get an offset per operator.
• If a route is any other transit type, it should be by line.

So if there are 11 lines:

• 2 railway,
• 3 train with 2 from a single operator and 1 from a different operator, and
• 6 other transit types with 4 subway and 2 light rail

Then we'd see a total of these 9 offsets:

• 1 combined railway line offset,
• 1 combined train line for operator A (two lines with same offset)
• 1 combined train line for operator B
• 4 individual subway lines "next" to each other in the same operator
• 2 individual light rail lines "next" to each other in the same operator

[nvkelso]

Punting to next release.