Does the feature overlap with another feature

[bkowshik]

• Per voice with @geohacker and @amishas157
• Ref: Using context for detecting harmful features #112, Flag stray lakes #108

---

As part of the context based validation, this compare function will flag suspeciously overlapping features. A couple of examples we have seen in the recent past are:

• https://osmcha.mapbox.com/46963151/

Lake in Manhattan overlapping existing buildings.

• http://osmcha.mapbox.com/45536604/

A residential area becomes a Park for what looks like a Pokemon mapper.

In scenario's like ^, the feature that was created/modified overlapped quite a lot of existing features on OpenStreetMap, which being the context of where the feature will actually be. It is super important to detect features like these and correct them as soon as possible as they affect the very looks of the map. Ex:

Residential areas rendered as lake and park due to harmful edits.

---

Workflow

NOTE: Focussing on just new/updated water bodies in iteration 1 to keep our focus narrow.

1. A new lake or an existing lake gets edited on OpenStreetMap.
2. Calculate all map tiles (xyz) that cover the lake.
3. Download vector map tiles from Mapbox API, convert to a FeatureCollection with all features in the tile.
4. Check if new/modified lake overlaps with any feature in the FeatureCollection and flag if there is a suspecious overlap.

Uncertainities

• What zoom level tiles should be downloaded from the API
  • Tile at lower zoom levels don't have all the data. Ex: Buildings generally show up in tiles greater than zoom 15
• There could be good overlaps too. We need to differentiate between a good and a harmful overlap.
• Lakes and parks features fit this use-case well. What other feature types can something like this handle?

---

cc: @planemad @manoharuss

[srividyacb]

Found two more cases where overlapping feature were bad edits

1. https://osmcha.mapbox.com/47340745/
2. https://osmcha.mapbox.com/47340745/

[amishas157]

Working over this issue here: #135. It's based on the workflow described by @bkowshik ^

Tracking down the issues which are coming by:

• For relation type features, we get the bounding box of the relation and not the proper geometry. Therefore, we use individual relation members which are part of that relation to find any overlap with the existing features and also making sure it should not flag overlap members from the same relation

• Another issue which came by was closed ways geometry. So as these are not polygons , therefore it would be impossible to find feature with which it shares same osm area. To deal with that, we polygonized these kind of geometry in changeset-parser based on condition if it has id-area-key. Ref.

• Recently there was another issue of feature finding overlap with itself. And this is caused due to lag with a feature going to mapbox-streets and same feature coming this pipeline for processing. As if the formed happens early than the latter, then a feature would be flagged for overlapping with itself. To curb that from happening , we ignore the cases of feature overlapping with itself.

[bkowshik]

• http://osmcha.mapbox.com/47878397/
• A waterway created very close (almost touching) a highway.

[amishas157]

Working in this PR : #135
Closing the issue