Automatische Korrektur von Fehlern in addr:* (2) - postcode u. country

Warum nicht auch De → DE und dE → DE?
Und wenn schon DE vorliegt, können noch eventuelle Leerzeichen entsorgt werden.

Ob es wohl auch vorkommt, dass nachfolgende Form verwendet wird?

DE-12345 / DE 12345 / DE12345

Innerhalb des Deutschen Grenzpolygons sollte dies auch sicher ersetzbar sein.
Groß- und Kleinschreibung braucht man wohl weder beim “D” noch beim “DE” zu unterscheiden.

Warum machst du dir bei addr:country überhaupt die Mühe etwas zu ersetzen? Wenn ich das in diesem Thread richtig verstehe, filterst du die Daten durch ein “grenzscharfes Polygon”. Damit ist doch schon klar, dass addr:country nur DE sein kann. Und wenn er fehlt, kann er doch bedenkenlos hinzugefügt werden. Oder sehe ich das falsch?

Der erste Teil deiner Schlussfolgerung mag ja noch richtig sein, wobei ich die Behandlung von Enklaven wie die Vennbahn (belgisches Staatsgebiet) oder einige Stellen an der Schweizer Grenzen nicht kenne.

Ein Tagg hinzuzufügen, das bisher noch nicht da war, hat jedoch eine ganz andere Qualität, als einen gewollten aber fehlerhaften Wert zu korrigieren. Davon lässt man besser erst einmal die Finger. Sonst setzt man sich ggfs. dem Vorwurf aus, per Bot eine bestimmte Tagging-Praxis durchsetzen zu wollen. Das muss nun wirklich nicht sein.

Edbert (EvanE)

Das hatte ich auch überlegt, mich dann aber letztlich an den Fällen orientiert, die ich auch tatsächlich bisher vorgefunden habe. Grundsätzlich spricht nichts dagegen.

Bisher ist mir diese Form nicht begegnet, auch wenn sie vorstellbar ist. Ich vermute aber, daß diejenigen, die in addr:postcode das Land angeben, tendentiell keine ISO 3166-Codes kennen bzw. nicht wissen, daß diese in OSM genutzt werden.

Dazu hat mir Edbert bereits die Worte aus den Fingern genommen. Ich selbst vergebe addr:*-Tags auch stets im Fünferpack, möchte aber nicht anderen diese Tagging-Präferenz aufzwingen. Zwingend notwendig ist addr:country nicht, und manche halten es sogar für völlig überflüssig. Wenn das Tag vorhanden ist, soll es richtig sein; aber ob es verwendet wird, soll dem Mapper überlassen bleiben, der die Adresse eingetragen hat. Die Ergänzung von addr:country im Zuge der Korrektur von addr:postcode ist momentan der einzige Fall, der mir legitim erscheint, da hier der Mapper offenbar die Landeszugehörigkeit kodieren wollte.

Zumindest für andere Staaten habe ich Einträge wie “It” und"Be" gefunden. Für DE habe ich den Eindruck, dass die Einträge recht gut manuell gepflegt sind. Diese Arbeit sollte ja zukünftig der Bot weitgehend übernehmen. Ggf. müsste man die History überprüfen, wie oft z.B. “De” manuell korrigiert wurde. Man kann es natürlich auch einfach auf Verdacht einbauen, da ohne Risiko und Aufwand möglich.

Anderen aufzuzwingen so taggen zu müssen, würde ich auch nicht wollen. In gewisser Weise wird dies jedoch den Mappern schon durch die Verbreitung dieser Tags (zumindest in DE und DK) und dadurch, dass diese zu den MapFeatures gehören. Da würde der Bot eher diesen Zwang reduzieren. Davon, dass die Tags ohne Bot vielleicht nur in 50% der Adressen vorhanden sind, hat ja nun niemand einen Vorteil.
Der gravierenste Nachteil dieser Tags dürfte sein, dass deren Erstellung und Pflege Zeit kostet. Dies könnte der Bot weitgehend aufheben.

Völlig nutzlos ist es zumindest, wenn es nicht vollständig erfasst ist. Wenn es vollständig erfasst wäre, könnte es Auswertungen erleichtern und zur Erkennung von plotzlichen Problemen in Grenzrelationen dienen. Man sollte sich entscheiden, ob man dieses Tag will oder nicht. Die Variante wir machen halben Kram, um keine Entscheidung herbeiführen zu müssen, vereint nur alle Nachteile ohne irgendwelche Vorteile zu haben.

Das Tag würde wohl auch manuell von anderen Mappern nachgetragen, wobei ich vermuten würde, das dies häufig unabgestimmte mechanical Edits über JOSM sein werden. Ein nicht gesetztes Tag kann man ja nicht als Verbot werten, dieses noch zu setzen. Wenn man es so werten würde, wäre einem Mapper noch mehr aufgezwungen, diese Tags gleich mit zu setzen, wenn er dem Projekt nicht schaden will.

Man könnte das aber auch so interpretieren, dass der Mapper die Landeszugehörigkeit explizit in der Postleitzahl kodiert haben wollte.
Sehr viel wahrscheinlicher ist allerdings, das sich der Mapper nicht viel Gedanken über das Format gemacht hat.

“De” habe ich nun oben ergänzt.

Etwas mehr als 75 % der Adressen in Deutschland sind mit addr:country=DE getaggt.

Unglücklicherweise gibt es in OSM keinen allgemein akzeptierten Prozeß zur Herbeiführung einer solchen Entscheidung. Die Lösung, die Entscheidung alleine zu treffen und per Bot umzusetzen, ist aber zweifellos die am wenigsten akzeptierte; deshalb werde ich dies nicht tun. Wenn wir irgendwann einen Prozeß für eine solche Entscheidung haben (den ich mir sehr wünschen würde!) und diese Entscheidung zugunsten der systematischen Ergänzung ausfällt, stehe ich für die technische Umsetzung gerne zur Verfügung.

Ich weiß von mindestens einem Mapper, dessen “div. Adresskorrekturen” zum großen Teil im Ergänzen von addr:country bestehen (während Fehler wie “Strasse” und überzählige Leerzeichen erhalten bleiben). Wenn dies aber ein Mapper an jeweils einigen Dutzend Objekten macht, ist das etwas anderes als wenn ein Bot 800’000 Adressen anfaßt. Es ist auch weiterhin keinem Mapper verboten, das Tag zu setzen, aber meinen Bot werde ich nicht dafür einsetzen; schon allein um seine Akzeptanz nicht durch Bearbeitungen zu untergraben, die viele als überflüssig ansehen werden.

Danke!
Wenn man ein Feld automatisch ergänzen kann, dann ist das doch ein Zeichen für vollständige Redundanz und somit nicht nur überflüssig, sondern auch pflegeaufwendig. Ich hatte mal das Vergnügen einen Rechtschreibfehler im Straßennamen zu korrigieren, der an so ziemlich an allem was da so rumstand (Gebäuden samt Nebengebäuden und Zufahrten aller Art inclusive Relationen) dranhing :frowning:

Alleine treffen solltest du die Entscheidung natürlich nicht. Wenn es keinen passenden Prozeß gibt, sollte man dringend daran arbeiten, einen zu etablieren. Wie konnte man eigentlich die Entscheidung treffen, den redaction Bot massenhaft Daten vernichten zu lassen, wenn man nicht einmal in der Lage ist, zu entscheiden, ob man nun ein Tag ergänzen möchte oder es lieber aufgibt.

Das Tag mag man als überflüssig ansehen, jedoch sollte es allen einleuchten, dass die Bearbeitungen durch den Bot nicht überflüssig sind, da sie massiv Arbeitszeit von Mappern freisetzen, die an anderer Stelle sicher sinnvoller eingesetzt wäre. Wenn wir jetzt bereits 75% Prozent Anteil haben, kann man wohl davon ausgehen, dass dieses auch manuell weitgehend vervollständigt würde. Gegenüber dem Potential an Arbeitszeit, dass man hier einsparen könnte, sind die Einsparungen an Arbeitszeit durch deine Straßennamen-Korrekturen vermutlich lächerlich gering.

Prinzipiell gebe ich dir da Recht, aber ich muss da einige Einschränkungen machen:

  • Der Bot kann den Pflegeaufwand deutlich reduzieren.

  • Zumindest in DE (und DK) gilt, wenn wir jetzt schon 75% dieser Tags haben, würde der Pflegeaufwand auch nicht mehr wesentlich erhöht. Da die derzeit aufgebrachte Pflegearbeit vermutlich hauptsächlich in der Vervollständigung besteht, würde der Pflegeaufwand sogar deutlich reduziert.

  • Auch wenn ein Tag redundant ist, kann es ggf. manche Nutzungen (z.B. bei Abfragen über die Overpass API) erst ermöglichen, wenn es leicher auswertbar ist. Ich würde erwarten, dass die Prüfung, ob ein Element in einem Grenzpolygon enthalten ist, ungleich aufwendiger ist. Man musste wohl eine technische Lösung finden, damit keine Anwendungen an dem erhöhten Rechenzeitbedarf scheitern. Ansonsten dürfte ein Verzicht auf dieses Tag kaum durchsetzbar sein.

Ich denke auch, dass ein Verzicht auf dieses Tag auch am ehesten durchsetzbar wäre, wenn man den Umweg über eine automatische Vervollständigung nehmen würde. Denn dann würden diese Tags wohl langfristig nicht mehr als mühsam manuell erfasste Daten, sondern als Produkt eines Bots angesehen werden, bei dem dann das Löschen leichter fällt.

Mir gefällt diese Redundanz auch nicht. Hier wäre wohl die Lösung über eine Relation zumindest für die Pflege besser.
Allerdings dürfte die manuelle Umstellung und auch die Neuerstellung aufwendig und fehleranfällig sein.
Technisch würde ich hier auch ein großes Potential sehen, wo ein Bot behilflich sein kann. Mit passender Bot-Unterstützung würde ich dann auch die Neuerstellung und Plege für jedermann leicht handhabbar halten.
Allerdings müßten wir auch hierzu wieder eine Entscheidung herbeiführen, derartige Strukturen mit Bot-Unterstützung einzuführen.

Ein Nachtrag hierzu mit einem weiteren Grund, nicht einfach jeden vorhandenen Wert, sondern nur ganz bestimmte zu überschreiben: gelegentlich landet auch z.B. der Ortsname in addr:country, z.B. hier: http://www.openstreetmap.org/browse/node/2131504938/history

Aber hier (http://www.openstreetmap.org/?lat=48.98243933916092&lon=11.599038541316986&zoom=17) sind ja schon lauter Relationen gewesen!
Vor lauter Relationen schafft es der Renderer nicht mal, das landuse=residential darzustellen. Ich hatte damals fast schon überlegt, das ganze Dorf neu zu mappen - aber mittlerweile mache ich lieber einen Bogen um begeisterte Relationsmapper und solche Gebiete :frowning:
Nichts gegen sinnvoll eingesetzte Relationen, aber pflegen tu’ ich sie definitiv nicht gerne, wenn sie flächendeckend und NUR für eine idealisierte Datenstruktur erzeugt werden. Wer sowas macht, soll sich privat ein GIS anschaffen und dort spielen (grummel).

Es gibt ja auch Gegenden wo country wirklich sinnvoll ist. → http://de.wikipedia.org/wiki/Baarle

Ich glaube auch, dass es ein Problem ist, dass in JOSM die Vorlage für Adressen sich alles “merkt” außer country. Das ist das einzige, was ich wenn ich mehrere Adressen hintereinander eintrage, bei jeder Adresse noch mal Manuell eingeben muss. Oder ist das nur bei mir so?

@ubahnverleih: Bei Adressen kopiere ich den node → füge ihn ein → ändere die Hausnummer → fertig.

@pyram: Hatte auch einmal helfen wollen und Wiese und Acker von den Straßen getrennt und als landuse eingetragen - war aber ganz schnelle zurückgepappt. - Also doch Bogen machen.

Oder hinterher, mit dem Filter, alle passenden Knoten oder Wege auswählen und an alle ein passendes Tag drankleben. Funktioniert in Baarle eher schlecht, aber mitten im Land ist das recht effektiv.

Per Mail hat mich der Vorschlag erreicht, Wall·E auch für die Korrektur solcher Fälle abzurichten. Dort wurde der Name eines Bundeslandes in addr:country eingetragen.

Ich bin mir noch unschlüssig, ob ich diese Idee weiter verfolge - ich weiß nicht, wie häufig dieser Fehler passiert. Bisher ist mir nur dieser eine Fall (in 41-facher Ausführung) bekannt. Wenn wirklich nur ein bis zwei Mal im Jahr jeweils eine Handvoll bis ein paar Dutzend Objekte so getaggt werden, können sie auch gerne zur manuellen Korrektur stehen bleiben. Im housenumbervalidator werden sie angezeigt.

Falls ich aber eine Ersetzung von addr:country zu DE vorsehe, wenn dort der Name eines Bundeslandes steht, stellt sich die Frage, was aus dem ursprünglichen Wert werden soll. Einerseits hat der Nutzer den Namen eingetragen, und gerade ein Bot sollte grundsätzlich keine Information löschen, sondern in diesem Fall lieber in addr:state verschieben. Andererseits ist nach meinem Verständnis in Deutschland das Bundesland nicht Bestandteil einer “Adresse” - weder im strengen Sinne einer Postanschrift [1] noch im täglichen Sprachgebrauch (man sagt ja nicht “Köln, NRW” wie etwa “Austin, Texas”). So gesehen könnte das Bundesland auch ganz weg.

Was meint ihr?

[1] Man kann natürlich z.B. “Freistaat Bayern” mit auf den Briefumschlag schreiben, um die dortige separatistische Folklore zu parodieren - dann muß man konsequenterweise aber auch Auslandsporto aufkleben.

Nahmd,

ein wenig offtopic: wäre es möglich, bei jedem Durchlauf Einträge mit leading oder trailing Blankspace in allen Feldern zu korrigieren?

Möglicherweise auch Mehrfachblanks und Tabs im inneren auf Einzelblanks normieren, da bin ich mir aber nicht sicher.

Ich denke, das sind immer Vertipper, denn je nach Programmierung der Auswertetools wird ein solcher Eintrag bei einer Suchmaschine nicht gefunden oder von einer Renderengine ignoriert werden, was kaum im Sinne des Eingeber ist.

Wir haben zur Zeit >1.2 Millionen solcher Einträge in der Datenbank, und das wäre ein kleiner Anfang, die Zahl abzubauen. Händisch hat man da ja keine Chance mehr.

Oder sprengt dies das Konzept der Fehlerkorrektur?

Ich mache das bereits für die Keys, allerdings händisch: das ist möglich, weil nur so um zehn neue pro Tag auftauchen. Ich hatte auch schon überlegt, die Korrektur der Values (nur für DE und nach vorheriger Diskussion) selbst anzugehen, hab die Idee aber verworfen: ich hab einfach zuviel Angst vor automatisierten Edits. (Hier Smily mit gesträubten Haaren hindenken)

Gruß Wolf

Wenn Du versprichst, Dich auch on-topic zu äußern, darfst Du weiterlesen :wink:

Leading/trailing whitespace war einer der Punkte im ursprünglichen Meinungsbild zur Wiederaufnahme der xybot-Korrekturen und fand damals breite Zustimmung. Ich hatte mich seinerzeit enthalten, weil ich mir unschlüssig war, wie problematisch überzähliger Leerraum tatsächlich ist. (Klar, er gehört da nicht hin; aber tut er in allen Fällen so weh, daß man ihn per Bot bekämpfen muß?) Wenn die addr:*-Korrekturen abgeschlossen sind, könnte ich das Thema Leerraum auch noch angehen. Sonst scheint sich niemand darum zu reißen. (Schade eigentlich: mir wäre lieb, wenn das einschlägige Know-how auf ein paar mehr Köpfe verteilt wäre. Wobei gerade Leerraum-Entfernung mit meiner inzwischen vorhandenen Software-Infrastruktur ein Klacks ist, und jemand anders erst bei Null anfangen müßte.) Das kann aber noch ein paar Wochen dauern; bis dahin hoffe ich auch, daß mein Antrag auf einen Toolserver-Account durchkommt.

“Nebenbei” im Zuge der bisher implementierten Korrekturen bringt Leerraum-Entfernung meines Erachtens nicht viel. Ich bearbeite ja nur kleinen Bruchteil der täglich hinzugekommenen Daten; da würde ich auch nur einen Bruchteil des überzähligen Leeraums erwischen. Und eigentlich möchte ich Korrekturen, die nicht artverwandt sind, in Code, Filtering und Changesets auch lieber getrennt halten.

Dann lieber mit einem eigenen Werkzeug Leerraum gründlich entfernen. Und einen neuen Faden aufmachen :wink:

Nahmd,

Werd ich eher nicht, und das aus gutem Grund: ich hab für die Prisma (Fernsehbeilage in vielen Zeitungen in NRW) das Aufräumen der angelieferten Programmdaten gebaut. Das Material enthält Fehler: falschgeschrieben Namen von Darstellern und Crew, von den Sendern verhunzte Filmtitel, Unfug in Texten (im XML-Textfeld eine RTF-Datei), usw.
Mit dem Zeug wird eine strukturierte Datenbank gefüllt; es geht um täglich ca. 5000 Sendungen mit 50000 zu prüfenden und zu fixenden Datensätzen. Dabei fallen Arbeitslisten für die Redakteure an (Zeug was ich als Unfug erkenne, aber mit den vorhandenen Regeln nicht gefixt bekomme); diese geben die Korrektur ein, aus der neue Regeln entstehen.
Mit der Erfahrung aus dem Projekt würde ich wahrscheinlich so ziemlich alles anders machen. Und deshalb halte ich mich lieber ganz raus. :slight_smile:

Sorry, das habe ich einfach verpennt.

Das gilt auch für andere Themen: von den gut 30.000 verwendeten Keys könnte man auch leicht ein Drittel entsorgen praktisch ohne entwas kaputt machen zu können, weil das im Grunde Fehler sein müssen. Und für die allermeisten würde ich automatisch einen Ersatz finden, ohne Basteln von regulären Ausdrücken, sondern einfach mit fehlertoleranter Suche in einer Liste der bekannten Tags.

Ich drücke die Daumen. Kann man irgendwo ein “+1” (wie ich dieses Mem hasse! ;)) hinterlassen für den Antrag?

Ok. Gute und nachvollziehbare Entscheidung.

Letzteres ist unnötig; die Frage ist ja vollständig beantwortet.

Gruß Wolf

.oO( … hat sich bemüht, den Anforderungen der Fragestellung gerecht zu werden … ) :stuck_out_tongue:

Jetzt doch noch einer off-topic von mir hinterher: Der Code für die Entfernung von führendem/nachfolgendem Leerraum ist fertig (21 Zeilen Emacs Lisp inklusive Docstring), aber bis auf weiteres werde ich den nur auf handverlesene Objekte loslassen (vgl. 15022201 ff.). Bei der Bot-Entwicklung haben erstmal die Adresskorrekturen Vorrang. Wenn ich sicher bin, daß diese zuverlässig laufen, kann das nächste Projekt kommen. Und das dann hoffentlich auf dem Toolserver.