4.09.2017 | Michael Reichert
The Tagging view of our OpenStreetMap Inspector tool got two new checks (represented as layers) a few days ago. Both look for oddities in OSM data.
The freedom of OpenStreetMap to tag what you want can lead to tagging errors. One common but maybe dangerous error is the usage of tags like disused=yes, abandoned=yes, construction=yes and proposed=yes on objects.
For example, if a mapper wants to map a road which is under construction, they usually tag highway=construction + construction=secondary/tertiary/<whatever>. This is a good way of tagging because data consumers who look for roads and who are not interested in roads under construction can just look at the value of the highway=* key and check if its value is in a defined set of “good” values (primary, secondary, tertiary, …).
Unfortunately, some mappers tend(ed) to use highway=secondary/tertiary/<whatever> + construction=yes in this case. This tagging is misleading. Data users have to check if an object is marked as being under construction. Because a minor key [1] such as disused=* inverts another tag, we call this tagging style “misleading”. OSM should be easy to use and that’s why the tagging of these objects should be improved.
Currently, the processing software only checks for misleading tagging if there is at least one of the following “main” keys and inverting keys:
Main keys are:
highwayrailwayamenityIf the value of a main key is disused, abandoned, razed, dismantled, proposed or construction, it is ignored, further checks are skipped, and the object is not reported as errorenous.
Inverting keys are:
disused=*abandoned=*razed=*dismantled=*construction=*proposed=*Inverting keys with a value of no are ignored because they do not invert the meaning of the main key.
As a side effect, objects with mixed tagging like highway=primary + construction=primary are reported as errors, too. They occur if a mapper changed the object from highway=construction to highway=primary but forgot to remove construction=primary. It is an indicator that these objects might be worth checking.
It occurs rather often that newbies add objects to OSM without proper tags. They manage to add a name, a description and/or a website but that’s it. This is caused by both a lack of experience and a suboptimal user interface of the editor being used (and in rare cases a lack of suitable tags). These objects are more or less hidden from any data consumer because nobody wants to parse the value of a name or description tag to guess what it represents.
The processing software distinguishes between non-feature keys and feature keys.
A key is considered a non-feature key if it begins with one of the following strings:
namedescriptioncommentwebsitecontact:websiteThe following keys are considered being feature keys, i.e. they describe what the object represents:
building, landuse, highway, railway, amenity, shop, natural, waterway, power, barrier, leisure, man_made, tourism, boundary, public_transport, sport, emergency, historic, route, aeroway, place, craft, entrance, playground, aerialway, healthcare, military, building:part, training, traffic_sign, xmas:feature, seamark:type, waterway:sign, university, pipeline, club, golf, junction, historic
The office tag is only a feature tag if it has a value other than yes.
Keys are considered being feature keys if the begin with one of the following strings:
historic, razed, demolished, abandoned, disused, construction, proposed, temporary, TMC
All other keys are considered being neutral and do not influence the evaluation.
If an object has a non-feature key but no feature key it is flagged as an error.
If you find such an object, please check the following:
If you help fixing these errors, you will have to do a lot of research for tags. Consider this a valuable experience – you will learn lots of tags you did not know and you will learn what could be mapped or is mapped at OSM.
Due to changes in OSRM we had to set up our own process which looks for routing errors. We now use Open Source Routing Machine’s “small components” extractor but with the default car profile. Don’t be frightened. There are lots of new errors because our validation is now strict and flags everything which is unreachable using the default car profile most OSRM users probably use.
We added a new layer, called “sinks and sources”. A similar layer existed a few years ago. It will show all one-way roads (using the default OSRM car profile) which lead into nowhere or start nowhere, i.e. are not connected to the network at both ends. See the OSM wiki for
further instructions.
[1] The OSM data model itself does not differentiate between major and minor, more or less important keys. But the usage of tags which has established since 2004 does and there are tags like amenity=shelter which are further distinguished by using shelter_type=*.
