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

Communities Deutschland (Germany)
81

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 "
82

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.

83

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)

84

+1

85

+1

86

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

87

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

88

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

89

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.

90

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.

91

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

92

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.

93

Ok, dann wird das wohl doch komplizierter. Wär ja auch zu schön gewesen.

94

Vorschlag für den Anfang: Nur dann den ersten Buchstaben kleinschreiben, wenn danach keine Großbuchstaben mehr kommen. Während es durchaus Sinn machen kann, Abkürzungen auch in keys groß zu schreiben sollte [A-Z][a-z]* eigentlich immer falsch sein, weil es einfach nicht den allgemeinen Regeln entspricht, selbst wenn es vielleicht in einem Proposal in dieser Form angenommen worden wäre.