Where we see the project going, and the path to getting there.

OpenStreetMap flows throughout Development Seed’s work. We are contributors, validators, software developers, maintainers, and users of OSM data and tools. We are inspired by the project, and the mission to empower everyone in the world to put themselves on the map. From this vantage, we lay out some important trends that we see shaping the near future of OSM and share our thoughts on the tools and systems that we will need to get the remaining billions onto the map.

OpenStreetMap is growing at an incredible pace. The project has crossed nearly six million contributors. Billions more people rely on OSM data that powers a wide range of apps — from powering the maps of Snapchat, to providing the location data in games like Minecraft, to supporting lifesaving insights to first responders and public health workers. As the project grows and evolves, so too does the nature of the work to collect, maintain, improve, and use this data.

We believe that these trends will shape the future of the project.

As more of the world is mapped in OSM, a higher percentage of the work will be verifying and improving the map, and greater attention paid on data that is contextual and locally sourced. Improving accuracy and utility of AI will empower mappers and validators to make the map better, faster. Organized efforts and institutions will have a greater interest and role in systematically improving and maintaining the map. Imperatives for accurate data will lead to bigger investments in verification and change detection.

I’ll take each of these in turn and talk about the implications for OSM and the tools that will be needed to support and adapt to these trends.

A higher percentage of the work will be verifying and improving the map.

Just yesterday, over 2 million nodes were added to OSM. While this number itself doesn’t tell us anything about the quality and nature of the mapping task, it tells us the importance of continued verification of OpenStreetMap data. There’s an inherent amount of trust users have with maps — and OpenStreetMap is now the trusted data source for many applications.

Along with improvements to remote mapping workflows, we have to think about field verification as a core aspect of OpenStreetMap mapping. As we exhaust data that can be traced directly from satellite imagery through arm-chair mapping, our efforts will focus more on verifying and improving existing data. It becomes important to reflect some level of temporality to improve the context of the map data. Does this bus stop actually exist? Has this building roof type changed since it was mapped?

Field mapping is a huge part of bringing communities together, but there’s a gap between what needs verification and what’s being verified. We need tools that can surface the bus stop in need of verification by mappers who are nearby. Tools like StreetComplete are headed in the right direction, asking users to map missing attributes from the street network. Development Seed has been building Observe — a cross-platform, offline field mapping tool. Observe, at the moment, only works for points of interest (POIs), but in the next few months we will add full editing capabilities and annotation functionality. There can be several versions of Observe that target specific user groups, for example, mappers interested in adding trees or health centers. Another interesting tool is Digital Democracy’s Mapeo — an offline survey application with peer-to-peer capabilities. OSM data verification requires the combination of mobile map editors alongside useful surveying applications. Combining these powerful tools with an increasing population who are online and connected will yield more ground-truth data and maps that reflect communities’ priorities.

AI will empower mappers and validators to make the map better, faster.

Machine Learning and AI is used by several groups in OpenStreetMap to map new areas faster. This will become central to armchair mapping workflows. Over the next few months, we’ll see this more tightly integrated into existing tools like Tasking Manager and JOSM. There’s broad agreement within the community on how to deploy these techniques to improve the map.

mapwith.ai from Facebook

Our team has been working with the Humanitarian OpenStreetMap Team to build an array of models and integration tools like ML Enabler. ML Enabler is meant to become a universal registry for ML models that can be used to improve OpenStreetMap. Recently, Facebook announced RapiD — a version of the iD editor with AI assistance integrated with state of the art machine learning and conflation for way geometries. Microsoft has been on the forefront of producing high quality building footprints using machine learning models for the US and many parts of Africa.

In the short-term, we’ll see these data sets directly integrated into editing tools. Tools like Tasking Manager will serve a higher purpose beyond acting as a mapping management tool. In anticipation of this, we’ve begun integrating ML Enabler to JOSM, which will allow any mapper to see available model predictions directly from within JOSM, reducing the amount of time spent switching between tools. The most important aspect of the ML workflow will assist the mapper and help them do their tasks better.

Organized efforts and institutions will have a greater interest and role in systematically improving and maintaining the map.

Coordinated mapping campaigns already represent the majority of OSM mapping. As more institutions rely on OSM data, we expect that trend to accelerate. OSM software and approaches weren’t built with these efforts in mind and that has lead to frustration from organized mappers and other OSM contributors.

Figure by Jennings Anderson which shows where corporate editors are editing. https://www.mdpi.com/2220-9964/8/5/232/htm

The community is beginning to build processes to regulate transparency and accountability for both paid and unpaid contributions in OSM. For the first time in its history, OpenStreetMap has a Directed Editing Policy, which promotes the global adoption of best practices in an effort to increase the quality of all map contributions and ensure they are meaningful.

As groups like Humanitarian OpenStreetMap Team, Facebook, Microsoft, Amazon, Mapbox and Apple increase their investment in OSM, they will need different tools to manage their contributions, and the rest of the community will need to be able to understand the extent of these contributions and their impact on coverage and quality of the map.

The tools in OpenStreetMap have a very loose definition of organizations and associations. We believe that OSM needs clear and persistent teams and associations across the OSM ecosystem. A few tools like OSMCha and Tasking Manager are developing a concept of teams within their apps. But those teams aren’t shared across tools. Tools like iD and JOSM are unaware of these teams.

To address this, we are building OSM Teams — a social glue for applications in the OSM ecosystem. The project is currently in early beta release. We are extremely grateful for all the feedback we’ve received so far online and at the State of the Map conferences in Minneapolis and Heidelberg. We are currently working on integrating Teams to OSMCha and are beginning to develop a project roadmap with other tool maintainers. We invite folks to contribute to the project themselves, and appreciate any feedback on how to build a meaningful notion of teams across OSM applications.

Bigger investments in change detection and analytics.

Most urban planners use maps that are out-of-date. Maintaining an accurate map is a struggle for any city, but the ones growing the fastest often have the fewest resources to put towards mapmaking. These cities may also be the most vulnerable, and most complex for businesses and planners to operate in. OpenStreetMap is already paving the way to solve some of these challenges.

Identifying what areas need attention on the map as time goes on is something that hasn’t been attempted at a very large scale in OSM. When a new residential unit or bridge is detected, informing mappers to verify and update the map will become an essential workflow in the future. This requires investment in change detection and analytics.

With a growing number of volunteers and mapping tasks, matching mappers to tasks is crucial. Looking for the right task to map can sometimes be tedious and involves opening them in the editor. Insights are not available at the task selection. New mappers should automatically see ‘easier’ tasks first, validation will be available only to ‘experienced’ mappers, and certain users can map specific features ‘faster’ than others. This will reduce the overall amount of time users spend on tools like Tasking Manager looking for the right task to map.

Tools like OSMesa and historic QA Tiles snapshots will find their way to more tools than what they’re currently used in. Our own user analytics platform, Scoreboard, relies on OSMesa — an OSM data processing stack based on GeoTrellis. Scoreboard provides metrics and motivation for mappers by rewarding contributions, promoting campaigns, and reporting current mapper statistics. Our next steps for Scoreboard include aggregating team statistics and engaging users with personalized notifications and greater administrative capabilities.

OpenStreetMap is more powerful if we make it easier to map together. We’re excited to continue playing a part in building tools for OSM and supporting the community as it grows. Let us know your thoughts or if you’re using any of the tools above by giving us a shout @developmentseed. And if you want to help us build further and faster, take a look at our open positions to join our team!