BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/19)

Ich hab jetzt erst einmal den Hofnamen auch zu note hinzugefügt

Um einen besseren Überblick zu bekommen, was in diesen Feldern gespeichert ist, habe ich jetzt noch alle existierenden Werte für Hofnamen und Gebäudebezeichnungen sortiert nach Häufigkeit ausgegeben und ebenfalls online gestellt. Die Hofnamen beziehen sich dabei auf die gesamte Adresse, die Gebäudezeichnungen auf einzelne Gebäude. Mit den gestern aktualisierten Daten wird jetzt beides zusammen als note ausgegeben und nichts mehr unter addr:housename. Bitte die neuen Daten herunterladen und die mit addr:housename nicht mehr verwenden - in praktisch allen Fällen ist das mal mehr oder mal etwas weniger falsch als housename.

Danke, ist Dein Skript auf github jetzt auch auf dem gleichen Stand? Ich bin darauf umgestiegen…

Ja natürlich

Ich habe mich entschieden den Output noch feiner aufzugliedern und nicht nur für jede PLZ ein eigenes File anzulegen, sondern für jede Ortschaft+PLZ.

Nachdem mir diese Changeset-Diskussion mit einer falschen Zuweisung für addr:city aufgefallen ist, habe ich Leoben zu den Ausnahmen aufgenommen. Die neuen Dateinamen richten sich nach dem Input, also dem Ortsnamen in den BEV-Daten, in diesem Fall “8700 Göß.osm” - Göß wird dort allerdings nur noch als suburb gesetzt und addr:city ist die Gemeinde Leoben (wie auch für die anderen “Ortschaften” der Gemeinde).

Es gilt weiterhin:

Wuerde es Dich stoeren, als Trenner Zwischen PLZ und Ortschaft einen Unterstrich und kein Space zu verwenden? :wink:

Script ist geändert, Dateien werde ich später hochladen. In den Ortsnamen war sowieso schon vorher (u.a.) kein Space erlaubt und jetzt sind auch noch alle nur klein geschrieben, denn zumindest in einem Fall gab es eine unterschiedliche Groß-/Kleinschreibung für den Ortsnamen, was für Filenamen auch nicht so ideal ist

Wie man auf https://regio-osm.de/hausnummerauswertung/anzeige_dynamisch.html sieht, werden Regionen ab einem Adress-Abdeckungsgrad von ca 80% als vollständig gemappt angesehen.
Das bisherige Jahr war zumindest für mich ein Jahr des Lernens. Die uns zur Verfügung stehenden Werkzeuge sind zuletzt immer besser geworden. Besonders hervorzuheben sei hier das JOSM Plugin austriaaddresshelper, und besonders die von Luzandro aufbereiteten BEV Adressen.
Immer wieder werden Importe kritisch hinterfragt. Wir sollten uns aber nun aufgrund neuer mächtiger Werkzeuge -Luzandro sei erwähnt- eine Zielvorgabe setzten, bis zu welchem Zeitpunkt wir der Öffentlichkeit Österreich als flächendeckend mit wenigstens 80% gemappt präsentieren können.
Erst ab diesem Zeitpunkt dürfen wir über weitere Qualitätsvorgaben diskutieren.
Vielfach wird davon gesprochen dass die wertvolle Arbeit der vorort Mapper zu achten ist. Vorort Mapper arbeiten niemals mit Adress-Nodes sondern zu 99% mit Gebäude Polygonen. Selbst wenn wir also die Adresse vom Gebäude auf einen Adress- Node übertragen, bleibt hierbei immer die wertvolle Arbeit der Vorort Mapper in der Gebäude Historie erhalten, und so auch diese Information weiterhin erhalten.

User gemeinsames Ziel:
Österreich bis zum 31. 12 2018 in Adresse als vollständig gemappt zu präsentieren.

Von schnell schnell möglichst viel halte ich überhaupt nichts. Mein Ansatzpunkt ist verschiedene Werkzeuge zur Verfügung zu stellen, die häufige Fehlerquellen reduzieren. Mittlerweile bin ich der Ansicht, dass auch das Aufbereiten der Daten in dieser Form mehr Nutzen als Schaden darstellt. Man kann die Büchse der Pandora sowieso nicht mehr schließen, auch per regio-osm waren sie schon weniger aktuell/detailiert als .osm-File verfügbar und basemap abzeichen oder AddressHelper haben auch schon zu großflächigen Fehlern geführt also kann man sowieso nur versuchen die User in richtige Bahnen zu lenken.

Ich möchte den Thread jetzt allerdings nicht in eine Grundsatzdiskussion zum Adressmapping abgleiten lassen, also bitte bei Themen bleiben, die sich auf diesen Datensatz beziehen.

Wie ich schon auf der Mailingliste geschrieben habe: Wir (speziell Du) sollten uns am Projekt OSM nicht verheizen und auch die Geduld der Kollegen nicht ueberstrapazieren.

Zwischendurch mal ein ausgedehnter Survey (Spaziergang) der die eine oder andere Parkbank mit schoener Aussicht oder andere Kleinode in die Datenbank bringt haben auch viel Wert.

Du solltest Dich dort zu den Vorwuerfen auf der Mailingliste aeussern und Deine Plaene offenbaren, sonst riskierst Du - zu Recht - eine Sperre. Derzeit hast Du dort ohnehin die Mehrheit hinter Dir.

Aus meiner Sicht basiert OSM auf drei Saeulen:
o Der computerbasierten Arbeit Daten zu erfassen
o Dem Survey (Naturgenuss)
o Der Kontakt mit der Community

Nimm Dir das zu Herzen!

Lg, Gppes

Thema OpenStreetMap Adresserfassung Österreich, Ziel 80% bis 31. Dezember 2018

Fortsetzung unter: https://forum.openstreetmap.org/viewtopic.php?pid=713453#p713453

Das Script akzeptiert jetzt tlw. unvollständige Input-Files, bspw. kann man STRASSE.csv durch eine Version ersetzen, die nur die Zeilen enthält, die sich im Vergleich zum letzten Stichtag unterscheiden und alle anderen Straßen werden ignoriert.

Die Änderungen sind nicht immer ganz offensichtlich und enthalten nicht nur neue Straßen, oder Straßen mit geändertem Namen. Zum einen kann sich einfach nur die zugewiesene Gemeinde geändert haben, oder auch nur ein Straßennamenzusatz, der vom Script ignoriert wird. Laut BEV kann dieser Zusatz zwar auch Bestandteil des Straßennamens sein, aber bspw. soll es hier die Wiener Straße (und noch andere, die über mehrere Ortsgrenzen gehen) mit dem Zusatz als Namensbestandteil “Traiskirchen” oder “Möllersdorf” geben, was mir neu wäre, dass das hier irgendwo so verwendet wird:
https://www.openstreetmap.org/way/348324122#map=17/48.01745/16.29476

Zu finden im Ordner diffs.

Ich wäre dir wirklich sehr dankbar, wenn du die Duplikatsprüfung nicht deaktivierst und auch nicht weiterhin trotz wiederholtem Hinweis “wertvolle Informationen” wie “Wohnhaus” einfach so wie sie sind hineindumpst

edit:
In dem Fall gibt es überhaupt nur den einen Node, der relativ offensichtlich zu einem “Wohnhaus” gehört, aber du darfst auch gerne building auf house ändern:
https://www.openstreetmap.org/node/5873542096

In dem Fall lässt du absichtlich 3 Nodes, was ich für völligen Schwachsinn halte:
https://www.openstreetmap.org/node/5873542085
Kein Router wird dir Note als Unterscheidungsmerkmal anzeigen - wenn du einen Betrieb zu dem “Betriebsgeb.” kennst, kannst du ja einen entsprechenden POI mit der Adresse anlegen. Ansonsten kannst du building=commercial/warehouse setzen, wenn du diese Information nutzen möchtest, wobei du ja nicht einmal die beiden Gebäude getrennt, aber 2 Nodes für 2 Gebäude gesetzt hast. Die Adresse kann man einmal auf dem Wohngebäude oder der Einfahrt lassen, aber nicht so mit 3 Nodes, das ist einfach nur ein schneller Pfusch damit deine Malen nach Zahlen Karte eine andere Farbe bekommt und danach schaust du die Gegend nie wieder an und irgendjemand anders kann das dann aufräumen

Hallo Luzandro,
es gibt noch andere Anwendungsarten als Routing. Bei Gehöften ist die Zusatzinformation Lagerhaus, Wohnhaus oder Austragshaus sehr wohl eine relevante Information.
Zum Argment Routing fällt mir noch auf, dass in den BEV Sätzen -ausgenommen Vorarlberg- eine Systematik festzustellen ist, dass die Adresse fast immer auf ein Nebengebäude verortet ist.

Ich lagere die Duplikatsprüfung auch deshalb in einen weiteren Arbeitsgang aus, da hierbei viel differenzierter geprüft werden kann. OverPassTurbo sei Dank. Überhaupt ist OpenStreetMap nach einer Adressergänzung noch keineswegs fertig gemappt. Da sind noch viele weitere Arbeitsschritte notwendig. Ich finde jeder Arbeitsschritt sollte aber möglichst vollständig in sich abgeschlossen sein. Wenn schon Adresse, dann unbedingt jeweils für das gesamte Gemeindegebiet vollständig. Darauf habe ich auch http://hdyc.neis-one.org/?Negreheb in meinem Blog hingewiesen. https://www.openstreetmap.org/user/addresshistory*org/diary/44870#comment42715

Übrigens, egal was Du aktuell sonst im Forum postest. Du bist definitiv jene Person in Österreich, der wir in letzter Zeit für viele konstruktive Werkzeuge zu Danken haben. Dem Meister der Werkzeuge Luzandro und dem BEV für deren hochwertigen Adressdaten ein klares Danke.

Edit. +Dank

Noch zur Info was nicht verwendet wird: prinzipiell gäbe es zu Gebäuden auch noch ein Feld für die “Überwiegende Eigenschaft dieses Objektes” mit 9 Kategorien, die sich zwar relativ problemlos direkt in building tags übersetzen ließen, aber soweit ich das sehe sind da viel zu viele falsche Informationen drinnen, die auch niemand kontrollieren würde (abgesehen davon, dass es aktuell wohl sowieso kaum eine Auswirkung hat).
Ähnlich sieht es mit der Tabelle GEBAEUDE_FUNKTION aus, die einigen Objekten eine Funktion wie “Apotheke” zuweist. Ich habe mir mal eine Liste mit den Adressen ausgeben lassen, wo sich laut BEV eine Apotheke befinden soll, aber im Umkreis von 150 Metern keine in den OSM-Daten gefunden wird - das waren 157/647, aber 3/4 davon werden bei einem Recheck auf https://www.apotheker.or.at auch nicht gefunden, bzw. tlw. sind auch andere Apotheken so nah, dass dort schon dadurch gar keine sein dürfte.

Ich habe kurz überlegt, ob ich die Ausgabe für mehrfache Gebäude zu einer Adresse ohne Unteradressen irgendwie ändern soll, aber fürs erste sehe ich das als unnötigen Aufwand ohne Nutzen an. Unabsichtlich kann meiner Ansicht nach nicht viel passieren und gegen Absicht kann ich sowieso nichts machen. Was evtl. unabsichtlich durchrutschen könnte, sind unnötige Notes, wie das gelegentliche “Wohngebäude” auf dem einzigen Gebäude einer Adresse, das um nichts anders aussieht, als die ganzen anderen Wohngebäude drumherum in der Siedlung ohne Note. Das ist zwar auch ein wenig nervig, aber wenigstens richten sich notes nur an andere Mapper und zumindest Enduser sollten davon normalerweise nicht irritiert werden.

Das Wiki sagt zu mehreren Gebäuden zu einer Hausnummer:

Mir ist allerdings keine Relation bekannt, mit der man eine (oder mehrere) Zugangskoordinate(n) mit der dazugehörigen Fläche verknüpfen und somit Routing-/Render-Position beeinflussen könnte. Insbesondere bei sehr großen Flächen mit mehreren Adressen wäre es ja sinnvoll die einzelnen Adressen als Punkte anzulegen und mit der Fläche zu verknüpfen, wo die gemeinsamen Eigenschaften gespeichert sind, aber auch ohne Verknüpfung würde ich in dem Fall eben Nodes zur Einfahrt setzen.

Hallo Luzandro, ich gehe inzwischen in meiner Arbeitsweise dazu über, den BEV Satz unverändert als gesamtes einzuspielen. Erst anschließend beginne ich -ohne Overpass- Filter- unter Einbeziehung aller OSM Daten mit der Bereinigung von Duplikaten.
Über den BEV Datums- TAG kann man aktuelle BEV Daten problemlos filtern. Beim zusammenfügen von Adressen aus früheren BEV Adresssätzen, löse ich hierbei jeweils den ältere BEV Datums- Merker auf. So wie ich das sehe sollten nach einem erfolgreichem Abgleich sämtliche älteren BEV Datums Merker in neueren Daten aufgelöst sein, bleiben ältere BEV Adressen übrig, so ist das ein Hinweis dass es diese Adressen nicht mehr gibt.

Vielleicht beschreibst auch Du eine Vorgangsweise im Abgleich nach Deinen Vorstellungen.
Grüße Johann

Edit: typo

Ich hole jetzt mal ein wenig aus, warum die BEV-Daten und regio-osm nicht die Reine Wahrheit™ darstellen.

Die braunen Adressen sind hier offensichtlich falsch, wobei es mittlerweile schon deutlich besser geworden ist und der Großteil der restlichen Adressen stimmt, oder zumindest nur mehr um eine Position vertauscht ist. Davon abgesehen verwendet aber auch keiner den Straßennamen “Dürrsee-O”. In OSM ist das jetzt “Dürrsee Ost” und die Straße hat als official_name “Dürrsee-O” - Nominatim findet damit beide Varianten, für regio-osm “fehlen” diese Adressen dagegen. Seen scheinen überhaupt ein Fall zu sein, wo die BEV-Adressen oft falsch oder irgendwo sind, tlw. einfach mitten im See.

Ähnlichen Effekt bzgl. regio-osm gibt es hier:

Die Straßennamen in den BEV-Daten sind abgekürzt, in OSM ist schon alles mit vollem Namen vorhanden. Da setze ich vielleicht “K. R. v. Ghega-Gasse” als official_name, aber “bessere” nicht die vorhandenen aus (bzw. lösch sie nicht einfach und setze neue Nodes)

Gerade bei (v.a. neueren) Reihenhäusern sind die Adressen oft auch erst einmal nur irgendwie durcheinander gewürfelt grob in die Gegend geschmissen. Das kann sehr hilfreich sein, um zu sehen, welche Adressen es prinzipiell einmal geben sollte, aber für die genaue Position ist es wenig hilfreich (und anfällig dafür, dass per AddressHelper irgendein Blödsinn eingetragen wird).


Auch die Gegend, wo du schon beim basemap Abzeichnen daneben gehaut hast, ist immer noch falsch in den BEV-Daten. Die Adressen Ferdinand-Porschestraße 6-12 sind da irgendwo als möglicherweise scheinbare Identadressen, während sie User pebuse schon vor einem Jahr bei einer Begehung den 4 Gebäuden im Norden ohne Adressen zugewiesen hat.

Und das sind offensichtliche Fehler und nicht subtilere, wie um 1 Position verschobene, wie beim angesprochenen See, oder überhaupt Gegenden, die unsystematisch durchnummeriert sind. Was ich damit sagen will: ungeschaut vorhandene Adressen löschen ist völliger Irrsinn, wobei ich generell nichts davon halte, Adressen von Gebäuden zu löschen und an der gleichen Stelle einen Node ohne Informationsgewinn anzulegen.

Die Angaben unter at_bev:addr_date kann man meistens auch nur auf die Attribute beziehen (und da kann man sich nicht 100% sicher sein). Die Position ist (zum Glück) praktisch nie 1:1 die aus den BEV-Daten. Wenn es keinen Grund dazu gibt, greife ich die alten da auch nicht an.
Ich hab jetzt mal geschaut, wieviele Einträge es in der Adress-Tabelle von 10/2017 gibt, deren ID (ADRCD) sich in den Daten von 04/2018 nicht mehr finden lassen, das sind österreichweit anscheiend 1.193 / 2.375.123. Ich hab da bei ein paar Gegenden, die ich kenne, hineingeschaut und so eine richtig komplett falsche ist mir da nicht einmal aufgefallen. Tlw. wurde offenbar genau die gleiche Adresse wieder mit mehr Informationen zu Gebäuden neu angelegt, eine Identadresse aufgelöst, eine Adresslücke aufgelöst, obwohl nicht zu erkennen ist, dass das Grundstück mit einem anderen zusammengelegt worden wäre, oder eben wirklich die Zusammenlegung von benachbarten Grundstücken: https://my.sofortcloud.com/index.php/s/qCejcVUFyigZdus

Andere Änderungen zw. den letzten beiden Stichtagen kannst du hier sehen: https://my.sofortcloud.com/index.php/s/wnmvDwU3sZI6GEG
Das sind irgendwelche Einträge im Output, die im vorigen nicht vorkamen, sprich unterschiedliche Position, Straßennamen, Schreibweise etc. Den obigen Vergleich mit den IDs könnte man prinzipiell auch noch machen und sich nur die neuen IDs anschauen.

Fehlende Adressen zu ergänzen halte ich auf jeden Fall sinnvoller, als in Gegenden, zu denen du keinen Bezug hast, irgendwelche Importe drüber zu bügeln, damit es einen mehr oder weniger definierten Stand gibt und der Vergleich mit den Import-Daten dann überraschenderweise sagt, dass alle Importdaten vorhanden sind.

Wenn du auf kleinerer Ebene systematisch vorgehen willst, kannst du auch einzelne Straßen abarbeiten (Kontextmenü auf addr:street => Schlüssel/Wert suchen):

Auf den Aspekt in der Natur erhobener Straßennamen muss man näher eingehen.
Das Österreichische Gebäuderegister GWR bildet heute als gemeinsame Datenbasis -also als Datenbank von Straßenbezeichnungen, Adressen, und Nutzungsarten von Gebäuden- eine Brücke zwischen dem Melderegister so auch den vorliegenden BEV Bezeichnungen.

Straßenbezeichnung welche Deiner Meinung nach in BEV Daten gekürzt- vorliegt, findet sich tatsächlich so geschrieben als amtliche Bezeichnung im Reisepass, sowie in Benhördenschreiben, Gerichtsakten und anderen amtlichen Dokumenten wieder.

Was also auch immer, auf einem vielleicht historschen Emailschild steht, ist daher zwar interessant, es gilt aber trotzdem allein die amtliche Schreibweise laut GWR.
Das macht nun für uns die Verfügbarkeit von BEV Adressdaten besonders wertvoll. Nur durch diese wird OSM tatsächlich für Adressen brauchbar (Identadressen ausgenommen).

Natürlich gibt es da und dort auch in amtlichen Datenbanken Fehler, solche Fehler im Namensraum bewegen sich aber tatsächlich im Promillbereich (Ich meine hier nicht die Adressposition sondern den Namensraum). Durch lokale OSM Recherche erhobene Schreibweisen sind daher, sobald uns amtliche Bezeichnungen aus den BEV Daten vorliegen, bestenfalls noch in der OSM Objekt Historie sinnvoll.

Das sehe ich nicht so. Man kann sicher diskutieren, ob man die Kurze als official_name setzt, oder stattdessen die Lange auf alt_name ändert, aber komplett überschreiben und wegwerfen finde ich nicht sinnvoll.
Genauso wenig wie ich zwangsweise geringfügige Abweichungen bei der Schreibweise ändere, was bspw. Bindestrich oder Abstände anbelangt, solange es konsistent ist und das ist es ja bei den offiziellen Daten innerhalb einer Gemeinde auch nicht immer. Die Oskar Helmer-Straße in Markt Piesting steht bspw. in den 2017er Daten als “Oskar-Helmer-Straße” und 2018 als “Oskar Helmer-Straße” - war das jetzt voriges Jahr umgekehrt noch falsch? Ein vernünftiger Router muss das sowieso ignorieren.

Solange OSM Nominatim Adressen ausschliesslich zeichengenau interpretiert, sehe ich auch allein die exacte Amtliche Schreibweise als zulässig sowie vernünftig. Also beschwere dich sofern dich das stört, hierfür beim Nominatim Team.