Measure Quality of our Map with Notes.

Here is another use of key value pairs for OSM notes (

Several times i have read a discussion about quality assurance of our map data. Often this results in a comparison with software projects, that uses a staging mechanism.

a) Test Environment
b) PreProd Environment
c) Productive Environment

Software is tested and moved from a) to b) and hopefully error free :slight_smile: to c).

Our way for the data of OSM is completely different. And I am sure, we can’t turn it in a way software developers deploy their software.

If someone having an OSM account is pressing „UPLOAD“ , the data is live. Untested, not reviewed.
This live data is very quickly review by many mappers using RSS feeds for modifications in their area. Or mappers simple use OSM Data and notice errors.
And typically mappers are very fast in removing them.

In the past, all data consumers try to use the most recent data of OSM, and - as a result - our fast bug fixing is reflected in their maps. This works of course for online maps, with a short update cycle.

With increasing mobile devices offline usage is getting more and more popular (and free offline data is an OSM USP).

If one generate now an offline map, one does not know the quality of the data.
There can be errors, they do not want to have in their maps. I just refer to, to show what I mean.

One can not know, wether the export contains such a „smaller“ bug or not.
Of course, if you surf all forums and mailing list, you will find a „talk“ about that. But no structured information.

With key value pairs we can tag a "start Date“. The start date can be set when entering the note in the database. It can be set to the date of the changeset, if a specific changeset has produced the error. If the bug is fixed, the note is closed and gets the end date.

With categories like

regards: Landuse or
regards: motorway

an data consumer can measure the Quality of an export at one time in one region, for the usage he has, and can generate an offline map, with minimized relevant error count.

As a result we will add an quality information stream in parallel to our data stream we are providing.

edit 1+2: Typos