Automatische Korrektur von Fehlern in addr:* (5) - street, housenumber

Oli-Wan wrote:

Ein weiterer sehr häufiger Fehler beim Eintragen von Adressen besteht darin, daß Straße und Hausnummer nicht separat, sondern zusammen in entweder addr:street oder addr:housenumber geschrieben werden; ... Diese Daten sollen getrennt werden.

... wurde zurecht darauf hingewiesen, daß es nicht damit getan ist, einfach die vermeintliche Hausnummer zu identifzieren, ... Grund ist, daß es einzelne Straßen gibt, deren Name tatsächlich eine Zahl am Ende enthält ...

Ich denke, daß ich nun einen Weg gefunden habe, die Korrektur hinreichend sicher zu gestalten; ...

Die vorgesehene Korrektur geht wie folgt vonstatten: zunächst wird überprüft, ob addr:street die Form "Straße Nummer" hat; ...

Bei dieser Prüfung werden die mutmaßlichen Adressbestandteile bereits identifiziert. ... Im Prinzip könnte nun ... wäre da nicht das Restrisiko mit den numerierten Straßen.
Hierfür habe ich mir folgende Lösung überlegt: per Abfrage an die Oberpfalz-API wird geprüft, ob es in der Nähe (...) eine Straße gibt, deren name-Tag mit dem zuvor identifizierten Straßennamen übereinstimmt. ...
Wird eine Straße (...) dieses Namens gefunden, wird die Korrektur durchgeführt.

... eure Meinungen? Reicht die vorgesehene Sicherung aus? Habe ich Sonderfälle übersehen?

So wie beschrieben finde ich das sinnvoll.
Die eingebauten Prüfungen geben nach meiner Einschätzung genug Sicherheit, um Fehl-Korrekturen zu vermeiden.

Dass einige Fälle nicht korrigiert werden können, weil z.B. der Straßenname falsch geschrieben ist oder mehrere Hausnummern verwendet wurden, muss man wohl in Kauf nehmen. Dafür gibt es ja die Warnung "Still looks strange ..."

Edbert (EvanE)

EvanE wrote:

Dafür gibt es ja die Warnung "Still looks strange ..."

Jein. Eine solche Warnung kommt nur ins Log, wenn das Objekt auch angefaßt wurde, aber immer noch Auffälligkeiten bestehen, d.h. Wall·E einen Teil, aber nicht alle Fehler behoben hat.
Beispiel: "Carl-Marx-Str. 25" wird zu "Carl-Marx-Straße 25" ersetzt, aber die Zerlegung von Straße und Hausnummer erfolgt nicht, weil die nahegelegene Straße natürlich Karl-Marx-Straße heißt. Dann wird das verdächtige Tag im Log vermerkt (dieses Verdachtslogging muß ich allerdings noch einmal sorgfältig überarbeiten). Steht dagegen von vornherein "Carl-Marx-Straße 25" in addr:street (und liegt auch sonst kein korrigierbarer Fehler vor), wird keine Änderung vorgenommen und es gibt keinen Logeintrag. Dafür taucht das Objekt zum einen immer wieder in der Kandidatenliste auf, die ich mir gelegentlich näher ansehe, zum anderen gibt es ja noch andere Werkzeuge.

Die Ausgabe auf der Konsole ist noch etwas ausführlicher als das veröffentlichte Log; dort stehen u.a. auch die Objekte, die überhaupt nicht bearbeitet wurden, etwa weil der Filter zu grob arbeitet oder der ursprünglich vorhandene Fehler in der Version auf dem Server nicht mehr besteht:

Fetching␣way␣#37419903␣from␣the␣server...
This␣way␣is␣not␣affected␣by␣any␣substitution␣rule.

Daneben gibt es eine zweite Ausschlußliste (primär um unnötige Serverzugriffe zu verhindern):

node␣#1702684704␣is␣on␣the␣"probably␣fine"␣list␣-␣skipping.

Und schließlich noch die Fälle, wo sehr wahrscheinlich ein Fehler vorliegt, der Bot aber machtlos ist:

node␣#1154688902's␣addr:city␣tag␣looks␣funny:␣"Schachtenbach␣921␣Meter"
but␣I␣can't␣do␣anything␣about␣it
This␣way␣is␣not␣affected␣by␣any␣substitution␣rule
way␣#42806823's␣addr:postcode␣tag␣looks␣funny:␣"223983"
but␣I␣can't␣do␣anything␣about␣it
This␣way␣is␣not␣affected␣by␣any␣substitution␣rule
way␣#136509708's␣addr:postcode␣tag␣looks␣funny:␣"Leiking"
but␣I␣can't␣do␣anything␣about␣it
This␣way␣is␣not␣affected␣by␣any␣substitution␣rule
way␣#192606969's␣addr:postcode␣tag␣looks␣funny:␣"465282"
but␣I␣can't␣do␣anything␣about␣it
This␣way␣is␣not␣affected␣by␣any␣substitution␣rule
way␣#198303762's␣addr:postcode␣tag␣looks␣funny:␣"0738"
but␣I␣can't␣do␣anything␣about␣it
This␣way␣is␣not␣affected␣by␣any␣substitution␣rule

Vier der gezeigten fünf Fehler tauchen auch im housenumbervalidator auf und verschwinden in der Folge bald.

Im Simulationsmodus (kein Schreiben zur API) ist Wall·E übrigens auch über das "normale" Log noch etwas geschwätziger und läßt sich detailliert auch über die Fälle aus, die oben mit "not affected" abgehandelt werden:

no␣edits␣made␣to␣node␣#298518238.␣timestamp=2010-05-24T15:54:20Z,␣addr:*␣tags:
addr:city="Birkenau"
addr:country="DE"
addr:housenumber="Schimbach␣15"
addr:postcode="69488"
addr:street="Schimbacher␣Straße"
no␣edits␣made␣to␣node␣#342241098.␣timestamp=2009-12-10T00:32:47Z,␣addr:*␣tags:
addr:city="Tønder"
addr:housenumber="6"
addr:postcode="6270"
addr:street="Møllehusvej"
no␣edits␣made␣to␣node␣#462335269.␣timestamp=2013-02-11T22:02:56Z,␣addr:*␣tags:
addr:housenumber="51"
addr:postcode="17192"
addr:street="Papenbergstraße"
no␣edits␣made␣to␣node␣#648991784.␣timestamp=2012-12-17T20:34:09Z,␣addr:*␣tags:
addr:housenumber="zu␣1"
no␣edits␣made␣to␣node␣#747161501.␣timestamp=2010-05-24T15:53:38Z,␣addr:*␣tags:
addr:city="Birkenau"
addr:country="DE"
addr:housenumber="Schimbach␣21"
addr:postcode="69488"
addr:street="Schimbacher␣Straße"
...

Soweit der kleine Exkurs zur Wall·E-sischen Prosa 😉

Hat denn neben Edbert (und mir) niemand eine Meinung hierzu?
Ich weiß, daß ich euch viel Text zumute, und man einige Minuten braucht, um die Beschreibung zu verdauen. Ich möchte euch aber bitten, diese Zeit zu investieren. Vielleicht findet ihr ein Problem, das ich bisher übersehen habe. Auch wenn Teile der Beschreibung unklar sind, bitte nachfragen! - vielleicht liegt es daran, daß ich den betreffenden Aspekt selbst nicht hinreichend verstanden habe.

PS. Toolserver-Account ist genehmigt.

EvanE wrote:

Dass einige Fälle nicht korrigiert werden können, weil z.B. der Straßenname falsch geschrieben ist oder mehrere Hausnummern verwendet wurden, muss man wohl in Kauf nehmen. Dafür gibt es ja die Warnung "Still looks strange ..."

Kennt ihr die PHP-Funktion similar_text? Keine Ahnung ob selbiges bei dir auch möglich wäre, aber ich könnte mir Vorstellen, dass man den Straßennamen der Straße mit der aus addr:street vergleicht, und (wenn wie in deinen Beispielen ein Bindestrich fehlt) sobald eine Ähnlichkeit von ca. 90% erreicht ist, automatisch der Straßenname in addr:street übernommen werden kann. Den Prozentwert kann man vlt. abhängig von der Stringlänge variabel setzen. Nur so eine Idee 😉

Ansonsten gibt es zu deiner super Arbeit nicht viel zu sagen. Was du machst hat Hand und Fuß 🙂

reneman wrote:

Kennt ihr die PHP-Funktion similar_text? Keine Ahnung ob selbiges bei dir auch möglich wäre, aber ich könnte mir Vorstellen, dass man den Straßennamen der Straße mit der aus addr:street vergleicht, und (wenn wie in deinen Beispielen ein Bindestrich fehlt) sobald eine Ähnlichkeit von ca. 90% erreicht ist, automatisch der Straßenname in addr:street übernommen werden kann. Den Prozentwert kann man vlt. abhängig von der Stringlänge variabel setzen. Nur so eine Idee 😉

Der Name an der Straße ist aber nicht notwendigerweise richtiger als der in addr:street. Deswegen sollte Wall-E dort nichts ändern. Es sei denn, eine einzelne Adresse wird durch mehrere Adressen mit der gleiche Schreibweise wie die angrenzende Straße haben überstimmt.

Für alle anderen Fälle hilft nur manuelles Überprüfen aller Fehler, die der Adress-Layer des OSM Inspektors anmeckert.

Baßtölpel

Für die Korrektur der Straßennamen gibt es doch schon eine Prozedur (Daher die Annahme, dass diese "richtiger" sind inkl. Abgleich Straßenlisten). Aber du hast recht, über einen Umkreisabgleich via Overpass-API spricht grundsätzlich nix, außer der User der addr:street gesetzt hat, hat überall via Copy&Paste alle addr:street falsch gesetzt 😄

reneman wrote:

Für die Korrektur der Straßennamen gibt es doch schon eine Prozedur (Daher die Annahme, dass diese "richtiger" sind inkl. Abgleich Straßenlisten). Aber du hast recht, über einen Umkreisabgleich via Overpass-API spricht grundsätzlich nix, außer der User der addr:street gesetzt hat, hat überall via Copy&Paste alle addr:street falsch gesetzt 😄

Die Straßenlisten sind aber noch nicht flächendeckend verfügbar und in manchen Gegenden von zweifelhafter Qualität. In vielen ländlichen Gegenden hat sich auch noch niemand um die fehlenden oder falschen Straßen gekümmert. Es ist nicht überall so grün wie in NRW... Aber langfristig kann man natürlich schon davon ausgehen, daß die Straßen korrekt sind weil anhand der Straßenlisten verifiziert.

Baßtölpel

Baßtölpel

reneman wrote:

EvanE wrote:

Dass einige Fälle nicht korrigiert werden können, weil z.B. der Straßenname falsch geschrieben ist oder mehrere Hausnummern verwendet wurden, muss man wohl in Kauf nehmen. ...

Kennt ihr die PHP-Funktion similar_text? Keine Ahnung ob selbiges bei dir auch möglich wäre, aber ich könnte mir Vorstellen, dass man den Straßennamen der Straße mit der aus addr:street vergleicht, und (wenn wie in deinen Beispielen ein Bindestrich fehlt) sobald eine Ähnlichkeit von ca. 90% erreicht ist, automatisch der Straßenname in addr:street übernommen werden kann. Den Prozentwert kann man vlt. abhängig von der Stringlänge variabel setzen. Nur so eine Idee 😉

Ansonsten gibt es zu deiner super Arbeit nicht viel zu sagen. Was du machst hat Hand und Fuß 🙂

Ein Bot wie Wall-E soll nur dann korrigieren, wenn die Korrektur sehr sicher richtig ist. Etwas zu korrigieren nur weil es wahrscheinlich richtiger ist, kann ziemlich daneben gehen.
Das habe ich bei einer Korrektur von addr:street in einer Straße erlebt, deren Name falsch geschrieben war. Als dann der Straßenname auf die richtige Schreibweise korrigiert wurde, durfte ich das ganze Prozedere noch einmal wiederholen.

Unabhängig davon meine ich, dass die Suche nach Fehlern, die für Wall-E entwickelt wurde, gegebenenfalls zusätzlich für eine Qualitätskarte genutzt werden kann. Dabei kann eine Ähnlickeitssuche oder andere Erweiterungen ggfs. sinnvoll sein.

Edbert (EvanE)

EvanE wrote:

Unabhängig davon meine ich, dass die Suche nach Fehlern, die für Wall-E entwickelt wurde, gegebenenfalls zusätzlich für eine Qualitätskarte genutzt werden kann. Dabei kann eine Ähnlickeitssuche oder andere Erweiterungen ggfs. sinnvoll sein.

Grundsätzlich gerne (wobei ich zum Bauen einer solchen Karte der falsche Ansprechpartner bin); ich fürchte aber, daß Du Dir davon ein bißchen zuviel versprichst. Mein Filterprogramm ist sehr simpel - da steckt nichts drin, was die Entwickler von housenumbervalidator und OSMAddressCorrector nicht auch (und schon lange vor mir) hingekriegt haben. Außerdem ist es darauf ausgelegt, gerade jene Objekte zu finden, wo eine automatische Korrektur möglich ist - da bleiben nur relativ wenige andere Objekte hängen, und die landen (s.o.) größtenteils im housenumbervalidator. Was daneben noch übrig bleibt, ist meistens aus der Ferne ohnehin nicht zu korrigieren.
Aus dem eigentlichen Bot-Programm könnte man vielleicht ein paar Ideen übernehmen, um z.B. Korrekturvorschläge zu generieren, die zur automatischen Durchführung zu unsicher sind. Ich habe mal mit dem Gedanken gespielt, das Programm um einen entsprechenden interaktiven Modus zu ergänzen, aber das ist bisher nur eine vage Überlegung.
Eine eigene Karte werde ich nicht basteln. Einerseits habe ich davon keine Ahnung (und auch zu wenig Interesse, um mich entsprechend gründlich einzuarbeiten), andererseits ist das Spektrum einschlägiger QS-Karten mit OSM Inspector, housenumbervalidator und OSMAddressCorrector schon überaus reichhaltig und bedarf keiner weiteren Fragmentierung. Eventuell wäre es eine Option, Output von Wall·E (Korrekturvorschläge, Warnmeldungen) in eine der bestehenden Karten zu integrieren.

Basstoelpel wrote:

Aber langfristig kann man natürlich schon davon ausgehen, daß die Straßen korrekt sind weil anhand der Straßenlisten verifiziert.

Wenn Straße und Adresse uneins sind, würde ich auch eher auf die Straße tippen. Straßen sind meist schon länger drin als die entsprechenden Adressen, da war mehr Gelegenheit zum Korrigieren (mit Straßenliste oder nicht); und Fehler im Straßennamen fallen auch eher auf, weil der Name einer Straße schließlich auf jeder Karte gerendert wird. Aber wie Du schon sagst, das ist keine Bot-Aufgabe, und selbst eine manuelle Korrektur sollte in der Regel nicht aus der Ferne erfolgen. Gelegentlich ist die Abweichung auch mehr als ein bloßer Tippfehler, etwa hier (ehrlich gesagt tippe ich in dem Fall ebenso wie in der gesamten Umgebung darauf, daß jeweils der highway Recht hat).

Die street/housenumber-Zerlegung ist jetzt aktiv: sie hat gleich zweimal korrekt angeschlagen (s.u.), und sie hat (viel wichtiger) noch keinen Unfug mit korrekten Daten getrieben.

editing␣node␣#2161518729,␣http://www.openstreetmap.org/browse/node/2161518729
addr:street␣tag␣modified:␣"Oppelner␣Str.␣3"␣->␣"Oppelner␣Straße␣3"
addr:street␣modified:␣"Oppelner␣Straße␣3"␣->␣"Oppelner␣Straße"
editing␣way␣#126776483,␣http://www.openstreetmap.org/browse/way/126776483
addr:housenumber␣modified:␣"Großwalding␣3"␣->␣"3"
addr:street="Großwalding"␣added

Mag sich mal jemand dieses Knotens erbarmen?

node␣#1154688902's␣addr:city␣tag␣looks␣funny:␣"Schachtenbach␣921␣Meter"
but␣I␣can't␣do␣anything␣about␣it

http://www.openstreetmap.org/browse/node/1154688902

Oli-Wan wrote:

Mag sich mal jemand dieses Knotens erbarmen?

node␣#1154688902's␣addr:city␣tag␣looks␣funny:␣"Schachtenbach␣921␣Meter"
but␣I␣can't␣do␣anything␣about␣it

http://www.openstreetmap.org/browse/node/1154688902

Tja, da sieht die ganze Ecke etwas merkwürdig aus.
Davon lasse ich lieber die Finger. Was die wenigen Bearbeiter sich dabei gedacht haben mögen, vermag ich nicht zu erahnen. Ist das ein Bergwerk mit Tiefenangabe, soll da die Höhe (über NN) beim Namen dokumentiert werden? Warum addr:city statt place=* + name=*? usw.

Da fällt mir nur Löschen ein, aber das ist natürlich etwas radikal.

Edbert (EvanE)

Oli-Wan wrote:

Wenn Straße und Adresse uneins sind, würde ich auch eher auf die Straße tippen. Straßen sind meist schon länger drin als die entsprechenden Adressen, da war mehr Gelegenheit zum Korrigieren (mit Straßenliste oder nicht); und Fehler im Straßennamen fallen auch eher auf, weil der Name einer Straße schließlich auf jeder Karte gerendert wird.

Wer noch nie selbst Straßennamen mit einer frisch veröffentlichen Liste korrigiert hat, glaubt nicht, wie groß der Anteil der falsch geschriebenen Straßen ist. Als ob überwiegend Legastheniker die Straßennamen bei OSM eintragen. Wenn die Straße nicht gerade Marienplatz, Reeperbahn, Ku'damm oder Kö heißt, lungern dort, wo es eine solche Listenauswertung noch nicht gibt, die Schreibfehler eine halbe Ewigkeit in den Daten herum. Photomapping sollte vorgeschrieben werden, das reduziert die Möglichkeit des falsch Abschreibens auf einmal.

Genug geätzt, ich mal einen Aufruf draus: Jeder der nicht diktatbefreit ist, schaue mal, ob nach http://regio-osm.de/listofstreets/data.html/http://regio-osm.de/listofstreets/grafikdarstellung/ in seiner Umgebung noch fehlende/falsch geschriebene Straßen vorhanden sind und kontrolliert mal das nächste Dutzend im Laufe dieses Jahres. Dort, wo es diese Auswertung noch nicht gibt oder merkwürdig scheint, etwa weil OSM deutlich mehr Straßen hat als die Liste, frage er doch bitte die zuständige Körperschaft nach einer offiziellen Liste. Bis vor-voriges Jahr haben diejenigen, die das getan haben ihre Bemühungen auch auf http://wiki.openstreetmap.org/wiki/Stra … erzeichnis vermerkt. Alternativ, schaut auf http://tools.geofabrik.de/osmi/?view=addresses, welche Adressen nicht zu den angrenzenden Straßen passen und überprüft, ob die Straßen oder die Adressen korrekt sind.

Wer macht nicht mit?

Baßtölpel

Nahmd,

Oli-Wan wrote:

Mag sich mal jemand dieses Knotens erbarmen?

node␣#1154688902's␣addr:city␣tag␣looks␣funny:␣"Schachtenbach␣921␣Meter"
but␣I␣can't␣do␣anything␣about␣it

http://www.openstreetmap.org/browse/node/1154688902

Ich hab die Höhe mit Infos ausm Netz verifiziert und dann an den bereits vorhandenen “place=hamlet” gehängt, sodann den jetzt überflüssigen Node getilgt. Bei der Gelegenheit noch die Gebäude rechteckifiziert und ein addr:city=Bayrisch Eisenstein angehängt.

Gruß Wolf

Nahmd,

Basstoelpel wrote:

Genug geätzt, ich mal einen Aufruf draus: Jeder der nicht diktatbefreit ist, schaue mal, ob nach http://regio-osm.de/listofstreets/data.html/http://regio-osm.de/listofstreets/grafikdarstellung/ in seiner Umgebung noch fehlende/falsch geschriebene Straßen vorhanden sind und kontrolliert mal das nächste Dutzend im Laufe dieses Jahres.

Das macht so keinen Spaß. Wenn dann will ich eine Seite blitzsauber bekommen. Zum Beispiel diese.

Die roten Einträge sind klar, aber wie bekomme ich die gelben Einträge weg?
Da sind Forst und Spazierwege darunter, die jeder unter dem Namen kennt, die aber keine Wohnstraßen mit adressierbaren Häusern sind. Wie sage ich der Seite: “der Weg+Name ist ok, ist aber keine benamste Straße im eigentlichen Sinne, überspring das Teil bei deinem Vergleich”?

Gruß Wolf

Oli-Wan wrote:

EvanE wrote:

Unabhängig davon meine ich, dass die Suche nach Fehlern, die für Wall-E entwickelt wurde, gegebenenfalls zusätzlich für eine Qualitätskarte genutzt werden kann. Dabei kann eine Ähnlickeitssuche oder andere Erweiterungen ggfs. sinnvoll sein.

Grundsätzlich gerne (wobei ich zum Bauen einer solchen Karte der falsche Ansprechpartner bin); ich fürchte aber, daß Du Dir davon ein bißchen zuviel versprichst. Mein Filterprogramm ist sehr simpel ... Außerdem ist es darauf ausgelegt, gerade jene Objekte zu finden, wo eine automatische Korrektur möglich ist - da bleiben nur relativ wenige andere Objekte hängen, ... Was daneben noch übrig bleibt, ist meistens aus der Ferne ohnehin nicht zu korrigieren.
Aus dem eigentlichen Bot-Programm könnte man vielleicht ein paar Ideen übernehmen, um z.B. Korrekturvorschläge zu generieren, die zur automatischen Durchführung zu unsicher sind. Ich habe mal mit dem Gedanken gespielt, das Programm um einen entsprechenden interaktiven Modus zu ergänzen, aber das ist bisher nur eine vage Überlegung.
Eine eigene Karte werde ich nicht basteln. Einerseits habe ich davon keine Ahnung (...), andererseits ist das Spektrum einschlägiger QS-Karten mit OSM Inspector, housenumbervalidator und OSMAddressCorrector schon überaus reichhaltig und bedarf keiner weiteren Fragmentierung. Eventuell wäre es eine Option, Output von Wall·E (Korrekturvorschläge, Warnmeldungen) in eine der bestehenden Karten zu integrieren.

Eigentlich meinte ich, nicht unbedingt deine Filterregeln, sondern die Erfahrungen, die in den diversen Threads zu Straßen- und Adress-Korrektur erarbeitet wurden. Dabei sind vor allem die Dinge interessant, die wegen Unsicherheit keinen Eingang in die Bot-Regeln finden konnten.

Ein Beispiel wären Straßen mit Nummern im Namen.
Mit der Overpass-API und dem Overpass-Turbo als Entwicklungstool ist das in wenigen Minuten erstellt. Beispiel:
http://overpass-turbo.eu/?q=PCEtLQp0aGl … BMieM6_U_L

Man kann das direkt als interaktive Karte exportieren:
[url]http://overpass-turbo.eu/map.html?Q=%3C!--%20this%20query%20looks%20for%20highways%20with%20a%20number%20in%20its%20name%20--%3E%20%3Cosm-script%3E%20%3Cunion%3E%20%3Cquery%20type%3D%22way%22%3E%20%3Chas-kv%20k%3D%22highway%22%20regv%3D%22motorway|primary|secondary|tertiary|residential|unclassified|service%22%2F%3E%20%3Chas-kv%20k%3D%22name%22%20regv%3D%22[0123456789]%22%2F%3E%20%3Cbbox-query%20s%3D%2250.78987674433805%22%20w%3D%226.716766357421874%22%20n%3D%2251.16901107945215%22%20e%3D%227.305908203125%22%2F%3E%20%3C%2Fquery%3E%20%3Crecurse%20type%3D%22way-node%22%2F%3E%20%3C%2Funion%3E%20%3Cprint%20%2F%3E%20%3C%2Fosm-script%3E[/url]

Du siehst, das ist gar nicht so schwierig.
Nichtsdestotrotz will ich eigentlich irgend jemanden animieren, so ein Tool aufzubauen. Du bist dabei nicht meine primäre Zielperson.

Mir geht es im Grunde ähnlich wie dir. Einfache Abfragen mittels Overpass-API/-Turbo kann ich erstellen und daraus das erzeugen, was der Overpass-Turbo unterstützt. Aber verschiedene Abfragen zu einer Karte mit Layer-Switcher und dem ganzen Drumherum zu bauen, das übersteigt dann doch meine Möglichkeiten.

Edbert (EvanE)

Netzwolf wrote:

Nahmd,

Basstoelpel wrote:

http://regio-osm.de/listofstreets/data.html

Das macht so keinen Spaß. Wenn dann will ich eine Seite blitzsauber bekommen. Zum Beispiel diese.

Die roten Einträge sind klar, aber wie bekomme ich die gelben Einträge weg?
Da sind Forst und Spazierwege darunter, die jeder unter dem Namen kennt, die aber keine Wohnstraßen mit adressierbaren Häusern sind. Wie sage ich der Seite: “der Weg+Name ist ok, ist aber keine benamste Straße im eigentlichen Sinne, überspring das Teil bei deinem Vergleich”?

Hallo Wolf,

in dem speziellen Fall scheinen auch viele Wohnstraße zwar in OSM aber nicht in der Liste vorhanden zu sein. Möglicherweise fehlen in der Liste die Straßen der Vororte. Wenn Du diese gelben weghaben willst, solltest Du die Stadt nach einer vollständigen Straßenliste fragen. Oder die Liste von Hand vervollständigen. Die Listen sind in einem Wiki gespeichert.
Für den Fall benamstes Objekt aber dennoch keine Straße frag doch Dietmar mal freundlich an, ob er dafür etwas nachrüstet.

Grüße,

Baßtölpel

EvanE wrote:

Ein Beispiel wären Straßen mit Nummern im Namen.
Mit der Overpass-API und dem Overpass-Turbo als Entwicklungstool ist das in wenigen Minuten erstellt.
...
Du siehst, das ist gar nicht so schwierig.

In der Tat sehr beeindruckend. Es wird wohl doch mal Zeit, mich gründlicher mit der Overpass API zu befassen (bisher weiß ich im wesentlichen nur das, was für die zur Trennung von Straße und Hausnummer konstruierte Funktion osm-verify-nearby-road nötig war).
Aber Kartenbauen ist einfach nicht meine Welt. Du liegst also schon richtig damit, hierfür nach einer anderen Zielperson Ausschau zu halten.

PS. [0123456789] -> [0-9] oder [[:digit:]] 😉

Oli-Wan wrote:

PS. [0123456789] -> oder [[:digit:]] 😉

[0-9] ist klar.

[[:digit:]] kannte ich nicht, Danke dafür.
Ich hatte es mit \d probiert, so wie es mein Editor (TextWrangler auf einem Mac) versteht. Als das nicht funktionierte, habe ich die Primitiv-Version genommen, mit der es dann auch ging.

Edbert (EvanE)

Ich habe das Objekte-pro-Änderungssatz-Limit jetzt von 20 auf 60 Objekte erhöht. Fundamentale Fehler scheinen nicht zu passieren, und nachdem die kürzlich ins Logging eingebauten Bugs behoben sind, ist anhand des Protokolls nun wieder eine ausreichende Kontrolle möglich. Wenn der Toolserver-Account eingerichtet ist, werden die Adresskorrekturen dorthin umziehen und dann bald komplett automatisiert laufen (sofern nicht plötzlich doch noch große Probleme auftreten).

Daß der heutige Änderungssatz 64 (> 60) Objekte enthielt, lag an einem gestern eingebauten Bug, in dessen Folge der Änderungszähler nicht inkrementiert wurde und bearbeitete Objekte auch nicht in die Sperrliste geschrieben wurden. Dieses Problem ist behoben.
Von den 64 Objekten mußten im übrigen 56 nachbearbeitet werden - trauriger Rekord. Ich frage mich, wie Leute es fertigbringen, addr:street=Karl-Liebknechtstrasse einzutragen, wenn JOSM doch automatisch den vorhandenen Straßennamen Karl-Liebknecht-Straße vorschlägt. Bei Nutzern weniger ausgefeilter Editoren wie Potlatch/wheelmap/Pushpin/Vespucci/iLOE würde ich es ja verstehen.

Oli-Wan wrote:

Bisher entdeckt mein Filterprogramm nicht alle Fehler des hier diskutierten Typs. Vorerst werde ich es nicht ändern, d.h. die genannten Korrekturen würden erst einmal hauptsächlich an Objekten durchgeführt, die aus anderen Gründen im Filter hängen bleiben (...). Mittelfristig würde ich aber auch das Filterprogramm anpassen, um möglichst viele "Straße Nummer"-Fehler zu erwischen.

Das ist nun geschehen, das Filterprogramm schaut sich nun auch addr:street näher an und sucht dort nach Zahlen. Erfolg der Aktion: jede Menge Altlasten, die nun allmählich abgetragen werden - wunderbares Testmaterial für die Straße/Hausnummer-Trennung. Und so viele Straßen des 18. Oktober, 13. Juni, 8. Mai usw., daß gleich die nächste Änderung im Filter nötig war.

Oli-Wan wrote:

Eine Hausnummer ... besteht also aus mindestens einer arabischen Ziffer sowie maximal einem Buchstaben, der durch ein oder mehrere Leerzeichen von der Zahl getrennt sein kann. (Mehrere Hausnummern, etwa 12-14, werden so nicht erfaßt. Den Regex werde ich evtl. noch entsprechend anpassen.)

Änderung des Regex ist erfolgt, als Hausnummer gilt nun:

"[[:blank:]]+\\([[:digit:]]+\\([[:blank:]]?[[:alpha:]]\\)?\\|[[:digit:]]+[-/][[:digit:]]+\\)[[:blank:]]*$"

Die relativ häufige Form 12-14 oder 12/14 wird nun also auch erfaßt, 12a-12f sowie Kombinationen mit Komma oder "+" hingegen nicht. Ggf. erweitere ich den Regex erneut, wenn der aktuelle Berg abgetragen ist und ich einen Überblick habe, was dann noch übrig bleibt.

Edit: "/"-Variante.

Ich bin gerade zufällig über eine Bearbeitung durch xybot gestolpert: Der hat offenbar auch Straßen und Hausnummern getrennt, freilich ohne Abgleich mit vorhandenen Straßennamen (und ohne Dokumentation). Herausgekommen ist dann leider auch sowas: http://www.openstreetmap.org/browse/nod … 91/history - genau der Typ von Fehler, den ich mit der Overpass API-Abfrage verhindern will.
Ich habe keine Ahnung, wie häufig derartige Bearbeitungen vorgekommen sind und wie hoch die Fehlerquote war. Hat vielleicht jemand Interesse, hier mal weiter nachzuforschen? Vermutlich genügt es, sich die Änderungssätze "Korrektur der Schreibweise der Straßennamen in Deutschland und Österreich; Str(\.?|asse) => Straße" im Jahr 2012 (per Skript) anzusehen. Eine schöne Detektivaufgabe :-\

Edit: mmd hat ein älteres Beispiel gefunden.

Das ist sicherlich kein Einzelfall: http://www.openstreetmap.org/browse/nod … 46/history

Gefunden mit:

node( {{bbox}} )["addr:housenumber"~"."]
["addr:street"~"."]
["addr:street"!~"\[ ßa-z\]$"]
;out meta;

Annahme: Straßen enden mit einem Kleinbuchstaben (+ß). Leerzeichen sind noch im Regex enthalten, da noch nicht flächendeckend entfernt. Klappt nicht so toll in Mannheim, das war aber klar.

http://www.openstreetmap.org/browse/nod … 41/history <- zwar nicht von xybot aber trotzdem gleiches Muster (kaputter Import)

Hallo,

wie schaut es denn mit den beiden Straßen aus:

http://www.openstreetmap.org/browse/way … 18/history
http://www.openstreetmap.org/browse/way … 06/history

Beide habe ich eingetragen und die heißen so. Machen die auch Probleme?

Bsp. mit einer Adresse:
http://www.openstreetmap.org/browse/way/38327145

vg

Andreas

derandi wrote:

wie schaut es denn mit den beiden Straßen aus:
An der B 320
An der B 115
Beide habe ich eingetragen und die heißen so. Machen die auch Probleme?

Nein, keine Probleme. Vom bisherigen Filterskript wurden sie gar nicht erfaßt; das neue, schnellere und flexiblere Filterprogramm, auf das ich gerade umstelle, ist zwar sensitiv auf Ziffern in addr:street, kennt aber die gängigsten Ausnahmen, u.a.:

␣static␣const␣regex␣street_numeric_exception1
("^(Straße|Platz)␣des␣[[:digit:]]{1,2}\\.␣(Januar|Februar|März|April|Mai|Juni|Juli|August|September|Oktober|November|Dezember)$");
static␣const␣regex␣street_numeric_exception2
("^(An␣der␣)?([BLK]␣?|((Bundes|Landes|Kreis)straße)␣)[[:digit:]]+$");

(wobei allerdings noch ein bißchen Finetuning notwendig ist). Adressen mit addr:street wie oben landen dann gar nicht erst in der Kandidatenliste. Und falls (wegen eines anderen Fehlers) doch, versucht der Korrekturalgorithmus sie z.B. in "An der B" und "320" zu zerlegen und fragt dann die Overpass API, ob es eine Straße "An der B" in der Nähe gibt. Da dies (hoffentlich) nicht der Fall ist, wird die Änderung unterlassen.

Ich denke darüber nach, das Übereinstimmungskriterium für den Straßennamen geringfügig aufzuweichen.
Als Erinnerung für alle, die allmählich den Überblick verlieren: Wall·E versucht, z.B. addr:street="Bahnhofstraße 20a" in addr:street=Bahnhofstraße und addr:housenumber=20a aufzuteilen. Wegen der Vielfalt von Sonderfällen wie "Weg Nr. 12" (Hamburg), "An 44" (Landau) oder "Gewerbegebiet an der B 95" ist als Sicherung eine Prüfung eingebaut, ob es in der Nähe des Objekts eine Straße gibt, die den vermeintlichen Namen trägt. "Bahnhofstraße" wird in aller Regel gefunden, die Zerlegung wird somit durchgeführt; "Weg Nr." wird dagegen nicht gefunden und eine Bearbeitung unterbleibt.
Ich erwäge nun, bestimmte Abkürzungen als synonym anzusehen, etwa "St." für "Sankt". D.h. "St. Nimmerlein-Straße 12" würde auch bei Vorhandensein einer "Sankt Nimmerlein-Straße" in der Nähe bearbeitet, ebenso "Sankt Nimmerlein-Straße 12" bei Vorhandensein einer "St. Nimmerlein-Straße". Ein Risiko von Fehlkorrekturen scheint mir dabei nicht gegeben zu sein. Allerdings würde ich die bisherige Schreibweise in addr:street beibehalten (also nicht "St." zu "Sankt" vereinheitlichen) - welche Schreibweise "richtig" ist, mag ein Mapper vor Ort entscheiden, so es einen gibt. Mir geht es nur darum, die falsch verortete Hausnummer auch in so einem Fall korrigieren zu können.

Anlaß der Überlegungen war dieser Knoten, wo die obige Ergänzung freilich nichts genützt hätte, weil noch zwei weitere Fehler im Straßennamen die Korrektur verhindert hätten. Insgesamt lagen hier in einem einzigen addr:street-Tag satte fünf Fehler bzw. Abweichungen zum in OSM verwendeten Straßennamen vor. (Die übrigen Tags sind überraschend gut weggekommen, bloß das amenity-Tag ist falsch.)

-snip- verguckt 🙁

- snip -
Walters Frage schneller beantwortet, als er sie wieder löschen konnte 🙂

Hallo zusammen,

mir ist gerade noch ein "Fall" eingefallen, welcher evtl. auch hier mit korrigiert werden könnte (er wäre aber auch für einen neuen Faden geeignet) und zwar:
Wenn ein Mapper beim eintragen der Hausnummer versehentlich die Shift-Taste (bzw. die Feststelltaste) gedrückt hat und sowas bei "rauskommt":
anstatt 2 -> "
anstatt 5 -> %
anstatt 18 -> !(
Mir wäre jetzt kein Fall bekannt, wo soetwas wirklich in einer Adresse stehen würde (lasse mich aber gerne aufklären), zur zusätzlichen Absicherung könnte man per overpass prüfen ob in der Nähe jeweils eine höhere bzw. niedrigere Hausnummer vorhanden ist.

Vllt. ist es ja mal eine Überlegung es mit einzubauen.

Ansonsten weiter so, wirklich eine spitzen Arbeit, die du hier leistest!

jman1983 wrote:

anstatt 2 -> "
anstatt 5 -> %
anstatt 18 -> !(
Mir wäre jetzt kein Fall bekannt, wo soetwas wirklich in einer Adresse stehen würde (lasse mich aber gerne aufklären)

So etwas ist mir in Hausnummer und Postleitzahl schon begegnet, sah dann aus wie ein Comic-Fluch ("%$&§!").
Kann ich mal ins Filterprogramm aufnehmen - dann sehe ich, ob es sich lohnt, über eine automatische Korrektur nachzudenken. Mein Bauchgefühl sagt aber, daß es eher wenige Fälle sein werden und daher eine manuelle Korrektur sinnvoller ist. (In addr:postcode war obiges das einzige mir bekannte Vorkommen; hier ist das Filterprogramm bereits sensitiv auf "alles außer Zahlen".)

Mit einiger Verspätung nun noch einmal zu den "geshifteten" Hausnummern (also ! statt 1 etc.).
Ich habe nun den Bestand nach entsprechenden Hausnummern durchsucht. Es gibt durchaus reichlich Hausnummern wie "!" oder "&"; aber eine automatische Korrektur ist - zumindest mit vertretbarem Aufwand - nicht sinnvoll möglich. Bei "!" mag es noch gehen, aber schon bei "&" gibt es Probleme: Je nach Tastaturlayout liegt "&" entweder auf der 6- oder der 7-Taste. Da hilft nur: nachsehen, auf welcher Straßenseite und zwischen welchen anderen Nummern die fragliche Hausnummer liegt. Auch "1#" kann auf "13" (QWERTY-Layout) zurückgehen oder (m.E. häufiger) auf einen Wurstfinger auf der Returntaste (QWERTZ, insbesondere Notebooktastaturen).

Daneben gibt es noch Fälle, wo die Hausnummer zwischen Anführungszeichen steht (die meisten davon in Hannover und von ein und demselben Mapper), oder ganz eigenartige Dinge wie f/*r, aber auch legitime Exoten.

Ich werde mich demnächst mal daran machen, einige der manuell korrigierbaren Sonderzeichen zurechtzurücken. Sobald ich dem Filterprogramm ausgetrieben habe, reichlich falsch positive Resultate mit u.a. ½ zu liefern, kann ich das Suchergebnis auch bereitstellen, falls jemand mithelfen will. Edit: Lohnt nicht, zu wenige.

Auf @talk-de wird im übrigen gerade darüber diskutiert, ob man Hausnummern, die in addr:housename gelandet sind per Bot in addr:housenumber ändert. Nur falls du dich da einbringen möchtest.

aighes wrote:

Auf @talk-de wird im übrigen gerade darüber diskutiert, ob man Hausnummern, die in addr:housename gelandet sind per Bot in addr:housenumber ändert. Nur falls du dich da einbringen möchtest.

Danke, habe ich gesehen - und verfolge die Diskussion mit Interesse. Ich halte mich da aber raus, um nicht den Faden zu kapern oder einseitig zu beeinflussen. In der Diskussion ist auch schon weit mehr OSM-Sachverstand vertreten, als ich noch einbringen könnte.

Das lustige ist, daß ich selbst just gestern wieder mal über eine entsprechende Ergänzung meines Programms nachgedacht habe; lediglich die Faulheit hat ein entsprechendes Posting hier verhindert. Ich hatte zwar auch schon länger gesehen, daß etwa im housenumbervalidator regelmäßig addr:housename=<Zahl> angezeigt und in der Folge von einem Mapper in addr:housenumber geändert werden, sodaß man grundsätzlich erwägen könnte das zu automatisieren; aber der große Cluster von derartigen "Hausnamen" in Berlin-Siemensstadt - die vermutlich genau den von Peter Wendorff geschilderten Fall darstellen - hat mich davor zurückschrecken lassen. (Deren Ersteller habe ich ohne Erfolg Ende März angeschrieben.) Daneben gibt es wohl noch jede Menge Altlasten, die nicht im housenumbervalidator angezeigt werden; jedenfalls war eine entsprechende Suche gestern recht ergiebig.
Eine Möglichkeit zur Abgrenzung verrutschter Hausnummern von Gebäude-Referenznummern etc. wäre, zusätzlich das Vorhandensein von addr:street zu fordern (und sowieso die Abwesenheit von addr:housenumber oder deren Übereinstimmung mit addr:housename).

A proposito Berlino, falls jemand von dort mitlesen sollte: Es gibt am ZOB nahe Westkreuz einige sehr eigenartige "Hausnummern", die vermutlich Bushaltestellen sind: http://www.openstreetmap.org/browse/node/2227177305

Oli-Wan wrote:

A proposito Berlino, falls jemand von dort mitlesen sollte: Es gibt am ZOB nahe Westkreuz einige sehr eigenartige "Hausnummern", die vermutlich Bushaltestellen sind: http://www.openstreetmap.org/browse/node/2227177305

Korrekt, das sind die einzelnen Haltestellen, vergleichbar mit den verschiedenen Gleisnummern am Bahnhof. Bin letzte Woche von dort mit dem Bus abgefahren. Hier ein Bild (nicht von mir) wie es in der Realität aussieht: http://www.bus-bild.de/1024/2-mercedes- … -56233.jpg (in diesem Fall Haltestelle bzw. Gate 27)

Oli-Wan wrote:

Mit einiger Verspätung nun noch einmal zu den "geshifteten" Hausnummern (also ! statt 1 etc.).
...

Ich war in der Zwischenzeit auch nicht ganz untätig und habe mich an einen "privaten" Bot gemacht. Allerdings ist er noch nicht ganz ausgereift, obwohl er z.B. schon eine "geografische Abhänigkeit" besitzt. Soll soviel heißen wie: Eine Hausnummer !! (11) kann nicht bei 72,74,76,76a,76b etc. sein...

Ob ich ihn jemals soweit voranbringe, dass er in die "freie Wildbahn" darf, weiß ich noch nicht. Du hast ja die Messlatte für "Bot's" ziemlih hoch gelegt. (Was ich absolut begrüße!!!)
Solltest du dich dazu entschließen, diese Art der Korrektur auch durchführen zu wollen, werde ich umgehend mein kleines, bescheidenes Skript ins Archiv befördern.

MfG

Jan

jman1983 wrote:

Ich war in der Zwischenzeit auch nicht ganz untätig und habe mich an einen "privaten" Bot gemacht. Allerdings ist er noch nicht ganz ausgereift, obwohl er z.B. schon eine "geografische Abhänigkeit" besitzt. Soll soviel heißen wie: Eine Hausnummer !! (11) kann nicht bei 72,74,76,76a,76b etc. sein...

Wie oben geschrieben, glaube ich nicht, daß sich dieser Fehlertyp mit der notwendigen Sicherheit automatisch beheben läßt. Schon alleine die verschiedenen Tastaturlayouts erschweren die Sache erheblich; dazu kommt, daß etwa "/" durchaus korrekt und "&" zumindest mit Absicht verwendet werden kann. Selbst für eine Heuristik, die nur einen Teil der Fälle sicher korrigieren kann, scheint mir der Programmieraufwand in keinem angemessenen Verhältnis zu den vorhandenen Fehlern zu stehen. Aber ich bin gespannt, was Du Dir da ausgedacht hast - vielleicht liege ich mit meiner Einschätzung ja auch falsch. Allerdings habe ich heute (zumindest in DE) das Testmaterial drastisch dezimiert. 🙂

PS. Selbst wenn aus Deinem Korrekturskript nichts werden sollte - Du hast Dir ja sicher einige Gedanken zur Filterung problematischer Hausnummern gemacht, die könnten evtl. im housenumbervalidator Verwendung finden. Ich habe auf die Schnelle nur nach einer kleinen Auswahl verdächtiger Zeichen gesucht:

static␣const␣regex␣housenumber_strangechars␣("[\"#!*$%&=^]")

Bei addr:housename=<ZAHL> kann folgender Fall problematisch sein:
Auf dem Gelände des Uni-Klinikums Bonn (UKB, Bonn-Venusberg) haben die Gebäude eine Nummer unabhängig von deren postalischen Adresse (meist Sigmund-Freud-Straße xx). Diese interne Nummer steht groß vor den Gebäuden und wird im lokalen Lageplan verwendet.
Um diese Information zu erfassen, wurden die Eingangsknoten mit addr:housename versehen (nicht von mir). Eine Verwendung von ref=<ZAHL> statt addr:housename scheint mir kein Ausweg zu sein.

Wie auch immer, in so einer Situation, die man auf vielen größeren Geländen finden kann, ist es nicht möglich housename einfach auf housenumber zu ändern.

Edbert (EvanE)

EvanE wrote:

Auf dem Gelände des Uni-Klinikums Bonn (UKB, Bonn-Venusberg) ... wurden die Eingangsknoten mit addr:housename versehen

Sehr interessant, habe mir das gerade mal angeschaut. Würde man, wie oben von mir vorgeschlagen, zusätzlich das Vorhandensein eines addr:street-Tags fordern, blieben die "Hausnamen" des UKB außen vor. (Jene in Berlin-Siemensstadt ebenfalls.)

Die beiden Hausnummern an der Hautklinik (12 und 325, jeweils Sigmund-Freud-Straße) sind aber nicht so gewollt, oder?

Oli-Wan wrote:

EvanE wrote:

Auf dem Gelände des Uni-Klinikums Bonn (UKB, Bonn-Venusberg) ... wurden die Eingangsknoten mit addr:housename versehen

Sehr interessant, habe mir das gerade mal angeschaut. Würde man, wie oben von mir vorgeschlagen, zusätzlich das Vorhandensein eines addr:street-Tags fordern, blieben die "Hausnamen" des UKB außen vor. (Jene in Berlin-Siemensstadt ebenfalls.)

Bei folgendem Beispiel (TU Hamburg-Harburg) hat man zur Numerierung zwar Buchstaben verwendet, aber es zeigt, dass die Hausnumerierung auch mit addr:street und addr:housenumber zusammenkommen kann. Dass mal eine Hausnummer mal nicht vergeben oder nicht erfasst ist, weil der Mapper sie nicht kannte oder die Beschilderung fehlt, ist auch nicht unwahrscheinlich.

http://www.openstreetmap.org/?lat=53.46 … 7&layers=M

EvanE wrote:

Bei addr:housename=<ZAHL> kann folgender Fall problematisch sein:
Auf dem Gelände des Uni-Klinikums Bonn (UKB, Bonn-Venusberg) haben die Gebäude eine Nummer unabhängig von deren postalischen Adresse (meist Sigmund-Freud-Straße xx). Diese interne Nummer steht groß vor den Gebäuden und wird im lokalen Lageplan verwendet.
Um diese Information zu erfassen, wurden die Eingangsknoten mit addr:housename versehen (nicht von mir).

Wobei mir housename auch nicht richtig zu sein scheint. Zumindest ist es bei Universitäten ja oft der Fall, dass es einerseits natürlich eine Gebäudenummer gibt, andererseits aber zumindest ein Teil der Gebäude zusätzlich einen Namen hat, beispielsweise zur Ehrung ehemaliger Universitätsmitglieder oder auch eher funktional. Das wäre in housename dann eher korrekt, also müsste man für die Gebäudenummer einen anderen Weg finden - wobei ref= schon am ehensten dem Üblichen entspräche.

slhh wrote:

Bei folgendem Beispiel (TU Hamburg-Harburg) hat man zur Numerierung zwar Buchstaben verwendet, aber es zeigt, dass die Hausnumerierung auch mit addr:street und addr:housenumber zusammenkommen kann. Dass mal eine Hausnummer mal nicht vergeben oder nicht erfasst ist, weil der Mapper sie nicht kannte oder die Beschilderung fehlt, ist auch nicht unwahrscheinlich.

http://www.openstreetmap.org/?lat=53.46 … 7&layers=M

Ich verstehe den Einwand nicht ganz: hier sind addr:street und addr:housenumber vorhanden, dazu noch name="Gebäude X". Selbst wenn letzterer "Gebäude 24" lauten sollte und/oder als addr:housename eingetragen wäre so wie hier (wo übrigens auch eine von der Hochschule vergebene Gebäudenummer als ref:RWTH hinterlegt ist), gäbe es hier kein (vermeintliches) Falschtagging einer Hausnummer in addr:housename. Ein solches könnte nur dann fälschlich erkannt werden, wenn statt "Gebäude 24" nur "24" eingetragen wäre.

Oli-Wan wrote:

Ein solches könnte nur dann fälschlich erkannt werden, wenn statt "Gebäude 24" nur "24" eingetragen wäre.

Das dürfte dann sehr vom Mapper abhängen, was in OSM eingetragen wird. Ebenso dürfte es sehr vom mapper abhängen, welcher Schlüssel für diese angaben verwendet wird. Im Falle der TU Hamburg-Harburg gibt es sicher kein Problem, aber das Beispiel sollte zeigen, dass Ausgangslagen durchaus realischtisch sind, bei denen die automatische Korrektur problematisch wäre, wenn der Mapper die Daten in bestimmter Weise erfasst hat.

Oli-Wan wrote:

EvanE wrote:

Auf dem Gelände des Uni-Klinikums Bonn (UKB, Bonn-Venusberg) ... wurden die Eingangsknoten mit addr:housename versehen

Sehr interessant, habe mir das gerade mal angeschaut. Würde man, wie oben von mir vorgeschlagen, zusätzlich das Vorhandensein eines addr:street-Tags fordern, blieben die "Hausnamen" des UKB außen vor. (...)

Die beiden Hausnummern an der Hautklinik (12 und 325, jeweils Sigmund-Freud-Straße) sind aber nicht so gewollt, oder?

Jep, 325 sollte ein Hausname sein. Ich muss irgendwann mal im UKB noch einige Ergänzungen machen und werde das dann anpassen.

Leider ist das im UKB so, dass dort nur Nummern an/vor den Häusern sind. "Gebäude 325" oder "UKB 325" wäre als Hausname sicher sinnvoller, entspricht aber leider nicht den Tatsachen.

Edbert (EvanE)

errt wrote:

EvanE wrote:

Bei addr:housename=<ZAHL> kann folgender Fall problematisch sein:
Auf dem Gelände des Uni-Klinikums Bonn (UKB, Bonn-Venusberg) haben die Gebäude eine Nummer unabhängig von deren postalischen Adresse (meist Sigmund-Freud-Straße xx). Diese interne Nummer steht groß vor den Gebäuden und wird im lokalen Lageplan verwendet.
Um diese Information zu erfassen, wurden die Eingangsknoten mit addr:housename versehen (nicht von mir).

Wobei mir housename auch nicht richtig zu sein scheint. Zumindest ist es bei Universitäten ja oft der Fall, dass es einerseits natürlich eine Gebäudenummer gibt, andererseits aber zumindest ein Teil der Gebäude zusätzlich einen Namen hat, beispielsweise zur Ehrung ehemaliger Universitätsmitglieder oder auch eher funktional. Das wäre in housename dann eher korrekt, also müsste man für die Gebäudenummer einen anderen Weg finden - wobei ref= schon am ehensten dem Üblichen entspräche.

Das ist ja der Grund auf Hausname und Eingang auszuweichen.
Die Gebäude heißen Abc-Klinik oder so ähnlich. Dadurch ist Name also bereits belegt.

Unabhängig davon haben haben sie eine groß angeschriebene Gebäudenummer innerhalb des Klinik-Geländes. Und diese ist wiederum unabhängig von ihrer Anschrift / Postadresse. Womit die Hausnummer ebenfalls nicht sinnvoll ist.

Edbert (EvanE)

Um noch einmal hierauf zurückzukommen:

aighes wrote:

Auf @talk-de wird im übrigen gerade darüber diskutiert, ob man Hausnummern, die in addr:housename gelandet sind per Bot in addr:housenumber ändert.

Da Bürste sein Vorhaben augenscheinlich nicht weiter verfolgen wird, möchte ich noch einmal die Frage aufwerfen, ob diese Korrektur in mein Programm mit aufgenommen werden kann/sollte. Ausgangspunkt ist, daß regelmäßig Hausnummern (rein numerisch, ggf. noch mit Buchstabenzusatz) in addr:housename statt in addr:housenumber landen. Das wird zum einen durch die automatische Ergänzung von Tagschlüsseln in JOSM begünstigt, zum anderen durch "housename"-Felder in Editoren wie P2, iD, wo der User bisweilen einfach das falsche erwischt. (Genauso wie Postleitzahlen in addr:housenumber landen, oder Städtenamen in addr:country, oder verschiedene Adressbestandteile vertauscht werden). Das tägliche Aufkommen kann im housenumbervalidator besichtigt werden (aktuell ist allerdings nicht viel zu sehen).

Der einfachste Ansatz wäre, addr:housename auf Hausnummer-artige Werte zu prüfen (123, 123a, 123-127) und ohne weitere Umstände in addr:housenumber zu verschieben (es sei denn, dieses Tag ist bereits mit einem abweichenden Wert belegt).

Problem ist nun (vgl. Hinweise zum UK Bonn weiter oben), daß gelegentlich sonstige Gebäudenummern in addr:housename landen, welche keine Hausnummern im eigentlichen Sinne sind (von der Gemeinde vergeben, postalischen Zwecken dienend), sondern z.B. internen Verwaltungszwecken dienen oder die Orientierung auf einem weitläufigen Gelände ermöglichen, welches z.B. nur eine Hausnummer hat oder wo die Hausnummern der einzelnen Gebäude irregulär verstreut sind. Nach meinem Verständnis wären diese sonstigen Nummern zwar in der Regel in ref, ref:* oder gar (mit Präfix) name besser aufgehoben als in addr:housename, eine Verschiebung in addr:housenumber ist in diesen Fällen auch nicht sinnvoll.

Kann man diesen Einwänden Rechnung tragen und die housename-housenumber-Verschiebung so gestalten, daß diese Sonderfälle ausgesperrt werden? Ich denke: ja, wenn man folgende Bedingungen stellt.

• addr:housename hat einen Hausnummer-artigen Wert /[[:digit:]]+( ?[[:alpha:]])?/ (evtl. noch ergänzt um Mehrfachnummern).
• In addr:housenumber steht entweder der gleiche Wert wie in addr:housename oder keiner. Im Falle identischer Werte können die weiteren Bedingungen entfallen.
• Tag addr:street vorhanden.
• darüber hinaus außer weiteren addr:*-Tags nur Schlüssel aus einer begrenzten Positivliste, etwa building=* und entrance=* sowie Metatags wie source und created_by.
• Diese Bedingung wird auch an Elternobjekte gestellt.
• ...?

1 und 2 sollten klar sein. 3 bis 5 sollen die Fälle ausschließen, wo "irgendeine" Nummer in addr:housename gelandet ist, aber nicht die Hausnummer.
Eine Adressangabe mit addr:street verlangt in der Regel auch nach einer addr:housenumber. Ist keine Straße angegeben, kann der Wert in addr:housename durchaus eine sonstige Referenznummer sein (es sei denn, die Straße wurde bloß nicht eingetragen - in diesem Fall unterbleibt halt eine mögliche und sinnvolle Korrektur).
Solche sonstigen Referenznummern finden sich gehäuft an Gebäuden mit weitergehender Funktion (amenity, shop usw.); daher die Beschränkung auf Gebäude und Eingänge. Dabei sind noch Tags am Elternweg eines Knotens sowie z.B. am Multipolygon, dem ein Weg angehört, zu berücksichtigen.

Jetzt wollte ich gerade die Gebäude der Bonner Uniklinik gegen obigen Regelsatz abgleichen - aber da scheint es keine addr:housename mehr zu geben...
Anderes Beispiel: Weg 184762125 und die anderen Gebäude auf dem Siemens-Gelände in Berlin bleiben unangetastet - addr:street fehlt. Gleiches gilt für die Gebäude im Industriepark Wolfgang (Hanau) wie Weg 212472773. Weitere semi-legitime Exoten finde ich gerade nicht.

Ein Beispiel wo solche Gebäudenummern (waren allerdings als name=* getaggt) vermutlich falsch in Hausnummern umgetagt wurden, ist das DESY-Gelände: http://www.openstreetmap.org/#map=18/53.57634/9.88164
Der Adressnode mit Hausnummer 85 innerhalb von einem mit Hausnummer 20 getaggten Gebäude zeigt zumindest, dass dort etwas falsch ist.

Mit den doppelten Nummern wäre ich etwas vorsichtiger. Per Zufalls kann es auch mal bei einem einzelnen Gebäude eine Übereinstimmung von Gebäude und Hausnummer geben.
Vielleicht hilft hier als zusätzliches Kriterium, ob sich weitere addr:housename im Nummernformat in der Umgebung befinden, da Gebaudenummern immer gehäuft auftreten dürften.

Hi Oli-Wan,
der housenumbervalidator von gulp hat mir z.B. diesen Addressknoten für die Verbesserung vorgeschlagen: http://www.openstreetmap.org/browse/node/2402341861
Wieso fasst Dein Bot den Knoten nicht an und ändert "Str." in "Straße"? Oder ist er nur noch nicht dorthin gekommen?
In nächster Umgebung gibt es zig weitere solche Knoten. Ich habe bisher von einer händischen Korrektur abgesehen, damit Du das ggf. automatisiert behebst.

Danke,
Peter

Ganz einfach: der beanstandete Knoten liegt in Österreich.
Von der AT-Mailingliste habe ich nur die Zustimmung zu Leerraum und wiederholten Knoten eingeholt, vgl. auch Übersicht auf der Wikiseite. Mit österreichischen Adressen bin ich nicht vertraut, deshalb kann ich auch ohne einheimische Hilfe das Programm für Adresskorrekturen nicht für Österreich anpassen.

Ist es möglich, automatisch die bisherigen "Mittelschulen" (in Sachsen?) in "Oberschule" umzubenennen?

geri-oc wrote:

Ist es möglich, automatisch die bisherigen "Mittelschulen" (in Sachsen?) in "Oberschule" umzubenennen?

Möglich wäre das schon, aber wäre das auch sinnvoll?
Immerhin gilt bei OSM der Leitsatz, wir mappen, was vor Ort ermittelt werden kann.

Namen von Schulen ergeben sich aus dem, was vor Ort angeschrieben ist und nicht aus organisatorischen Änderungen durch das Kultusministerium.

Bei automatischen Ändern der Namen, wäre zudem die Mechanical Edit Policy zu beachten/befolgen. Das schließt eine gründliche Diskussion (das Forum reicht nicht) und Dokumentation ein.

Edbert (EvanE)

Ich habe nicht den kompletten Thread Mail für Mail gelesen, also sorry, wenn das schon angesprochen wurde...

Aber wäre es nicht generell möglich bei solchen automatisierten Änderungen, dass der erste Bearbeiter (meistens der Creator) eines durch einen Script geänderten Elementes eine Mitteilung bekommt? Also nicht eine Mitteilung pro Element, sondern genau eine Mittelung mit der Liste aller durch das Script geänderten Elemente. Dann kann derjenige einfach noch mal drauf gucken. Und er bekommt einen Hinweis, dass er es beim nächsten mal gleich richtig macht.

Ich weiss natürlich nicht, ob das technisch geht, also ob man von programmtechnisch Mitteilungen an OSM-Kennungen versenden kann.
Vielleicht kann man auch programmtechnisch denjenigen identifizieren, der den addr-Tag zugefügt hat.

Gruß, dgdg

EvanE wrote:

...
Immerhin gilt bei OSM der Leitsatz, wir mappen, was vor Ort ermittelt werden kann.

Namen von Schulen ergeben sich aus dem, was vor Ort angeschrieben ist und nicht aus organisatorischen Änderungen durch das Kultusministerium.

...
Edbert (EvanE)

Ist sicher richtig. Aber die Schule hat in Großbuchstaben "Mittelschule Schmiedeberg" an der Hauswand stehen, was durch Kostenentstehung geändert werden könnte - aber wegen den Kosten nicht möglich ist.

Offiziell besagt ein Schild am Eingang (auf dem Schulgelände) Oberschule Schmiedeberg mit Anschrift und Kontaktmöglichkeit.

geri-oc wrote:

EvanE wrote:

Immerhin gilt bei OSM der Leitsatz, wir mappen, was vor Ort ermittelt werden kann.
Namen von Schulen ergeben sich aus dem, was vor Ort angeschrieben ist und nicht aus organisatorischen Änderungen durch das Kultusministerium.

Ist sicher richtig. Aber die Schule hat in Großbuchstaben "Mittelschule Schmiedeberg" an der Hauswand stehen, ...
Offiziell besagt ein Schild am Eingang (...) Oberschule Schmiedeberg ...

Wenn du das vor Ort geprüft hast und dort widersprüchliches vorfindest, dann ist es in dein Ermessen als Mapper gestellt, was du dort als richtig ansiehst.
In deinem konkreten Fall würde ich Oberschule ... als name=* setzen und den bisherigen Namen als old_name=* dokumentieren. Auf diese Weise wird der alte Name auch weiterhin bei einer Suche gefunden.

Edbert (EvanE)

EvanE wrote:

geri-oc wrote:

Ist sicher richtig. Aber die Schule hat in Großbuchstaben "Mittelschule Schmiedeberg" an der Hauswand stehen, ...
Offiziell besagt ein Schild am Eingang (...) Oberschule Schmiedeberg ...

Wenn du das vor Ort geprüft hast und dort widersprüchliches vorfindest, dann ist es in dein Ermessen als Mapper gestellt, was du dort als richtig ansiehst.
In deinem konkreten Fall würde ich Oberschule ... als name=* setzen und den bisherigen Namen als old_name=* dokumentieren. Auf diese Weise wird der alte Name auch weiterhin bei einer Suche gefunden.

Nachtrag:
Die Änderung von Mittelschule zu Oberschule ist eine inhaltliche und gehört daher nicht zu den Bot-Aufgaben.
Der Bot Wall÷E kümmert sich aus gutem Grunde nur um Fehler in der Schreibweise und nicht um inhaltliche Fehler.

Das soll sagen, eine Änderung Strasse -> Straße (und ähnliches wie mehrere Leerzeichen) kann in DE von Wall÷E durchgeführt werden. Eine Änderung von ABC-Weg nach XYZ-Allee ist nicht Sache des Bots, sondern soll von Mappern mit Vor-Ort Kenntnissen durchgeführt werden.

Es hat gute Gründe, dass Oli-Wan zuerst eine ausführliche Diskussion geführt hat, mit dem Ziel zu ergründen, was machbar und sinnvoll ist und welche Ausnahmen man berücksichtigen muss (z.B. *trasse darf nicht korrigiert werden).

Edbert (EvanE)

dgdg wrote:

Ich habe nicht den kompletten Thread Mail für Mail gelesen, also sorry, wenn das schon angesprochen wurde...

Wenn ja: macht nichts: selbst ich überblicke nicht mehr völlig, was schon alles angesprochen wurde, zumal ich gleich ein halbes Dutzend verschiedener Fäden zu den verschiedenen automatischen Bearbeitungen angelegt habe 😉

Aber wäre es nicht generell möglich bei solchen automatisierten Änderungen, dass der erste Bearbeiter (meistens der Creator) eines durch einen Script geänderten Elementes eine Mitteilung bekommt?

Möglich wäre das. Wer ein fehlerhaftes Tag eingetragen hat, ist relativ leicht automatisch herauszufinden, ähnliches habe ich in anderem Zusammenhang bereits in Betrieb. Das Versenden von Mails über die API ist nicht vorgesehen (oder zumindest nicht dokumentiert); da müßte ich also über die Website gehen. Allerdings weiß ich nicht einmal, ob der automatische Mailversand durch die Nutzungsbedingungen gedeckt ist. (Vermutlich eher nicht.)

Aber selbst wenn es möglich und erlaubt ist, sehe ich eine Reihe von Gegenargumenten, inklusive Nachteilen für mich selbst:

• An den fehlerhaften Einträgen sind überproportional häufig Einwegmapper beteiligt. Diese anzuschreiben bringt nichts.
• Ebenfalls häufig beteiligt sind Anfänger (die in der Folge noch weitermachen). Grundsätzlich mag es sinnvoll sein, diesen das richtige Tagging zu erklären. Andererseits denke ich, man sollte ihnen ihre Fehler nicht übermäßig unter die Nase reiben und ihnen auch nicht den Eindruck vermitteln, daß sie unter Beobachtung stehen. Da kann eine solche Mail unter Umständen mehr kaputtmachen als helfen.
• Fehler, die automatisch behoben werden können, müssen auch nicht ganz so dringend abgestellt werden. Lieber diese geräuschlos beseitigen und fertig. Die meisten Mapper lernen von selbst und machen nach und nach weniger Fehler.
• Eine automatisch generierte Mail kann unmöglich das komplette Spektrum möglicher Fehler ansprechen, bzw. das Schreiben eines entsprechenden Textgenerators wäre mit immensem Aufwand verbunden.
• Im Einzelfall schreibe ich gelegentlich einen Mapper direkt an, wenn ich feststelle, daß "seine" Objekte gehäuft im Log auftauchen.
• Bisweilen sind auch schlichte Tippfehler wie "Stra0e" betroffen - da braucht man dem Mapper gar nicht zu erklären, daß es "Straße" heißen muß.
• Das Sprachproblem. Die meisten, die in DE mappen, sprechen natürlich Deutsch; bestimmte Fehler in Adresstags werden aber auch von Durchreisenden eingebaut, die kein Deutsch sprechen - oder sogar gerade deswegen. Da hilft eine Mail auf Deutsch auch nicht.
• Bestimmte Fehler, wenn man über die Adresskorrekturen hinausgeht, sind primär dem Editor zu verdanken. In diesem Fällen kann der Mapper ohnehin nicht viel tun.
• Wenn ich solche Mails verschicke, muß ich mit weiteren Rückfragen rechnen, deren Beantwortung eine beträchtliche Mehrarbeit bedeuten kann.
• Es ist jedermann möglich, die Änderungssätze von Wall·E oder das öffentlich verfügbare Log zu verfolgen (wobei ich mich gelegentlich frage, ob das überhaupt noch jemand tut), und ggf. selbst einzelne Mapper zu kontaktieren. An einer besseren /history-Seite wird ja gearbeitet, sodaß das möglicherweise zukünftig auch leichter wird. Außerdem könnte ich den letzten Bearbeiter noch ins Log schreiben.

Vorweg: Die OSM-Mail ist für die direkte Kommunikation der Mapper untereinander gedacht. Automatisches und/oder massenweises versenden von Mails ist nicht erwünscht und kann auch zu Blocks/Sperren des Accounts führen.

Auch ohne diese Regelung halte ich es für nicht zielführend. Dem wissenden Powermapper, der sich mal vertippt hat muss man (wenn überhaupt) anders anschreiben als den Gelegenheitsmapper und den Einsteiger noch ganz anders. Zum anderen merkt man unpersönlichen Mails dieses Unpersönliche an. Auch wenn da "Hallo <Username>" steht. Solche Mails lese ich nur, wenn ich diese angefordert habe.

Hallo,

ich habe da einige spreewälder Eigenheiten 🙂 , denen ich am Wochenende begegnet bin. Vor allem im Ort Lehde gibt es eine Reihe von Grundstücken, die nur auf dem Wasserweg zu erreichen sind. (übrigens wird hier die Post auch per Kahn verteilt) Da bin ich auf einiges gestoßen, wo es keine regulär keine Straßen als solches gibt, sondern Wasserwege die Funktion der Straßen übernehmen.

http://www.openstreetmap.org/browse/way/100733087
http://www.openstreetmap.org/browse/node/1761556052
http://www.openstreetmap.org/browse/node/1761556047

Wäre sowas für den Bot ein Problem, oder wird das ignoriert, da Sonderfall??

Ergänzend ist meinerseits zu sagen, daß ich im Moment nicht weiß, wie die Adresse postalisch richtig wäre. Ergänzend wäre auch zu sagen, daß ein Routing z.B. zum Haus in Lehde, Suezkanel 7 nicht möglich ist, da der Suezkanal ein Wasserweg ist, was hier aber keine Rolle spielt.

Sven

streckenkundler wrote:

ich habe da einige spreewälder Eigenheiten 🙂 ...
http://www.openstreetmap.org/browse/way/100733087
http://www.openstreetmap.org/browse/node/1761556052
http://www.openstreetmap.org/browse/node/1761556047

Nein, damit gibt es keine Probleme. Alles, was nicht auf Straßennamen in der Nähe angewiesen ist, läuft ungehindert durch; eine Trennung von "Suezkanal 5" in (Wasser-)Straße und Hausnummer findet dagegen nicht statt, weil in der Nähe keine passende Straße gefunden wird (gesucht wird nur nach highway=[diverse]).

Übrigens gibt es da eine Abweichung in der Schreibweise zwischen Suezkanal und Suez-Kanal.

Danke für die Info... War mir nur gestern aufgefallen und ich dachte, frage mal nach 🙂

Oli-Wan wrote:

Übrigens gibt es da eine Abweichung in der Schreibweise zwischen Suezkanal und Suez-Kanal.

Danke, das schaue ich mir demnächst an, denn ich will die Gewässertags durchsehen: Schiffbarkeit, Name, Landesgewässer, Motor ect. Da gibt es eine ganze Reihe von Infos aus Gesetzen und Verordnungen.

Sven