Ambiguous kind values from some POIs

[nvkelso]

tl;dr

The following are still ambiguous:

• ice_creme (amenity is dominant with some shop)
• station (aerialway: station)
• winery (craft and tourism is not recommended by OSM wiki and taginfo shows basically no use even though we source that for landuse polygons)

Original report:

The following POI kind values are ambiguous by the time the end up in Mapzen tiles with respect to their OSM source data. Sometimes this is deliberate (like ice_creme), but sometimes it's not and data loss occurs. The yes stuff is especially weird – by the time it ends up in tiles, it's anyone's guess as to yes what!

• brewery
• brewery
• bus_stop
• bus_stop
• dry_cleaning
• dry_cleaning
• gate
• gate
• ice_cream
• ice_cream
• sawmill
• sawmill
• sawmill
• ski
• ski
• station
• station
• theatre
• theatre
• winery
• winery
• winery
• yes
• yes

Related:

• Order of kind coalesce sometimes funky (and "yes") #282

[rmarianski]

Is there a way that we can handle the yes values in a general way? For example, if the tag is ice_cream=yes, does it make sense to add kind=ice_cream instead?

That doesn't solve the ambiguity, but we talked about some other schemes to handle this too, either including the source tag on the feature itself, or adding a more specific kind key, eg for ice_cream=cherry we would add ice_cream_kind=cherry.

[zerebubuth]

I'm in favour of going with the same technique we're using for landuse which guarantees we know which values we're dealing with. Anywhere we're doing COALESCE(raw_column, raw_column, ...) we're potentially getting some unexpected values like "", "yes", or things which don't make much sense like kind:ice_cream in POIs because someone put aerialway=ice_cream, amenity=no on the original data.

[rmarianski]

We'd need to define the entire white list for each layer though right?

Hhmm, I thought this was going to be a lot of work, but after looking at the details a little, we're already effectively doing that to determine whether a feature should be included anyway, so we might as well be more explicit about what ends up in the kind value too. 👍 to your approach.

[zerebubuth]

Yup, another advantage is that we can be very explicit about which values we're outputting in the docs.

But the disadvantage is that it means we'd need a code / query / migration change to bring in new values rather than bringing them in serendipitously. Personally, it seems better to be sure about what we're serving up, and that we're not egregiously misclassifying stuff.

[nvkelso]

👍 for moving into the functions – essentially adding a mz_calculate_poi_kind to parallel the existing landuse kind calculation? That could also hugely simplify the mz_calculate_poi_level function (so it'd be a kind lookup, not all the details about where it came from).