UNSCOPED: Caps are layering on top of roads, fix roads layer order

[sensescape]

• [x] Functional data in tiles
• [ ] Polish data in tiles
• [x] Functional styling
• [ ] Polish styling

[sensescape]

[nvkelso]

Let's @bcamper, @zerebubuth, @sensescape and @nvkelso brainstorm about this one. I suspect it will require combination of server and client work.

[bcamper]

I think the issue here is not the entire cap, but just the outline stroke of the cap. Those are drawn directly under the line fill by default, but we can control the order of it separately in the scene file if we have the right data to filter on.

On Friday, September 25, 2015, Nathaniel V. KELSO notifications@github.com wrote:

Let's @bcamper https://github.com/bcamper, @zerebubuth https://github.com/zerebubuth, @sensescape https://github.com/sensescape and @nvkelso https://github.com/nvkelso brainstorm about this one. I suspect it will require combination of server and client work.

— Reply to this email directly or view it on GitHub https://github.com/tangrams/eraser-map/issues/2#issuecomment-143150628.

[bcamper]

@sensescape do you have good examples where I can see this?

[sensescape]

Here's one example: http://localhost:8000/#17/37.80199/-122.45861

[sensescape]

Another: http://localhost:8000/#17/40.72369/-74.00750

[sensescape]

I would like the round cap here to smoothen the transition for the different road types. I'm not sure if this is working: https://github.com/tangrams/eraser-map/blob/gh-pages/eraser-map.yaml#L1104

http://localhost:8000/#17/37.76917/-122.40942

[sensescape]

http://localhost:8000/#17/40.75633/-73.99643

[bcamper]

@sensescape I believe that round rule is working based on most of your screenshots having round caps :) But it may be overridden in some cases like this, where it's explicitly set to butt? https://github.com/tangrams/eraser-map/blob/gh-pages/eraser-map.yaml#L1123

[zerebubuth]

@bcamper I was thinking about the transition between roads, and wondering how flexible we can be with the end caps? For example, if we have the topology (hi, TopoJSON!) then we could find the max(line_width) at any shared point and have the incoming segments flare out to that width. It would be even more awesome if we could also do avg(fill_color) and blend to that :smile:

It looks like we might have the information in the (TopoJSON) tiles to do this, and it seems like the kind of thing that might be possible to do at some point in the future. What do you think? Something we might have a chat about in November?

[bcamper]

@zerebubuth yes I wonder if something cool could be done there. Thinking about a generic Tangram feature, the most straightforward would be to specify some kind of tapering options when drawing lines, like:

• start and end widths, with continuous tapering along the whole line
• tapering caps, e.g. taper from the normal line width up/down to a target taper width, but only at the end of the line segment (how short/long the taper is could be configurable)

This simplest form of this would have the start/end data encoded in the tile already, so it could just be plugged into the renderer. I can also see a more advanced feature where Tangram can use topology to derive that (not trivial but plausible...), though I think we would still have problems at places like tile borders. Let's talk more!

[bcamper]

@zerebubuth I guess what I'm asking for is adjacency data in the tiles, like road types that connect at the start and/or end of a road line, so that we could filter and style on that. Like denormalizing the topology into into the geometry properties. Using actual topology could be cool too, though it also implies a format like TopoJSON that can encode it? We'd be going offroad with the MVT format at that point if there's no current way to encode topology (it's protobuf though so we could probably additional optional topology info).

[zerebubuth]

@bcamper We can try recovering adjacency data in the same way we do for TopoJSON tiles. The difficulty might be if we have any joins which don't occur at the first or last point in the linestring. Keeping the topology through the tile generation process is something that I'm really interested in doing for other reasons (e.g: simplifying boundaries properly, generalising networks without introducing gaps, etc...), so perhaps this has to be hitched to that.

Nice idea! Having TopoMVT would be really interesting and might be a big win in file size for some cases - in the same way that TopoJSON can be over GeoJSON.

[nvkelso]

I need to draw some pictures.

[nvkelso]

The scene file now uses a different approach. Fixing the root issue of this original is not a 1.0 launch feature.

[nvkelso]

Here's the same area today: