Hello. I have some questions for the Mapillary team.
I understand that Meta is a member of Overture. Does that mean that Mapillary data contributes to Overture datasets? If so, could you please explain what data is used and how?
As much as I like the idea of Overture, I’ve found it frustrating that I can’t report inaccuracies in their POI and building data, or somehow correct it myself.
So I’m curious if a meaningful way I can improve Overture data is simply to go out and capture Mapillary imagery. For example, if a building no longer exists, can Mapillary detect that and update the data? Can imagery of shopfronts automatically refresh Overture POI data? And does Overture road segment data include lane markings? When Mapillary detects lane markings, does Overture get this data?
You’re right Meta is a founding member of the Overture Maps Foundation and Mapillary plays a role in that collaboration. We shared our commitment here: Mapillary’s Commitment to Overture in the early beginning of Overture’s journey.
As much as I like the idea of Overture, I’ve found it frustrating that I can’t report inaccuracies in their POI and building data, or somehow correct it myself.
I completely understand the frustration. You’re right, there is currently a gap where you can’t directly provide feedback and have it fixed in the Overture data. I’ll pass this feedback along to the Overture Maps folks.In the meantime, feel free to create an issue on Overture’s GitHub.
As you also mentioned there are numbers of ways where Mapillary and Mapillary generated data can help to improve Overture Maps data. Your given examples are actually great however there are no production ready workflow for these themes where Overture uses Mapillary to auto-update Overture data.
For POIs, there’s ongoing work to use street-level imagery to validate and improve Overture places data. Sean Gorman from Zephyr (who’s also part of Overture) has done great work documenting some of the early results: Scaling POI Relocalization with Mapillary. Please do check Sean’s articles about this work. We’re also working on hosting his work on Mapillary blogpost soon and share more details.
I’ve worked directly with researchers from the University of Santa Cruz who have shown that building entrances can be automatically detected from Mapillary imagery, another potential way street-level data can enrich map datasets.
You might also find it useful that Overture POIs are surfaced as a layer in the Rapid editor which makes it easier to see and work with Overture data on OSM editor however changes will not be available on Overture Maps.
Thanks again for your feedback and checking with us.
What is Mapillary, what is your conclusion?
For me, Mapillary is the following, and Overture Maps plays an important role here.
Although OpenStreetMap calls itself the “free map”, the community insists that mappers may only add data they have personally collected on-site. As a result, OSM often lacks sufficiently current coverage for many practical use cases. Anyone who needs to include new buildings, construction sites or road closures frequently turns to UMap or Google MyMaps.
Such maps are easy to share, but maintaining them usually falls on the creator alone and their reach remains limited. A big help is creating your own Street View-style imagery.
Google Street View follows its own schedule. Much more flexible is the Mapillary app: with a smartphone, new roads and changes can be captured quickly and uploaded to the open system.
Mapillary thus enables decentralized, community-driven updating of geographic data and is a powerful tool — especially for businesses, cities and municipalities — to inform major map providers quickly and reliably about local changes.
This is only partially true. OpenStreetMap, like every other map provider has spots of detailed, highly accurate, and very recent coverage but also areas of little to no or outdated coverage. And, it is for good reasons that the OpenStreetMap community asks contributors to only commit verified data. Large scale automated imports of verified data are also possible. You just have to announce automated imports (or edits) and work with people before you do so, instead of willy-nilly dumping data into the OpenStreetMap database just because you can and nothing technically prevents you from doing it. This is called respect for others and cooperation.
Yeah, that’s why Overture Maps is rather counterproductive for the success of open data and OpenStreetMap itself than any help. It makes people choose the easy way out, take a shortcut. Anybody who needs new building outlines or anything else new on the map for that matter, can update OpenStreetMap easily and thus contribute to an open license for the common good which ultimately serves everybody. Overture Maps enables people to cheap out. Its users are not inclined nor encouraged to give back in any shape, way, or form but instead encouraged to only take and not to cooperate. I am sorry but imho Overture Maps only feeds humanity’s worst traits, like greed and laziness.
Indeed, it is frustrating. Hence, use OpenStreetMap. Focus on libertarian solutions.
I agree that OpenStreetMap is excellent in many areas — especially roads and paths. However, after more than 20 years of development, it’s disappointing that quality in other very labour-intensive areas, such as building coverage and address coverage, has stagnated or even declined in many regions. A truly productive map should deliver high quality across the board, not just in selected categories.
This is exactly why user reports in OSM are already very useful. In my opinion, Mapillary represents the next logical step because it doesn’t just provide reports — it supplies photographic evidence.
A tight integration of Mapillary images directly into OSM’s user report system would be a huge improvement for both projects.
Conversely, it would also be great if Mapillary added a simple comment function to its smartphone app. Those comments could then be partially analysed by AI, making it much easier to process feedback and improvement suggestions.
Libertarian solutions are great when they actually lead to better results. That’s why I believe closer cooperation between the two projects makes more sense than just recommending one over the other.
That’s right. Mapillary is so far just a collaborative evidence provider for OpenStreetMap and other open data projects. Please, do not get me wrong, the Mapillary platform is already quite complex for what it is today and a lot of man hours of work went into it. It is a remarkable achievement. What I rather mean by just is that it could have been a bit more already and can be a lot more in the future. For now, Mapillary leaves a bunch of very useful potentials untapped. For example, since the FB takeover Mapillary’s integration with the Rapid Editor, which is also one of Meta sponsored GIS projects, has been rather lackluster. There is a lot more synergy potential to unlock together with this project than has been tapped into so far. Rapid Editor already successfully integrates with other Meta AI projects in the GIS space, like human in the loop verification of road ways and building footprints. Thus, I am baffled why Mapillary’s traffic sign and point feature layer verification has not been already integrated into Rapid Editor. Imho a huge waste of unemployed potential. For an organization as large as Meta with the budget it has at its disposal, I am surprised that top level management has not yet discovered such simple synergy effects between Meta projects and divisions. Sure, I am not a Meta insider but it does look a bit strange from the outside.
The ultimate goal for Mapillay is of course to have AI automatically generate a machine readable map database (similar to OpenStreetMap) built directly from just aerial/satellite and street-level imagery. We are not there yet but my estimate is that we are probably going to be in the next decade. Hence, real life auto-mapping! Just like in 1990s FPS games.
Sure, you can file this suggestion with OpenStreetMap’s notes developers.
I am not sure this would be a good idea, although I am not entirely sure what you have exactly on your mind. Mapillary and its mobile apps imho should stay focused on easy, efficient, and swift image collection. At the collecting stage, street-level imagery has many use cases, not only map creation. Hence, it would be unwise to clutter the mobile apps with functionality that is better left to be implemented in other (imagery) data extraction tools.
Libertarian solutions are not about being better or worse content wise than commercial or closed source solutions. They are about respecting people’s freedoms. Both models strive to become best at what they are trying to do but they use different means and ends to achieve their goals. In this sense, libertarian solutions are always great.
It is analogous to organic food. Organic food is neither healthier nor better than conventionally grown or produced food. It is about the way food is grown, produced, processed, and made, including taking care for side effects on human beings and the environment.
I completely agree that the mobile apps should stay focused on fast and efficient image collection — that must remain the core. However, I think there is a very low-overhead way to turn Mapillary into a much more powerful feedback channel without cluttering the app or turning it into an editor.
The real-world scenario
Every week I get approached by:
local residents
city authorities
small businesses
infrastructure companies
who are frustrated about map errors in their area (missing or wrong road names, outdated construction, new bike lanes, closed streets, etc.). They want a simple way to report these issues so they get fixed. Example of a currently non-functional construction site detour here: Way: 875075857 | OpenStreetMap .
Right now my answer is usually: “Please go to the desktop editor or contact the specific map provider…” — which almost never results in new imagery. Most people just give up.
What I would love to be able to recommend instead
Install the Mapillary app (very easy).
Drive/walk the affected area and record sequences.
Add a short comment on one of the images (or on the sequence) describing the problem.
That’s it.
This would give us two things at once:
Fresh, high-quality street-level imagery exactly where changes happened.
Human-readable context (“New roundabout built here in March 2026”, “Street name changed from X to Y”, “Construction blocking sidewalk until July”, etc.).
The people who care enough to report an error in their own neighborhood are often the best possible contributors — motivated, local, and willing to go out with their phone. We should make it as frictionless as possible for them.
Important boundaries
No complex editing tools in the app.
No need to turn every user into a Rapid/OSM editor.
Comments stay optional and simple (text + optional photo tag).
Keep the messaging neutral: “Help improve maps so people can find their way” — no commercial or political angle.
This approach would bring in significantly more coverage from exactly the people who notice real-world changes first, while the actual map editing can still be done later by the community or data consumers (Overhead, Street View partners, Mapbox, etc.).
Would love to hear other opinions — maybe this could even be implemented as an optional “Report issue” mode that doesn’t interfere with the normal capture workflow.
I see where you are aiming at @osmplus_org. And, I also fully understand your and other people’s frustration about outdated maps. However, the problem scenario you are describing is not so easy to fix with just a simple “note” attached to an image on Mapillary or wherever else, including OpenStreetMap for that matter. It is a start and thus OpenStreetMap already has a geo-tagged notes system for non-fully fledged OpenStreetMap contributors. But, the key issue is that we live in a complex world and there is no one map database for everything. There are multiple map data providers who source data in different ways, from different sources, and over different cycles. For example, every car maker provides some sort of map data from all different kinds of vendors with their cars these days. Each of them operates in a different data silo, uses different tools, and has different internal data structures. Additionally, all map data providers, no matter commercial or volunteer driven, have limited resources, as well as in terms of manpower as in terms of funds. Hence, it is literally impossible to make every map data consumer and customer, who is far away from mapping, happy with an ever up-to-date map, even if such people would leave geo-tagged notes, like they can on OpenStreetMap today. OpenStreetMap notes are nice but they still require somebody to verify an existing note against some form of evidence and actually commit a changeset to the database. But, an update in the OpenStreetMap database is not the end of the story. Somebody has to push this updated database to end user consumer devices. Again, there a cycles and time intervals involved here too. And, not every map data provider sources data from OpenStreetMap. So, notes can help but they will not fully fix the scenario you are describing. Furthermore, I do not think that it makes sense for Mapillary to double OpenStreetMap’s already existing notes system effort for non-OpenStreetMap contributors.
In short terms, if you really care about your map data over a select area then it is indeed best to become proficient in OpenStreetMap (and Mapillary, of course ) contributing. Because OpenStreetMap is currently the only solution that gives you the lowest barrier of entry and non-gated access to serious map data. This is where Overture Maps falls short but understandably though because it serves a slightly different purpose for its users than OpenStreetMap.
Maybe if we had an open upload protocol specification from Mapillary, a third party app that would implement such a notes feature could prove me wrong (which of course, I would be fine with)? Anyhow, AFAIK OsmAnd already supports OpenStreetMap notes (via a plug‑in, I think) which enables users to report map updates immediately. Despite that and overall, OpenStreetMap notes have had limited effective impact on the evolution of the map database. Nevertheless, maybe @Anders and @Yaro can spare the time to integrate OpenStreetMap notes with the Mapillary mobile apps?
This is exactly what and who OpenStreetMap’s geo-tagged notes are for. It is for people who want to hint at updates but do not want to, do not have the time for, or do not have the skills to use an OpenStreetMap editor. So yes, it is always helpful when you can make or encourage such people to provide evidence imagery via Mapillary of changes and leave OpenStreetMap notes about these changes. But, doubling efforts makes little sense imho.
However, going back to @wa_wheatbelt’s initial question…
Just like @asturksever has already mentioned, there is no way for anybody to directly update Overture Maps because it a composition of map data sources and layers that come with different licenses, including closed source commercial licenses. Hence, you would need to look up who provides the data layer for the specific data you want updated in Overture Maps and do the update there, if you even can. Mapillary imagery can lead to Overture Map updates eventually but it is not guaranteed because it depends on the way how a specific Overture Maps data layer provider evidences their data.
Mapillary is very special, both as an image repository and a map data generation tool. Regarding the latter, given that anyone can contribute fresh imagery, I believe Mapillary has massive untapped potential in this age of automated mapping, as I indicated in my original post.
Personally, I’m very interested in TomTom’s Orbis map. It aims to be the most up-to-date and accurate roadmap by pulling data from many sources, including Overture. OSM is a primary source of Orbis’s road geometry and landuse polygons. Overture’s buildings dataset appears to be the same AI-traced Microsoft buildings available in Rapid Editor. TomTom Orbis integrates this Overture buildings dataset, but buildings in OSM appear to take precedence. I’m not sure if that selective integration of OSM buildings happens at Overture or at TomTom. Point of Interest data in Orbis also looks like it may partially be source from Overture’s POI dataset, if I remember correctly.
Anyway, my interest in TomTom, and my volunteer involvement as an individual partner with partial edit access to their pre-Orbis map used in the TomTom GO Expert app and their SatNav units, is predominantly my reason for interest in Overture. Personally I feel that Overture data has made maps worse over its first three or so years. No doubt that will improve, and I would love Mapillary data to be utilised to speed up improvements. But maybe I’m naïvely overestimating the potential of these automated processes and Mapillary’s suitability with most of its data captured on lower precision equipment than Google’s Street View cars, for example. I’m no expert on the matter. Just a mapping enthusiast.
Thank you @dsdfidksmyw for the buildings example. So, in other words, if you want to update a building outline for Overture Maps your best chance is to do the update in OSM because Overture Maps prioritizes OSM buildings first. However, Overture Maps may have a different priority list for POI sources.
On a side note, it is interesting that Google ML appears twice in the table.
Anyhow, imho every use of AI should provide the option for a (conscious) human being to override it. This should not only apply to auto-pilot AI in a plane cockpit or a car’s driver seat but to every use of AI. Every AI is going to make mistakes and some human being is going to have to pay for that mistake in one way or the other eventually. AI never has to pay to consequences for any of its mistakes. Sure, human beings also make mistakes but they are conscious entities that have context understanding and the ability to self-correct. Human beings also live in a real physical world where survival depends on so many things no AI is aware of nor cares about. For Overture Maps this should mean to have a policy that they are only going to source ML data which can be fixed at the source through the intervention of a human being. For Mapillary this should mean that people can not only fix blurs but also traffic sign and point feature detections (at the source).
Yes. From that buildings page, I was able to find a page with the list of sources for POIs. It’s definitely a quantity over quality approach. OSM isn’t even on the list, though I think it should be considered the most authoritative source.
And I do agree that AI needs humans to approve the output/results, besides some limited tasks. For example, adding lane tags to road segments can be automated with high accuracy and relatively minor consequences for errors. But it must be easy to correct errors once discovered. And it would be good if the AI is programmed to avoid making changes if the quality of source imagery is low. That being said, I’m much more comfortable with the idea of AI suggesting edits where imagery indicates the map is outdated, leaving humans to either approve the suggestion or manually edit the map.
I’m very much against these AI building outlines from Microsoft and Google though. In my experience, they’ve been of such a low quality that it feels like using them would be vandalism of the map.
The reason they don’t use OSM is because to conflate with other data sources requires that everything be released under the ODbL (Open Database License). Copyright and License | OpenStreetMap
As for quality, they calculate a confidence score based on location information, presumably collected from their members but maybe other sources. Consumers of the data are expected to use those scores to show only ones that are more likely to exist.
Focus on libertarian solutions.
