Map editing with automatically derived map features - mapillary2osm


Hi everyone,

For the next month we’ll be experimenting with a new Mapillary challenge which will leverage Mapillary computer vision technology to improve OpenStreetMap. We’re working with the community in select locations to take features we’ve detected automatically and convert them to map data in OpenStreetMap.

The process is pretty simple:

Mapillary provides GeoJSON that shows the location of benches, mailboxes, and rubbish bins that we have detected. Each GeoJSON represents an area of 25 square kilometers. This should be enough map data for a meaningful challenge, whilst giving each group the opportunity to add every detected feature and achieve 100% completion.

There is also the opportunity for each group to collect more imagery during the challenge and request new downloads of the data. This can be done three times during the challenge by each group which will allow the groups to capture new streets or improve the quality of imagery if a particular feature has not been picked up in that area.

Each changeset will have #mapillary2osm in the comments to help inform us when an edit is linked to the competition. Edits will be tracked on this leaderboard and ranked according to the number of relevant nodes added by each username.

This is very much an experiment, but we’re hoping it will help to inform us on how our detected map features can be converted to OpenStreetMap data. This will inform our improvements to OpenStreetMap’s Mapillary integrations.

If you would like your location to be considered for future challenges, comment below with the latitude and longitude of the area.

This is an important step in understanding how we can convert automatically derived data to useful map data in the OpenStreetMap.

We’re looking forward to seeing the results.


Ed & Team

The plan:

Make sure you read through the following to know how to participate and have your edits included on the leaderboard.

Challenge structure

  1. Take a look at your zone: 25 square kilometre zones have been created around each of the lat/lons that were put forward by each community group. This should be enough to get a decent number of point features, but also an area that can be completed to 100% for the derived features.
  2. Download map features: Find the map feature data for your area and download it. The map features are provided as a GeoJSON file and can be viewed in iD Editor by going to ‘Map Data’ on the sidebar and then loading the GeoJSON file where it says ‘Custom Map Data’. You will see the detections as pink circles on the map. Use the Mapillary street-level imagery layer to see which images the map features have been detected in.

The map features contained in the GeoJSON are provided under the ODbL license and may not be used for any purpose other than OpenStreetMap editing.

  1. Edit the map:
  • Take a look at the detected feature and the image it was detected in. If it’s not on the map, add it!
  • Edits should be creating one of the following objects:
  • Add the hashtag #mapillary2osm to the changeset so that we can link these edits to the #mapillary2osm challenge.
  • If you are a relatively new mapper, select ‘I would like someone to review my edits’ when saving the changeset.
  • If it looks like each location will complete all map edits well before the end of the challenge, we may release other map feature data. These will appear in the same folders.
  1. Capture more imagery: Contributors can capture more imagery in the target area and request new map feature data 3 times during the competition. This is 3 requests per location, not per individual, so coordinate as a team to make sure you capture imagery and request map data at the right times. Requests to be sent to me as a private message.

The leaderboard will update hours after you make the edits with the total reflecting the sum of nodes created that have one of the three tags.


16th of April: Map feature data made available and challenge begins

16th of May: Challenge closes.

20th of May: Results announced.

Target locations

Here are the 6 locations selected for this initial experiment. We encourage people to contribute to the location only if they reside in the same country.

  • Antwerp, Belgium (coming soon)
  • Austin, United States
  • Ballerup, Denmark
  • Kyiv, Ukraine
  • Melbourne, Australia
  • São Paulo, Brazil

Comment below if you are interested in participating in future map editing. Provide the latitude and longitude of the area you would like to start editing.

Map features in focus:


The top 5 participants in the most active area will receive an assortment of Mapillary swag. A minimum of 5 edits are required to be eligible for the prize.


Please keep in mind that these edits are going to OpenStreetMap and affecting real people who rely on these maps.

  • Make sure all edits you make are reflecting the reality on the ground. This means you should not be:
    • Making fake edits to increasing your score.
    • Adding false detections to the map. Just because Mapillary says an object is there, doesn’t mean it really is.
    • Adding the wrong tags to objects.
  • The map data provided in each GeoJSON is to be used for OpenStreetMap contributions only. It is not to be used for any commercial purposes.
  • The quality and quantity of detections will vary between each of the participating locations. This is inevitable. One objective with this challenge is to work out how the detection accuracy varies between locations. You can help to improve the detection accuracy by capturing high quality images in your area. This will increase the chance of an object being identified but also provide an opportunity for more training date in future.

I tried Melbourne (Richmond). There seemed to be 2 detections for one three bicycle rack. So I kept my hands off it.
I tried another street. But I really cannot work with the small Mapillary window in ID. I am used to the switching bookmarklets.
Further it is not a good idea to choose a place where they drive at the other side of the road.
The bicycle racks are hard to see because of the parking cars.
Richmond is not totally Mapillary covered.

I am not going to stress my brains. I’ll wait for a mission in a place I know.

1 Like

This has a bit of overlap with btw. Unsure if you’ve come across it before.


Yeah definitely. Adrien who developed it is fantastic! Room for more collaboration here.


Yeah, some great enhancements here :slight_smile:

1 Like

I would love to see how well this works in Trondheim (lat=63.4305&lon=10.3953). Disclosure: (1) I’ve noticed on Pic4review that the Mapillary detected locations are often quite far off the actual location, and (2) many of these amenities are already on the map. :slight_smile:


I did a little test in Ballerup, and I have to agree with the criticism from @filipc, the photo in iD is too small to use. You can make the photo bigger, but then it will cover too much of the map.

In addition, I see these problems:

  • There are too many Mapillary tracks going over eachother to be able to pick the right photos. (This is a general problem with Mapillary.)
  • Even though amenity locations are shown on the map (through the GeoJSON data layer) it can still be very hard to find a photo that actually shows the item. This is easier with the map data view on the Mapillary site, where the photos showing an object are highlighted. However, the map data view on the Mapillary site is almost impossible to use, since nothing is visible on the photos themselves, because they are covered with object overlays.

Thanks for the feedback @pbb.

Definitely improvements that can be made to the iD workflow.

Interested to hear more on your second point. The actual object that has been detected flashes in the image to show you the object you have filtered by. Are you saying this is easy to miss with all the other detection overlays?


I wrote down my second point in a bit of a mess, I was talking about both iD and the Mapillary site, so now I don’t know if you are referring to the situation in iD or on the Mapillary site :wink:

In iD, I see for example these three indicators for benches, but I have no clue which photos I can use to verify this and to see the precise location: …

Oh nice. I can not upload any images to this forum. I am getting a message “missing credentials, provide credentials with one of the following options:” followed by only an “OK” button…

And on the Mapillary site, it is easy to see which photo I can use for reference, but the photo is covered in coloured areas, masking the actual photo, so I can still not determine how this object is located in relation to it’s surroundings…

Just imagine an illustrative screneshot here…


When viewing on Mapillary you can toggle the segmentation overlay by pressing ‘Object detections’ on the top menu. This will allow you to distinguish the object more clearly relative to its surroundings.

I have reported the forum image upload issue. I am encountering this myself.


This is true. But after I have turned off object detection, then I have to re-enter the search term when turning on object detection again. This can get irritating when there’s several photos with a “hit” close to eachother, and you try to see if they all identify the same object, or if they are different objects.

Ideally, when I have object detection filtered on “benches”, then only the benches would also be highlighted on the photo, and there should be a quick toggle to turn this highlight on and off on the photo only.

1 Like

For benches, “Point features” (underneath “Detections”) works a lot better. But that is not available for post boxes and bicycle parking.


Yes these are good points. Discussing with design and front end to see how we highlight more relevant segmentations better.


To be very honest, I don’t think any user needs the on-photo object highlighting. It’s a nice show-off for what Mapillary can do, but there is no practical use. At a later stage where the user can report errors in the object detection, then it will become useful, but as far as I can see only for that purpose.

On the other hand, indicating objects on the map is very useful.


Personally I find it useful. Sometimes the machine has identified something and I am unsure where it is. Then I zoom in on the flashing object and see that sure enough a manhole has been spotted in the distance.

1 Like

I find it useful so that I can refine the data. e.g., yes it’s a bench, but where is it in the image so i can determine if it is a bench with a backrest?

1 Like

Have you seen that Antwerp is now available. No one has edited here yet so it would be great to have OSM Belgium participating.

Here are the objects detected in Antwerp.

And check out the benches detected!

1 Like

I don’t think it is possible to have multiple custom map data files in OSM ID.
The job you propose should be done while comparing it to the official Antwerp data.

I will suggest it to the locals.


I just load the detection GeoJSON into iD. The detections in each GeoJSON correspond to the editing area in focus so you only need the one file.


Dear Eduardo,
Tried this (post 16/19) as soon as I learned of it, zoomed in on a part of Antwerpen in Belgium, specifically the intersection of the Ferdinand Coosemansstraat with the Walemstraat and the adjacent Wasstraat ; also used the posting box finder to check for any nearby posting boxes.

Observations :
1/ in ID, the ‘key’ and ‘img_keys’ values are rather long sequences, and can’t be copied/pasted - therefore no apparent way to view the photo on which M’y detected the posting box;
2/ dots from the mailbox file do not coincide with dots on Mapillary when zoomed in - can’t view the specific pic on which the mailbox was detected that way, either;
3/ has a posting box finder, see , searched for Walemstraat 6 postcode 2600, which is where there are four clustered dots in your mailbox json file - returned as nearest posting box Belpairestraat 85, which by the way was not detected by Mapillary.
4/ jumped on the bicycle to view the spots, uploading the sequence as I type this, essentially : there are no posting boxes in the Ferdinand Cooremansstraat anywhere near where M 'y detected them and placed four dots, and there isn’t a posting box in the adjacent Wasstraat near number 11, where there is one detection;
5/ there is a well hidden posting box in the Belpairestraat, outside number 85, as predicted by the posting box finder.

Points for improvement :
a/ properly define the words posting box (where stamped addressed mail is placed by the sender for collection by the postal service) and letter box (the destination of the letter where the postal service worker will deposit the item for the recipient to pick up ;
non-native english speakers looking for a word tend to turn to which lists letter box as “a box attached to an outside wall, or a slot in the door of a building, into which mail is delivered.”;

please avoid ‘mailbox’ : gives two (North American) meanings, which are ambiguous in that they can apply to either “a box into which mail is delivered, especially one mounted on a post at the entrance to a person’s property.” or “a public box with a slot into which mail is placed for collection by the post office; a postbox.”.
b/ there needs to be a workable link for the mapper to view the photo on which the posting box was detected, which will help in placing the feature in the best possible spot.
c/ in the interim, while s/o works on point b/ above, could the dots in the json-file please coincide more exactly with the track when zoomed in?

With high regards, and do keep up the good work,

1 Like