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

update 2019-04-15: Ich habe den Einleitungstext komplett überarbeitet um ihn an die aktuellen Gegebenheiten anzupassen und veraltete Informationen zu streichen

Motivation

Aufgrund von Problemen und Limitierungen des AddressHelper bzw. einer Änderung der Geocodierung in den BEV-Daten habe ich den BEV-Konverter angepasst, um neben Verbesserungen beim AddressHelper auch gleich noch mehr Informationen, wie Unteradressen oder Gebäudepositionen, direkt als osm-Dateien zu erhalten. Insbesondere auch bei fehlerhaften oder ungenauen BEV-Daten kann es beim AddressHelper etwas problematisch sein, wenn man nicht sieht auf welche Datenbasis dieser zurückgreift. Die osm-Dateien sind aber genauso wie der AddressHelper nur als Hilfsmittel zum manuellen Eintragen gedacht, siehe bspw. hier, warum man nicht einfach stupid blind importieren sollte.

Unteradressen

Einer Adresse können in den BEV-Daten auch mehrere Gebäude zugewiesen sein. Wenn diese eine Unteradresse besitzen, wird die als addr:unit übernommen (dieser Style zeigt addr:unit auf der Karte an).
Es gäbe zu den Unteradressen auch noch einen Prefix zur Nummer wie “Obj.”, “Stg.”, “Haus”, “/”, etc. den ich nicht übernehme. Wie auch schon in diesem Thread thematisiert existieren allerdings auch ein paar Adressen, die sich nur dadurch unterscheiden, wobei die in JOSM integrierte Duplikatswarnung davor bewahren sollte, dass man so etwas übersieht. Um den Prefix in diesen Fällen dann doch wieder heraus zu bekommen, kann man bspw. geoland.at verwenden.

Darüber wie Unteradressen angegeben werden sollen, existiert aktuell kein eindeutiger Konsens. Ich persönlich verwende fast überall addr:unit (zumindest wenn nicht schon anders erfasste Unteradressen zu dieser Adresse existieren), wobei ich die volle Adresse nur angebe, wenn es ein komplettes Gebäude betrifft. Für mehrere Eingänge zu einem Gebäude vergebe ich dagegen mittlerweile nur mehr die Basisadresse auf das gesamte Gebäude und bei den einzelnen direkt am Gebäuderand liegenden Eingangs-Nodes nur mehr die Unit (die Auflösung der zugehörigen Gesamtadresse ist dabei trivial und auf der gerenderten Karte ist es deutlich übersichtlicher. Umgekehrt wäre es umständlicher, die redundante Information vor dem Rendern an den geeigneten Stellen wieder heraus zu filtern). In manchen komplexeren Fällen kann es auch sinnvoll sein, die Zusammenhänge als Relation abzubilden, siehe hier: https://forum.openstreetmap.org/viewtopic.php?id=65732

addr:place

Bitte auf Fälle achten, wo addr:street auf addr:place geändert werden muss. Der einzige Fall, wo das automatisch passiert, ist wenn Straßenname = Ortsname

addr:city

Für addr:city wird immer der Name der Gemeinde verwendet. Sollte eine Straße in einer Gemeinde mehrfach vorkommen, wird bei den Adressen dieser Straßen zusätzlich ein addr:suburb mit dem Ort gesetzt. Das entspricht zwar der Möglichkeit 2 aus dem Leitfaden der Post, muss aber nicht zwingend immer den lokal gebräuchlichen postalischen Adressen entsprechen.

Zugangs- vs. Hauskoordinate und Identadressen

Die BEV-Daten enthalten sowohl eine Zugangskoordinate zu einer Adresse, welche sich am Grundstücksrand bei der Straße befindet, als auch Hauskoordinaten, die sich zentral über den Gebäuden befinden, die einer Adresse zugewiesen sind. Grundsätzlich wird für die osm-Dateien die Adresse wenn vorhanden auf die Hauskoordinate gelegt, zumindest wenn diese eindeutig ist. Bei mehreren Gebäudepositionen zu einer Adresse wird die Zugangskoordinate verwendet, es sei denn die Gebäude besitzen eine Unteradresse.
Umgekehrt kann ein Gebäude auch mehreren Adressen zugewiesen sein, wobei eine davon als Hauptadresse ausgewiesen ist. In den osm-Dateien wird daher für die Hauptadresse die Hauskoordinate verwendet, für die übrigen die Zugangskoordinate. Auch dazu, wie mit Identadressen umgegangen werden soll, gab es schon Diskussionen ohne wirklichen Konsens, aber es sollte somit zumindest einmal erkennbar sein, was laut BEV die primäre Adresse sein sollte, wobei das auch manchmal fraglich ist, ob das überhaupt mit der Praxis übereinstimmt: die Hauptadressen auf dem folgenden Bsp.-Bild dürften auf die (größere) Vösendorferstraße 78 bzw. 80 lauten, obwohl die Garagenzufahrten und der Eingang dem Luftbild nach wohl in der Rigolettogasse liegen dürften.

Wie schon oben angesprochen kann es in komplexeren Fällen mit Identadressen und Unteradressen evtl. sinnvoll sein, die Zusammenhänge als Relation abzubilden, siehe hier: https://forum.openstreetmap.org/viewtopic.php?id=65732

Workflow

Die Ordner- bzw. Dateistruktur sieht so aus:
Bundesland / Bezirk / Gemeinde / Ort / Strasse_PLZ_Ort_(Gemeinde).osm
bzw. für die gefilterten Daten
Bundesland / Bezirk / Gemeinde / Ort_filtered / Strasse_PLZ_Ort_(Gemeinde)_filtered.osm

Wenn man nicht nur an gezielten (Unter-)Adressen, sondern einer ganzen Ortschaft interessiert ist, bietet es sich an alle Straßen des Ortes per Drag&Drop in JOSM zu öffnen. Die Ebenen sind gesperrt, d.h. sie lassen sich weder hochladen, noch bearbeiten, sondern die Daten müssen zuerst in eine Arbeitsebene kopiert werden (Ctrl+Alt+V fügt an der ursprünglichen Position wieder ein). Wenn eine gesperrte Ebene aktiv ist und ihr Daten von OSM herunter ladet, landen diese automatisch in eurer (oder einer neuen) Arbeitsebene. Mit dem Shortcut “2” zoomt ihr auf den Bereich der aktuellen Ebene (“3” zoomt auf die aktuelle Auswahl), was durch die Gliederung nach Straßen auch den Effekt hat, dass sich damit leicht Ausreißer und Fehler in den BEV-Daten finden lassen:

Bei der Gelegenheit kann man dann auch gleich fehlende Gebäude oder Straßen eintragen, Adressen mit Gebäuden verschmelzen (Geometrie ersetzen), Straßennamen kontrollieren bzw. auf addr:place ändern und/oder einen entsprechenden Place anlegen, etc.
Mit Datei → Sitzung speichern als… könnt ihr die aktuelle Sitzung mit allen (noch) offenen Ebenen speichern um den Überblick zu behalten, welche Straßen ihr schon behandelt habt.

Neue Straßen

Siehe hier für eine umap mit neuen oder möglicherweise fehlenden Straßen.

Nur in OSM fehlende Adressen

Neben den vollständigen Daten habe ich auch zusätzliche Dateien erzeugt, wo alle zum Stichtag schon in OSM vorhandenen Adressen herausgefiltert wurden, mit einer gewissen Toleranz was Schreibweise betrifft und unter Berücksichtigung von alt_name/official_name. Der Filter findet hier nur auf Ebene der Hausnummer statt, also wenn diese gefunden wird, werden auch alle Unteradressen entfernt. Bei einer signifikanten Abweichung der Position werden die Nodes nicht entfernt, da nicht klar ist, welche der beiden Positionen falsch ist (falls überhaupt und nicht nur das Gelände so groß ist). Es sollte mittlerweile selbstverständlich sein, dass auch diese Daten nicht dazu geeignet sind, einfach unbearbeitet blind zu importieren.

Gebäudebezeichnungen / Hofnamen

Zu einigen Adressen oder einzelnen Gebäuden existieren in den BEV-Daten Hofnamen bzw. Gebäudebezeichnungen. Ich hatte diese ursprünglich als Note exportiert, allerdings hat sich das in der Praxis aus verschiedenen Gründen als problematisch und wenig hilfreich erwiesen. Wer sich dennoch dafür interessiert kann das Script lokal mit entsprechendem Parameter laufen lassen und die Information in entsprechende OSM-Tags übersetzen, wo es sinnvoll und aktuell ist, aber bitte NICHT einfach so wie sie sind hochladen.

Tolle Sache!!!

In den Daten sind oft auch Hausnamen enthalten z.B. “XXX-Hof” oder “YYY-Gut”.

Ich raetsle was ich damit machen soll, nachdem ich den Sachverhalt oft nicht kenne, tendiere ich dazu den Hausnamen-Eintrag zu loeschen…

Hat jemand eine Meinung dazu?

Lg, Gppes

Hast du ein Bsp. dafür?
Aber grundsätzlich: ohne Ortskenntnis nicht eintragen

Das JOSM Plugin austriaaddresshelper funktioniert offensichtlich wieder. Ich verwende hierbei weiterhin die auf Github zu findende https://github.com/JOSM/austriaaddresshelper/releases ältere Version des Plugins v0.5.1. Diese Version verzichtet noch auf eine integrierte Prüf Abfrage auf Duplikate, und ist daher wesentlich schneller.
Das finden von Duplikaten verlagere ich in einen weiteren Arbeitsgang. Eine gezielte Overpass-Turbo Abfrage nach Duplikat Adressen, bietet wesentlich bessere Flexibilität und Genauigkeit.

Vom User Luzandro bereitgestellten BEV Open Data Adressen (2018!) sind zu empfehlen, leider schlägt hierbei die in JOSM ebenfalls integrierte Fehlerwarnung, auf doppelte Adressen an, obwohl es sich per “note” angemerkt, hierbei um zum Beispiel wertvolle Information über Nebengebäude handelt. Ich klammere daher Adressen mit der Anmerkung “note” vom Prüf Vorgang aus. http://overpass-turbo.eu/s/Bma . (damit der overpass Server nicht übermäßig belastet wird, nur jeweils ein Overpass- Abfragefenster beschränkter Größe aufziehen)

Diese Prüf Abfrage kann man gegebenenfalls direkt in JOSM ausführen, das vereinfacht das Suchen und Finden von Duplikaten wesentlich.

Ich möchte anmerken dass im BEV- Adress-Satz von Luzandro, im Datenfeld addr:city die jeweilige Ortschaft steht.
Im vom austriaaddresshelper gelieferten Datensatz hingegen im Datenfeld addr:city der Name der Katastralgemeinde.

Google macht es so wie Luzandro, und leitet den Namen der Katastralgemeinde wohl nur aus der Gemeindegrenze ab.

Nach einigem experimentieren, bin ich in der Tiroler Katastralgemeinde Wildschönau auf folgendes, mittels OSM Nominatim funktionierende Baukastensystem gekommen:

addr:city=Wildschönau
addr:country=AT
addr:housenumber=20
addr:postcode=6311
addr:street=Dorf, Oberau
addr:suburb=Oberau
building=yes

addr:city=Wildschönau
addr:country=AT
addr:housenumber=83
addr:postcode=6313
addr:street=Dorf, Auffach
addr:suburb=Auffach

Eine OpenStreeetMap Adress- Abfrage, liefert so das selbe Ergebnis wie per Tiroler Tiris System.

Wie gesagt sollen die Notes auch nicht einfach direkt übernommen werden. Informationen wie “linkes/rechtes Gebäude” oder “Altbau/Neubau” sind für OSM uninteressant und verdienen keine “eigene” duplizierte Adresse. Ähnlich sieht es bei bestimmten Gebäudetypen wie “Lagerhalle” aus, die man nur, wenn man möchte, als spezifischere building Information übernehmen könnte. Interessant sind v.a. Informationen zu POIs, die noch nicht in den OSM-Daten sind, wie “Kindergarten” oder “Gasthaus”, wobei man da auch noch kontrollieren sollte, ob das noch aktuell ist.

Die Wildschönauer Adressen schauen etwas eigenwillig aus, aber offenbar wird das so verwendet. Da könnte man zwar theoretisch auch automatisch erkennen, ob der Ortsname schon beim Straßennamen angehängt ist und entsprechend city/suburb setzen, aber ich glaube es ist besser wenn solche Sonderfälle im Einzelfall von Personen mit Ortskenntnis entschieden werden.

Ich habe jetzt mal ein XML (PLZ 8770) mit dem Browser aufgemacht und nach “addr:housename” gesucht. Da hat man fast schon den Eindruck, dass es eher die Regel ist, dass da was drinnen steht… :wink: :


<node id="-2260288" lat="47.337258" lon="15.020231"><tag k="addr:country" v="AT"/>
<tag k="at_bev:addr_date" v="2018-04-02"/><tag k="addr:postcode" v="8770"/>
<tag k="addr:street" v="Sattlergasse"/><tag k="addr:city" v="Sankt Michael in Obersteiermark"/>
<tag k="addr:housenumber" v="2"/>
<tag k="addr:housename" v="Zimmermannkeusche"/></node>

<node id="-2260289" lat="47.337126" lon="15.021776"><tag k="addr:country" v="AT"/>
<tag k="at_bev:addr_date" v="2018-04-02"/><tag k="addr:postcode" v="8770"/>
<tag k="addr:street" v="Schulgasse"/><tag k="addr:city" v="Sankt Michael in Obersteiermark"/>
<tag k="addr:housenumber" v="1a"/>
<tag k="addr:housename" v="S C H U L H A U S"/></node>

<node id="-2260290" lat="47.337024" lon="15.021988"><tag k="addr:country" v="AT"/>
<tag k="at_bev:addr_date" v="2018-04-02"/><tag k="addr:postcode" v="8770"/>
<tag k="addr:street" v="Schulgasse"/><tag k="addr:city" v="Sankt Michael in Obersteiermark"/>
<tag k="addr:housenumber" v="1"/>
<tag k="note" v="Volksschule"/></node>

Das ist das, was in den BEV-Daten als “Hofname” angegeben ist. Siehe Schnittstellenbeschreibung:

addr:housename ist da mMn. falsch, wenn es eine richtige Adresse gibt (ich hab noch nicht geschaut, ob es überhaupt Fälle gibt, die NUR einen Hofnamen haben). Tlw. könnte man es als “name” übernehmen, aber nicht wenn so etwas wie “S C H U L H A U S” angegeben ist.

edit: es gibt 348 ohne Adresse, aber auch da ist es oft nur irgendein Beschreibungstext wie “Wasserbehälter”, “Trafosation” oder “Beachvolleballplatz” (sic)
Wäre wohl auch besser kombiniert mit der Gebäudebezeichnung als “note” aufgehoben

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