Overturemaps.org - big-businesses OSMF alternative

What the heck does it mean to “co-collaborate”?

Thanks for your article! I have a question about these bits (translated with DeepL):

The license is already known: it is CDLA Permissive 2.0: analogous to MIT and CC-BY, requiring only a source. (…) A special permission will be given for use in OSM. Of course, all OSM-based data will be published under ODbL.
We even win in terms of sources: we used to suggest that companies and government agencies open data to OpenStreetMap. That led to long discussions about why and why. Now everyone will be opening up data for a solid project with millions of dollars in funding and dozens of developers on staff, supported by all the well-known companies from the top of the rankings. And that data will all be in a single format. It will be elementary to take them to refine OSM.

So OSM data will be “released” by them under ODbL, and I assume only their own data will be released under the CDLA. You mention that CDLA is something like MIT, but if that’s the case why the need of a “special permission” to be used in OSM?

1 Like

With permissive licenses, it’s not always obvious whether our way of attribution (via a link under osm.org/copyright → wiki/Contributors) would be okay with publishers. The OSMF LWG analysis suggests it’s fine, but you can never be safe with licenses. Hence the explicit permission is better than nothing.

As far as I got, companies (including Meta) plan to continue improving OSM with the externally provided data, which would be aggregated on Overture Maps portal. Hence the permission would be obvious.


TL;DR: I think they’re going for UUIDs as concept identifiers and their file format will be inspired by the IMDF (vocabulary very, very similar to OSM Wiki, but uses “.” over “:” / “_” on keys)

Based on quick casual browsing on Twitter for “overture maps”, then people proud about this, I found someone’s from one of these company days before mentioning this (which might give a hint on their mindset to push for broader adoption of whatever data exchange format to sideline OSMF over time):

From their “solutions” one is the GTFS from Google (pointer as success case for bus routes) and a new concentioned data package, Indoor Mapping Data Format, which seems to be around since at least 2019. But is from Apple, not AWS/Meta/Microsoft/TomTom:

At the https://www.ogc.org/pressroom/pressreleases/4415 explains a bit how this has been standardized, but I’m somewhat a bit disappointed if Overture Maps Foundation will either use IMDF done by another company or create a conventional in similar way. From the “war” on open vs closed specifications, I remember the case of Office Open XML had a major discussion, even an ISO, to brag about be an open standard with wider discussion, but OMF (if going this path) will effectively have an “open standard” not more than an informational IETF RFC. And from this link, a paragraph:

An OGC Community Standard is an official standard of OGC that was already available as a widely used, mature specification, but was developed outside of OGC’s standards development and approval process. The originator of the standard brings to OGC a “snapshot” of their work that is then endorsed by OGC membership so that it can become part of the OGC Standards Baseline.

So, this approach on file format is actually less than the OpenStreetMap Wiki: the actual “points of interest” are poorly defined, if defined at all over mere key use in en-US. Pretty lazy job, I mean is not even monolingual. The JSON/Geojson is not even JSON-LD/GeoJSON-LD. Not just this is less semantic, but seems that the whole “Global Entity Reference System” is a buzzword for long random UUIDs that any tool can generate but are unlikely to conflict with each other (actually, "globally unique identifier GUID are another name used for UUIDs).

Despite them saying in the FAQ they aren’t focused on community, and informally we know here they’re sometimes upset with DWG not allowing mass changes, from the “OGC Community Standard” thing, plus all the idea of trying to appear friendly to OSM, seems otherwise. Also even GTFS from Google had very slow adoption despite having no competition of file formats, so Overture from medium to long term attempt requires developers to promote use of their exchange format (if they don’t, it will make them work very, very, very manual, unable to scale up).

Anyway, they’ll be very susceptible to public criticism about technical implementation (because otherwise their data would be more outdated pretty quickly). But if they’re going for an IMDF-like approach, from their way to think like layers, to even the way they would do conflagration at later stages, becomes predictable, regardless of they avoiding leaking any code before going public.

1 Like

OSMF official replay in the blog.openstreetmap.org on December 22, 2022 by Mikel.



Discussion is happening next door: Views from the OpenStreetMap Foundation on the launch of Overture


A few more blog posts from various people in the OSM community and beyond:

(please add your own… this post is a wiki)


As far as I can remember OSM has always been community-driven raw map data project, with focus on manual, on the ground mapping of reality with no one specific use case in mind. Now any data usage (especially complex data like maps) is not just taking raw data and use it as is. You need structuring, cleaning, quality control, mixing with other datasets etc, and all these steps are purpose-driven. Therefore from the ancient times of cloudmade (and mapbox, grofabrik, skobbler etc etc) OSM users for real business (or fun) had to build their stack on top of OSM. I’ve been involved on a few these initiatives in past, same thing every time: inconsistent coverage, tags etc. Amost all of these downstream companies have kept it private and closed in terms of both tech and “clean” data, and until OSM attribution is included it has been ok.

Now Overture seems to build same old stack, but in completely new level: with backing and collaboration of major players and at least promise to make resulting data also open. Thats something mapboxes of the world never did. And this can be a game changer thing, it can become partial replacement to these OSM commercial sellers, but not to OSM community. It is a play to outcompete no less than Google Maps. I see OSM has to win from here more than loose.


With the exception of adding additional addresses that previously was done by the mapboxes of the world, I don’t quite see why everyone is reading an ‘open google competitor’ into this. Overture has neither announced open aerial / sat data nor open traffic data and I don’t see any economic reason why that would change. These are the things that most people find missing in purely OSM based apps.

I would aggree that technically the Overture play is similar to what cloudmade, mapbox and others have done in the past and what others that haven’t pivoted away from that yet are still doing. But as I pointed out in my 1st comment, there is a qualitative difference between having a multitude of small players serving as an intermediary and a single big business pressure group as sole distributor.


Ok, I think you meant that even if technically they would not be sole distributor, then there is real risk that they just do what Google Maps did 20yrs ago to bulk of geo business: have more famous, nicer, richer and cheaper (free!) product than now provided by small ones (like MapTiler), right? And then OM would be way stronger and tougher partner for OSM community (and OSMF) than previous corps, who have also tried to nudge OSM to be better for their commercial needs. Valid point.

As someone with history of being pushed out of my OSM-based microbusiness by mapbox (kinda) I see that the next level of consolidations, the big ones taking over them is just a law of nature and business, something companies always need to take into account. Now for OSMF the key is to make clear to OM parties that OSM is first of all living community with own strong opinions and everyone needs to be super careful with community who gives them golden eggs. Use the data, attribute, sponsor a bit, but stay in a safe distance.

1 Like

Via a hacker news post, I came across this blog post from 2018: Seems to have flagged some of the underlying concerns that the group behind Overture has and tries to solve from their perspective?

Some form of persistent IDs, standardized tagging, protection from poor edits by having a review method, and layers

To me as a new contributor to the project that mostly map POIs, that blog post calls out very sensible things that I wish the OSMF could pick up on

1 Like

He actually followed up and provided more details in a new comment

He’d tried to import addresses in Vancouver based on public government data, but had gotten pushback from someone that said you could only map that on the ground.


For the avoidance of doubt he suggested trying to do this in 2014, and said then that he didn’t know how to do the work himself (“and I don’t know if my weak GIS/coding skills would be enough to achieve it”). What this has to do with anything now I have no idea. :slight_smile:

1 Like

@andygol : I wanted to quickly comment on the API part in your blog post, part 2:

The site code itself is inseparable from the API code. A limited circle of people is responsible for its maintenance, which is good, but they only have enough strength to maintain the infrastructure. I assume that they no longer have the energy or time for any innovations, and they are not obliged to do it either. They act on a voluntary basis without receiving any reward other than moral satisfaction and understanding of their own significance for the project.

It seems you’ve missed some of the recent progress in the API space. Most of the productive API code resides in a separate repo nowadays and was written in C++. In particular the changeset upload was rewritten from scratch back in 2019 and now runs about 60 times faster than the old version. As a result of that, we could shut down 3 out of 6 servers, b/c they were no longer needed.

Besides, the API evolved over time:

we’ve added JSON support as an example, retired no longer needed endpoints, password security was enhanced, we’ve added OAuth 2.0 to enable single sign on for this Discourse instance, etc.

Of course, none of this is managed by the OSMF directly, the OSMF doesn’t run the osm website project (I guess you knew that already).

Behind the scenes, there’s much more software running (like osmdbt, planet-dump-ng, Chef cookbooks, osmosis, osm2pgsql, mod_tile…), which you didn’t even mention. Some of it was also sponsored in part by the OSMF.

(Edit: I added “project” above)


I agree with essentially all in the above posting, except the quoted which is patently wrong.

While it might be arguably true that the OSMF dosen’t control the websites code development (though they have in the past directly or indirectly paid for parts of it), not only does the OSMF own all hardware that the site runs on, pays in full for all hosting and employs a full time SRE to keep it running, every user of it and associated services agrees to the OSMFs ToS.

AKA the OSMF runs the OSM website.


Oh, I forgot one important word: it should read as the OSMF doesn’t run the osm website project, quoting from Reimagining the OSM.org · Issue #3785 · openstreetmap/openstreetmap-website · GitHub

Obviously, the hardware, operations and ToS bit is correct, no doubts about that one.


I’m curious: 3 weeks on is anybody doing anything differently as a result of the announcement or planning to do something?

1 Like

Speaking for myself, I am more enlightened by (much of) this thread and will continue to keep my eyes open to this. I think we (OSM Contributors) should keep our eyes open to this and continue to “discuss amongst ourselves.” Maybe this isn’t an ideal space (some heat, some light), but it seems some of us found some value here.

This could be a “landing place” for any news updates our community might wish to post about this topic.

1 Like

Is there anything we can do differently, without knowing a lot more than we do now?


Waiting to see if this results in anything beyond a press release.

Podcast interviewing Marc Prioleau of Overture.