Ich habe gerade den Code noch einmal etwas umgebaut. Die Struktur und der Ablauf haben sich ein wenig geändert, aber die Logik bleibt im Wesentlichen dieselbe. Z.B. wird nicht mehr zuerst Leerraum entfernt und dann gefragt, ob noch etwas übrig ist, sondern erst auf “nur Leerraum” geprüft, dieser Fall ggf. separat behandelt und ansonsten mit der Leerraumentfernung fortgefahren.
Das Logging bzw. der weiter gefaßte Konsolenoutput sollte nun komplett sein; das oben noch wortkarge Verhalten in dem Fall, daß sich der Wert eines Tags im Laufe der Objekthistorie geändert hat, lautet jetzt etwa:
history forbids whitespace removal in tag "name"="Adler Modemarkt " of way #209872722
adding way #209872722 to "can't fix whitespace" list
Die wichtigste Änderung ist aber der Einbau zweier lokaler Variablen, die das Verhalten bei “nur Leerraum” kontrollieren, zusammen mit entsprechendem bedingtem Code. Je nach Wert der Variablen können solche Tags entweder gelöscht oder ignoriert werden. Wenn ich das Verhalten später ändern will, muß ich nicht mehr den Code umschreiben und erneut testen, sondern nur die Variablen ändern. Erst einmal sind beide an nil gebunden, d.h. die betroffenen Tags werden ignoriert.
way #209876355: value of "addr:housenumber"=" " consists only of whitespace: tag ignored.
In den anderen oben genannten Fällen verhält sich das Programm (zumindest bei der Handvoll Testobjekte) wie zuvor.
Nächste Schritte: Test der übergeordneten Funktion (Einlesen und Abarbeiten einer kompletten Kandidatendatei) im simulierten, anschließend realen Modus (zunächst nur wenige Objekte); analog Blindtest an realen Daten ohne Leerraum in Tags.
Update: Funktionen getestet, ergänzt, von Fehlern befreit, Logging verbessert (Log der ersten Läufe fehlt). Problem in osm.el bei anonymen Bearbeitungen gefunden und behoben. Tests mit Whitespace-Trägern aus germany.osm (Limit=1) erfolgreich; anschließend zu Testzwecken zwei NRW-Regierungsbezirke aufgeräumt. Kontrolle zuerst per Auge, später mit einer vor einiger Zeit speziell für diesen Zweck entwickelten Prüffunktion (osm-versions-differ-only-by-whitespace
- das war die, mit der ich “versehentlich” das Problem mit den trunkierten Koordinaten gefunden habe).
Der Blindtest steht noch aus, aber da erwarte ich keine unangenehmen Überraschungen mehr.
Leider gibt es doch einen beträchtlichen “can’t fix”-Anteil, in der Regel wegen der Objekthistorie. Auf 125 korrigierte Objekte kommen 28 als nicht korrigierbar markierte (lokal, per Sperrliste).
Update 2: Blindtest mit zufällig ausgewählten Objekten (5495 Knoten, 2835 Wege, 357 Relationen aus dem Regierungsbezirk Köln) erfolgreich:
total number of objects modified: 0
BTW: Was zum …? http://www.openstreetmap.org/browse/relation/2615664