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

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.

Ich habe einmal begonnen, mir die übrig gebliebenen bzw. als “can’t fix” markierten Objekte näher anzusehen. Bisher gibt es nur vage Hinweise, daß sich anhand der Historie unbeabsichtigte Bearbeitungen rekonstruieren lassen - aber bei 439 Objekten habe ich auch noch nicht allzu genau hingesehen.

Ich werde aber die Kontrolle der Objekthistorie etwas aufweichen, um einige typische Fälle auszusortieren. Die entsprechende Funktion ein Veto ein, wenn das zu korrigierende Tag in einer früheren Version auftaucht, aber dort einen anderen Wert hat. Dieses Veto werde ich unterdrücken, wenn der Unterschied nur in Leerraum besteht, also überschüssgier Leerraum bereits teilweise entfernt wurde:

way 177084929 v2 has whitespace in the following tags:
		name=" Untere Bornholzstraße"
history:
	v1:	name="                                                           Untere Bornholzstraße"
	v2:	name=" Untere Bornholzstraße"

Man mag es kaum glauben, aber auch der umgekehrte Fall kommt durchaus häufiger vor:

way 159306191 v4 has whitespace in the following tags:
		name="                                   Bergstraße"
history:
	v1:	name="Bergstraße"
	v2:	name="Bergstraße"
	v3:	name="                                   Bergstraße"
	v4:	name="                                   Bergstraße"

Ferner sollen Bearbeitungen durch Bots (xybot, aber auch Wall·E selbst) ignoriert werden. Dazu ein Beispiel.

way 165729549 v2 has whitespace in the following tags:
		name=" Belgrader Straße"
history:
	v1:	name=" Belgrader Strasse"
	v2:	name=" Belgrader Straße"

Hier hat xybot die Schreibweise des Straßennamens korrigiert. In so einem Fall werde ich den Wert des Tags vor der Bot-Bearbeitung als äquivalent zum Wert danach ansehen. Wieviel diese Ausnahme bringt, bleibt abzuwarten.

Außerdem sollen Versionen nicht beachtet werden, die ausschließlich aus Leerraum bestehen. Hier wurde offenbar eine leere Hausnummer eingetragen und nach Bemerken des Fehlers die richtige Zahl ergänzt:

way 165945150 v3 has whitespace in the following tags:
		addr:housenumber=" 41"
history:
	v2:	addr:housenumber=" "
	v3:	addr:housenumber=" 41"

Wenn diese (und evtl. weitere, noch zu identifizierende) Spezialfälle implementiert sind, lösche ich die “can’t fix”-Liste und lasse das Programm noch einmal laufen. Vielleicht entsteht dabei schon etwas mehr Übersicht. Schlußendlich sollten Fälle, wo Leerraum wirklich “neu” entstanden ist, ohne Bedenken korrigiert werden können.

way 179141339 v3 has whitespace in the following tags:
		name="Reifen Diehl "
history:
	v1:	name="Tanzschule Taeschner"
	v2:	name="Reifen Diehl "
	v3:	name="Reifen Diehl "

way 189743439 v2 has whitespace in the following tags:
		name="Bruker AXS GmbH "
history:
	v1:	name="er AXS GmbH "
	v2:	name="Bruker AXS GmbH "

Dies ist mal ein Beispiel, wo die Entfernung von Bestandteile des Werts unbeabsichtigt erfolgt sein könnte und möglicherweise ein menschlicher Mapper eine bessere Korrektur anbringen könnte als die bloße Löschung des Leerraums:

way 159051148 v3 has whitespace in the following tags:
		name="Waldweg "
history:
	v2:	name="Waldweg nach Oblfing"
	v3:	name="Waldweg "

Andere Wege in der Nähe tragen ähnliche Namen (“Waldweg nach …”). Leider hat der (ehemalige) Mapper natürlich keinerlei Hinweis zu seinen Absichten im Änderungssatz hinterlassen.

Nachtrag: nach den oben skizzierten Änderungen und der Beseitigung eines anderen Fehlers konnten noch einige (gut 80) weitere Objekte bearbeitet werden. Die oben angegebene Zahl 439 ist mit der jetzigen Zahl 268 nicht direkt vergleichbar, weil ich schon einige Objekte händisch von Leerraum befreit hatte, wo Wall·E dies aufgrund der Objekthistorie verweigert hatte, es aber offensichtlich dennoch sinnvoll war. Jedenfalls markiert das Programm im aktuellen Datenbestand den Leerraum an 268 Objekten als mit seinen gegenwärtigen Beschränkungen nicht korrigierbar.

Nachtrag 2: Was ich auch noch durchgehen lasse, ist der Fall, daß der Wert in der älteren Version ein Teilstring des aktuellen Werts ist, so wie oben, wo “er AXS GmbH” zu “Burker AXS GmbH” ergänzt wurde. Das hilft auch in einigen Fällen, wo nachträglich “e.V.”, “GmbH”, “GbR” und dergleichen angehängt wurde; aber auch, wenn Aldi zu "ehem. Aldi " wurde (Sinn mal dahingestellt, wenn man gleichzeitig das shop-Tag beläßt). 268 → 224.

Nachtrag 3: Einen großen Teil des Bodensatzes habe ich nun nach manueller Selektion noch per force-Option aufgeräumt - hier ergab sich aus der Objekthistorie keine sinnvollere Korrekturmöglichkeit. Übrig geblieben sind Fälle wie die folgenden, wo es durchaus möglich erscheint, daß versehentlich Teile des Werts gelöscht wurden:

way 36788397 v12 has whitespace in the following tags:
		name="Kindergarten "
history:
	v1:	name="Staufenstr"
	v2:	name="Staufenstraße"
	v3:	name="Staufenstraße"
	v4:	name="Kindergarten Staufenstraße"
	v11:	name="Kindergarten "
	v12:	name="Kindergarten "

way 73563287 v9 has whitespace in the following tags:
		name="Holiday Inn Express "
history:
	v2:	name="Holiday Inn Express Frankfurt Airport"
	v3:	name="Holiday Inn Express Frankfurt Airport"
	v4:	name="Holiday Inn Express Frankfurt Airport"
	v5:	name="Holiday Inn Express Frankfurt Airport"
	v6:	name="Holiday Inn Express Frankfurt Airport"
	v7:	name="Holiday Inn Express Frankfurt Airport"
	v8:	name="Holiday Inn Express Frankfurt Airport"
	v9:	name="Holiday Inn Express "

way 159051148 v3 has whitespace in the following tags:
		name="Waldweg "
history:
	v2:	name="Waldweg nach Oblfing"
	v3:	name="Waldweg "

way 164929585 v3 has whitespace in the following tags:
		name="Zur Alten "
history:
	v1:	name="Zur Alten Flussbadeanstalt"
	v2:	name="Zur Alten Flussbadeanstalt"
	v3:	name="Zur Alten "

way 190901048 v6 has whitespace in the following tags:
		name="Gaertnerei "
history:
	v1:	name="Gärtnerei Christensen"
	v2:	name="Gärtnerei Christensen"
	v3:	name="Gärtnerei Christensen"
	v4:	name="Gaertnerei "
	v5:	name="Gaertnerei "
	v6:	name="Gaertnerei "


way 209783876 v3 has whitespace in the following tags:
		name=" Friedhof"
history:
	v1:	name="Jüdischer Friedhof"
	v2:	name=" Friedhof"
	v3:	name=" Friedhof"

oder der Wert aus anderen Gründen generell fragwürdig erscheint:

way 123007786 v4 has whitespace in the following tags:
		name=" (E6)"
history:
	v2:	name="Markeirung (E6)"
	v3:	name=" (E6)"
	v4:	name=" (E6)"

way 123253342 v8 has whitespace in the following tags:
		name="unmarkierter Grenzübergang "
history:
	v3:	name="unmarkieter Grenzübergang (15.7. bis 15.11)"
	v4:	name="unmarkieter Grenzübergang (15.7. bis 15.11)"
	v5:	name="unmarkieter Grenzübergang (15.7. bis 15.11)"
	v6:	name="unmarkieter Grenzübergang (15.7. bis 15.11)"
	v7:	name="unmarkieter Grenzübergang "
	v8:	name="unmarkierter Grenzübergang "

way 123554558 v5 has whitespace in the following tags:
		name="unmarkierter Grenzübergang "
history:
	v1:	name="unmarkierter Grenzübergang (15.7. bis 15.11)"
	v2:	name="unmarkierter Grenzübergang (15.7. bis 15.11)"
	v3:	name="unmarkierter Grenzübergang (15.7. bis 15.11)"
	v4:	name="unmarkierter Grenzübergang (15.7. bis 15.11)"
	v5:	name="unmarkierter Grenzübergang "

way 153774489 v8 has whitespace in the following tags:
		name=" (Im Winter,Loipe)"
history:
	v4:	name="Zum Goldsteig"
	v5:	name="Zum Goldsteig (Im Winter,Loipe)"
	v6:	name="Zum Goldsteig (Im Winter,Loipe)"
	v7:	name=" (Im Winter,Loipe)"
	v8:	name=" (Im Winter,Loipe)"

way 161638288 v3 has whitespace in the following tags:
		name="Krankenhaus Saarlouis vom DRK "
history:
	v1:	name="DRK Krankenhaus Saarlouis"
	v2:	name="DRK Krankenhaus Saarlouis"
	v3:	name="Krankenhaus Saarlouis vom DRK "

way 166975247 v5 has whitespace in the following tags:
		width="rutschiger ,Steiler Steig (Pfad) Gras, u. Dornen            "
history:
	v1:	width="rutschiger ,Steiler Pfad"
	v2:	width="rutschiger ,Steiler Pfad"
	v3:	width="rutschiger ,Steiler Pfad"
	v4:	width="rutschiger ,Steiler Steig (Pfad) Gras, u. Dornen            "
	v5:	width="rutschiger ,Steiler Steig (Pfad) Gras, u. Dornen            "

way 167067530 v5 has whitespace in the following tags:
		name="Albert Möllenberg Gartenbau u. Kranzbinderei (0) "
history:
	v1:	name="Möllenberg Albert Gartenbau u. Kranzbinderei (0) "
	v2:	name="Albert Möllenberg Gartenbau u. Kranzbinderei (0) "
	v3:	name="Albert Möllenberg Gartenbau u. Kranzbinderei (0) "
	v4:	name="Albert Möllenberg Gartenbau u. Kranzbinderei (0) "
	v5:	name="Albert Möllenberg Gartenbau u. Kranzbinderei (0) "

Auch schön:

way 11982334 v7 has whitespace in the following tags:
		name="Europasteg "
history:
	v3:	name="Europasteg"
	v4:	name="Europasteg"
	v5:	name="Europasteg"
	v6:	name="Europasteg (don't piss in the lake)"
	v7:	name="Europasteg "

Eine weitere automatische Korrektur, die ich gerne aufnehmen würde, betrifft Leerraum in Rollen von Relationsmitgliedern. Diese Korrektur paßt thematisch zur Korrektur von Leerraum in Tags und ließe sich auch technisch nahtlos in jene einbinden.

Die Behandlung von Leerraum in Rollen kann m.E. deutlich einfacher erfolgen als bei den Tags: Leerraum löschen, fertig. Eine Kontrolle von Vorgängerversionen scheint mir nicht nützlich, weil Rollen typischerweise nicht aus mehreren durch Leerzeichen getrennten Wörtern bestehen und z.B. " platform" nicht aus “bus platform” entstanden sein kann - bzw. wenn doch, war die ursprüngliche Rolle ohnehin Murks (anders als bei name="Zur Alten " entstanden aus name=“Zur Alten Flussbadeanstalt”). Auch eine besondere Zurückhaltung bei “nur Leerraum” erscheint mir nicht nötig, denn jedes Element einer Relation hat eine Rolle - aus dem bloßen Vorhandensein von role= kann man (im Gegensatz zu Tags) nicht folgern, daß der Mapper hier eine bestimmte Eigenschaft eintragen wollte.

Tatsächlich wären derzeit vornehmlich Rollen mit “nur Leerraum” betroffen:

     46 role=" "
     13 role="platform "
     13 role="forward "
      7 role="perimeter "
      5 role="forward_platform "
      2 role="entrance "
      1 role=" stop_exit_only"
      1 role="stop:39 "
      1 role="stop:38 "
      1 role="stop:37 "
      1 role="stop "
      1 role=" stop"
      1 role="platform:58 "
      1 role=" intersection"
      1 role="forward_stop_5 "
      1 role="forward_stop "
      1 role="backward_stop "
      1 role=" Backward"
      1 role="backward "

Aktuell insgesamt 99 Rollen, verteilt auf 39 Relationen.

Mir ist keine Rolle bekannt, die planmäßig ein Leerzeichen enthält. Von daher mach es so.

Ich bin erstaunt, dass es so wenige sind, da bisher die Rollen niemals systematisch auf Fehler geprüft wurden.

Edbert (EvanE)

+1

+1

Hallo Oli-Wan,

auch von mir mal eine Rückmeldung zu deinen umfangreichen Bemühungen: Super Arbeit, sehr hilfreich und gut dokumentiert. Find ich gut!

Wo ich gerade das " Backward" sehe, wird Großschreibung bei keys schon korrigiert? Bei roles wäre es auch gut.
Ich nutze backward und forward nicht mehr, aber ich kenne einen Mapper, der es an bestimmten (gehört hier nicht hin) Stellen gerne einsetzt. Trotz Hinweis schreibt er es meistens groß und dann bringt es gar nichts.

Viele Grüße
Daniel

Die Großschreibung ist leider häufig zu finden, z.B. Amenity=* oder amenity=Kindergarten

Es gibt so vieles, was automatisch korrigiert werden könnte.
Viel einfacher wäre aber eine automatische Überprüfung im Editor (bei JOSM teilweise bereits implementiert, bei Potlatch wohl noch nicht).
Aber selbst JOSM warnt nicht davor, maxweight=3,5 mit falschem Komma zu schreiben.

Walter

Auch Dinge wie operator=Deutsche Bundespost → Deutsche Post AG usw.

Nein. Ich versuche, verschiedenartige Korrekturen nicht zu vermischen, sondern jeweils nur zusammengehörende Korrekturen in einen Prozeß zu packen. Für Schreibfehler in Schlüsseln, Tags und Rollen habe ich noch nichts im Sortiment.

Hat mich auch gewundert. Andererseits muß man auch festhalten, daß nur ein Bruchteil aller Mapper jemals aktiv eine Relation bearbeitet hat. Laut hdyc sind nur gut 44’000 User letzter Anfasser mindestens einer Relation. Wie viele bleiben übrig, wenn man jene ausnimmt, die nur “passiv” eine Relation bearbeitet haben, etwa durch Löschen oder Aufspalten eines Weges? Vielleicht ein paar Tausend (weltweit!), und das sind tendentiell die erfahreneren Mapper, die mit ihrem jeweils bevorzugten Editor umgehen können. Noch dazu ist es häufig gar nicht (mehr) nötig, Rollen manuell einzutragen. JOSM kann einfache Multipolygone (outer, inner) automatisch erstellen, per Plugin auch Abbiegebeschränkungen (from, to, via), und hilft auch sonst per automatischer Ergänzung. Bei Routenrelationen braucht man ohnehin keine Rollen; und wie oft sie bei anderen Relationen schlicht fehlen, wo sie eigentlich nötig wären, vermag ich nicht zu sagen - aber auch fehlende Werte sparen falsche Werte ein.

Das mit der Großschreibung ist mir aber auch schon passiert. Sowohl im Key als auch im Value. Z.B. Building=Yes … Kann schon mal passieren, wenn man zu schnell tippt.
Im Value würde das Korrigieren wohl eine lange Liste an Werten benötigen, aber im Key sollte eine automatische Korrektur doch leicht möglich sein. Keys werden ja immer klein geschrieben.

Idealerweise ja, aber nicht jeder hält sich beim Tagging-Schema-Entwurf an diese Konvention. Beispiel: die TMC-Altlasten

Inzwischen sollte das Problem bei rosemary behoben sein, Issue ist geschlossen. Die Codepflege funktioniert dort inzwischen offenbar um Längen besser als in jenem dunklen Zeitalter voller Doppeleinträge, an das ich gar nicht zurückdenken mag. Damit bleibt noch Potlatch als Hauptquelle überschüssigen Leerraums.