Improving the OSM map - Why don't we? Posted by marczoutendijk on 9 March 2015 in English (English). Last updated on 23 April 2017.
I will start a new series of comments on the current mapping problems and curiosities that I encounter with OSM.
On this wikipage it can be seen that the preferred way of tagging the entrance of a building is by means of the entrance=* tag and that the building=entrance tag is now deprecated.
With OpenPoiMap I began to explore the world to see how this is being carried out. I started with this code in the User Pois box (without the numbers, they are there to help me clarify the images that follow).
- building=entrance 
- entrance=yes 
- entrance=main 
Then I visited Helsinki and saw this map where I have selected all the deprecated building=entrance tags.
Now the same with all the good tags ( and )
And here everything together:
Finally I went to Paris and found no deprecated tags.
I tried the same with other cities and found more or less the same situation. Sometimes no deprecated tags, but too many times I saw too much deprecated tags. This leads to the situation that it becomes more and more complex to create tools that deal with this data in a consistent way because the data itself is inconsistent. Is that what we want?
The community has decided (did they really?) that using building=entrance is no longer the correct way of tagging the entrance of a building. It is easy to change such an incorrect tagging, and steps have been taken to do just that. But they were reverted on the ground that it was a mechanical (unapproved) edit.
So what next? Will we stay forever with a database containing stuff we don’t want it to contain? Or are we taking steps to (re)create a healthy database?
Comment from AndiG88 on 9 March 2015 at 22:10
Just wait 5 years until enough people use the new tag and the old one falls of and more people remove it. Aparently that’s how people here want it.
Because of that I have currenly lost my interest in OSM. It’s just too slow and too anoying if you want to change any kind of tagging. Why do we still have amenity=emergency_phone in the database? That’s just bullshit….
Comment from escada on 10 March 2015 at 16:45
On one hand, it is better to have one tagging scheme for 1 feature. On the other hand you have just showed how easy it is to retrieve data using the different tagging scheme’s. So you might wonder why it is a problem to have different schema’s in place.
Maybe we should just develop a query language that can deal with different schemas and synonyms.
Comment from marczoutendijk on 11 March 2015 at 21:31
Escada, the point is that for every redundant tag (as is the case with the entrance key), programmers have to take into account every weird combination of tags in order to have the program work. But it is impossible to take all these combinations into account because one doesn’t know them all. In my next story I’ll show some of those.
The next link from taglocator shows the problem: http://mijndev.openstreetmap.nl/~marczoutendijk/openpoimap/taglocator.html?map=amenity&zoom=18&lat=60.16636&lon=24.9395&layers=B00FFFFFFFFFTFFFFFFFF
This church is shown with 3 markers because the entrance is marked in the deprecated way (building=entrance). The more inconsistency in the database the more problems show up when trying to get the data work for you.
Remember: Garbage In, Garbage out.
Comment from flohoff on 15 March 2015 at 14:24
I dont really see the point. The problem with “entrance=*” or “building=entrance” is that there is no use case. If there would be user you would have a feedback loop for people to change their tagging. No user of your data -> broken data.
This is why i am against tagging every little small detail to obscure tags. As long as there is no use case there wont be any maintenance. This is for example true for number of parking lots on an amenity=parking or stuff.
Comment from Rostranimin on 24 March 2015 at 12:33
You raise an interesting issue… I’ve been reflecting on this kind of thing quite a lot recently. I’ve been discussing the advantages and disadvantages of different mapping systems (maps, data, open data, etc) - often in conversation with people who aren’t converted to see why OSM is useful. I’m now very much in the habit of saying that OSM is “just another tool”. I want to make clear that sometimes we should look to OSM, and other times we should look to another data/map source (Ordnance Survey being the obvious one discussed in the UK). The point is that these are different data sources… each with their advantages and disadvantages. When I want to know the precise location of something at street level, then (if the data is up to date) I go to the most precise Ordnance Survey data. When I want to know what paths and cycle paths are considered important in a town I start with OSM.
My point… OSM is what it is precisely because of how it works. This means that some things will be imperfect and potentially really really irritating. But it is what it is because of how it works. So we should do our best to improve the irritating stuff, but if it can’t be fixed then we need to learn to live with it. I have a list of really really big irritations with OSM, but I also use OSM mapping as my preferred navigation tool when on a bike because it’s the best source of information.
The beauty (and pain) of crowdsourced data and open source (etc)….
Comment from Alexandre de Menezes on 26 March 2015 at 19:30
How about automatically converting “building=entrance” to “entrance=yes”? It should no be hard to do this for the entire database. A slightly more complicated tool would covert it to “entrance=main” if it is the only entrance to the building, or some more appropriate rule.
Comment from marczoutendijk on 26 March 2015 at 19:43
Please reread the last two paragraphs of my post, because what you propose is exactly what has been done by someone, but then it was reverted by another person on the grounds that it was a mechanical edit.