OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#1 2013-01-03 13:23:37

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

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

Noch ein Vorschlag für eine automatische Korrektur. Diesmal geht es um zwei relativ einfache Fälle, die ich hier zusammenfasse. Die allgemeinen Gegebenheiten (Anwendungsbereich, Account usw.) sind die gleichen wie in http://forum.openstreetmap.org/viewtopic.php?id=19610 .

  1. In addr:country soll

    d / D / de / De / GER / Deutschland / Germany -> DE

    ersetzt werden, wobei auch Leerraum vor oder nach dem ursprünglichen Wert gleich mit ersetzt wird und im Falle der ausgeschriebenen Worte Groß- und Kleinschreibung nicht beachtet wird (also auch GERMANY, GERmany, deutschland etc.).

    Zum Nachlesen der Regexe:

    (osm-obj-tag-value-replace-regexp
    	object "addr:country"
    	"^[[:blank:]]*\\(Deutschland\\|Germany\\)[[:blank:]]*$"
    	"DE")

    ohne Unterscheidung zwischen Groß und Klein; sowie mit Unterscheidung:

    (osm-obj-tag-value-replace-regexp
    	object "addr:country"
    	"^[[:blank:]]*de[[:blank:]]*$" "DE")
  2. Beim Auftreten von

    D-12345 / D 12345 / D12345 / D - 12345
    DE-12345 / DE 12345 / DE12345 / DE - 12345

    (also Buchstabe D und genau fünf Ziffern, unmittelbar aufeinander folgend oder durch Leerzeichen, Bindestrich oder die Folge " - "getrennt, oder dasselbe in grün mit DE) in addr:postcode soll dies durch die Ziffernfolge ersetzt werden; falls noch nicht vorhanden, wird ferner addr:country=DE ergänzt. Leerraum vor/hinter der ursprünglichen Zeichenfolge wird ebenfalls erkannt und entfernt.

    (osm-obj-tag-value-replace-regexp
      object "addr:postcode"
      "^[[:blank:]]*D\\([- ]\\| - \\)?\\([[:digit:]]\\{5\\}\\)[[:blank:]]*$"
      "\\2")
    (osm-obj-add-tag object "addr:country" "DE")

Edits
De -> DE ergänzt.
" - " ergänzt.
"GER" ergänzt.
"DE...12345"-Kombinationen ergänzt.
"d / D" ergänzt

Last edited by Oli-Wan (2013-07-29 09:47:16)


No animals were harmed in the writing of this posting.

Offline

#2 2013-01-04 02:17:37

slhh
Member
Registered: 2012-09-02
Posts: 358

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

Oli-Wan wrote:

In addr:country soll

de / Deutschland / Germany -> DE

ersetzt werden, wobei auch Leerraum vor oder nach dem ursprünglichen Wert gleich mit ersetzt wird und im Falle der ausgeschriebenen Worte Groß- und Kleinschreibung nicht beachtet wird (also auch GERMANY, GERmany, deutschland etc.).

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

Offline

#3 2013-01-04 02:34:58

slhh
Member
Registered: 2012-09-02
Posts: 358

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

Oli-Wan wrote:

Beim Auftreten von

D-12345 / D 12345 / D12345

(also Buchstabe D und genau fünf Ziffern, unmittelbar aufeinander folgend oder durch Leerzeichen oder Bindestrich getrennt) in addr:postcode soll dies durch die Ziffernfolge ersetzt 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.

Offline

#4 2013-01-04 08:22:03

webpassenger
Member
Registered: 2009-05-08
Posts: 35

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

Oli-Wan wrote:

In addr:country soll

de / Deutschland / Germany -> DE

ersetzt werden, wobei auch Leerraum vor oder nach dem ursprünglichen Wert gleich mit ersetzt wird und im Falle der ausgeschriebenen Worte Groß- und Kleinschreibung nicht beachtet wird (also auch GERMANY, GERmany, deutschland etc.).

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?

Offline

#5 2013-01-04 09:25:07

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

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

webpassenger wrote:
Oli-Wan wrote:

In addr:country soll
    de / Deutschland / Germany -> DE
ersetzt werden, wobei auch Leerraum vor oder nach dem ursprünglichen Wert gleich mit ersetzt wird ...

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)

Offline

#6 2013-01-04 09:48:43

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

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

slhh wrote:

Warum nicht auch De -> DE und dE -> DE?

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.

slhh wrote:

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

DE-12345 / DE 12345 / DE12345

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.

webpassenger wrote:

Warum machst du dir bei addr:country überhaupt die Mühe etwas zu ersetzen? ... Und wenn er fehlt, kann er doch bedenkenlos hinzugefügt 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.

Last edited by Oli-Wan (2013-01-04 10:06:12)


No animals were harmed in the writing of this posting.

Offline

#7 2013-01-05 17:13:01

slhh
Member
Registered: 2012-09-02
Posts: 358

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

Oli-Wan wrote:
slhh wrote:

Warum nicht auch De -> DE und dE -> DE?

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.

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.

Oli-Wan wrote:

Ich selbst vergebe addr:*-Tags auch stets im Fünferpack, möchte aber nicht anderen diese Tagging-Präferenz aufzwingen.

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.

Oli-Wan wrote:

Zwingend notwendig ist addr:country nicht, und manche halten es sogar für völlig überflüssig.

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.

Oli-Wan wrote:

Wenn das Tag vorhanden ist, soll es richtig sein; aber ob es verwendet wird, soll dem Mapper überlassen bleiben, der die Adresse eingetragen hat.

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.

Oli-Wan wrote:

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.

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.

Offline

#8 2013-01-06 23:49:55

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

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

slhh wrote:

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.

"De" habe ich nun oben ergänzt.

slhh wrote:

Davon, dass die Tags ohne Bot vielleicht nur in 50% der Adressen vorhanden sind, hat ja nun niemand einen Vorteil.

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

slhh wrote:

Die Variante wir machen halben Kram, um keine Entscheidung herbeiführen zu müssen, vereint nur alle Nachteile ohne irgendwelche Vorteile zu haben.

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.

slhh wrote:

Das Tag würde wohl auch manuell von anderen Mappern nachgetragen, ... Ein nicht gesetztes Tag kann man ja nicht als Verbot werten, dieses noch zu setzen.

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.


No animals were harmed in the writing of this posting.

Offline

#9 2013-01-07 00:34:46

pyram
Member
Registered: 2012-06-16
Posts: 926

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

Oli-Wan wrote:

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 :-(

Offline

#10 2013-01-07 02:20:32

slhh
Member
Registered: 2012-09-02
Posts: 358

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

Oli-Wan wrote:

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.

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.

Oli-Wan wrote:

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.

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.

Last edited by slhh (2013-01-07 02:21:16)

Offline

#11 2013-01-07 03:23:39

slhh
Member
Registered: 2012-09-02
Posts: 358

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

pyram wrote:

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.

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.

pyram wrote:

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 :-(

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.

Offline

#12 2013-01-29 17:06:47

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

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

webpassenger wrote:
Oli-Wan wrote:

In addr:country soll
de / Deutschland / Germany -> DE
ersetzt werden, wobei ...

Warum machst du dir bei addr:country überhaupt die Mühe etwas zu ersetzen?

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/nod … 38/history


No animals were harmed in the writing of this posting.

Offline

#13 2013-01-29 22:37:01

pyram
Member
Registered: 2012-06-16
Posts: 926

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

slhh wrote:

Hier wäre wohl die Lösung über eine Relation zumindest für die Pflege besser.

Aber hier (http://www.openstreetmap.org/?lat=48.98 … 86&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 :-(
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).

Offline

#14 2013-02-01 10:03:15

ubahnverleih
Member
From: Dresden
Registered: 2011-06-04
Posts: 81

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

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?

Offline

#15 2013-02-01 10:29:24

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 4,049
Website

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

@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.

Offline

#16 2013-02-01 15:37:29

errt
Member
Registered: 2009-12-01
Posts: 1,068

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

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.

Offline

#17 2013-02-13 13:35:23

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

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

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.

Last edited by Oli-Wan (2013-02-13 14:02:45)


No animals were harmed in the writing of this posting.

Offline

#18 2013-02-13 15:03:31

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

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

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

Offline

#19 2013-02-13 16:30:40

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

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

Netzwolf wrote:

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

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


No animals were harmed in the writing of this posting.

Offline

#20 2013-02-13 17:11:56

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

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

Nahmd,

Oli-Wan wrote:

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

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. smile

Leading/trailing whitespace war einer der Punkte im ursprünglichen Meinungsbild zur Wiederaufnahme der xybot-Korrekturen und fand damals breite Zustimmung.

Sorry, das habe ich einfach verpennt.

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.

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.

(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.

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

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

Ok. Gute und nachvollziehbare Entscheidung.

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

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 … ) tongue

Offline

#21 2013-02-13 21:43:28

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

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

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.

Last edited by Oli-Wan (2013-02-13 21:47:45)


No animals were harmed in the writing of this posting.

Offline

#22 2013-02-26 13:01:12

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

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

Ich habe bei der Trennung von PLZ und Ort noch eine Ergänzung vorgenommen. Neben

D-12345 / D 12345 / D12345

wird nun auch

D - 12345

erkannt und verarbeitet. Stein des Anstoßes war dieser Knoten.


No animals were harmed in the writing of this posting.

Offline

#23 2013-02-27 00:11:29

RvdtG
Member
Registered: 2012-08-22
Posts: 56

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

Man könntest auch ganz verwegen auf Vorhandensein eines 5-stelligen numerischen Strings prüfen und den ggf. vorhandenen Rest entfernen. Oder weniger verwegen, beliebige Kombinationen von Sonderzeichen zwischen D/DE und der 5-stelligen Zahl entfernen.

Prüfst du bei Postleitzahlen mit D/DE ob addr:country vorliegt? Andernfalls würde ich ein solches Vorliegen als Indiz für eine deutsche Postanschrift werten.

Kann eigentlich - außer den bereits genannten Exklaven - eine ausländische Anschrift auch bei exterritorialen Gebieten wie Konsulaten oder Kasernen vorliegen?

Grüße
RvdtG

Offline

#24 2013-02-27 11:35:17

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

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

RvdtG wrote:

Man könntest auch ganz verwegen auf Vorhandensein eines 5-stelligen numerischen Strings prüfen und den ggf. vorhandenen Rest entfernen.

Das würde auch addr:postcode="12345 Kleinkleckersdorf" erfassen, siehe http://forum.openstreetmap.org/viewtopic.php?id=19840 .

RvdtG wrote:

Oder weniger verwegen, beliebige Kombinationen von Sonderzeichen zwischen D/DE und der 5-stelligen Zahl entfernen.

Das wäre möglich; der von mir gewählte Weg ist sicher nicht der einzig gangbare. Mir ist aber wohler dabei, die Regeln für die Ersetzung so streng wie möglich zu halten und nur bei Bedarf schrittweise zu erweitern, als mit einer von vornherein (zu) weit gefaßten Regel irgendwann eine böse Überraschung zu erleben. Der jetzige Regex deckt sämtliche korrigierbaren Fälle von "Postleitzahl mit D" ab, die mir bisher begegnet sind. Natürlich sind auch andere Formate denkbar, aber wenn sie in der Realität nicht auftreten, braucht man sie auch nicht zu berücksichtigen.

RvdtG wrote:

Prüfst du bei Postleitzahlen mit D/DE ob addr:country vorliegt? Andernfalls würde ich ein solches Vorliegen als Indiz für eine deutsche Postanschrift werten.

Nein. addr:country=DE wird aber im Zuge der Korrektur von addr:postcode ergänzt, falls noch nicht vorhanden. "D-", fünfstellige Postleitzahl und Lage innerhalb Deutschlands sind für mich Hinweis genug, daß es sich um eine deutsche Adresse handelt.

RvdtG wrote:

Kann eigentlich - außer den bereits genannten Exklaven - eine ausländische Anschrift auch bei exterritorialen Gebieten wie Konsulaten oder Kasernen vorliegen?

Einziges mir bekanntes Beispiel in OSM: http://www.openstreetmap.org/browse/way/54222836
Enklaven werden durch das Filterpolygon berücksichtigt.


No animals were harmed in the writing of this posting.

Offline

#25 2013-05-06 21:18:13

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

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

Zwei weitere triviale Ergänzungen "based on a true story": in

de / De / GER / Deutschland / Germany -> DE

ist GER neu (zu viele Sportübertragungen geguckt?), zu

D-12345 / D 12345 / D12345 / D - 12345

ist jetzt auch noch

DE-12345 / DE 12345 / DE12345 / DE - 12345

hinzugekommen.


No animals were harmed in the writing of this posting.

Offline

Board footer

Powered by FluxBB