Hier mal der aktuelle Stand meiner Überlegungen zum Thema, nachdem ich mir die obigen Wortmeldungen noch einmal durchgelesen habe.
Grundidee ist immer noch, Leerraum nur dann zu entfernen, wenn hierdurch eine nennenswerte Verbesserung erzielt wird. Die von mir ursprünglich angedachte Unterscheidung zwischen Festwert- und Freitext-Tags vermutlich nicht das beste Kriterium, denn auch in Freitext-Werten kann Leerraum störend sein (Sortierreihenfolge, Suchabfragen). Auch der Ansatz mit einer Positivliste von Schlüsselnamen, bei denen Leerraum im Wert geputzt wird, ist spätestens dann nicht mehr praktikabel, wenn man sich von der Trennung Festwert/Freitext löst.
Inzwischen denke ich daher eher in die Richtung, Leerraum grundsätzlich überall zu beseitigen und nur endlich viele Ausnahmen zu definieren. Diese Ausnahmen senken zugegebenermaßen die Zahl der Bearbeitungen nur unwesentlich und bei einer Größenordnung von insgesamt 2500 Bearbeitungen (plus zukünftig fortlaufend weitere; 2500 entspricht grob dem Aufkommen innerhalb eines Jahres) könnte man das Argument “Aufblähen des Datenbestandes” wohl noch übergehen, aber es widerstrebt mir einfach, bei Tags, die per se völlig unsinnig sind (Stichwort area:ha), Leerraum-Kosmetik zu betreiben, wenn eigentlich ein viel gründlicheres Aufräumen angebracht wäre.
Konkret hieße das, folgende Tags zu sperren:
-
note, fixme, FIXME - nur für interne Zwecke gedacht, schadet also niemandem
-
eea:cdda:sitecode, area:ha - liegen ohnehin in Tschechien und resultieren wie üblich aus einem Import; area:ha ist per se unsinnig, ebenso Tags wie dummy=JOSM und ein aufs OSM-Wiki zeigendes website-Tag, was sich alles in demselben Import findet.
-
source - wird das irgendwo genutzt?
-
designation - de facto ist das Tag in DE unbrauchbar, da schadet etwas Leerraum auch nicht
Vielleicht noch eine Handvoll weitere, wenn ich die Liste noch einmal gründlicher durchgesehen habe.
Die Sperre soll dabei im Filter erfolgen, d.h. das Filterprogramm spricht nur an auf Leerraum in Schlüsseln sowie Leerraum in Tags außer den gesperrten. Ein Objekt mit designation=“Wohnhaus˽” wird also nicht ausgefiltert, eines mit designation=“Wohnhaus˽” und building=“˽yes” dagegen schon (eines nur mit building=“˽yes” natürlich auch). Das Korrekturprogramm entfernt anschließend sämtlichen Leerraum, den es in den Tags der Kandidaten findet (wenn das genannte building=“˽yes” schon angefaßt wird, dann auch designation=“Wohnhaus˽”).
Tags mit leerem (“”) oder nur aus Leerraum bestehendem Wert sollen im gleichen Zuge komplett entfernt werden.
Bei Konflikten zwischen Tags, deren Schlüssel sich nur um Leerraum unterscheiden (“ref”=1, “ref˽”=2) keine Änderung; falls kein Konflikt vorliegt (“ref”=1, “ref˽”=1), Löschung desjenigen mit dem Leerraum (“ref˽”).
Das Korrekturprogramm werde ich noch so erweitern, daß es nur Tags bearbeitet, die auch in allen Vorgängerversionen genau so vorhanden waren. Damit will ich Fälle ausschließen, wo bei einem Bearbeitungsversuch z.B. versehentlich vorhandener Text überschrieben wurde (“Bahnhof Kleinkleckersdorf” → “Bahnhof˽”). Streichen oder abschwächen kann man diese Vorsichtsmaßnahme später immer noch, wenn sie sich als nicht notwendig erweist.
Soweit meine aktuellen Überlegungen. Was haltet ihr davon?
Der weitere Fahrplan bei Wall·E sieht wie folgt aus: Wenn bis dahin keine neuen Probleme mehr auftauchen, werde ich bei der Marke von insgesamt 6000 Bearbeitungen den Probebetrieb der Adresskorrekturen für beendet erklären (d.h. nicht mehr jedes Objekt einzeln im Brauser kontrollieren, sondern nur noch die Logfiles durchschauen, auch das nach und nach nur noch stichprobenartig) und auch den Korrekturprozeß als cronjob laufen lassen. Eigentlich ändert sich nur für mich selbst etwas (weniger Arbeit), außer daß Wall·E zukünftig immer zu festen Zeiten loslegt.
Die Leerraum-Korrektur wird in jedem Fall erst danach starten: voraussichtlich zuerst in einem Aufwasch nur die Schlüssel mit Leerraum, dann weiter in Paketen von z.B. 200 Objekten pro Änderungssatz (nach ein paar Tests mit weniger Objekten).
