Egregious flickering between parking lot AOIs and church AOIs in Phoenix

[nvkelso]

z-order fighting was epic and epileptic along the highway by the Phoenix Mountain Preserve on Tangram ES in Eraser Map master-907. Happened again while at the airport.

https://www.openstreetmap.org/edit?#map=18/33.57197/-112.02500

/#18/33.57174/-112.02592

[nvkelso]

This looks to be a data problem (both have sort_key of 4):

From: http://vector.mapzen.com/osm/all/18/49496/105094.topojson?api_key=vector-tiles-HqUVidw

{
"arcs":
[
[
7
]
],
"properties":
{
"area":
22829,
"id":
61155897,
"kind":
"place_of_worship",
"min_zoom":
10.0167,
"religion":
"christian",
"sort_key":
4,
"source":
"openstreetmap.org"
},
"type":
"Polygon"
},
{
"arcs":
[
[
8
]
],
"properties":
{
"area":
5894,
"id":
63919565,
"kind":
"parking",
"min_zoom":
10.9935,
"sort_key":
4,
"source":
"openstreetmap.org"
},
"type":
"Polygon"
}

[nvkelso]

In app screenshots of the church area:

[nvkelso]

Z fighting alsoat the Phoenix airport (below). This one might be more complicated as building parts are involved? /cc @bcamper

18/33.43562/-111.99794

[nvkelso]

@bcamper and @blair1618 I thought we had "fixed" this be resolving to the a-z sort order of the layer names when the layers (features) are at the same z-index in Tangram?

I had filed this vector tile issue a while ago, thinking the Tangram fix alone would work. Related is https://github.com/mapzen/vector-datasource/issues/504.

[nvkelso]

Reviewing other screenshots from the trip, looks like parking lots in shopping malls are also affected:

[matteblair]

The "collision resolution" we added doesn't prevent features from being set to the same order. It's very hard to automatically determine whether two features will overlap and have the same order, the best way to resolve this right now is in the stylesheet. On Feb 16, 2016 1:30 AM, "Nathaniel V. KELSO" notifications@github.com wrote:

Reviewing other screenshots from the trip, looks like parking lots in shopping malls are also affected:

[image: screenshot_2016-02-14-16-52-09] https://cloud.githubusercontent.com/assets/853051/13068793/af0cab40-d433-11e5-84df-ceda386c5599.png

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

[nvkelso]

@zerebubuth it sounds like https://github.com/mapzen/vector-datasource/issues/364 needs to be acted on after all :/

[nvkelso]

@blair1618 We have dozens and dozens of landuse AOI types alone, so to resolve this we'd either need to smartly pack (calculating on the server) custom z-orders per tile depending on what's in the tile (hard), or widen up the sort_key values sent from the server from around 5 now to one per each landuse kind (easier). How many indexes values can we use safely? And are those distinct from the text priority values (I think they are, but that number's been growing in the scene file recently)?

[matteblair]

There should be enough usable range in orders to add spacing on the order of 5 units. Order is usable up to very large values (on the order of 5000) as long as there is no feature geometrically beneath another feature of a lower order. For example, an extruded building of order 50 sitting on a landuse of order 500 is going to cause problems (the building may be covered).