Ambiguous landuse values (from different OSM keys)

[rmarianski]

There are situations where the kind value doesn't have the most appropriate tag's value in it. We should also return back the value that is in the landuse tag on the feature to help with these situations.

[rmarianski]

@nvkelso we discussed a separate approach offline too where we could expand the possible values in the kind to capture this. For example: kind=station (power)

When it's ambiguous, do we want to include the source tag, in this case landuse? Or, add more kind values?

[nvkelso]

I'm starting to lean towards kind=station_power where we postfix the original key namespace. Do we do this all the time (no, this would break the simplicity of coalescing into kind), only when there are known collisions (yes). But do we force the postfix on all confusing values, or not on the dominant usage and only on the minor usages? Adding it only for the minor usages seems less like is more of a feature (and wouldn't regress existing stylesheets and cause issues for customers).

@zerebubuth What are your thoughts?

[zerebubuth]

If we prefix the kind with the original key and then separate the key and value with an = then we haven't lost any information 😉

I guess the best solution to any of this is to come up with a single, unique string to represent every feature that we want to pull in. That's going to be a bunch of work, which is why I think it might be easier to just stick with the OSM key=value pairs.

[nvkelso]

Another example where playground should loose out to pier:
http://vector.mapzen.com/osm/all/19/154336/197070.topojson?api_key=vector-tiles-HqUVidw

[nvkelso]

Most of this was done via other commits.

The one actionable item from this issue if for power stations, which was elsewhere changed to export {kind: substation}. Closing this in favor of new issues with specific problems.

I see pier but no playground in tile commented Oct of last year.