Recently I have learned from discussion here: Failing on the safe side not easy for routing consumers of openstreetmap data, regarding keys with unknown values, eg:
Curiously, the mapping intent of barrier=* supports the “rather not” while the mapping intent – at least to me – of highway=* does not support the “rather not”. Thoughts?
I assume you’re referring to some part of Barrier or Gap on Path, [1] but I’m not really sure exactly what you’re asking. Generally speaking, we map what’s there and then it’s up to data consumers (such as routers) to decide, based on their use case and audience, how they wish to interpret and use the data.
Note: I participated in that thread, with my “work hat” on, as @UW_Amy_Bordenave ↩︎
Creating a digital representation of the real world necessarily requires making simplifications. For example representing a 3D object like a rocky path or a roadway as a 2D line (not even a polygon). But it turns out that those simplifications have eventually allowed us to achieve things like “decently good car routing across the world” that would simply not have happened otherwise.
Achieving even “decently good” is not trivial, and one of the things developers have had to do is to look deeper than merely the OSM key name. Otherwise car routers would be quite surprised if they did assume that anything highway is routable for cars. Similarly pedestrian routers if they assume anything highway is routable for pedestrians.
But maintaining a list of highway values routable for a car is still vastly less effort than trying to compute a route from raw data like a digital terrain model or a bitmap of a scanned paper map. In practice it is probably less error-prone, too.
One of the things one learns as a software developer is to notice, check, and document your assumptions. So chances are a router developer has considered the assumption “absolutely everything tagged highway in OSM is routable for my purposes” at some point, and presumably rejected it.
I think that’s a bit simplified. barrier=* means “Discourage this route”, while highway=* means “Don’t prefer this route”. The difference is slight, and in practice the same (hence your “rather not”), though maybe it helps create an intuition.
An unknown highway=* value could easily mean the vehicle the user is trying to use will not work on the way, and concretely this means there is no default access hierarchy to check against.
I would not waste effort on trying to find general meaning for OSM keys, that rarely - if ever - produces anything useful.
If I would be designing such tool then I would completely ignore unsupported barrier and highway and at the same time detect unhandled values with notable usage and/or wiki page and review them.
To me, that’s rather a question to the router developers than to mappers. I would assume, we mapper try to express the situation as good as “possible”/“we are willing to do”.
Your “failing on the safe side” is a decision done by the router/renderer. Their problem is, that the users measures the usability rather in giving “proper” routes. But proper does not mean always legal and as well proper means avoiding mistakes in OSM. So, yes routers/renderers tend not to fail on the save side.
The issue is that unless you know what certain tag means (and you cannot unless you’ve learned about it specifically) you just can’t assume it will be usable for purpose you intend.
E.g. if you’re writing a router and you default to routing anyone on any highway=*, it will fail horribly if it happens not to be suitable – e.g. if you try to route truck on highway=footway or a pedestrian on many highway=motorway. And both trucks and many pedestrians will fail on highway=via_ferrata, not to mention on highway=no.
Also, just because the key is named highway=*, does not mean the object it is added to is any kind of Highway. That is not how OSM tagging works, it is not an English dictionary. E.g. highway=street_lamp can hardly be used as highway by anyone, yet it is still using the same highway=* key.
Same is with barrier=*, but in other direction. While many values will be blocking some methods of travel (but not necessarily yours, e.g. most pedestrians are able to overcome barrier=kerb), some of them will indicate lack of blockage (e.g. barrier=entrance). Thus, you need to know the full key=value pair, not just key.
TL;DR: both highway=* and barrier=* are too vague by themselves[1], so you really must consider full tag (i.e. both the key and the value; e.g. highway=footway or barrier=kerb) and not just a key (e.g. highway=* or barrier=*) to have any idea about what it is actually intended to mean.
And making decisions without having a clue about what the data you’re processing actually means is generally considered a bad idea.[2]