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.