Missing the sort_order on landuse labels

[nvkelso]

http://vector.dev.mapzen.com/osm/all/15/5235/12671.topojson?api_key=vector-tiles-HqUVidw

http://vector.mapzen.com/osm/all/15/5235/12671.topojson?api_key=vector-tiles-HqUVidw

landuse_labels: {
type: "GeometryCollection",
geometries: [
{
type: "Point",
properties: {
name:fa: "دانشگاه ایالتی سان فرانسیسکو",
kind: "university",
name: "San Francisco State University",
area: 1003630,
sort_key: 4,
name:pt: "Universidade Estadual de São Francisco",
label_placement: "yes",
source: "openstreetmap.org",
name:fr: "Université d'État de San Francisco",
name:ru: "Университет штата в Сан-Франциско",
min_zoom: 9,
id: 28965902,
name:es: "Universidad Estatal de San Francisco"
},
coordinates: [
613,
698
]

The new version on dev is missing the sort_key.

[zerebubuth]

Looks like this is because we de-duped a bunch of stuff and now (after #201), the university is ending up in the POIs layer instead. This seems right to me, but we don't have a sort order like we do for landuse.

Here's a list of the top 100 kinds of POIs on my local North America database. @nvkelso, can we make a sort_key lookup like we have for landuse? What should it look like to begin with?

[nvkelso]

@zerebubuth When we dedup do we merge property key/values from the looser onto the winner? Should we? We started talking about this (for area) in #348.

Inventing new sort order for POIs seems like a separate chunk of work (and we should research it's utility in Tangram), tracking that with new #360.

[zerebubuth]

We don't, currently. At the moment, the most important feature is left as-is, and any less important ones are simply removed.

Merging feels like it could be quite a minefield. For example, if we needed to merge a less important item with a secondary tag onto a more important one of a different kind, do we merge that? Do we have a whitelist of "universal" tags like area, name:*?

For the sake of something more concrete, imagine that there's a school POI with kind=school and we merge that with a nearby playing field of the same name kind=pitch, sport=baseball, we presumably don't want to merge that to get kind=school, sport=baseball - that's just confusing.

Some tags we might want to merge in other ways. For example; the sport example, we might want to merge adjacent tennis courts and baseball pitches as sport=[tennis,baseball], but we might want to merge adjacent polygonal features such as buildings or parks by summing their area (and volume) to reflect that they represent more than one feature. In that case, we'd have to be careful; it's easy to imagine that a merged feature at zoom N with area A+B might pass client-side filters, whereas at zoom N+1 they might not reach the server-side threshold for merging and A, B by themselves might fail the client-side filters and disappear, only perhaps to reappear at the next zoom level.

It seems to me that merging is pretty hard, and perhaps we should think a bit more about all the possible corner cases before attempting it.

[nvkelso]

Getting proper areas for POIs is covered over: #348.

[nvkelso]

Process changed.