OpenStreetMap

As some of you might know, Facebook has been using machine learning algorithms to help human mappers edit and validate geometry faster. Over the past year, we have completed mapping all the roads in Thailand and most of Indonesia. Watch the video below to see the progress.

Video on Thailand Mapping

Based on this work, many NGO’s, local communities, and tech companies have requested the data, which we have been sharing when available, like we did for last year’s Kerala Floods to help with disaster response. In the case of disasters, many enthusiastic OSM volunteers offer up their time to help fill in an area’s missing data. However, new volunteers often encounter two challenges: it’s hard to get started quickly and there’s a steep learning curve to master high-quality edits. To address these challenges, we’ve created a version of the primary OSM iD editor that we call RapiD to helps every mapper make edits quickly using roads suggested by our Map With AI service. It also has strong integrity checks to ensure edit quality. Special thanks to the original makers of the iD tool for building an incredible foundation.

In a previous diary, we shared our internal workflow for mapping using AI. Since that time, we have made some significant changes in order to allow greater accessibility and simplicity when working with the data. These enhancements and simplifications have coalesced into the current version of the RapiD editor. Over the next few weeks, we are happy to announce that we’ll start testing RapiD using the Humanitarian OpenStreetMap Assisted Mapping for Good Tasking Manager with selected partners to gather critical feedback. Based on that feedback, we will be exploring the possibility of opening the RapiD editor source code and how-to service documentation to the entire OSM community.

With or without AI assistance, mapping is a time-consuming process. It took our internal mapping team about a year and half to map all of Thailand, even with the AI roads speeding up the editing process. To improve global OSM coverage at a faster pace and in a more collaborative manner, we believe the best way to move forward is to team up with the whole OSM community and create tools that empower every mapper.

After spending a lot of time researching the mapping techniques and preferences of various OSM communities, we decided it was best that we change our workflow. While Facebook mappers have over a month of training to ramp up before they start making live edits in the map, this is not true for most other mappers. So, we focused on two major changes:

  • First, we needed to make our roads available on-demand for users. Our original process used static XML files that offered less flexibility in terms of task size and had to be uploaded all at once.Often times, OSM users only partially map an area and will upload frequently so as to not lose their edits.
  • Second, we needed to build a tool that was accessible and familiar to OSM users. The previous version of our internal iD fork was highly customized for mapping AI roads, but this came at the cost of different styling and hotkeys from official iD. Users would have been forced to relearn iD instead of just hopping in and immediately understanding what they saw. So, we worked closely with the developers of the original iD team to re-factor and created the RapiD editor, porting many integrity changes to both versions.

RapiD Editor

RapiD takes all the power of our AI-assisted mapping and makes it accessible to all levels of users. Upon opening a task area, the user will be presented with an additional RapiD Assist layer in magenta. These magenta ways are road predictions that a user can choose to add to the map. To avoid causing data errors, the predicted ways will automatically crop themselves at task edges. Furthermore, a round of real-time conflation is done to make sure they do not duplicate existing OSM roads. Any predicted road not specifically chosen for inclusion by the user will not be uploaded.

image_RapiD.png

To use RapiD, a user selects a road then clicks “Use This Feature” to bring the predicted way onto the map. From there the feature is like any other newly digitized road and can be further edited as needed. add_ML_road.gif

If an editor decides they don’t want to use the predicted road, they can mark “Remove This Feature” to make it disappear. remove_ML_road.gif

To aid in tagging these newly created roads correctly, we have added a hotkey to cycle through the most common road tags. tagging.gif

The AI layer can be toggled on and off as needed. turn_off_ML.gif

So how do we actually generate roads from satellite imagery?

We use a type of machine learning called a Deep Neural Network segmentation model that we run against satellite imagery. The actual output of this is an image giving the probability of each pixel being part of a road. Bright magenta means there is high confidence of the pixel being a road, while transparent means there is low confidence. For a much more in depth look at this subject, check out our DeepGlobe Challenge website or research paper. Screen Shot 2019-05-08 at 11.50.31 AM.png

Once we generate this magenta output layer, we convert it from a raster image into a vector data format. Then we conflate this vector data with OSM and drop any predicted roads that already exist in OSM. The magenta roads available in RapiD are the final result of this post-processing. Screen Shot 2019-05-08 at 11.51.15 AM.png

Ensuring Data Quality

Official iD now has a powerful built-in validation panel, which was the result of a collaborative effort among a group of iD developers, including engineers from the Facebook Maps Team. RapiD incorporates this panel and adds a set of additional checks that are specifically relevant to our AI data.

Short road checks look for roads that may need extension or deletion. short_way_checks.png

We have enhanced the disconnected road check to check when a newly-added cluster of roads is disconnected from the already existing road network. This enhancement has also been integrated into the latest release of the primary iD editor.

Isolated_clusters_check.png

Additionally, we have created a hotkey to let users track where they have edited ways. When toggled on, the segments of a way that have been modified will turn green as well as the entirety of any AI road added. This gives users far more visual clarity on what they have and have not touched while editing than is currently possible in iD. edited_roads_hotkey.gif

Now that you know more about what RapiD does, you might enjoy this comparison video of manual mapping in iD versus using the Map with AI service in RapiD.

Mapping Speed Comparison Using RapiD

Data Integrity and tracking our edits

To further ensure the quality during this process, we will be running a number of tracking tools daily to check on the changesets submitted to OSM through the RapiD editor. This includes the OSMCha flags, KeepRight and OSMOSE. At this beginning stage, all data issues will be reviewed by the Facebook internal mapping team and fixed accordingly. Eventually, we intend to build a project issue tracking system into Tasking Manager 3 to allow a more integrated approach to data validation.

The indicators to track changesets submitted through RapiD are these tags:

  • on each feature: source=digitalglobe, AND;
  • on each changeset: created_by=RapiD (version number)

How to reach the team

  • You can e-mail the team at osm@fb.com
  • Profiles for some of the team members
  • We have created a #mapwithai_feedback slack channel on OSM US. Members of the team will be available to answer questions immediately during these time below.
    • Friday 31st May - 11:30am-12:30pm PST
    • Tuesday 4th June - 9am-10am PST
    • Thursday 7th June - 11am-12pm PST
    • Monday 10th June - 9am-10am PST

We look forward to sharing the feedback and findings of our testing phase. Stay tuned for more!

Discussion

Comment from jharpster on 29 May 2019 at 18:26

Great work DrishT! Nice to see the continued contributions to OSM from the mapping team at Facebook.

Comment from Omnific on 29 May 2019 at 20:10

What a great tool! Hope this is released for all, as this might even help mapping in the US (West Virginia is a great example).

Comment from DrishT on 29 May 2019 at 20:20

Thanks Omnific! We do plan to release it for all. After our internal testing we still wanted to test it out more for the next few weeks to make sure its bug free :)

Comment from Greg_Rose on 29 May 2019 at 20:41

droool Love the new validation panel/tools in iD… this new ML version looks FANtastic!

Comment from maning on 30 May 2019 at 02:32

❤️

Comment from Aury88 on 30 May 2019 at 05:44

why not put the “source” tag on the changeset instead of the single feature?

Comment from @lex99 on 30 May 2019 at 16:10

Will the data processed by RapiD still be open source ?

Comment from DrishT on 30 May 2019 at 17:17

Hello Aury88, Great question! Last year we were asked by some community members to identify data coming from us to be more specific, so we decided to tag features along with changeset comments. It makes for easier tracking.

Current changeset comments include: * created_by - RapiD 0.9.0 * hashtags - #MapWithAI * imagery_used - Facebook’s Map With AI - Maxar Imagery

Lex99, thank you for checking on that. The data produced by the AI model, that can be uploaded to OSM via the RapiD editor is open.

Comment from MarTintamarre on 31 May 2019 at 09:16

Congratulations to you and your team, looks very promising! Are you (or do you know if other people are) planning to do a similar work on buildings pre-mapping? I’ve seen a huge number of companies and researches working on that, but none were close to operational use like you are here for roads…

Comment from kirsanov on 31 May 2019 at 18:57

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.

Comment from mikelmaron on 3 June 2019 at 20:50

@DrishT fascinating process. It definitely felt helpful to be getting hints on the 2 dozen road network gaps in a very dense settlement. The editing experience was great.

Ended up using Bing some, since the imagery was well aligned and looked more clear, in places where needed to look closely if roads went through.

There were also a handful of false positives and paths not identified. Curious to learn how the validation process goes, and if the feedback on what’s used and what’s not is used to further refined the learning model.

In some cases, it was a bit in between – most of the road was correct, but there was a spur that needed to be deleted, or a junction wasn’t quite connected to the network correctly (which was nicely picked up by the iD validator)

Comment from kirsanov on 4 June 2019 at 14:50

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

Comment from geocruizer on 6 June 2019 at 20:28

Wow this is so cool, huge time saver. A few immediate comments are:

  • No all roads were picked up and it’s unclear to me why as they visually all looked the same. Why are certain segments picked up and others are not?

  • Not sure the system is snapping every intersection. Is there a snap tolerance?

  • I did notice road lines being drawn over buildings in the image (where small building clusters/villages were). The buildings themselves were not mapped.

  • Having road tag info readily available would be nice. Even if basic attributes such as “paved vs unpaved”

  • I’m assuming the road vectors have been preprocessed and RapiD is not doing this on the fly?

Nice work overall. Excited to use this tool more.

Comment from kirsanov on 7 June 2019 at 14:28

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!

Comment from Greg_Rose on 7 June 2019 at 16:34

As other have said, noticed predicted roads going over some bldgs. Also - why can’t it just give me an untagged line, instead of a residential road? Otherwise, very nice so far - would like to put it through some jungle territory in DRC for instance, and see how it does!

Comment from kirsanov on 7 June 2019 at 18:03

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.

Comment from amapanda ᚛ᚐᚋᚐᚅᚇᚐ᚜ 🏳️‍🌈 on 8 June 2019 at 07:15

Impressive tech! Well done on releasing this. We need more people making interesting software for OSM. The video of “iD vs RapiD” is impressive. a ✕2.6 speed up is nothing to sneeze at!

I have a concern that people will not spend as much time reviewing the data as in this video, and aim to do things ✕10 or ✕20 times faster by just accepting everything. A demo video where everything is manually reviewed, but a reality where it’s a data import is not fair. Have you considered this problem and any ways to fix it? Would a software enforced maximum upload/mapping rate help prevent that problem?

✕2,6 is certainly an improvement, but comparing it to iD might not be great. JOSM is built to have a steeper learning curve, but to allow experienced users to work faster. Have you timed how long an experienced JOSM user could map that area?

Comment from NunoCaldeira on 9 June 2019 at 10:22

It’s funny that Facebook creates an editor and does not attribute OpenStreetMap in every map (static, thumbnail. browsable) that contains OSM data and comply with ODbL 4.3:

“4.3 Notice for using output (Contents). Creating and Using a Produced Work does not require the notice in Section 4.2. However, if you Publicly Use a Produced Work, You must include a notice associated with the Produced Work reasonably calculated to make any Person that uses, views, accesses, interacts with, or is otherwise exposed to the Produced Work aware that Content was obtained from the Database, Derivative Database, or the Database as part of a Collective Database, and that it is available under this License.”

You are in brech of ODbL by not complying as in 9.1: “9.1 Any breach by You of the terms and conditions of this License automatically terminates this License with immediate effect and without notice to You. For the avoidance of doubt, Persons who have received the Database, the whole or a Substantial part of the Contents, Derivative Databases, or the Database as part of a Collective Database from You under this License will not have their licenses terminated provided their use is in full compliance with this License or a license granted under Section 4.8 of this License”

Worst is Facebook is setting a TERRIBLE example of how to use Open Data without following it’s guidelines.

You are using Mapbox services, which Terms of Service https://www.mapbox.com/tos/ under 10, requires attribution to remain intact: “you will display our required branding and attribution, including all links, when you use the Services, as outlined in our documentation” and the documentation heads to https://docs.mapbox.com/help/how-mapbox-works/attribution/ which states (and notice the word STRICTLY): “The text attribution contains at least three links: © Mapbox, © OpenStreetMap and Improve this map. This attribution is strictly required when using the Mapbox Streets tileset due to OpenStreetMap’s data source ODbL license.”

And by the way, thanks for never replying to my email of 6th of December 2018, as we started exchanging emails on my initial request for facebook to attribute the maps on the 25th of August of 2018. Yes that’s 9 months, in 270 days and Facebook still didn’t manage to add a simple “© OpenStreetMap contributors” and comply with the required attribution as mentioned on https://www.openstreetmap.org/copyright “We require that you use the credit “© OpenStreetMap contributors”.”

I truly hope a lot of OpenStreetMap contributors sue Facebook, as they only granted their data to OpenStreetMap Foundation to be used under ODbL, as in the contributor terms 3 https://wiki.osmfoundation.org/wiki/Licence/Contributor_Terms “3. OSMF agrees that it may only use or sub-license Your Contents as part of a database and only under the terms of one or more of the following licences: ODbL 1.0 for the database and DbCL 1.0 for the individual contents of the database; CC-BY-SA 2.0; or such other free and open licence (for example, http://www.opendefinition.org/okd/) as may from time to time be chosen by a vote of the OSMF membership and approved by at least a 2/3 majority vote of active contributors. “

I hereby publicly request the OSMF, as the Licensor under ODbL 9.4 c) to notify Facebook and remove their rights under ODbL, if the violation is not fixed after 30 days of notice.

An email with this content will be sent to the individual members of the Board of OpenStreetMap Foundation.

Comment from 4004 on 9 June 2019 at 10:22

This looks really nice, some ai assisted mapping workflow is well overdue especially for undermapped areas. Do you consider imagery offsets?

Comment from Joseph E on 9 June 2019 at 12:20

I also am concerned about suggesting highway=residential by default. While this is the most common type of road in towns and cities, in rural areas highway=unclassified is very common. Why not suggest highway=road? This is a generic tag and local mappers can improve it to a more specific value later.

Also, I’m curious how the tool performs in areas with lower-quality or poorer-resolution imagery. You must have found lots of this, here in Indonesia.

Do you consider imagery offsets?

This is also a good point. JOSM has an imagery offset database which can be quite helpful, but I don’t know if this is integrated into iD or RapiD. In areas like Indonesia, the default Bing imagery is often a few meters off of reality, though it is better than some imagery providers. You need to check local GPS traces to correct the offset.

Facebook … does not attribute OpenStreetMap in every map

This is a problem. I agree that facebook should properly attribute openstreetmap, and provide a link so that facebook users will know now to improve the map.

Comment from sabas88 on 9 June 2019 at 18:20

Beautiful work! Thanks for your effort!

Comment from kirsanov on 10 June 2019 at 17:06

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.

Comment from kirsanov on 10 June 2019 at 17:15

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.

Comment from kirsanov on 10 June 2019 at 19:02

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.

Comment from amapanda ᚛ᚐᚋᚐᚅᚇᚐ᚜ 🏳️‍🌈 on 16 June 2019 at 11:39

limiting the user uploads purely on the quantitative basis is a tricky problem – and from what I know, no other tools use it

Yes, no other edit has a speed limit, but other editors don’t have computer vision help! 😁 OSM requires imports and mechanical edits to go through a review/feedback process, so the idea of “uploading too much too quickly can be bad” isn’t a new idea. The goal of your editor is literally in the name, to be rapid. 😉

It’s more than 2 years since Facebook said they’d release the source for their iD version (while mapping Thailand).

Comment from DrishT on 23 June 2019 at 18:53

Hey Rory,

You are correct, editing is faster with our tool, but more importantly the quality of the geometry is very good. I understand the idea of mapping too fast is frowned upon mostly because bad edits are hard and time consuming to revert. Our team has spent many many hours fixing new mapper edits so we understand this concern, which is why we built many integrity features into this version of iD. This allows mappers to get real time feedback when they are making mistakes and in some cases blocks the user from saving until an error is fixed. With the added benefits of incorporating OSMCha flags, KeepRight and OSMOSE we have more review/feedback processes in place to manage data quality.

Also the version of ID was released last year, you can find it here - https://github.com/osmlab/id-validation. But we also have the new one coming shortly after testing :)

Comment from amapanda ᚛ᚐᚋᚐᚅᚇᚐ᚜ 🏳️‍🌈 on 24 June 2019 at 07:36

Also the version of ID was released last year, you can find it here - https://github.com/osmlab/id-validation

Oops! Mea culpa. Sorry for not keeping track.

Comment from Smart D on 6 August 2019 at 03:21

Great work DrishTie,

Allow me to say a few words, I do appreciate the effort you and your team put into this. Especially the part of coordinating ground-based validator from Africa, like myself and providing us with prompt feedback about some necessary changes that we detected and needed an adjustment on.

I also, admire the balance between AI and human participation. As with Mapwith.ai, there is a nexus of AI suggested roads, with human participation. That is human checks to see, if what the AI suggests is good enough to be uploaded, if it’s human uploads. Else, humans make the necessary changes and uploads and it waits for validation by another human.

There is always a human in the process and the human checks for quality, the human is not just being there for the sake of being there. This aspect of “humans, not AI, determine quality” is a critical component.

RapiD doesn’t take away the human-participating nature of OSM. It can’t and it’s not meant to do so. Its aim is to help reduce the burden of mapping and also shorten the time it takes to map, which I think it’s phenomenal. Mapwithai is only helping mappers map better, but the humans are always in charge.

Once again, kudus to the map with AI team.

Comment from stevea on 6 August 2019 at 04:21

Not that I mind, but Smart D has quoted me (and largely channels my sentiments) that this tool does seem to fairly well balance “keeping humans in the loop to determine quality” as the AI begins the process with reasonable-seeming suggestions at data for a human to examine, edit and finally determine are suitable for submission to the OSM database. The discussion came from a thread named “[OSM-talk] Sharing, Facebook, mapwithai_feedback” at https://lists.openstreetmap.org/pipermail/talk/2019-August/083020.html . There may be additional dialog there which continues and does not overlap with any other channels about this. I wouldn’t want those concerns / that dialog to fall through the cracks.

Knowing that Facebook participates in the Slack channel named mapwithai_feedback (yet I and many others don’t; that dialog is effectively invisible to us), I have also invited Facebook to directly address that talk thread. I recognize that Slack channel, this Diary entry continuing AND suggesting a talk list rather clearly identifies how fragmented is this conversation — this is almost inevitable in a worldwide project and the many technologies / channels used to communicate about this new tool. However, I do ask that the most important “fruits of the conversation” are widely and freely disseminated to as large and diverse segments of the OSM community as is possible. I offer my perspective that this is a very helpful and informative Diary entry, along with the many entries that have followed DrishT’s initial submission; thanks to all who have spent the time to communicate these (partial) results of the mapwithai tool and its effectiveness in the form of this feedback.

Let’s keep the many channels of communication open and may there be much cross-pollination of subject matter and “fruits” of the conversation among them. Especially in the non-proprietary channels like talk and this Diary. (Slack and Facebook are proprietary communication technologies requiring a contractual obligation and some in an open project like OSM choose not to use these, or to minimize their use in conjunction with OSM).

Thank you for reading, SteveA OSM Contributor since 2009

Comment from DrishT on 6 August 2019 at 06:25

Hello Stevea,

Thank you for posting your thoughts and feedback. I wander if you can share a little more about the readership and engagement of the community as whole on the Talk List. What is it’s reach to the whole community and is it representative of the diverse community that is OSM today?

I agree that the community communications are fragmented and its hard to keep up but the team has been engaging in as many places as possible where we get reach outs with questions. That has ranged from Changeset comments, OSM Messages, Diary posts, Twitter, Whatsapp, Github, Facebook, Wiki’s, E-mail, Slack, Telegram and various Talk Lists all of which have active local OSM community groups. I think they are all quite visible to the community in question as well.

We chose to announce our work and engage the community by making an OSM Diary post that sits on openstreetmap.org because it’s safe to assume anyone who is using OSM knows where to find it and should have an easier barrier to comment and ask questions :) Not to mention its much easier to follow and respond, can incorporate visuals and is friendly for on demand translation for many people who don’t speak English as their first language.

I completely agree with you that we should keep the many channels of communication open. We are happy to answer any direct questions about our tools, data, processes and the people behind them.

Here is a summary of the quickest ways to reach us in addition to the ones on the diary post.

Look forward to chatting more.

Best, Drishtie

Comment from DrishT on 6 August 2019 at 06:30

Hello Smart D,

Thank you for sharing your feedback. It’s been great learning from you on the ground in Africa and working with you over the last several weeks.

Keep us posted on how we can help! Happy mapping.

Best, Drishtie

Comment from maning on 6 August 2019 at 08:15

We had a chance to test RapiD via the https://tasks-assisted.hotosm.org/ at Pista ng Mapa 2019 conference in Dumaguete, Philippines last week. The general comments of the local community is positive and has the potential of improving the speed and quality of mapping (tweet of the demonstration here).

A couple of notes below:

  1. Unlike other parts of the world, detections in the Philippines are fewer, this is because most areas (population centers) were already well mapped by the local community. The detections provided by RapiD allowed us to identify the last remaining gaps to complete the road coverage.
  2. Geometry quality of detections are very good (although jot perfect) and is comparable to an average mapper. This allows us to focus on tagging quality and connectivity instead of tracing. The time to investigating the correct tag based on local knowledge augmented by imagery will definitely improve the overall quality of the data.
  3. Validation is integrated to the workflow. Most common geometry errors can be avoided before upload.

We are continuing the tests and we will share back observations to FB to improve the workflow. Good job to those who built it!

Comment from kirsanov on 6 August 2019 at 11:55

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.

Comment from stevea on 6 August 2019 at 21:23

DrishT: You ask about “the readership and engagement of the community as a whole on the Talk List.” I don’t have any definitive data about that, except to say that many consider that communication channel to be a rather narrow one which does not come close to “properly” representing the very wide and diverse spectrum of Contributors to OSM. (I agree with that sentiment, it seems to be what some describe as “hobby or craft mappers,” people who have a lot of time on their hands to highly curate some parochial or specialized subset of map data, along with highly specialized professionals who have the time to kibbutz/criticize/engage in philosophical dialog about the project). There isn’t anything wrong with those activities or those Contributors, however, I believe many (all?) would agree that is “only a sliver” of our community. However, it is very widely read by the community of OSM volunteers who read mail list pages and posting there might be considered “casting a wide net” of dialog. Another widely read source (I believe) is the OSMWeekly “newsletter,” available in many languages (at http://weeklyosm.eu ). You might consider including them on significant milestones in the future of this project, they will certainly consider reporting it.

It is true that no single channel of communication in a project this large and diverse will address everybody, or even be close to that. Yet the reason I asked for your (or anybody from Facebook’s) participation there, is that Talk is a relatively OPEN channel, without “high bars to entry” that many consider with the numerous contract-of-adhesion channels you mention (as opposed to the relatively open ones of OSM itself, email, talk lists and similar non-proprietary communication channels).

At least half of the channels you mention (Twitter, WhatsApp, Github, Facebook, Slack, Telegram…) require agreement of a contract which has “take it or leave it” terms and/or proprietary technology that effectively restrict open communication. Talk (one among at least several channels) does not do this (or has MUCH lower “cost” or “bar to entry” agreements), and so many feel those are much more appropriate channels of communication in a project like OSM, whose first name, after all, is “Open.”

As an example of what I’m talking about, note that out of the bulleted items you offer as channels, the majority of them require agreeing to a (Twitter/Facebook, Github…) “Terms of Service” agreement, whereas only email does not. I appreciate that you offer the “osm@fb.com” email address, however, as you will see by those (not me, but others) who complain about Facebook’s lack of response at Talk, it could be seen as disingenuous to offer that email address here, as it is characterized as “unanswered.”

I appreciate that you list as many channels as you do and that the initial announcement was right here on this Diary, in OSM itself. I hope you can also appreciate that there are MANY (myself included, if you can’t tell), who wish to see (specifically corporate) usage of and communication about OSM — especially potentially revolutionary or at least highly significant technological advancements — remain as open as possible. You seem to agree.

I believe it would go a long way to assuage this apparent disconnect with the beginning of an “address the crowd,” by having you or somebody who represents Facebook in an official capacity reply to the topics at Talk. Yes, it can be a cumbersome channel, yes, it will require reading through the threads and following issues which some claim have been ongoing for months, yes, it is “yet one more” to the list above. Yet, if Facebook wants to address its OSM audience “on our own turf,” that would be a good move in a positive direction, imo.

As an aside (but still important): I apologize to you here for using a male-gender pronoun with you in Talk (I’m usually gender-neutral as I can be); I regret that error and simply explain that I was unfamiliar with the name Drish – it won’t happen again!

Regards, SteveA

Comment from DrishT on 9 August 2019 at 15:26

Hello Steve,

Thanks for your message. I appreciate the time you took to share your thoughts. I think we are quite aligned here. After all we have the same goal for this community driven project and want OpenStreetMap to be an inclusive place for everyone who wants to participate to make it better.

I like your idea of sharing announcements more widely like the OSMWeekly newsletter so will gladly to do so in the future! We will pay more attention to cross posting news so that we can reach a wider audience.

Also thanks for addressing the gender pronoun.:) No problem on my side. Its hard to tell online from names :)

Best, Drishtie

Comment from LSkalayo on 13 August 2019 at 14:50

RapiD is an amazing tool. It has helped us add missing roads throughout different states in Mexico. We have found RapiD to be eight times faster than manually drawing in missing geometry. Each road created by the AI is verified and added by an editor. As editors correct the AI roads, the AI is becoming more accurate as it learns from the editors. We are able to use this tool to improve the data being added to OSM and to map communities often overlooked. There are many areas of new growth and development in the states we are working through. RapiD gives us the ability to quickly and accurately add in large, new communities. The AI also draws in roads that would have easily been overlooked by an editor. It has proven to be very effective and allows our workflow to be far more efficient. The issues that we originally found with this tool- such as the snapping issue with roads - seems to have been addressed and now happens very rarely. The new “Issues” feature in RapiD catches these issues for the editor to fix when it does happen. Unlike in JOSM where the validator is only run after hitting the “validate” button, RapiD is always running the validator, allowing the editor to continuously fix issues created. The Facebook team has been extremely responsive with any issue we have brought to them and has quickly resolved them. We are really impressed with the AI and really appreciate this tool!

Comment from wulankhairunisa on 15 August 2019 at 22:56

Map with AI has been very helpful in the process of road mapping in Indonesia since last year. With the help of AI, it improved the quality and speed of mapping the roads. It guided mapper to visualize where the missing roads are.

Although in its implementation, remote mapping using AI assisted is not as easy as imagined. The mappers still need to give the roads classification manually which is difficult, because Indonesia has different road conditions in each island. I think this is clearly one of the reasons why human validation still plays an important role. One of the ways to face this challenge was to conduct field surveys on several different islands in Indonesia to gather local information. We have shared what we have got from the field with the Facebook team which I believed it could be used as valuable feedback in improving their tools.

Road data mapped with AI assistance were also useful in post-disaster mapping carried out by local communities. For example, post-earthquake and tsunami mapping activities in Palu, Central Sulawesi in September last year. Mapped roads helped navigate them to disaster affected areas, considering that many affected areas were located in remote areas where there were very limited information on road access. Mapped road networks combined with important infrastructure data (e.g health care, government offices, evacuation shelter, etc) that they have collected will be used to support the renewal of contingency plans and disaster management plans in the region.

Comment from stevea on 16 August 2019 at 02:03

Most excellent, wulankhairunisa. I might recommend you and other Indonesia OSM mappers stay within “the OSM network” (of communication tools: wiki, Diary entries, Talk pages…) to communicate with one another about these sorts of things. Discuss amongst yourselves, keeping things local, amongst volunteers who are “on-the-ground.” This keeps a firm boundary (which properly belongs) between OSM (“proper”) and Facebook, which instigates this AI tool (iD editor flavor) on country-at-a-time areas.

The “local / regional / national” roads-are-a-certain-sort-of-national-island-by-island” way, here, in Indonesia, is exactly what is to be expected. Keep that “local / regional / national” sort of “ownership” of OSM data WITHIN OSM, where it belongs. Facebook is merely unleashing a tool upon OSM, and we can either choose to use it (wisely) or not use it (or use it unwisely).

Each country has its own sort of road network that “maps onto” (in a logical sense) the OSM highway=* tag values (of motorway, trunk, primary, secondary, tertiary, residential, unclassified…) and those of you in Indonesia are really the best people to both know that and “use that” in OSM.

See the Facebook AI tool for what it is: a proxy to better data in OSM, but ONLY AS THE LOCALS SAY SO. YOU, that is to say, those of you in Indonesia (or wherever Facebook deploys) get to say how this tool is used.

By doing this, there is good feedback, humans are in the loop, OSM, Facebook and AI are identified as distinct from one another and so healthy dialog progresses. We can have forward momentum with all of these actors dancing on the ballroom floor together, but let’s keep the identities clear for now, yes?

I think that’s most of what I’d like to say about that, now.

SteveA California OSM Volunteer since 2009

Comment from rmikke on 1 August 2020 at 12:04

I’ve tried RapiD and I like it :)

Two questions:

  1. This was already asked by mikelmaron, but a year has passed and I wonder what the current status is. So, is the user feedback taken to further teach the AI?

  2. Can the AI use different imagery for different places? I mean, tere are aerial imageriess that usually cover one country or less, but they have better resolution and usually are better aligned than satellite imagery, so it would be easier to correctly connect lines detected by AI to the mapped road network.

Comment from kirsanov on 17 September 2020 at 15:31

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.

Log in to leave a comment