OSM2go has always been my favorite editor when I’m doing live mapping. Even if I have a Jolla 1 meanwhile I still carry around my N900 for the mapping things. There have been quite a few things that annoyed me nevertheless, like when I wanted to apply the tags of the last object to the current one it would ask if I want to overwrite the current tags. Even if there were none. So one day in April 2013 I sat down and hacked something together that would just fix that. Then I tried sending them to AMDmi3, who forked OSM2go on GitHub to give it some love. I failed to actually attach the patches, so nothing happened.

At the beginning of May 2016, I already had created an account on GitHub to throw some PRs on rurseekatze to beat OpenRailwayMap into shape. I found my old OSM2go patches on my disk and decided to finally get them upstream.

It took a few weeks before they were accepted, but then AMDmi3 probably feared that I would cause him more work with PRs, and he decided to just give me push access. Guess what, I did some commits.

Things have changed a bit since then: I have reworked the internal logic to use C++ instead of C. Using a std::map to map from an object id to it’s contents is just way more efficient than have an unsorted single linked list of them, with an additional cache for faster lookup. Sometimes this also creates additional opportunities to improve code, especially as the original code was extremely inefficient and could have been reduced to only run one loop even with the old C code. Those changes reduced the memory usage by several MB on larger projects, which is a big win on a device with only 256 MiB of RAM like the N900. Rewriting the track parser to not keep the whole XML in memory while parsing a GPX track reduced the time to open one of my projects 223 to 24 seconds. The presets menu can now work with nested folder, the presets (derived from JOSM ones) have been updated, when defining the area for a project you can now see the areas of the other projects and so on: I’m quite happy with what I now have.

And 2 weeks ago I finally was able to solve a mystery that bugged me for quite a while: why did HDYC only show JOSM and Potlatch as the editors I used? A few years ago I did quite some changes directly from my N900 using OSM2go, so what was happening there? Turned out that this had been broken ever since OSM2go added support for API 0.6, but it’s finally fixed and indeed HDYC now shows OSM2go again.

Just 2 questions remain: will I ever manage to build a Qt5 version of OSM2go so I can use it on my Jolla and do not need to carry around 2 phones all the time? And is anyone besides me actually using this?

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:

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

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

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