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

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.

Ä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/node/270680591/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/node/267877246/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/node/563834641/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/162365718/history
http://www.openstreetmap.org/browse/way/26706606/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

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

  • snip -
    Walters Frage schneller beantwortet, als er sie wieder löschen konnte :slight_smile:

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!

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.

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= 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

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-kleinbusse-am-berliner-zob-56233.jpg (in diesem Fall Haltestelle bzw. Gate 27)

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

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. :slight_smile:

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= 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= 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)

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?

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.46008&lon=9.96903&zoom=17&layers=M

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.