Add support for linear referencing properties and drawing

[nvkelso]

In preparation for OSMLR segments in Valhalla and Tilezen we're going to have single road geometries with multiple OSMLR segment IDs and their relative position along the geometry (and each direction on the line has a different ID?).

Let's start discussing how to model this data and how to render it in Tangram with this issue. (There may be some overlap with transit discussions?)

/cc @zerebubuth for vector tile encoding @meetar with his background in the OpenTraffic prototype map styling

[meetar]

👍 Can we start with some background about how the new scheme will differ from the previous one? Can I infer that there were multiple road geometries, each with a single OSMLR segment ID, and both directions on the line shared an ID? :)

[bcamper]

OSMLR ids are an entirely new type of data here, they don't exist in current tiles at all.

On Thu, Oct 19, 2017 at 3:18 PM, Peter Richardson notifications@github.com wrote:

👍 Can we start with some background about how the new scheme will differ from the previous one? Can I infer that there were multiple road geometries, each with a single OSMLR segment ID, and both directions on the line shared an ID? :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tangrams/tangram/issues/609#issuecomment-338009639, or mute the thread https://github.com/notifications/unsubscribe-auth/AABBXSIocOUq_OmWUwUFmabMRh63Yaweks5st6B-gaJpZM4P_f6H .

[meetar]

So the "geometries" in this case will be existing Mapzen vector tile geometries created by tilezen/vector-datasource, which will have new ID, position, and directionality attributes – is this closer?

[nvkelso]

At zoom 15 (max_zoom):

• Each OSM way is represented as a single Tilezen geometry feature (per tile, can span multiple tiles)
• Each Tilezen geometry feature would have two properties for OSMLR inbound and outbound IDs.
• This case should be essentially the same as the OpenTraffic demo app @meetar has helped build.

At zoom 14 (and 13,12,11,10):

• Tilezen does a good amount of line merging to reduce overall tile file size and to improve drawing performance. That's in conflict with having individual features tied with OSMLR IDs.
• We may do slightly less merging...
• For the Tilezen features we may included X number of "chained" OSMLR IDs per geometry direction that include the ID and the "linear referencing" span of the geometry that ID covers.
  • What's the best format to convey this data in the vector tile?
  • Is there an optimal format for joining live traffic (or other LR'd data) dynamically at render time in Tangram?
  • Is there an optimal format for Tangram to use to draw parts of the linear features per attribute property? This generally lines up with "data viz" sprint this quarter?
  • We'd like the data associated with actual road geometries so we can make use of the "traffic" properties both in rendering the traffic on that geometry like we do with the bike map styling, and to modify label collision logic around the traffic. We'd like to make full use of shaders in the drawing of the traffic, too (not just basic line and outline).

At mid- to low-zooms (7,8,9):

• We'd probably keep the OSMLR properties on kind:highway, sometimes on kind:major_road
  • The number of "chained" OSMLR's IDs starts to get a little ridiculous...
  • At zoom 7 a single logical "pixel" is ~ 1km, which is the maximum OSMLR segment length https://mapzen.com/documentation/terrain-tiles/data-sources/#what-is-the-ground-resolution
• We'd definately drop OSMLR properties on kind:minor_road and worse features.

Actual zooms TBD and included here for illustration only.