Filter out duplicate POIs (one from landuse AOI, one from building & etc)

[nvkelso]

Cloning this to a new issue to track down further edge cases...

I'm still seeing duplicate POIs, I think from different layers where one has an area and the other doesn't, but they have the same OSM ids. The proposed implementation is only within a single layer, do we need it to span across layers, or pack less stuff into multiple layers? (Seems like less double packing is the way to go.)
#16/37.7653/-122.4413

[nvkelso]

From @zerebubuth comment on that original issue:

I think the tile with the museum must have just not updated yet - what I see is below:

Regarding the duplicate schools; looks like they're coming from an amenity=school polygon which we put into the landuse layer and gets a label from there, and a building=school polygon which we put into the buildings layer and gets a label from there.

We have two options here:

1. Noting that this is very similar to the situation around the SFU campus, where buildings are appearing like POIs because their kind ends up being the same as the landuse polygon containing them, you had previously suggested suppressing the kind when it's the same as the landuse_kind and turn it into kind=building instead. We could do this as a separate post-process filter. (Alternatively, we could suppress the landuse polygon, but I think we'd prefer to keep the "larger" object, which is usually the landuse not the building polygon.)
2. Suppress duplicate POIs (across layers) by extending the post-processing step. This will also run into more corner cases, as we'd effectively need to define an ordering between layers so that we could choose the more important duplicate to keep.

In either case, I think it's worth tracking the follow-up as a separate issue so as not to hold up getting this, or anything merged after this, into prod.

[nvkelso]

Another example, the Lombard Motor Inn in SF as building label and as POI.

#19/37.80054/-122.42523

[nvkelso]

2. Suppress duplicate POIs (across layers) by extending the post-processing step. This will also run into more corner cases, as we'd effectively need to define an ordering between layers so that we could choose the more important duplicate to keep.

This approach smells better to me. There are going to be corner cases either way, and this option seems to allow us more determinism.

[zerebubuth]

Another example, the Lombard Motor Inn in SF as building label and as POI.

It is mapped as two separate objects, so we'll have to use a post-process de-dup filter since it's duplicated in the original data.

http://www.openstreetmap.org/#map=19/37.80074/-122.42582

• Mapped as a building with name: http://www.openstreetmap.org/way/243512088
• Mapped as a motel: http://www.openstreetmap.org/node/992609593

Arguably, these should be merged. But there's probably many, may other examples so it might be better just to leave it as-is so that we can use it as an example.

[zerebubuth]

Tracking the Lombard Motor Inn as an example of the kind of thing we want to filter out in #266.

[nvkelso]

This may be a duplicate of #266. Reevaluate once that is in dev.

[nvkelso]

Pretty sure this was a dupe.