Hi rmikke, sorry that it took me a while to get back to your questions. 1. Right now we are using the user “verbal” feedback to improve the models and the post-processing; we are not tracking the roads “deleted” by the users in RapiD. If there is an area where AI could be improved, let us know. 2. Switching between the different data sources would be great. Unfortunately, the image processing right now is relatively slow and costly, so we have to pre-compute it and can’t do it on the fly. I agree it sounds like a natural way to expand our work in the future.

Hi geow, thanks for the feedback – you are right, there are some false-positives in RapiD (dry river beds, canals, narrow beaches, glacier cracks); this is why we built it to make sure ML data is only a suggestion and the user is in charge to make the final decision. We are working on improving the models, but it’s a pretty challenging task!

Hi Maning, thanks a lot for the feedback. Tag prediction turns out to be quite hard, partly because the mapping communities in the different parts of the world could take different approaches to tagging (in particular, the difference between “residential”, “unclassified” and “track” could be subtle). I personally see the on-the-fly validation as an area where the algorithmic methods could provide very good insights and flag the potential issues at the very early stages of mapping.

Hi Joseph E – to be clear, we do not have highway=residential by default; we are using similar ML methods in order to predict highway tags – and it seems that it’s the most common type the model predicts for the published dataset. We are actively working on making the predictions better; the fundamental complexity coming from the fact the road types often depend on the local context.

For the low quality / low res / cloud coverage the answer is pretty simple – when we can’t find the roads with the high probability, we just don’t show them.

Thank you for the suggestions to handle the imagery offsets; this is a really hard question to handle in the general way, especially since we are mostly mapping the areas of the world with no GPS traces or offsets uploaded to OSM.

Hi 4004, you are right, mapping offsets is a hard problem to address. Our current approach is to minimize any change to the existing OSM data, so our algorithms behave very similar to what the human user would do – generate the roads for a particular satellite image layer, and merge it with the existing data.

Hi rorym, the quality of the mapping contributions is our major priority; this is why we built in the validation panel to inform the user about the potential issues, and the list of the checks could be expanded in the future. We are also making sure the accidental “bulk” uploads are impossible – the user has to manually select the roads one-by-one from the magenta layer and click “use this feature” in order to start working with it.

As for the mapping speed, I’d be very careful to do any general statements about the mapping speed-ups and speed comparisons – as you mention, it’s widely varies with the mapper’s skill and tools/shortcuts used; so making apple-to-apple comparisons are hard. This is one of the reasons why limiting the user uploads purely on the quantitative basis is a tricky problem – and from what I know, no other tools use it. We strongly believe that the best way to improve the quality of the contributions is to provide on-the-fly validation, reduce the task size, etc.

So fundamentally, I think that we can build the tools that both simplify the mundane tasks and improve the quality of the mapping contributions at the same time.

Good point. Basically, we would like to provide the support for the unexperienced mappers too; and auto-detecting the road type (when done correctly) is one of the possible ways of doing it.

We are planning to publish more mapping areas when the current round of bug fixes and feedback processing is done; hope you’ll be able to test RapiD on a wide range of terrains.

Thank you for looking into the details, geocruizer! To answer your questions: - It could be either original ML model failing to pick up the roads (hard to fix), or the post-processing issues (easier to fix). If you give me particular lat/lon, I can look into the details. - There are several things that we do at the road intersection – in particular, we try to minimize introducing the new nodes to OSM, and sometimes snap the intersection to the existing nodes. There are a couple of known issues with this strategy; we are looking into it how to improve it. - Catching the road intersections with the unmapped buildings is tricky; perhaps we should do a joint building/road detection process in the future. - Improving our road type prediction is one of the closest goals, since it’s one of the most confusing things for many mappers we talked to. The issue is that the road type often depends on the local context that could change from country to country. - we do most of the pre-processing off-line (because it’s quite resource-consuming), while RapiD conflates with the current version of OSM on the fly.

Hope it helps – and thank you for the constructive feedback and your kind words!

Thank you for the detailed feedback, mikelmaron!

We are currently investigating the ways of getting user feedback into the loop – fundamentally, each road we generate has an associated “confidence”, and in the future we can adjust the threshold based on the user feedback.

The spurs and junctions are exactly the issues we are fixing right now; here is the list of most common bugs: https://mapwith.ai/doc/training.html#bOQACASDXJG

Hi MarTintamarre, I am Danil Kirsanov; working with Drishtie on this project. Thank you for the idea! Mapping the buildings sounds like a natural continuation of this work; we are thinking about looking into.