Just wanted to say that I’ve been back from my journey through Italy for one week now.

OSM Route Manager and OSM History Viewer are working again, they had problems due to a full server disk. Furthermore, the server was down for about two weeks in August.

The cdauth’s map layers are working again, many of them had been broken due to OpenLayers API changes.

During the next weeks, I will upload the GPS traces of my journey (and probably create lots of highway=road as well as camping sites and supermarkets) and continue the work on OSM History Viewer and the new OpenStreetBugs client.

Unfortunately, mapping is kind of hard for me at the moment, as both the displays of my camera and my GPS device don’t work anymore (the latter is actually “broken”…). Fortunately though, I’ve got to know some mappers in my area (as well as have gotten mappers some people I know), so maybe some of us will do one or another tiny mapping party some day.

The first part of OSM History Viewer, the changeset visualisation tool, is ready for testing on http://osm.cdauth.de/history-viewer/ (I haven’t tested it much yet, so it could be really buggy).

During the analysis of the changeset, all ways that were changed are split into segments (connections of two nodes). Then the versions before and after the changeset are checked if they contain the segment. Segments that only exist in the old version are marked red, those that only exist in the new version are marked green, segments that exist in both versions (and thus were not changed) are marked blue. This way, you can see what exactly has changed, if someone only combined or split a way, this will not be marked as a changed (instead, it will be coloured blue).

One problem I am facing right now is that a single node movement can cause a way to change without the way being mentioned in the changeset. There is no way in the current API to find out which ways a node belonged to at a specified point in time. I can only guess this at the moment, maybe I will parse the history view on the OSM homepage in the future, as the way membership seems to be listed there.

A tag change visualisation will also be part of the changeset visualisation in the future, visualising which tags have been added, removed or changed on which way or node.

The second feature coming with OSM History Viewer will be a relation history analysis tool. It will be possible to show the changes on a relation (with all its members and sub-members) in a specified changeset as well as displaying who added which part to the current version of the relation (“blame” view).

… See full entry

I am currently developing a web tool to analyse the history of OSM elements visually. There will be two modes available:
1. Visualise changeset: This will highlight any changes made in a changeset on the map.
2. “Blame”: This will visualise who is responsible for removing or adding which part of a relation.

The reason why I need this tool is that recently, lots of errors are being added to cycle route relations I maintain. Sometimes, this happens by mistake (because someone extended a way that was part of the relation for example), sometimes on purpose (someone is not aware that the route runs another way now). In both cases, it is useful to write to the person that did the change to inform him about what he did wrong. But it is not always easy to find out who made a certain change, one main reason seems to be people splitting ways and thus adding certain ways to the relation. The person who has added a way to a relation that should not belong to it may not always be the person who did this mistake, it might be someone who split a way that errorneously was part of the relation.
Thus my History Analyser will work on per-node basis: if the nodes of a way added to a relation were previously part of another way belonging to the relation, this will not be considered to be a change. Accordingly, a way whose tags but not whose nodes were changed will not be visualised as having changed. Only the part of a way whose nodes have changed will be considered to have changed. Sub-relation support will also be implemented for better route analysis.

… See full entry

Auf einer Wanderung heute ist mir aufgefallen, dass hier am bayerischen Alpenrand abgesehen von vielen Wanderwegen auch noch einige Ortsbezeichnungen fehlen, und zwar einige Gipfel (natural=peak), ein paar Weiler (place=hamlet) und einige Almen oder andere benannten Plätze (place=locality). Die Einheimischen kennen und verwenden die Namen dieser Orte, als Nicht-Einheimischer ist es aber schwer, sie herauszufinden, da sie nirgends aufgeschrieben sind.

Es war so viel los, dass ich doch nur ein paar Straßen aufgezeichnet habe.

Werde nun in Ober- und Niederaudorf ein wenig aufzeichnen, Einbau erfolgt demnächst.

Schliersee-Neuhaus- und Bayrischzell-Geitau-Einbau komplett.

Neuhaus (Schliersee) und Geitau (Bayrischzell) komplett aufgezeichnet, Einbau folgt.

I played around a bit with OpenLayers and built a map that does pretty much everything I want. The map is available on http://osm.cdauth.de/map/. You can view OpenStreetMap data (Mapnik, Osmarender, Cyclemap, OpenStreetBrowser, Minutely Mapnik, and Hiking map; PSV- and piste map following soon), TeleAtlas data (Google Maps), Navteq data (Yahoo maps) and other geo data (OpenAerialMap, Relief map). It saves the current view in the URL hash part, so you always have a Permalink in your address bar. The OpenStreetMap Namefinder is also implemented. You can create Markers just by clicking on the map. My map might however still be pretty buggy at the moment.

Trying to complete the Bodenseerundweg cycle route, but the relation support in the new API seems to be so broken that I cannot even change the name of a relation. (Receiving a 412 Precondition Failed, both with JOSM and Merkaartor.) Without changing the tags, I cannot change the route, because I have to split it up and with the old name someone will like remerge all the parts.

Unfortunately, I can’t remove my notes in all the relations I was editing now that said not to modify them as I was working on them.

Habe große Teile des DoB und BSR aufgezeichnet. Was noch nicht drin ist, werde ich innerhalb der nächsten Tage einbauen.

Ebenso langer Tag, Alberweiler und Assmannshardt sind soweit fertig. Langsam wird auch das lcn-Netz in der Gemeinde noch vollständig, obwohl es so spärlich ausgeschildert ist.

In der Gemeinde fehlen jetzt noch die ganzen Feld-, Land- und Wirtschaftswege. Habe aber an einigen Ecken zumindest schon die Anfangszipfel der fehlenden Wege drinnen, sodass man zumindest sieht, was noch fehlt.

Langer Tag, Alberweiler und Assmannshardt komplett aufgezeichnet, Einbau in die Karte erfolgt demnächst.

Geretsried und Geretsried-Stein vervollständigt (nun quasi komplett).

A wrote a little PHP application as an alternative to the OSM Relation Analyzer. I call mine the OSM Route Manager. Check it out at http://osm.cdauth.de/route-manager/. It isn’t quite finished yet, especially the highlighting of long routes is taking lots of CPU power on the client side at the moment. Feel free to test it and report bugs.

This is intended mainly as an application to analyze _route_ relations, so I implemented three important features that I was missing in OSM Relation Analyzer:
- Roundabout support. It adds one virtual node in the middle of the roundabout and connects segments there.
- Sub-relation support. The members of sub-relations are handled as if they were members of the relation itself. This simplifies splitting long routes that share segments with other routes into parts.
- GPX export supporting alternative routes, excursions and sub-relations. In OSM Route Manager, you can combine segments making your personal route and export that as a GPX file.

I didn’t spend much time on developing that (else I wouldn’t have used PHP), so don’t expect it to be very fast. I also don’t cache many API results (except for the segmentation of the routes), so the speed additionally depends on the API (especially XAPI calls are very slow).

Gerade eine Mail an tourismus-bw.de geschrieben und die vier fehlenden oder falschen Schilder, die mir beim Aufzeichnen der Westroute zu schaffen gemacht haben, aufgelistet.

As I am rather new to OSM, I find it very interesting how the process of getting to know how to do things really differs from other projects.

Two years ago I was new to a Java application. I only had little experience with Java, even less with how to make use of Java-specific editor features and how to structure a Java application. So other people showed me how to use Eclipse, I started to read the source code of the project part by part and searched for more detailed information on Google. Once I found information about one topic, I knew how to do it. After one week, I was totally familiar with the structure of the project, knew where to find the information I needed and could change anything I wanted to.

With OpenStreetMap, the process of getting to know it is completely different. As a beginner, you can do things without noticing that you actually don’t know how to do them. You beginn to cycle around in your area and take a photo of everything you think is important. Then, when you want to get your changes into the map, you suddenly notice that you missed some information without even knowing that you needed it. OSM does not tell you what to map, you can map whatever you want, and suddenly you read somewhere on the Wiki that someone has mapped something you’ve seen during your trip, and you have to go there again because you hadn’t thought of mapping something like that.

… See full entry

Ich frage mich gerade, ob der Donauradweg tatsächlich vollständig einen Teil des D6/EV6 darstellt. Der D6 scheint jedenfalls vollständig Teil des EV6 zu sein.

Ich habe mich ein wenig im Internet umgeschaut und habe herausgefunden, dass der D6 von Tuttlingen auf dem Hohenzollern-Radweg (Hz) bis zum Bodensee führt (nur weiß ich noch nicht, ob nach Ludwigshafen oder nach Radolfzell, da es zwei Varianten des Hz gibt). Von dort führt er parallel zum D8 (Rhein-Route) bis nach Basel.

Es scheint also, als würde der Teil oberhalb von Tuttlingen nicht zum D6 gehören. Man müsste also für den Donauradweg Tuttlingen–Passau eine Relation anlegen (oder mehrere, gibt es zweiufrige Abschnitte in Deutschland?), und diese zur Donauradweg-Relation und zur D6-Relation hinzufügen. Der Abschnitt Donaueschingen–Tuttlingen hingegen dürfte nur Teil des Donauradwegs sein, nicht aber des D6. Werde mich wohl darum kümmern, wenn mir kein anderer zuvor kommt.

DoB-W 100% komplett. Werde bei Gelegenheit auch noch die Teile des BSR einbauen, die ich abgefahren habe. DoB und DoB-E werden wohl erst folgen, wenn es ein bisschen wärmer ist.

DoB-Westroute ist komplett aufgezeichnet. Werde jetzt mit dem Einbau beginnen.