add POV and other v1.8, v1.7 changes

[nvkelso]

• ⭐️Add POV for boundaries and capitals; add map unit lines (eg Wales and Scotland)
  • 
• 🚚Add heavy goods vehicle (hgv) overlay
• 🤑Add toll road overlay
• 🚧 Add construction roads
• 🏞 Add new landuse treatments
• 👨 Fix aboriginal_lands boundary line treatment
• 🔋 Fix generator icons to use kind_detail lookup
• 🐯 Fix zoo enclosure labels
• 🚘 Fix motorway junction (exit) labels
• ☠️ Fix danger_area and range landuse styling (not RED!)
• 🏷 Update labels-11 theme to not reference all the client side hacks that were fixed server side
• 💻 Remove bunch of logic that moved server side (like for filtering out bad features, setting label collision priority)
• 🎉 Upgrade Tangram JS to v0.19

[nvkelso]

@bcamper This PR is cleaned up and ready for new 👀, please!

[bcamper]

Great new features and I love all the code removal!

There are a few questions around filter logic or values that are worth addressing, may be one or two unintentional items, but otherwise all looks good.

I'd like to pull out a couple of these oft-repeated lines into globals, to be more concise and lower risk of copy-paste errors, such as:

var kind = (global.ux_point_of_view && feature['kind:'+global.ux_point_of_view]) || (global.ux_point_of_view_fallback && feature['kind:'+global.ux_point_of_view_fallback]) || feature.kind;

and

priority: |
                    function() { return (feature['min_zoom'] + (1 - 1 / feature['collision_rank']) * 0.1) || 65; }

I can take a crack at that.

[bcamper]

I believe this kind of "else" condition can be done with the new exclusive layer property added in JS -- make all the other layers exclusive, and if none matches, the non-exclusive "else" one does -- but it's not in ES yet.

[nvkelso]

YES! exclusive would be great here :) So in Tangram ES the layer won't match and won't display? Seems backwards compatible and okay to implement?

[nvkelso]

Reading the docs in tangrams/tangram#705 I'm confused how I'd implement this. Is there a !exclusive or priority: -1 to mean evaluate this one layer last? Or do I have to add priority to every other sibling layer here, too?

[bcamper]

OK I extracted some repetitive logic in:

f591907
91f3b8f

Noticing that the pre-existing language toggle stuff could benefit from this as well, but it looks more complicated because of the many variants (short name, left/right borders, etc.), so I'll leave that for now.

[bcamper]

Actually now that I'm looking at these lines like:

priority: |
  function() { return (feature['min_zoom'] + (1 - 1 / feature['collision_rank']) * 0.1) || 65; }

I'm realizing the default value of 65 will never be triggered. If collision_rank is missing, you'll get -Infinity. If min_zoom is missing, you'll still get a number, but less than 1.

What's the desired fallback logic here?

[bcamper]

So is this the desired collision priority logic:

• If both min_zoom and collision_rank exist, use the formula.
• If only min_zoom exists, use it (or use min_zoom + 1 if features without a collision_rank should rank lower by default than those that do).
• If neither exist, use the provided default.

But, even then, the fallback values in the style like 65, 58, etc. don't make sense as final priority values when compared with min_zoom based values that are going to be in the ~1-20 range.

Are those numbers supposed to be defaults for collision_rank?

[nvkelso]

You're right... those fallback values are a holdover from before all the collision_rank were moved server side and spread out with much greater detail. But something like this is still desired. If a feature has a min_zoom but no collision_rank then it should be evaluated as worst among peers of the same min_zoom.

Example:

• Feature A:
  • min_zoom: 10
  • collision_rank: 1000
• Feature B:
  • min_zoom: 10
  • collision_rank: 1001
• Feature C:
  • min_zoom: 10
  • collision_rank: null

The outcome should be Feature A wins over B wins over C.

I think this could be accomplished by falling back to feature.min_zoom + 0.999 and call it good?

[nvkelso]

I've addressed the collision priority changes primarily in 92afcab (simplified to remove the defaults), and added logic for road, water, and transit labels (turn transit overlay on to see it in action).

[nvkelso]

@bcamper This is ready for another review, please. I've addressed the collision priority stuff you called out (and fixed the transit overlay labels in the process), but don't know how to proceed on the #277 (comment) so maybe we defer that to a later PR?

[bcamper]

Made an additional fix to the those collision priority functions -- they need to check for null first, otherwise they'll divide by null which will be Infinity instead of falling back to the desired value.

Couple other small questions about things that may have issues, but probably not significant/blocking (please do take a look though).

[bcamper]

This is just assigning an explicit order value though, is the comment incorrect? (or the code?)

[nvkelso]

Updated the comment in 1da2c65.

We moved the zoom changes server side a few releases ago so the comment was outdated. There look to be a few static int values in the scene file still. I've filed #278 to track that.

[bcamper]

Still wondering about this one.

NVK: Removed in 930a049.

[bcamper]

@bcamper This is ready for another review, please. I've addressed the collision priority stuff you called out (and fixed the transit overlay labels in the process), but don't know how to proceed on the #277 (comment) so maybe we defer that to a later PR?

Agree we can follow up on this later.

[bcamper]

You're right... those fallback values are a holdover from before all the collision_rank were moved server side and spread out with much greater detail. But something like this is still desired. If a feature has a min_zoom but no collision_rank then it should be evaluated as worst among peers of the same min_zoom.
...
I think this could be accomplished by falling back to feature.min_zoom + 0.999 and call it good?

Yep that works, made some updates in 8fdfe3b.

[nvkelso]

I fixed a noticeable regression in the style between prod and this PR by changing order of operations in the collision_priority function in eafad26, which was preventing neighbourhood labels in SF to show up at zooms less than 16 and was preventing Golden Gate Park label from showing up w/r/t roads labels, and too many "bay" labels north of San Francisco.