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 ***@***.***> 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 <#1189 (comment)>, 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 tangrams/tangram#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?