Suche // Archiv

Das Buch

Die freie Weltkarte nutzen und mitgestalten.
Von Frederik Ramm
und Jochen Topf.


Karlsruhe Hack Weekend 18.-19. Februar 2017

FOSSGIS 2017 in Passau, 22.-25. März 2017


Tagging and Routing View Got Additional Layers

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.

Hidden Non-Operational Tagging

screen shot of OSM Inspector showing a toilet with disused=yes

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:

  • highway
  • railway
  • amenity

If 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.

Name/Description without Important Tags

screen shot of OSM Inspector showing a node which onyl has a name tag

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:

  • name
  • description
  • comment
  • website
  • contact:website

The 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.

How To Repair?

If you find such an object, please check the following:

  • If the object has a description tag and the description contains either non-factual information “the best bakery in A-Town, founded by James Smith in 1786″, it might be some kind of search engine optimization. Remove all non-factual information (it might be justified to delete the description completely).
  • If the object has a website tag, check if the website still exists. We don’t need closed shops.
  • Check if the object is located properly. If it is obviously wrong (e.g. center of the road) or on top of an existing object, it might have been be uploaded automatically.
  • Look for a proper tagging of the object. Add these tags. There are various sources of information:
  • Is the user a newbie and joined OSM recently? If yes, write a friendly welcome message. If it is more than a month ago and they is not active any more, use your time for more useful tasks.

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.

Changes To The Routing View

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.

screen shot of OSMI showing islands and sinks & sources layer

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=*.