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

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.

Taginfo ist eine feine Sache: http://taginfo.openstreetmap.org/reports/characters_in_keys#problematic und dann auf Werte mit = filtern. Es gibt Weltweit mindestens vier verschiedene tag mit Gleichheitszeichen am Ende, Größenordnung insgesamt ca. 20 Werte. In Deutschland fallen mir solche Tippfehler als Einzelfehler relativ schnell auf und werden händisch korrigiert.

Bei den Werten würde ich in diesem Fall tatsächlich keine Korrektur vornehmen.

Eine weitergehende Korrektur - besonders bei Gleichheitszeichen im Schlüssel - würde ich dann doch dem Menschen überlassen.

Mit freundlichen Grüßen Georg V.

Da bin ich offensichtlich anderer Ansicht. Inwiefern es schädlich sein soll, eine Bearbeitung nicht durchzuführen, ist mir rätselhaft.
Wenn ich mit DE durch bin, werdern hierzulande O(500) Objekte mit Leerraum am Anfang/Ende übrig bleiben. Niemand ist gehindert, sich dieser anzunehmen. Ich selbst möchte aber erst herausfinden, ob die Historie eine “bessere” Korrektur (automatisch oder manuell) ermöglicht als das bloße Löschen des Leerraums.

Ja, Taginfo hätte mir auch einfallen dürfen. :roll_eyes: Ansonsten habe ich Deinen Ausführungen nichts hinzuzufügen.

Wasserstandsmeldung zum Leerraum in DE: 1662 Objekte bearbeitet, 430 als “can’t fix” markiert.
Der Korrekturalgorithmus tut genau das, was er soll - allerdings nur, wenn er Lust dazu hat. In dieser Hinsicht besteht noch Verbesserungspotential. Da reproduzierbar dieselben Objekte betroffen sind und ich ähnliches bereits bei den anderen Korrekturen beobachtet habe, vermute ich ein Problem in der Upload-Funktion oder der Erzeugung von XML aus der internen Objektdarstellung. Dem werde ich nachgehen, sobald das Gros der mit Leerraum behafteten Objekte abgetragen ist und Kandidatendateien und Log wieder übersichtlicher werden. Dann werde ich auch einmal nach den als nicht korrigierbar eingestuften Objekten schauen. Ansonsten sollte die Leerraumbereinigung planmäßig am Sonntag und dann regelmäßig ausgeführt werden (ich bin schon gespannt, woran es dieses Mal scheitert).

Klingt gut. Sind die Logs öffentlich?

http://toolserver.org/~mapjedi/wall-e-log.txt

NB: Nicht bearbeitete Objekte sind dort in der Regel nicht vermerkt. Als “can’t fix” markiert sind:

(setq osm-cantfix-whitespace '(
(node 35100696 299811684 187045796 125620387 268051413 268916349 240084449 262514107 81362518 243711156 282740631 384887620 453664743 278127678 282734455 517585137 955215725 87754529 2164438250 679137880 1820613733 2064762207 36290451 240107290 248501661 320084663 321579855 325124977 336143113 387259767 404568070 412794477 427040163 432456633 502572184 648215766 669135687 865274572 1026980570 1164763768 1166654017 1184939299 1204119431 1376905675 1440198351 1453879654 1457289556 1515504426 1758139793 1777066593 1812182143 1856629637 1860309042 1894391721 1944125485 1962248672 1987538357 2132300692 2141384966 290227793 314698523 339063013 352945078 362203171 371328863 410416737 476265030 838540839 1125043960 1307052564 1552051873 1774458109 1787552125 1819496697 1860872580 1976450111 2050519548 2144172796 273815380 673249977 1949253595 266812269 387305516 410756669 438197412 510053833 596491639 599732524 728560727 1243026444 1652684121 1736954074 1753707656 1785978951 1812177336 1821595631 1845701589 1853375411 1879441105 1948867622 2002520834 2140500746 2158951698 272815244 540365898 963434390 1777783073 1849965966 1869445841 2018969266 2108643048 2118585873 280218639 288119861 387860822 517766535 565638908 601150703 608260215 734962105 747076240 897524868 963434378 1082126447 1141742148 1242998924 1427443934 1470077935 1629000458 1678793879 1700136399 1714281634 1731685400 1741824611 1744269579 1747604447 1753752059 1768893136 1787592285 1854184261 1854802489 1856417650 1869916385 1903690888 1950468540 2034609557 2112865409 2145764884 2211360029 2212805769 2225757854)
(way 156599350 25562895 40955212 61605734 176512614 183201207 25692975 26761912 27187134 28965845 33081068 35116157 35745339 35905021 36788397 37952799 51229880 68491505 18801455 28912111 34438751 34730561 42421051 43332647 95018566 96698352 96698357 101809117 122353743 123007786 135254757 33823104 34347019 173529769 183588812 184291224 200955735 209783876 11982334 44612643 56215301 59026012 84013548 93419155 96698355 96705801 97782138 112552468 123253342 123554808 126866432 137057132 140642570 143180717 148988011 159306191 159559216 159561889 159563015 159564175 159567142 159570120 159576535 159633792 159634718 159634746 159634759 159634844 159635030 159635071 159635474 159636314 159640578 159641980 159692310 160610275 165729549 165945150 169455811 169455991 169456337 169456594 169457147 169457313 169473490 169473491 169473588 169473798 169473868 169475260 169475265 169475410 172550150 179358854 191398050 191398519 191399160 191399164 194980019 194980078 9962976 10349428 23209379 27572754 27870973 28294570 28893929 29852864 35745340 73208213 73563287 90533560 96705793 121998946 123554558 158892227 159051148 159563944 159565635 159566521 159634383 159634691 159634704 159634771 159635441 159635588 159636240 159636273 159636335 159640845 159642230 159642480 161900344 164929585 169457060 169472724 169473492 169473585 169473834 169473937 169473939 169475262 169475404 169475416 169686028 170204267 183830632 186447777 190901048 191398467 199022469 199236286 199907933 202877708 209872722 7975202 9666645 23916251 29154255 30781905 30830488 33081529 34413529 35116158 35140286 37901733 48866102 52773044 54065500 68323141 80506279 88903245 90533691 96698350 96698360 97724069 103304726 108567559 110153049 112552620 112873120 115071419 122359244 124190414 124917420 126274327 131432007 145750004 148494907 153774489 159025682 159562824 159562826 159563714 159565134 159565265 159565832 159566144 159566365 159566800 159566993 159576790 159577592 159577944 159633630 159633650 159633998 159634192 159634577 159634665 159634776 159634811 159634872 159634876 159634887 159635000 159635091 159635439 159635594 159636127 159636352 159640073 159640568 159640588 159640695 159640789 159640815 159641007 159641047 159641065 159641493 159642368 159642640 159642996 159658773 159688459 161638288 162560146 162602927 162742324 164164400 165729544 165729552 165729554 166975247 166986226 167067530 173660425 173720254 174445538 174760608 175449042 177084929 177479336 179141339 179174295 179493996 180396526 181464177 181659406 189743439 190884675 197975181 199513483 199580778 200250040 202370466 203070320 203465456 204179316 212461133)
(relation 1355734 2374745 1589685 2320680 2438965 2690141 2799214 2847769)
))

Ich habe mal einige von den Nodes heruntergeladen.

Dabei ist mir aufgefallen, dass einige von denen gelöscht sind. Andere liegen in den USA und haben keine Tags. kann das sein?

Kann ich nicht nachvollziehen. Wenn ich die Objekte in OSM lade, zeichnet ihre Verteilung die Fläche Deutschlands nach. Alles andere wäre auch reichlich überraschend, weil jeweils ein Deutschland-Extrakt der Geofabrik als Ausgangsmaterial dient.

Erstmal ein großes Lob für die Arbeit.

Ich bin auch dafür grundsätzlich alle fest definierten Einträge per Botlauf zu kontrollieren und soweit möglich zu korrigieren. Eine Kontrolle direkt bei der Eingabe im Editior wäre natürlich noch besser. Ich habe auch schon selber Leerzeichen vor und nach den Werten erzeugt, wenn ich z.B. Straßen- oder Restaurantnamen kopiert habe (zu faul zum Tippen).

Die KeepRight-Karte zeigt auch viele Tags an in denen offensichtliche und vermutliche Fehlschreibungen sind. Vielleicht kann man händisch zu korrigierende Fehler dort mit darstellen.