New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ambiguous kind values from some POIs #532

Open
nvkelso opened this Issue Feb 19, 2016 · 7 comments

Comments

Projects
None yet
3 participants
@nvkelso
Member

nvkelso commented Feb 19, 2016

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:

@rmarianski

This comment has been minimized.

Show comment
Hide comment
@rmarianski

rmarianski Feb 19, 2016

Member

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.

Member

rmarianski commented Feb 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zerebubuth

zerebubuth Feb 19, 2016

Member

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.

Member

zerebubuth commented Feb 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@rmarianski

rmarianski Feb 19, 2016

Member

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.

Member

rmarianski commented Feb 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zerebubuth

zerebubuth Feb 19, 2016

Member

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.

Member

zerebubuth commented Feb 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nvkelso

nvkelso Feb 19, 2016

Member

👍 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).

Member

nvkelso commented Feb 19, 2016

👍 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).

@nvkelso nvkelso referenced this issue Feb 23, 2016

Closed

Add new POIs for Women's Day #526

6 of 6 tasks complete

@nvkelso nvkelso added this to the v0.9.0 milestone Mar 11, 2016

@nvkelso nvkelso added ready and removed ready labels Mar 14, 2016

@nvkelso nvkelso modified the milestones: v0.10.0, v0.9.0 Mar 16, 2016

@nvkelso nvkelso self-assigned this Mar 30, 2016

@nvkelso nvkelso added the loe medium label Mar 30, 2016

@nvkelso

This comment has been minimized.

Show comment
Hide comment
@nvkelso

nvkelso Mar 30, 2016

Member

yes and yes should be done as of v0.9 :)

Member

nvkelso commented Mar 30, 2016

yes and yes should be done as of v0.9 :)

@nvkelso nvkelso modified the milestones: v1.0.0, v0.10.0 Apr 4, 2016

@nvkelso nvkelso added the in review label May 18, 2016

@nvkelso

This comment has been minimized.

Show comment
Hide comment
@nvkelso

nvkelso Aug 29, 2016

Member

We fixed most of this along the way. The outstanding items are:

  • 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)

None of these is a ship block for v1 tiles so moving to v1.1 milestone.

Member

nvkelso commented Aug 29, 2016

We fixed most of this along the way. The outstanding items are:

  • 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)

None of these is a ship block for v1 tiles so moving to v1.1 milestone.

@nvkelso nvkelso removed their assignment Aug 29, 2016

@nvkelso nvkelso modified the milestones: v1.1.0, v1.0.0 Aug 29, 2016

@nvkelso nvkelso removed the in review label Sep 8, 2016

@nvkelso nvkelso modified the milestones: v1.2.0, v1.1.0 Dec 28, 2016

@nvkelso nvkelso modified the milestones: v1.6.0, v1.7.0 Sep 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment