The Overture open-mapping project

We're bad at marketing

We can admit it, marketing is not our strong suit. Our strength is writing the kind of articles that developers, administrators, and free-software supporters depend on to know what is going on in the Linux world. Please subscribe today to help us keep doing that, and so we don’t have to get good at marketing.

Once upon a time, not too long ago, Prioleau began, map making was mostly done by surveying — sending somebody out to measure where things were. That has changed over the last couple of decades with the advent of location-aware mobile devices; map making is now driven by sensors, not surveyors. That has changed the nature of maps and how they are used; Overture Maps was created to take advantage of (and support) those changes. The project is still in its early days, but it has the support of a long list of companies and is already being used by some of them.

Overture Maps was created to change the model for map production. The amount of available mapping data has exploded, he said, and the types of that data have changed. Maps that were once concerned with just the road network have grown to include information about speed limits, road signage, lane usage, and more. There may never be a world where all of this data is open, but there is space for a set of common base layers to tie it all together. These base layers might contain information about roads — their route, geometry, and directionality, for example — while letting others attach value-added data like traffic information. As has been seen in other areas, companies can cooperate in the creation of the foundational layers, while adding their special products on top.

The companies that initially sponsored Overture Maps had all been working on OpenStreetMap previously, but they had needs that were not being fully met there. For example, they want to use all of the available mapping data, much of which does not appear in OpenStreetMap; this data includes some government mapping data and the increasing amount of data generated by machine-learning systems. There is a need for a high degree of validation of this data; maps reflect facts, and there need to be protections to keep people from changing those facts. Among other things, Overture Maps uses machine-learning systems to validate map data.

That data also must be presented in an organized scheme, in a way that makes it easy for others to attach additional data to it. This process is called, for better or worse, "conflation". Overture Maps supports this functionality via a mechanism called the Global Entity Reference System (GERS). Every item of interest in a map is assigned a permanent GERS ID, which is a 128-bit identifier. GERS, he said, might be the most significant part of the entire Overture Maps effort; it makes conflation simple, easing the use of map data.

Mapping data can be divided into over a dozen data types, called "themes"; Overture Maps currently supports six of them. The transportation theme covers the road network, including information on public transit, cycling, and more. Places covers points of interest — primarily businesses. This is the most annoying data type to manage, since it is highly volatile and businesses often don't bother to notify the world when they cease to exist. Divisions are administrative boundaries, from national borders to neighborhood boundaries. Buildings is exactly what it seems, as is the addresses theme. Finally, the base theme covers geographical features, including ground cover, water features, and more.

One of the key features of Overture Maps, he said, is integrating data from multiple sources. As an example, the latest release included over 20 million new Japanese addresses, along with building data from both OpenStreetMap and the Microsoft building footprints database, which was machine-generated from satellite data. It turns out that the OpenStreetMap data is more complete in the cities, where the contributors live, while the Microsoft database is more complete in rural areas.

Returning to GERS, Prioleau said that mapping is being driven by an explosion of data types. But only some types are "exploding". The road network, while constantly changing, is relatively easy to keep up with; the same is true of addresses and such. This kind of data is manageable as a shared base layer that all can contribute to and use. The attached layers, though, which might include traffic data, restaurant reviews, opening hours, or any other sort of add-on data, are far too volatile to be managed in an open layer. This data will, he said, continue to be a proprietary product indefinitely.

For years, these add-on data types have been fragmented into numerous incompatible formats. Integrating the data into a useful product has often been more expensive than acquiring it in the first place. If everybody could agree on a global ID for mapping data, though, a lot of these problems would go away; GERS is meant to be that ID.

Being in Japan, Prioleau took a moment in his conclusion to talk about the automotive industry, which is collecting vast amounts of data as its cars phone home. (He did not address the privacy implications of this data collection). Manufacturers see this data as valuable, but have not always been able to realize that value. Identifying this data with GERS IDs would make it easy for these manufacturers to contribute some of the data to Overture Maps, and for them to use the rest to add value to their products. One manufacturer, for example, is looking at detecting a car's wheels slipping on ice, and sending an icy-roads notification to other cars operating in the area.

Once the talk was done, I could not resist asking the obvious question: why create a new project rather than focusing these resources on making OpenStreetMap better? Prioleau answered that he has been an OpenStreetMap contributor for nearly 20 years; it is far from clear, he said, that the project wants much of the work that is being done in Overture Maps. OpenStreetMap is focused on creating a community of mappers; dumping a bunch of AI-generated data into the project is not the best way to encourage that community.

The companies that launched Overture Maps first tried hard to turn OpenStreetMap into the sort of project they needed, he said; the OpenStreetMap contributors "successfully fended that off". So Overture Maps was created with a focus on the end users of the data rather than on the contributors. While a bit over half of the project's data comes from OpenStreetMap now, he said, he expects that proportion to fall in the future.

An interesting way to look at these two projects, perhaps, is to see OpenStreetMap as being analogous to a typical free-software development project, while Overture Maps is more like a distributor. The former is focused on its development community, while the latter is working on integrating the results of various mapping projects, performing quality control, and producing something that is easily usable by others. So, while the two projects might appear to be in competition at one level, there may actually be a useful role for both of them in the end.

[ Thanks to the Linux Foundation, LWN's travel sponsor, for supporting our travel to this event. ]