Issues with OSM quality assurance tools


Meanwhile there exist a bunch of tools which try to indicate errors in the OSM data, such as Openstreetbugs, the OSM Inspector or various tools written by Gary68. I find such tools important and cool, but in the past I have seen some disadvantages.

Ages ago, we used maplint to detect errors. It was very helpful, but sometimes it also was annoying to get mentioned of “false positives” over and over again. For example, it helped us a lot to detect residential ways without a name:


But we also learned, that there sometimes are residentials without a name. There are even complete villages with no street names (or even housenumbers).

In such situations, QA tools seduce mappers to do inadequate mapping to please the tool. In the aforementioned case, mappers might tend to add a name tag to the street with an empty value (name=""). This obviously is worse than having no name at all, as now streets with empty names might appear in navigation tools, name comparison QA tools and the like.

Just yesterday I played with Navit on my N810. I did some routing tests at O?wi?cim, Poland, which I mapped in January. There is an unclassified which leads over a tertiary and a railway, using a bridge. I mapped it live using osm2go while sitting in a bus on my way from Auschwitz-Birkenau back to Auschwitz I. Due to the speed of the bus, I missed to map the unclassified as a bridge. Someone then seems to have added a crossing between the unclassified and the tertiary, maybe mislead by some QA tool. Now Navit fails in proper routing, due to incorrect data. Pay attention to the red circle, where there is no junction at all, but the unclassified is on a bridge:


What do you do if your navigation gadget just tells you to turn left while you are on a bridge ;-) ?

Today I received a message about a roman highway I mapped recently. indicated that it was not connected to the crossing tracks:


I did this with reason. The ancient highway is visible as a slightly raised dedicated track, covered with trees nowadays. It will, however, be reconstructed until 2011. That’s why I mapped it as an unconnected track. At least the tool offers to mark it as a false positive, but I meanwhile connected it to the other tracks as there are further tools out there, so someone will likely connect them sooner or later anyway. A typical situation of mismapping according to QA tools.

I also could have the roman highway interseced around the crossings. I didn’t, as there is a “touch checker” out in the wild which tries to detect unconnected ways. It currently does this only for major highways, but I can imagine that it will be expanded one day.

Sometimes there is more than one way to map things. In the community, there might be several fractions, and they may have good reaons for their point of views. For example, there is some fuzzyness between highway=footway and highway=path. Even worse, there are several schemes to map house numbers. It seems that the Karlsruhe Schema gets widely adopted, but this does not necessarily mean that it is just plain wrong to use another scheme.

Openstreetmap uses plain text, english language tags to apply attributes to geographical objects in the database. The german community, one of the most active within the project, acquired this habit. Sometimes this leads to funny situations, where german mappers invent english tags which native speakers do not understand. For example, I introduced highway=stanchion for bollards back in 2006 (which meanwhile have been changed to highway=bollard).

Parts of the british community do not understand why other countries do not just use tags in their local mother tongue. Technically it was doable to read and interpret such tags as well. If China ever will be mapped, it is unlikely that they won’t use their own language for mapping, and it would be useful if our infrastructure was prepared unitl then.

Some time back, I started to map hunting stands, just for fun. I used german language tags (actually the humorous Annehmlichkeit=Hochsitz to highlight the educational intention) to map them, as the osm database was kept open to allow exactly this. I then wrote a tool to extract the hunting stands and to display them on top of a map:


One day I noticed on-site that the hunting stands are gone. I checked the data back home and noticed that someone converted the german tags to english tags without any need. This was an unnecessary action and a complete misinterpretion what QA is all about. Well, maybe it was just to prove german stubbornness ;-) .

So what’s the conclusion? Openstreetmap data needs quality assurance, that’s out of the question. But I’d ask anyone involved to consider the following points:

  • If you write a QA tool, it is worth considering the presentation of the errors. If they are decent, mappers will not tend to mismap something just to please your tool.
  • Be prepared to improve your tool, so it can be updated to reduce the amount of false positives. »My tool is not perfect« is a weak point.
  • If possible, allow to mark false positives as such (e.g. like does).
  • If you are fixing bugs indicated by a QA tool, do not fix things based on assumptions.
  • Last but not least, treat such tools as what they are. We are mapping the reality, which is complex. The tools can help us to improve the data, but a human being always must make the final decision.