OpenStreetMap

Improving the OSM map - why don't we? [10]

Posted by marczoutendijk on 13 August 2015 in English (English). Last updated on 23 April 2017.

Fix the fixme/FIXME/FixMe/Fixme/Fixme: !!

During my research of the taginfo database, more than once I was staring flabbergasted to the proliferation of keys.
In normal use a single key with its value would give enough information to describe the object you just created. E.g. the shop=* key. The value for that key comes from the suggested values in the wiki.
But what if one shop sells things that belong in various categories from the wiki? Like this one: You cannot add 5 shop keys to one node (which is ok and according to the rules of good database design; any key should exist only once for a given object). Suppose you could, which one should the renderer show? All 5? On the same spot on the map? You must be kidding!
So what now? Should you add a new node for every shop-type, including all the address information? Or should you just tag it with shop=food and possible list all the different values in a note? For this particular case the choice of the mapper wasn’t all that wrong, although I would have preferred a different solution.


### On now to the fixme-chaos! Why are so many people coming up with a new variation on the very well defined fixme key ?
Below you see an overview of the most of those variations.
The number of times used is also in the list. The first (and most used) 2 are:
fixme
FIXME
I do have a question about the second version:
WHY DO WE NEED AN UPPERCASE VERSION?????
Is the FIXME more urgent to fix than the fixme?
Do we have name and NAME, shop and SHOP, landuse and LANDUSE? (For LANDUSE the answer is yes but used only 2498 times, and Landuse is used 31 times. For NAME the answer is alo yes, 393 times).
But do we NEED those uppercase versions?
I don’t care that they are being used probably because of typing errors, I do care about a system which enforces consistent and reliable data entry.

Almost always it is possible to just have one single key and explain in the value of that key what needs to be fixed.
Why:
fixme:admin_level=7,8
and not:
fixme=admin_level should be 7,8
If you argue that it is more clear in this way (at first sight) what needs to be fixed, then I start a proposal that we should start using:
shop:bakery=yes instead of shop=bakery
amenity:bench=yes instead of amenity=bench
landuse:grass=yes instead of landuse=grass
Maybe even better is shop:bakery:yes=true and then use shop:bakery:yes=false for the Butcher?
Got the picture?


One reason I could think of why there exist so many variations is this: Why did the mapper use 4 times FIXME:X (he should have used fixme:x in the first place) and not just put all the city names - that apparently are missing from the map - in one single fixme=longlistofcitynames?
The reason is that no keyvalue can be longer than 255 characters, a stupid limitation that in current database design is absolutely not necessary.
Read the comments to my diary entry and read this.

Why are so many variations a problem?

Given the fact that OSM is a mondial database, it is logical that we need a greater number of tags to describe shops worldwide than we need to describe shops just in the UK. Cultural and social differences are reflected in the database and we should allow for it and respect it.
But so many keys are being used so little that we really need to think about ways to get a more consistent database.
Searching for something is probably the most useful task we keep database for. Tools (like OpenPoiMap rely on consistent data. If you want to know all amenity=atm in a given area, do you expect you have to search for amenity:atm=yes* as well?
With OpenPoiMap you can easily search for fixme or FIXME because this tag is easily available in its list of choices. Do you have some spare time? Then try to fix what what needs to be fixed in London! But for the other 300+ variations of the fixme key, you’re on your own! See my list above.

Conclusion.
Roughly 1300 keys are being used more than 10.000 times and they cover probably 99% of the data in the OSM database. That leaves us with about 53.000 keys with values that no one knows about and probably no one cares either. Do you?

Comment from Warin61 on 13 August 2015 at 23:06

The shop= key .. as an example of a good tag? No I don’t think so.

For example .. a scale model shop … sells

cars … in kit from and ready made aeroplanes … in kit from and ready made ships … in kit from and ready made railways … in kit from and ready made trains … in kit from and ready made parts for making models e.g. paint, bits of metal, plastic, wheels, small nuts and bolts, balsa wood, glues etc

… easy you just tag shop=scale_model But then there is a scale model shop that only sells railway/train models, another that only sells parts for making models…

The shop= key is not a good example of OSM tags. There are a lot of single use values in shop= as an example.

Comment from Warin61 on 13 August 2015 at 23:10

Arr .. I see your using it as an example of what goes wrong. And I agree. I have raised the scale model shop issue on the tagging group .. no one came up with a solution .. or at least I don’t recall it. I’d still trying to think of some way of doing it.

The capitals in a key … like FIXME … well I take the view that all OSM keys and values are lower case. Unless the value is a text entry.

Comment from Warin61 on 13 August 2015 at 23:24

One solution to the shop= key is to allow a second entry for the products sold, similar to the text entry mode of the key opening hours. So for your example shop=food shop_products=greengrocer, bakery, cheese, dairy

I’d take the wheelchair as being an access item rather than a for sale item.

Comment from M!dgard on 14 August 2015 at 00:28

fixme:admin_level=7,8 and not: fixme=admin_level should be 7,8 If you argue that it is more clear in this way (at first sight) what needs to be fixed, then I start a proposal that we should start using: shop:bakery=yes instead of shop=bakery amenity:bench=yes instead of amenity=bench landuse:grass=yes instead of landuse=grass Maybe even better is shop:bakery:yes=true and then use shop:bakery:yes=false for the Butcher? Got the picture?

Yes, we should all start using name_en=, name_nl=, addr_housenumber=, demolished_building=, shop_vending=bread;cheese;vegetables,milk;peanuts;underwear;batteries;books;jam;honey;butter;milk – oops, already had that one.

/sarcasm off

Namespaced keys are useful in their own ways. Keys that normally have just one value, are great for regular tags like amenity=bench, and keys that have multiple values are better expressed in namespaced keys. Admittedly in your example the comment is confusing, but fixme:phone=resurvey is just as clear as fixme=phone number needs resurveying.

Comment from M!dgard on 14 August 2015 at 00:30

For this particular case the choice of the mapper wasn’t all that wrong, although I would have preferred


On now to the fixme-chaos!

I think you forgot to finish your sentence?

Comment from i_am_a_burger on 14 August 2015 at 06:09

“Why are so many people coming up with a new variation on the very well defined fixme key ?”

If you want 2000000 million users and just one “fixme” you obviously need to autocorrect them.

Comment from escada on 14 August 2015 at 13:21

Because we have a free tagging system, we just need more powerful query languages that e.g. ignore upper/lowercase and search for parts of key instead of exact matches. The latter might not be wanted for every query though.

In the software I develop for a living, we also have to ignore the lowercase/uppercase differences for almost all user input. I know low level calls in programming languages like to threat them differently, but in many real life scenarios people just want to ignore it. I think OSM is not different for this.

Furthermore, any query language on OSM should be able to deal with suffixes like that indicate languages. e.g. I see a couple of fix:jp, fix:de etc.

Comment from user_5359 on 29 December 2015 at 07:27

“FIXME” should be capitalized, so it is at an alphabetical sorting on top of the list (JOSM editor).


Login to leave a comment