Whole Foods building kind_detail should be set to supermarket

[nvkelso]

Instead it's being set to building?

https://www.openstreetmap.org/way/194906343
http://vector.mapzen.com/osm/all/18/41920/101345.topojson

Tags

building    yes
name    Whole Foods Market
shop    supermarket

[nvkelso]

Same thing true for Foods Co:

• http://vector.mapzen.com/osm/all/17/20965/50665.topojson
• https://www.openstreetmap.org/way/25821952

And Costco:

• http://vector.mapzen.com/osm/all/17/20967/50664.topojson
• https://www.openstreetmap.org/way/43100828

[nvkelso]

Interesting: if building=supermarket in set in OSM, that does come thru. But not the value of shop.

• https://www.openstreetmap.org/way/78376265

[zerebubuth]

This was the intended behaviour, from previous discussions.

Would you like to change, e.g:

• Something tagged building=yes + shop=supermarket to have properties kind: supermarket? (Currently would be kind: building + shop: supermarket)
• Something tagged building=yes + amenity=theatre to have properties kind: theatre? (Currently would be kind: building + amenity=theatre)

Or perhaps the same as above, but including the original shop/amenity as well? What would we do when we have different building tags, e.g: building=office + shop=gift - would that become kind_detail: gift + building=office? (+ shop=gift also?)

[nvkelso]

Yeah, this is case case 7 in that earlier issue. Copying that text here:

7. a building with landuse and restaurant tags has building=yes, landuse=retail, amenity=restaurant and name=. This should result in a building polygon in the buildings layer with kind=building and a point in the POIs layer with kind=restaurant and name=. The landuse value for this building is ignored, although it may get landuse_kind from being enclosed in another landuse polygon anyway.

For this blog post, we're finding a lot of buildings that are tagged with building=supermarket that end up in tiles as kind_detail: supermarket, but as many buildings that have building=yes + shop=supermarket where it just ends up as a generic building in tiles and they sit next to each other in tiles producing inconsistent coverage when the data would support a more consistent coverage.

This isn't priority for an immediate fix (it's not critical to any upcoming blog posts, and it's not tied with active styling work).

[zerebubuth]

Case 7 is implemented accurately at the moment, as it says that something tagged building=yes should have a polygon in the buildings layer with kind_detail: building. Am I understanding correctly that you want to change the behaviour to the following?

7. a building with landuse and restaurant tags has building=yes, landuse=retail, amenity=restaurant and name=*. This should result in a building polygon in the buildings layer with kind=restaurant and a point in the POIs layer with kind=restaurant and name=*. The landuse value for this building is ignored, although it may get landuse_kind from being enclosed in another landuse polygon anyway.

Or, analogously for supermarkets:

7b) a building has shop=supermarket, building=yes, landuse=retail and name=*. This should result in a building polygon in the buildings layer with kind=supermarket and a point in the POIs layer with kind=supermarket and name=*. The landuse value for this building is ignored, although it may get landuse_kind from being enclosed in another landuse polygon anyway.

7c) a building has shop=supermarket, building=supermarket, landuse=retail and name=*. This should result in a building polygon in the buildings layer with kind=supermarket and a point in the POIs layer with kind=supermarket and name=*. The landuse value for this building is ignored, although it may get landuse_kind from being enclosed in another landuse polygon anyway.

[nvkelso]

We'll need this for a design @sensescape is sketching.

[nvkelso]

Subtask of #1348.

[nvkelso]

Scoping this to just be a hack for way derived POIs and building kind_details (versus a spatial intersection). So when there are multiple representations of the same OSM feature, we'll either take the tag value of building=* (when it's valid), else we'll fall back to the poi representation's kind calculation.

[nvkelso]

Verified, ready for prod.

[nvkelso]

This is working in "prod" Nextzen endpoint, closing.