Errors at edge of AOI

[smit1678]

At the edge of an AOI, some OSM data is not being shown in the OSM edit recency layer. These areas are also shown as poor in the completeness layer (unclear if they are related). Also unclear if these issues are coming from OSM QA tiles (I haven't investigated that yet).

cc @geohacker @kamicut

[geohacker]

@smit1678 yes these would be tiles that are skipped because they are outside the bbox, we probably need to add a buffer but that would mean we might overestimate by a small margin.

[smit1678]

Is there a reason we’re limited to bbox and not exact/simplified shape?

Nate Smith @nas_smith

---

From: Sajjad Anwar notifications@github.com Sent: Monday, May 21, 2018 11:25:49 PM To: hotosm/osma-health Cc: Nate Smith; Mention Subject: Re: [hotosm/osma-health] Errors at edge of AOI (#79)

@smit1678https://github.com/smit1678 yes these would be tiles that are skipped because they are outside the bbox, we probably need to add a buffer but that would mean we might overestimate by a small margin.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hotosm/osma-health/issues/79#issuecomment-390787845, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAwopjRqLx8RTBfoM4EL3TXYndVhNEJoks5t0zDdgaJpZM4UFvUP.

[geohacker]

Yes, because tile reduce uses a bbox to filter.

---

From: Nate Smith notifications@github.com Sent: Monday, May 21, 2018 6:15:07 PM To: hotosm/osma-health Cc: Sajjad Anwar; Mention Subject: Re: [hotosm/osma-health] Errors at edge of AOI (#79)

Is there a reason we’re limited to bbox and not exact/simplified shape?

Nate Smith @nas_smith

---

From: Sajjad Anwar notifications@github.com Sent: Monday, May 21, 2018 11:25:49 PM To: hotosm/osma-health Cc: Nate Smith; Mention Subject: Re: [hotosm/osma-health] Errors at edge of AOI (#79)

@smit1678https://github.com/smit1678 yes these would be tiles that are skipped because they are outside the bbox, we probably need to add a buffer but that would mean we might overestimate by a small margin.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hotosm/osma-health/issues/79#issuecomment-390787845, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAwopjRqLx8RTBfoM4EL3TXYndVhNEJoks5t0zDdgaJpZM4UFvUP.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hotosm/osma-health/issues/79#issuecomment-390799426, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAWr0mi3Y3XydSOR_9x-0YTyRlT3MAPaks5t0zxrgaJpZM4UFvUP.

[smit1678]

@geohacker Ok, this might be a significant issue because it's related to #80. In an area like northern Botswana where we're including southern Zambia into this (where there is also a lot of OSM coverage), numbers are way off.

[geohacker]

Agree that we may end up overestimating or underestimating. One way I can think of is using a buffer for the bbox in tile-reduce and then using the GeoJSON boundary during the analysis to throw out features that don't fall within.

[geohacker]

Oh actually, the above solution won't work in this case because we extract all buildings from a given OSM QA Tiles of a country, see here and here

This looks like a bigger QA tiles problem to me @smit1678.

[geohacker]

I got started on switching to planet QA tiles but that does cause huge over estimation. The only way to fix it would be:

1. using planet qa tiles
2. checking each building if it falls within the boundary of the country before the analysis

The work in progress PR is here but this is not very straightforward and will need a lot more time. Using the boundary inside osmlint will make the process slower by a huge margin.

The alternative approach would be stream all the buildings from osmlint through a script that checks for containment/membership and streams out the ones that are positive and then use that for analysis - this is doable, but not immediately.