Wall·E räumt auf: Leerraum in Tags und Rollen

sauber!

Danke
walter

Tags mit leerem Key oder Value können noch nützliche Informationen beinhalten! Beispiel: " "=“asphalt” Ob das in den Daten auch so vorkommt, kann ich allerdings nicht beurteilen.
Tags mit leerem Key und Value können mMn gelöscht werden.

Das mit der Vorgängerversion find ich ne gute Idee. Bei solchen Fällen kann man dann schauen, obs hilfreich ist.
Der Rest gut so.

Kommt vor, wenn auch eher selten. Ist vielleicht besser, diese zuerst einmal auch außen vor zu lassen. Die Schwierigkeit wird (auch für menschliche Korrekteure) in der Frage bestehen, ob der Verursacher das Tag löschen wollte oder nicht.

Nachtrag dazu: Ein Beispiel für einen Wert mit nur Leerraum - http://www.openstreetmap.org/browse/way/205351516 . Aus source=" " kann man nun wirklich nichts ableiten. Etwa bei shop=" " wäre es anders, da wäre es naheliegend, daß der User ein Geschäft eintragen wollte - wenn dann noch ein name=* vorhanden ist, könnte ein menschlicher Korrekteur evtl. schon sinnvoll raten. Allerdings habe ich gerade mal die Daten durchgeschaut: bei den vorhandenen Tags der Form key=" " gibt es nichts zu raten, die Schlüssel sind source (13), name (9), addr:housenumber (6), maxstay, fee, addr:housename (je 1). Insofern bin ich im Moment doch geneigt, Tags mit nur Leerraum im Wert ersatzlos zu löschen. Der Einwand von MasiMaster ist zwar grundsätzlich richtig, aber in der Praxis ist aus den halbleeren Tags nichts herauszuholen.

Der Weisheit letzter Schluß ist das Kriterium allerdings noch nicht; in seiner Rohform führt es nämlich bei ersten Tests (lokal, ohne Hochladen) dazu, daß kaum ein Objekt in Version >1 angefaßt wird.
Aus “Tag in allen Vorgängerversionen vorhanden und identisch” ist soeben “Tag in allen Vorgängerversionen, falls vorhanden, identisch zur aktuellen Version” geworden. Damit klappt es schon besser.

Nachtrag: Hier ist mal so ein Beispiel, wo Leerraum bei der Bearbeitung entstanden ist: “Untere Bärenlocherstraße” wurde zu " Bärenlocherstraße" geändert. In diesem Fall war die Entfernung von “Untere” vermutlich Absicht, denn parallel zur " Bärenlocherstraße" gibt es noch eine “Untere Bärenlocherstraße” - d.h. es ist ein “echter” Leerraum-Fehler. http://www.openstreetmap.org/browse/way/143180717/history
Wie gesagt, solche Fälle will ich über die Kontrolle der Historie erst einmal außen vor lassen. Wenn die anderen Fälle abgetragen sind, sieht man bei diesen vielleicht auch klarer.

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

Hallo Oli-Wan

Ich kann dich nur bewundern,

  • wie du konstant beim Thema dran bleibst
  • wie du das Thema in kleinere überschaubare Einheiten zerlegst
  • wie gründlich du Möglichkeiten und Fallstricke vorab erforscht
  • wie du stets die sichere Seite bevorzugst
  • wie detailiert du dein geplantes Vorgehen beschreibst (und damit)
  • wie du andere in dein Projekt einbindest.

Dafür wollte ich mal mein Lob aussprechen und Danke sagen.
(Mir scheint alles, was du im Vorpost zu Leerraum in Wert und Schlüssel erklärt hast, sinnvoll und angemessen.)

Edbert (EvanE)

Ja, in den genannten Fällen ist nichts herauszuholen. Allerhöchstens könnte es für fee=yes stehen, aber das ist Spekulation.

Ich hatte das erwähnt, weil dein Programm später sicher mal ohne (große) Aufsicht rennen soll, dann weiß man nie welche Tags “anfallen”.

Gut, bei fehlendem Value ist das sicher nicht so tragisch, bei fehlendem Key könnte man bestimmt mehr ableiten. Kommt aber sicher selten vor!?

einige Beispiel die mir grade fürs Ersetzen einfallen:
highway=“” → highway=road
building=“” → building=yes
bridge / tunnel → *=yes
shop → *=yes

Du hast Recht, auf Dauer werde ich das Programm nicht engmaschig überwachen. Andererseits hat xybot zuletzt vor gut einem Jahr Leerraum und leere Tags aufgeräumt. Ansonsten scheint da seitdem niemand großflächig was gemacht zu haben, daher sollte das aktuelle Aufkommen schon halbwegs repräsentativ sein.
Die Information über gelöschte Tags steht ja in jedem Fall im Log; ergänzend dazu ist es auch kein großer Akt, in eine zusätzliche Datei z.B. jeweils den Schlüssel zu schreiben, der zusammen mit dem leeren Wert gelöscht wurde, um den Überblick zu behalten.

Was die leeren Schlüssel angeht: diese sind in der Tat extrem selten. Das kann man andererseits gerade auch als Argument sehen, sie menschlichen Korrekteuren zu überlassen.

Das Programm, dessen Arbeit oben skizziert ist, ist erst einmal nur eine Testversion. Da ist noch nichts in Stein gemeißelt, und ich bin offen für jede Änderung (und daher dankbar für Deine Anmerkungen). Bei den leeren Schlüsseln etwa bin ich selbst unschlüssig, aber vielleicht lasse ich die lieber stehen. Bei leeren Werten denke ich eher, daß ein zusätzliches Log ausreichen sollte, um den Überblick (und die Kontrolle) zu behalten. Alternativ könnte man auch mit einer Whitelist arbeiten: “diese Schlüssel dürfen bei leerem Wert entsorgt werden, Raten ist aussichtslos”.

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

Hallo Oli-Wan,

arbeitet dein Code eigentlich immer den gesamten Datenbestand durch, oder hast du auch die Möglichkeit, changesets auszuwerten?

Walter

Der Standardablauf sieht so aus: Geofabrik-Extrakt herunterladen, daraus Kandidaten für die unterschiedlichen Korrekturtypen extrahieren, Korrektur starten. Also ja, ich wühle mich immer durch den gesamten Datenbestand.

Grundsätzlich könnte ich mit einigen Anpassungen der Werkzeuge auch Daydiffs lesen - das habe ich sogar (mit reichlich manueller Intervention) einige Tage lang gemacht, als die Geofabrik-Extrakte nicht aktualisiert wurden. Das war aber etwas mühsam, weil die Daten erst von osc zu osm konvertiert, dann um fehlende Knoten ergänzt und schließlich wieder ausgeschnitten werden wollten.

Einzelne Änderungssätze gingen bei Bedarf mit etwas Gymnastik aber auch. Hast Du einen bestimmten Anwendungsfall im Sinn?

Nachdem gestern in kleinen Portionen Leerraum von gut 100 Objekten getilgt wurde, werde ich heute noch ein paar etwas größere Tests laufen lassen. Wenn dabei keine Probleme auftreten (womit ich inzwischen nicht mehr rechne) und ich keinen Widerspruch vernehme, werde ich die Leerraumbeseitigung schon in den nächsten Tagen in den Automatikbetrieb bringen.

Im Gegensatz zu den relativ komplexen und immer wieder erweiterten Adresskorrekturen gibt es hier keine exotischen Spezialfälle, wegen derer eine wochenlange Testphase nötig wäre. Außerdem gibt es hier einen reichlichen Vorrat an bereits vorhandenen Fehlern, während ich bei Straßennamen und falschen Adressen immer erst auf frische Ware warten mußte. Die Kontrolle “geänderte Version unterscheidet sich von Vorgängerversion nur um Leerraum” ist im Unterschied zur Kontrolle, ob eine Adresskorrektur sinnvoll war, automatisch möglich (und bislang unauffällig verlaufen).

Edit: Schrecksekunde - im ersten größeren Änderungssatz zeigte das Kontrollprogramm “nil” (“false”) an. Was war los? An einem Knoten wurde created_by=“iLOE 1.9” planmäßig entfernt.

Wäre ja auch zu schön gewesen: es ist doch ein Problem aufgetaucht. Es darf erst einmal jeder selber raten, was hier schiefgelaufen ist:
I. http://www.openstreetmap.org/browse/node/2109655992
II. http://www.openstreetmap.org/browse/node/2091354100

Na, Problem erkannt? Wer noch etwas grübeln möchte, schaut lieber nicht unter dem nächsten Link nach - denn damit wird es zu einfach.
Und nein: die Antwort ist nicht, daß Wall·E nichts gemacht hat. Es hat jeweils eine Änderung gegeben.

III. http://www.openstreetmap.org/browse/node/443695950

— SPOILER —

— SPOILER —

— SPOILER —

— SPOILER —

— SPOILER —

— SPOILER —

Jetzt die Auflösung. Die Tags aller drei Knoten enthalten Line Feeds (einigen von uns besser als
bekannt); III. enthält darüberhinaus noch eine Menge anderen Müll aus einer offenbar mißratenen GPS-Wegpunkt-Konversion. Im Brauser sind die Line Feeds in der Regel nicht zu sehen, aber im rohen Ergebnis der HTTP-Abfrage sieht man sie.
Solche Line Feed-Zeichen kommen weit häufiger vor als nur an in von mir gefundenen Fällen; aber an diesen drei Knoten steht der Line Feed direkt vor oder nach einem Leerzeichen, worauf mein Ersetzungs-Regex “^[[:blank:]]+|[[:blank:]]+$” anspricht.

Lösung: ich muß den Regex so ändern, daß er tatsächlich nur noch Leerraum am Anfang oder Ende von Tags ersetzt, nicht mehr vor oder nach innenliegenden Line Feeds. Die haben da zwar in der Regel auch nichts verloren, sind aber nicht meine aktuelle Baustelle. Außerdem wird der Regex so angepaßt, daß er auch Linefeeds zum Leerraum zählt - also ein “\n”, " \n" oder "\n " am Anfang oder Ende des Tags komplett rausfliegt.

Edit: Ach ja, ein Ticket für Pushpin sollte ich wohl auch schreiben. Die beiden jüngeren der oben genannten Knoten haben ihr \n von diesem Editor erhalten.
Ein Issue für rosemary (aka wheelmap) zum Trimmen von Whitespace ist schon geschrieben; bei Potlatch spare ich mir die Mühe.

Edit2 / Nachtrag: Nach den Änderungen habe ich noch einmal einen Blindtest laufen lassen (5431 Knoten, 2872 Wege, 369 Relationen aus dem gestern aufgeräumten Regierungsbezirk Köln), keine Probleme. Jetzt wird wieder an Daten mit Leerraum (Regierungsbezirk Münster) getestet.

Edit3 / Nachtrag: Regierungsbezirk Münster ist aufgeräumt (ohne Probleme); weiterer Test bundesweit querbeet läuft.

Edit4 / Nachtrag: Kleiner Überblick. Bisher (ca.) 790 Objekte bearbeitet, 203 als “can’t fix” markiert, also ungefähr Verhältnis 4:1. Überwiegend Freitext-Tags, aber ein paar Fälle wie landuse=" brownfield" sind immerhin schon auf der Mapnik-Karte sichtbar geworden.

Hallo Oli-Wan,

es würde mich interessieren, welchen Rechenaufwand du hast,
und ob es möglich wäre, die Aufräumarbeiten auch auf andere Länder (z.B. AT, CH) auszudehnen.

Falls du die Diffs durchsuchst, wäre sogar ganz Europa machbar, bei einem Full-Scan wird das für den Rechner vermutlich zu viel sein.

Ich habe auch oft ein = am Ende eines Tags gesehen, das ist genauso störend wie ein Leerzeichen, nur dass es optisch leichter zu finden und zu korrigieren ist.
Falls du also noch Rechenzeit übrig hast, vielleicht findest du ja auch dafür eine passende Erkennungsregel.

Walter

Rechenzeit ist dank der freundlichen Unterstützung des Wikimedia Toolserver kein Problem mehr :slight_smile:
Aber auch in absoluten Zahlen ist der Rechenaufwand inzwischen überschaubar: das große Programm, das alle zehn Tage ausgeführt wird, braucht für DE je nach Maschine etwa 25 Minuten Rechenzeit, um die Kandidaten für Straßennamen, Adressen, Leerraum und wiederholte Knoten auszufiltern, das kleine Programm für Adressen etwa 10 Minuten. Die eigentlichen Korrekturprozesse brauchen jeweils weniger als eine Sekunde (Ausführungszeit ist natürlich länger). Von daher wäre die Ausweitung auf AT und/oder CH auch ohne Änderungen der Technik kein ernsthaftes Problem.

Ihr müßtet euch halt im jeweiligen Land per Mailingliste, Forum oder was auch immer ihr habt verständigen, ob das gewünscht ist. Nicht landesspezifische Korrekturen (bisher: Leerraum) lassen sich ohne weiteres übertragen; bei der Anpassung landesspezifischer Korrekturen (Adressen, Straßennamen) bräuchte ich natürlich Unterstützung.

Diese Sicherheitsmaßnahme halte ich für völlig unnötig und schädlich, solange es um das reine Entfernen von Leerraum geht.
Korrigiert ein Benutzer beispielsweise die Schreibweise eines Wertes, wird er oft die Leerzeichen nicht bemerken und diese belassen. Dies sollte doch wohl kein Grund für Wall-E sein, auf die Leerzeichenkorrektur zu verzichten.

Wenn es allerdings darum geht, Tags mit leerem Wert oder Schlüssel ganz zu löschen, hat diese Sicherheitsmaßnahme jedoch schon eine gewisse Berechtigung.

Für das Löschen von Tags mit leerem Wert komme ich immer mehr zu der Überzeugung, dass dies nur mit einer Positivliste von Schlüsseln sinnvoll ist, auch wenn es beim aktuellen Datenbestand von Deutschland unproblematisch sein mag.

Bei Schlüsseln die grundlegende Eigenschaften eines Objektes beschreiben, wäre ein Löschen nicht sinnvoll. Es ist z.B. schon eine gewisse Information, ob ein OSM-Weg ein highway, railway oder waterway ist, die man nicht einfach vernichten sollte.

Unproblematisch wäre das Löschen bei Schlüsseln, die zur Unterdifferenzierung praktisch überall vorkommen sollten.
Beispiele wären name, lit, surface und maxspeed.
Seltener verwendete Schlüssel könnten dagegen auch bei leerem Wert noch sinnvolle Hinweise enthalten.
Beispielsweise wäre maxweight=“” schon ein Hinweis darauf, dass sich an dieser Stelle eine in OSM noch fehlende Gewichtsbeschränkung befinden könnte. Ebenso wäre ford=“” ein deutlicher Hinweis darauf, dass hier ford=yes gemeint ist.

Unbekannte Schlüssel mit leerem Wert sollte man ebenso nicht einfach löschen. Z.B. könnte dort auch z.B. etwas in der Form “Key=Value” in das Schlüsselfeld geschrieben sein. Sollte derartiges in Realität tatsächlich entsprechend oft vorkommen, wäre letzteres auch noch ein Kanditat für eine automatische Aufteilung durch den Bot.

Für den Fall eines Tags mit leeren Schlüssel sehe ich kaum eine Möglichkeit, dass der Bot sinnvoll entscheiden kann, wann zu löschen ist.
Ausnahme wäre eine vermutlich kurze Liste mit Spezialfällen von Werten wie z.B. “yes” und “no”, die man auch manuell keinesfalls einem bestimmten Schlüssel mit hinreichender Wahrscheinlichkeit zuordnen kann. Auch könnte man vielleicht den Fall, dass “Key=Value” in das Feld des Wertes eingetragen ist, bei Bedarf automatisch korrigieren.

Dann würde ich auch erwarten, dass das “=” auch am Anfang des Wertes auftreten könnte. Technisch wäre beides wohl einfach in die Leerzeichenregel einzubauen, nur wäre der Changeset Kommentar dabei ggf. etwas irreführend. Vielleicht wäre ein Kommentar der Art “Leer- und Sonderzeichen bereinigt” sinnvoll. Oder lieber doch eine eigene Regel?

Hallo Oli-wan,

Mapper von Austria sind im users:Germany Forum zu finden, also hier.
Bei den Leerzeichen sehe ich wie du auch keinen Grund, für AT eine andere Regel zu erfinden.
Falls du Unterstützung bezüglich Überwachung, Kontrolle oder ähnlichem benötigst kann ich das machen.

Für das Gleichheitszeichen am Ende wäre ich für eine eigene Regel, am Anfang habe ich es bisher noch nicht gesehen.

Walter

Beim Gleichheitszeichen wäre ich vorsichtig. Das kann auch eine Bedeutung haben.

Aber nur teilweise, oder nicht? Da es auch eine eigene Mailingliste talk-at gibt, scheint es mir schon geboten, auch deren Einverständnis einzuholen.

Die Leerraumbereinigung ist sehr pflegeleicht - bei der brauche ich keine Hilfe. Ich habe da ein kleines Codefragment, mit dem ich alle Objekte in einem Änderungssatz automatisch dahingehend überprüfen kann, ob tatsächlich die einzige Änderung in der Entfernung von Leerraum besteht. Die wenigen Fälle, wo dem nicht so ist (siehe oben gefundenes und abgestelltes Problem; ansonsten Löschung von created_by) kann ich selbst kontrollieren. Und nach ein paar tausend Objekten ohne Auffälligkeiten werde ich die Leerraumbeseitigung ohnehin nicht mehr detailliert überwachen.

Wobei ich Unterstützung bräuchte, sind Dinge wie Adresskorrekturen. Daß in AT nicht Deutschland->DE, sondern Österreich->AT ersetzt werden muß und daß eure Postleitzahlen vierstellig sind, kriege ich gerade noch auf die Reihe. Aber möglicherweise gibt es bei Schreibweisen von Straßennamen etc. andere Eigenheiten als in DE, abweichende Ausnahmen und andere Gepflogenheiten bei Hausnummern. Und wenn eine solche Korrektur in Betrieb geht, muß sie in der Tat einige Zeit engmaschig überwacht werden - da würde ich Dein Angebot gern annehmen.

Die Sache mit dem Gleichheitszeichen schaue ich mir bei Gelegenheit mal an. Im Moment habe ich keine blasse Vorstellung von der Häufigkeit solcher Fälle und wie ggf. eine sinnvolle Korrektur aussähe: einfach nur das “=” entfernen oder möglicherweise ein anderes Vorgehen, evtl. auch abhängig von weiteren Bedingungen.