Some OpenStreetMap Futures

Earlier this year I was invited to give two presentations at the State of the Map US 2015 conference, which was held in the United Nations Headquarters in NYC. What a venue!

As well as an update on the OpenStreetMap Carto project I gave a presentation on what I see as some of the development prospects for OSM over the next few years. Making predictions is hard, especially about the future, etc, but I gave it my best shot.

I think it’ll be interesting to look back in a few years and see how much of what I discuss was prescient, and more interestingly, what topics I missed entirely!

One of the sections that interested me most (and took by far the longest to prepare the slides for) is that looking at who our developers are, and how this changes over time. It’s just before the 18 minute mark in the video if you want to have a look.

Here’s a couple of the charts, which provide food for thought (bear in mind they were produced in June, so the 2015 numbers reflect only the first 6 months of the year):

OSM Developer CohortsOSM Developer Retention ratios

I think the future success of OpenStreetMap depends on improving these figures – we should be aiming to retain at least 40% of our developers after their first year of contributing. We’re clearly getting better at attracting new developers, but what do you think is stopping them from sticking around?

3 thoughts on “Some OpenStreetMap Futures

  1. Matthijs Melissen

    I’m on mobile so I can’t watch the video right now. Could you add labels to the axes?

  2. Pingback: weekly 276 | weekly – semanario – hebdo – săptămânal – haftalık – 週刊 – týdeník – edisi

  3. Philippe Verdy

    Why did those that subscibed in 2011 were able to remain active with a higher rate than those that subscribed later? Was that the year when most public GIS workers adopted OSM more massively? And today we’re back to mostly individuals (that contribute a little in their own area then stop when they don’t find anything to do)?
    May be the rest of the activity is too much technical for most individuals, and we need more tools to assist them in more complex tasks, or some new motivations to help elsewhere: we need more TODO lists, with smaller tasks that can be done and checked more collaboratively even if they don’t live in the areas where tasks must be done.
    There are some good tasks, notably for compiling and comparing many sources of data, resolve them. And probably more servers to prepare data before it can be imported. Working on the mains OSM instance is probably too complex for most users.
    It’s high time to develop separate dataservers for more specific tasks which are easier to do, in order to prepare data with higher quality before it is imported/merged into the main OSM instance. We cannot just live with aerial/satellite imagery (something that just works in areas with low density of data, such as those selected for HOT projects).
    Even in poor countries, many sources have lot of official data but poor geolocalisation and it’s difficult to integrat them with the level of geographic accuracy needed to merge them in the main OSM instance: e.g. lists of villages, difficulties to find accurate toponymy (unstable orthography, many homonyms).

    We need to go further in the adminsitrative subdivisions, to help resolve many cases of ambiguities due to the toponymy. We need more extensive or exhaustive lists for important specific features : major roads, lists of streets in cities, postal codes. and there are lot of data in statistic reports that can be used to determine what is missing: we could locate on a project map list of missing items that need to be geolocalized more precisely, but we should still be able to produce exhaustive maps with darft boundaries even if they cannot be merged in the main dataset.

    The future of OSM cannot be with a single merged database mixing everything. We need simpler views that are easier to complete, and then refine progressively before they can be imported in the main database, and visual tools to compare these views and help preparing their merge.

    We also need tools to track incoming changes in the existing datasources: it is really too difficult to follow these changes and know what to do in the main database (we don’t know if what is in the main database is already more accurate than the incoming change in the datasource, when a first version was already imported, but modified in OSM later).

    Finally, notes in the OSM databse is essential to help qualify the data. It must become an integral part of the data.

    My opjion is that the OSM data model is largely insufficient and does not cover the needs correctly. It was designed only if all data was maximaly accurate the first time and would never have to be improved or changed later.

    And we still don’t have any tool or method to select sources in case of conflicting edits, using some form of consensus. Everyone works basically alone and does everything he wants or he thinks is good for all others. We also work as if everyone or every project was interested in the same level of details or accuracy.

Comments are closed.