OSMSuspects - Qualitätssicherung Adressen (Deutschland)

Ein Check der addr:*-Tags gegen administrative Grenzen bringt aber nicht immer das korrekte Ergebniss. Die PLZ-Grenzen sind hier auch wichtig…

Um zu testen, ob addr:city und addr:postcode stimmt, muß doch die PLZ-Grenze hergenommen werden und nicht die Administrative… Ansonsten bekommt man eine falsche Zuordnung in speziellen Grenzbereichen, in denen Häuser/ Grundstücke zwar in dem einen administrativen Bereich liegen, postalisch von der Adresszuordnung einem anderen Bereich zugeordnet sind. Beispiele hatten wir damals beu der PLZ-Grenz-Geschichte zur Genüge…

Das war auch der Hintergrund, warum, die Tags addr:city und addr:postcode zum Gegencheck sicher gut sind, sich aber aus den Grenzen (PLZ-Grenzen in OSM) besser ermitteln lassen. Einzig addr:suburb ließe sich innerhalb eines PLZ-Bereiches noch als Kriterium heranziehen…

Sven

Wäre nur ein Klack - und auch noch schneller, da nur knapp 8200 Runden notwendig wären.

Ist halt mal wieder die Frage, was addr:city nun wirklich bedeutet. Post-Adresse oder Navigationsadresse? Ich bin für zweiteres. Eigentlich steht ja die - hoffentlich korrekte - PLZ immer bei den Adressen mit dabei.

Gruss
walter

Ein wenig Statistik:

25.153 eindeutige addr:city in 10.224.918 Datensätzen/Adressen

  • davon 9.132 eindeutige addr:city in Übereinstimmung mit VG250 in 9.349.344 Datensätzen/Adressen
  • davon 16.021 eindeutige addr:city ohne Übereinstimmung mit VG250 in 875.574 Datensätzen/Adressen

Verwendete Daten:
Germany-Extrakt der Geofabrik mit Stand vom 2016-10-03T19:28:03Z
VG250 aktuellster downloadbarer Stand vom April 2016

Wer sich die “fehlerhaften” Einträge mal anschauen möchte:

Zumindest die nächsten 2 Tage liegen 2 Dateien auf meinem Billig-Host:

Ein einfaches cvs (UTF8, mit Trenner “|”, ohne die postcodes, suburbs und osm_ids) http://thannworker.com/data/qs_germany_adressen.csv (knapp über 700 kB)
Ein importierbares SQL komplett mit allem http://thannworker.com/data/qs_germany_adressen.sql.zip runtergeladen werden (als ZIP knapp 25 MB, ausgepackt ca. 106 MB, Datenbank “gis”, PG-Extension pg_trgm wird für den Index benötigt).

Mir geht es zuerst mal darum Schreib- und Tippfehler und falsche Verwendung in addr:city (z.B. Teilorte statt in suburb in city) herauszufinden.

Erstmal Danke für deinen Test.

Ich finde auch, in den Adress-Tags sollte die Navigationsadresse drin stehen. Ich hatte mir die länglichen und letzendlich ergebnislosen Diskussionen hier im Forum “Postadresse” vs. “amtliche” Adresse am Wochenende reingezogen. Egal wie die deutsche Community sich entscheidet: Was meiner Meinung gar nicht geht, das offensichtliche Fehler mangels QS nur durch Zufall behoben werden, weil mal jemand drüberstolpert.

Moin Walter,

da man im Allgemeinen ja nach Postadressen navigiert, ist das ja eindeutig - wenn nicht sogar eineindeutig! :wink:

Grüße, Georg

Wenn die Postadresse als Navigationsadresse gelten sollte ist es aber wichtig diese auf den “Zugang” (Eingang) einzutragen.
Bei Eintragung am Gebäudeumriss komm ich zum Beispiel an die Rückseite Varkausring 91, Pirna:
http://www.openstreetmap.org/directions?engine=mapzen_car&route=50.9582%2C13.9529%3B50.9527%2C13.9593#map=17/50.95226/13.95897

Die Frage ist ja gerade für AKK sehr interessant. Gehört da in addr:city “Wiesbaden” oder “Mainz-Kastel/Mainz-Kostheim/Mainz-Amöneburg” oder gar nur “Mainz”? In den Daten gibt es jede dieser Varianten.

Da ich kein Brief bin, orientiere ich mich nach Stadt → Straße → Hausnummer.

genauso eindeutig.

Gruss
walter

Dies sind alles offizielle Stadtteile/Ortsbezirke von Wiesbaden und deren Namen lauten im Real Live “Wiesbaden, Mainz-Kastell” und analog. Dass die Anwohner das natürlich anders sehen und auch die Umsetzung in OSM nicht sauber ist, ist mir klar.

https://de.wikipedia.org/wiki/Mainz-Kostheim

Gruss
walter

Moin,

worauf ich hinaus wollte ist:

Welche Adresse bekommt der 0815-Nutzer, wenn er nach einer Adresse sucht oder fragt - zu der er dann navigieren soll?

Bei der Suche nach einer Adresse findet man in der Regel nur die Postadresse (XYZ-Straße, A-Stadt), sei es bei Internetrecherche, vom Schriftwechsel oder, oder.
Nur in einzelnen Ausnahmen bekommt man von einem Anwohner die Aussage, er wohne in B-Dorf, seine Postadresse laute aber A-Stadt.
Manche kennen sogar nur Ihre (Post)Adresse - und wissen nicht einmal, dass sie tatsächlich auf dem Gebiet einer anderen Gemeinde residieren.

Zumindest sind das meine Erfahrungen mit diesen Sonderfällen aus dem realen Leben.

Außerdem müsstest Du dann noch das Wiki (Key:addr mit allen Übersetzungen) umschreiben.

Grüße, Georg

Schau mal bei
“addr:city und place=>name gibt es ein “missing streets” für Orte?”
Habe da eine Auswertung gemacht, die man für das Thema auch nutzen könnte.
Ist quasi ein missing places/Relations für addr:city Einträge.

Goetz

Das Thema verfolge ich (auch) - allerdings bin ich zwischenzeitlich desillusioniert, was das Thema betrifft.

Wir bekommen es als deutsche Community nicht hin, uns zu einigen, WAS ins Adress-Schema rein soll. Diskussionen darüber verlaufen regelmäßig im Sande.

Der eine möchte ausschliesslich Strasse und Hausnummer drinhaben (“Redundanz! Kannst die fehlenden Angaben ja über die administrativen Boundaries holen”), der andere alles (“Prima. Oh, was wenn es keine Boundaries dazu gibt?”).

Selbst innerhalb einer Stadt (sic!) bestehen erhebliche unterschiedliche Meinungen, wie die korrekten Schreibweisen sind und was wo wie reingehört - hast du ja selbst bei deinen Auswertungen gemerkt.

Was mich wirklich ärgert, sind solche Fehler, die seit 3 (!) Jahren bestehen und niemand merkt was aufgrund fehlender Qualitätskontrollen.

Was mich ärgert: es sollten erst mal systematisch vorhandene Fehler abgearbeitet werden.

Ein Vergleich:

Berlin: http://tools.geofabrik.de/osmi/?view=addresses&lon=13.71676&lat=52.48252&zoom=10&overlays=no_addr_street,street_not_found,nodes_with_addresses_interpolated,interpolation,interpolation_errors
Lausitz: http://tools.geofabrik.de/osmi/?view=addresses&lon=13.98387&lat=51.86626&zoom=10&overlays=no_addr_street,street_not_found,nodes_with_addresses_interpolated,interpolation,interpolation_errors

Was addr:city anbelangt: gebt mir ein Tool wie OSMI, daß mir die addr:city-Fehler anzeigt und dann korrigiere ich, wo ich Gebietskenntnisse habe. Für meine heimische Lausitz hab ich die Fehlerprüfung einigermaßen im Blick.

Sven

Also ich denke auf Gemeindeebene würde es mit addr:city schon sauber funktionieren das zu prüfen. Aber dann schon bei den Stadtteilen wird es zu Problemen kommen. Einfach weil der Begriff Stadtteil ziemlich vage ist. Das denkt man zwar vielleicht nicht, aber dem ist so. Einfach weil manche das darunter verstehen was offiziell ist, andere gehen dann nach Siedlungsbereichen…und die Städte machen es einem auch nicht leichter.

Bei größeren Städten ist das Problem vielleicht kleiner, aber bei kleineren Gemeinden… Hier gibt es bspw. eine Gemeinde. Laut deren Website gibt es drei Stadtteile. Und da ist die Kernstadt nicht miteinbezogen (was theoretisch aber wohl auch noch ein Stadtteil ist). Allerdings haben sie zwei Siedlungsbereiche dazugerechnet, die eigentlich zur Kernstadt gehören… Da kann man denke ich also viel Chaos stiften wenn man da was verkehrt macht.
Deswegen würde ich mich eher erst mal auf addr:city konzentrieren.

Na ein Glück habe ich zufällig vor ziemlich genau 24h rund zwei Dutzend genau derartiger Fehler ausgehend von OSMI in Berlin beseitigt :wink: Der OSMI-Stand ist derzeit “2016-10-26 20:21”, manches meiner Bearbeitungen ist also noch nicht dargestellt.

Zu den OSMI-Fehlern bei Deinem “Vergleich”: Etliche “No addr:street”-tags in Berlin gehören zu Briefkästen. Die jedoch sind ein ganz eigenes Aufgabenfeld, dessen man sich mal annehmen müsste.

Gibt es eigentlich eine Möglichkeit, die gefilterten OSMI-Fehler sich in JOSM reinzuholen? Selbst der OSMI-Zoom-Link zu JOSM funktioniert (bei mir?) nicht, Potlatch/ID hingegen schon…

Schöne Idee, könnte ich mir auch vorstellen

Wenn ich etwas Zeit hab, ordne ich meine Daten noch PLZ Region zu (das ist auch der Grenzfehler zu Polen etc. weg)und schreibe aus den Nodes zu einem Way ggf die Koordinaten in zwei Spalten.

Dann könnt Ihr das bestimmt mit Optik in ein anderes Tool einladen…
Den Nodetyp schreib ich auch dazu, dann könnt Ihr Euch Briefkästen etc rausfiltern.

Bei der Diskussion gibts übrigens andere Kuriositäten:
https://de.wikipedia.org/wiki/Ortstafel_(Deutschland)#/media/File:Hochwasser2011_01_13_IMG_0417.JPG

oder hier zufällig der Ort, den ich schon im Visir hatte, viel Infos für die Tags,
https://de.wikipedia.org/wiki/Ortstafel_(Deutschland)#/media/File:Os_Boltenhagen_P7160043.JPG

Aber das man für zweizeilige Angaben auf einem gelben Ortschild einen gemeinsamen Nenner für die Schreibweise
finden sollte finde ich schon. Das scheint mir ein offensichtliches (weil zweizeilig in Tags nicht vorgesehen) aber auch leicht lösbares Problem.
Wie/wo wird sowas entschieden?

Siehe eventuell Zweisprachige Namen im Siedlungsgebiet der Sorben/Wenden reloaded

Welche Grenzfehler? Ein konkretes Beispiel wäre nett.

Gruss
walter

Es ging um http://www.openstreetmap.org/way/385899441 in seiner Liste im Beitrag: https://forum.openstreetmap.org/viewtopic.php?pid=614496#p614496

Sven

Sorry, falls das hier schon jemand angemerkt hat: Der Ortseintrag-Name der DPAG stimmt nicht immer mit dem Namen der Gemeinde, in dem sich ein Haus befindet, überein. Das kann daran liegen, dass das Haus postalisch anders einsortiert wurde oder dass die DPAG einfach einen Ortsteilnamen als Namen des Ortseintrags verwendet (was trotzdem offiziell wäre). Letzteres kann z.B. durch ein postalisch nicht nachgepflegte Gemeindefusion entstehen oder weil einzelne abgelegene Höfe einen eigenen Ortseintrag bekommen.

Was das jetzt für das “korrekte” Tagging von “addr:city” bedeutet, ist nicht geklärt…