facebook / Rapid

The OpenStreetMap editor driven by open data, AI, and supercharged features
https://rapideditor.org
ISC License
517 stars 91 forks source link

Suggesting already submitted buildings #592

Closed kauevestena closed 2 years ago

kauevestena commented 2 years ago

Description

Hello Chris and RapID Team!! First of all, congratulatiions for the amazing work!!

I've submitted some edits, then the RapiD suggested again already mapped buildings, so it has been flagged as "building crosses building" as in the screeshot attached!

bug report

Fondly, Kauê Vestena

Version

2.0-alpha

What browser are you seeing the problem on? What version are you running?

Firefox v105.0

Steps to reproduce

The browser URL at the time you encountered the bug

https://mapwith.ai/rapid-v2-alpha#background=Maxar-Premium&datasets=fbRoads,msBuildings&disable_features=boundaries&map=20.47/-25.29910/-49.30551

Bonkles commented 2 years ago

Ah, this is expected behavior. It takes some time for the new building to flow into the OSM backend, and then it takes a bit of time for our conflation system to catch up(the conflation service is what decides, in the background, whether a RapiD building already exists or not and whether to show it to the user).

So, if you submit a building, there is a window of time where the edit you suggested will actually appear as an OSM feature and also in our RapiD layer. We don't really have a great answer for this as of now, there will always be a bit of lag before our conflation service 'catches up'.

May I ask how long you are waiting between submitting the buildings and then checking the same area of the map again? Is it immediately after? A few minutes/hours after? Anyway, clicking on the same area of the map now, I see that there are two OSM buildings, and the RapiD service isn't suggesting them anymore:

image
StephanGeorg commented 2 years ago

https://github.com/facebookincubator/RapiD/issues/601

kauevestena commented 2 years ago

@Bonkles well, I did never noticed this behavior at the old RapID...

About your question, it was really right after, on the mentioned one. But at the first time I've noticed, it may took 5 minutes or so, i'm not certain about the precise timing...

StephanGeorg commented 2 years ago

I noticed this in both versions as mentioned in #601 but this happens since ~ one or two weeks.

May I ask how long you are waiting between submitting the buildings and then checking the same area of the map again? Is it immediately after? A few minutes/hours after?

It is definitely minutes, in some cases it was more than 15mins. I also tried hard refresh, closed browser, ... but didn't help so a gave up editing.

Bonkles commented 2 years ago

Update: this is definitely NOT expected behavior. I suspect our service is caching OSM Data that it shouldn't be. Therefore, when it conflates against newly added buildings, it's still generating buildings and sending them to rapid according to stale OSM data.

We have opened a priority investigation into this and will report back.

Bonkles commented 2 years ago

Investigation started:

I submitted a single building in RapiD City, SD, via URL https://mapwith.ai/rapid#background=EsriWorldImagery&datasets=fbRoads,msBuildings&disable_features=boundaries,past_future&map=18.17/44.10224/-103.20913

image

THe screen repainted after the submission, and no duplicate rapid building was observed.

I then loaded the same area in safari, that worked fine too- no dupe buildings.

It looks like this may be a difficult one to reproduce.

StephanGeorg commented 2 years ago

I just tested it right now and it worked with v1.1.9 and v2-alpha. Maybe it was a performance issue because of high load to OSM servers?

Bonkles commented 2 years ago

Thank you @StephanGeorg we were about to ask if you could reproduce the issue. We suspect that load to OSM or unavailability to OSM could be causing this- we fail back to Overpass if OSM is unresponsive, and if overpass hasn't ingested the changes yet from OSM, it could cause this behavior.

We re hatching a plan to provide the user with a hint of when conflation goes 'wrong' and wasn't able to get information from OSM in a timely fashion. This should hopefully provide a better UX and let you know when we think something went wrong.

We will also put some better logging into our back-end service so that we can pinpoint the exact time(s) when these conflation requests have to resort to overpass downloads.

StephanGeorg commented 2 years ago

Sounds great.

Thanks a lot for RapiD and all your work on this. It's really amazing.

Bonkles commented 2 years ago

Closing this one out, we'll take up the improvements in issue https://github.com/facebookincubator/RapiD/issues/602.