So, ich habe mal ein bißchen was gebastelt. Der Code sollte bereits alle wesentlichen Punkte enthalten: Leerraum in Schlüssel oder Wert, Kontrolle der Versionshistorie, Abgleich mit bestehenden Tags bei Änderung eines Schlüssels. Logging etc. und Pflege von Sperrlisten sind bisher nur rudimentär umgesetzt, aber das kommt noch. Danach werde ich den Code noch einmal kontrollieren und aufräumen, anschließend im kleinen Maßstab an realen Daten testen.
Hier ist aber schon mal ein Überblick mit Beispielen, welche Fälle bisher berücksichtigt werden. Bitte schaut mal, ob euch Situationen einfallen, die noch durchrutschen könnten. Material sollte ausreichend vorhanden sein, um alle denbaren Konstellationen abzudecken (über 2000 Objekte in germany.osm). Vielleicht findet sich auch noch ein grundsätzlicher Fehler in meinen Überlegungen.
Die Korrekturfunktion schleift durch alle Tags (Schlüssel-Wert-Paare).
Zuerst wird für jedes Tag nach Leerraum am Anfang/Ende des Werts geschaut. Wird welcher gefunden, wird überprüft, ob unter dem zugehörigen Schlüssel in allen Versionen entweder der gleiche oder kein Wert (also auch nicht “”) eingetragen war. Das Tag muß also entweder in allen Versionen vorhanden gewesen sein oder irgendwann dazugekommen und dann in allen weiteren Versionen unverändert geblieben sein; zwischenzeitliche Löschung und exakte Wiederherstellung geht auch durch. Andernfalls ist - für das betrachtete Tag - an dieser Stelle Schluß.
Nun wird der überschüssige Leerraum aus dem Wert entfernt. Ist danach der Wert “”, wird das Tag komplett gelöscht. (Das Log stellt Leerraumentfernung und ggf. Löschung als einen Schritt dar.)
Weiter geht’s mit dem Schlüssel. Zunächst wieder Suche nach Leerraum und Kontrolle aller Vorgängerversionen.
Der Schlüssel (als String) wird von Leerraum befreit. Wenn dann nur noch “” übrig ist, wird das Tag gelöscht. Andernfalls wird geprüft, ob ein Tag mit dem gleichen Schlüssel schon vorhanden ist (Beispiel: aktuell betrachteter Schlüssel war “highway˽”, der geänderte String ist “highway” - gibt es schon ein Tag highway=*?). Falls es keines gibt, wird der geänderte String als Schlüssel in das Tag übernommen und die Korrektur ist abgeschlossen.
Gibt es bereits ein Tag, werden die beiden Werte verglichen. Sind sie identisch, wird das betrachtete Tag kurzerhand gelöscht, weil redundant. Beispiel: (ursprünglich) “˽highway”=“residential” sowie “highway”=“residential”, das erstgenannte entfällt. Sind sie verschieden, wird der Korrekturversuch abgebrochen, weil der Konflikt nicht gelöst werden kann.
Jetzt endlich ein paar Beispiele.
Leerraum im Wert: http://www.openstreetmap.org/api/0.6/node/13927006
editing node #13927006, http://www.openstreetmap.org/browse/node/13927006
modified tag [key="wheelchair:description"] value="Präsenzzeit des mobilen Service von 06:00 Uhr bis 22:40 Uhr " -> "Präsenzzeit des mobilen Service von 06:00 Uhr bis 22:40 Uhr"
(simulation run - no upload to the database)
Gibt’s auch am Anfang des Werts: http://www.openstreetmap.org/api/0.6/node/26597860
editing node #26597860, http://www.openstreetmap.org/browse/node/26597860
modified tag [key="name:fr"] value=" Frisingue" -> "Frisingue"
(simulation run - no upload to the database)
In beiden Fällen ist das fragliche Tag erst in der letzten Version dazugekommen, existiert also jeweils nur mit diesem einen Wert.
Ein Fall, wo der Wert nur aus Leerraum besteht und das Tag weggeworfen wird: http://www.openstreetmap.org/api/0.6/node/209876355
editing way #209876355, http://www.openstreetmap.org/browse/way/209876355
value of "addr:housenumber"=" " consists only of whitespace: tag removed.
(simulation run - no upload to the database)
Bei diesem Objekt verbietet die Objekthistorie die Leerraumbeseitigung: http://www.openstreetmap.org/api/0.6/way/209872722 : in Version 1 lautet das name-Tag “Adler Modemarkt˽˽” (zwei Leerzeichen), in Version 2 “Adler Modemarkt˽” (ein Leerzeichen). Da das Programm in diesem Fall nichts tut, schreibt es auch nichts ins Log. Eine Ausgabe auf der Konsole wird es geben, aber bisher gibt sich das Programm noch recht einsilbig.
(osm-task-fix-lt-whitespace 'way 209872722 nil nil t)
nil
Leerraum im Schlüssel: http://www.openstreetmap.org/api/0.6/node/2234071140
editing node #2234071140, http://www.openstreetmap.org/browse/node/2234071140
modified tag key=" website" -> "website" [value="http://www.kioskguide-hannover.de/index.php?seite=kioskdetails&id=113"]
(simulation run - no upload to the database)
Im folgenden Fall besteht ein Konflikt zwischen den Werten zu den beiden Schlüsseln “amenity” und “˽amenity”. Keine Änderung, kein Eintrag ins Log, bloß eine Nachricht, die auf der Konsole landen soll: http://www.openstreetmap.org/api/0.6/node/2010219552
can't fix whitespace in tag of node #2010219552: " amenity"="drinking_water": tag "amenity"="waste_disposal" exists