Recent diary entries
Recently I stumbled over the key "lines". According to taginfo there exist about 6500 objects with this key, a number that has been decreasing the last days as I deleted quite a lot of them (the keys, not the objects). From what I see there are 3 different usages of this key:
to tag which public transport lines are serviced here, so this may be a lines=U1 on a railway=subway or even on a railway=platform. Whereever I found that and the object was already part of a proper type=route route=(some public transport thing) for all of the lines keys, I simply deleted them. Given the relatively small number of these object noone can create any reasonable public transport information from these tags. public_transport relations do a far better job for them, and they are much more popular. Given the age of almost every instance of these keys on the objects they clearly predate the public_transport relations, and simply had not been removed when the relations were introduced. So whenever you care for public transport tagging anywhere please check if there are lines keys in the objects you edit, and if their information is contained in a proper relation, then just remove the lines keys.
to tag something that has a different key. I clicked a bit around in the OverPass queries linked from the taginfo page and any instance I found highway=* lines=* it should have been "lanes" instead. There are also some instances of railway=* lines=*, where I guess tracks would be the right key (at least for lines=1 and lines=2). In case you want to touch any of them: prefer to tag every track as it's own way and not use the "tracks" key. I assume that almost any combination of lines with either highway or railway is wrong and should be fixed.
to tag something entirely different. There is one instance of lines=1 in North America where this gives the number of power lines between poles. There are some instances of lines=phone where this tells you that there are telephone wires. There are some instances of lines=no or yes which tell you that this is a basketball court that may or may not have markings. I personally would not touch these taggings as it is clear to a human what they mean, and deleting them without replacing it with a proper tagging would destroy information (how relevant or not they may be).
From my point of view it would be great if all instances of #1 and #2 would be removed from the database. But simply deleting them is not the way forward, one should do it with care. The way to get rid of the greatest numbers of them is to introduce proper public_transport relations where they are missing, e.g. for some of the S-Bahn lines in Hamburg or U-Bahn in Stuttgart. In case you are bored and any of these tags are in an area you care about: check what is the proper tagging, and let's get rid of lines.
In the last days I mailed a lot of people about unusual values in their fire_hydrant tagging. The most important one was fire_hydrant:type, where some more or less unique values are already gone and replaced by the more common tagging. One nice thing were 3 things that were in fact no emergency=fire_hydrant, but emergency=water_tank. But since the original contributor was unsure on how exactly to tag these things he added an image tag to each of them, showing a photo. This way I could easily point him to the right direction, and as a nice side effect one of these images can now be seen on the wiki page for emergency=water_tank. Until now I only mailed those people that I was rather sure to understand either German or English and left out the Russian, Spanish (could also be Portugese or Italian, no idea), and French ones.
In the process of cleaning things up I learned that the New Tags JOSM presets, which I didn't know about before, introduced wrong tagging. It wrote the German names to the tag field instead of the English ones. Since this isn't exactly a new tag and JOSM already has a working template for this, I simply removed emergency=fire_hydrant from this presets.
Today I made the mistake to look into fire_hydrant:position values. This is probably unusable for any automated application, at least outside of your local clean area. There is a huge amount of inconsistent tagging in all sorts of languages. If I were really bored I would try to get clearance for a mechanical edit and would at start with deleting every fire_hydrant:* attribute that has an empty value. But sadly I'm not that bored, so any volunteers are welcome.
As an active firefighter I of course know about OpenFireMap. And I knew of highway=emergency_access_point way before the Weekly Task caused many more of them appearing in the database. But I always wanted to have something that is not a website, and something where I can customize what is shown.
Using the awesome library of Marble I was able to hack together OSMhyd, a Qt-based application that shows fire hydrants, water tanks and emergency access points. Of course this is far from complete, but maybe it serves someone else as inspiration.
If you are interested a bit more in the technical details and future directions I've written a bit more about that in my KDE related blog post.