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

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.

Bevor wir soweit gehen, wäre es dann doch deutlich sinnvoller, wenn Nominatim überhaupt mal alle eingearbeiteten Adressen mit exakter Schreibweise findet. Ich meine, jetzt ist der Suchradius leicht vergrößert worden - nennenswerte Besserung kann ich nicht beobachten. :roll_eyes:
Die Schreibweise ist natürlich ein anderes Problem. Das Problem ist, dass was im BEV-Datenstamm vorhanden ist und zugleich als amtlich angesehen wird, dann offenbar doch in der Realität nicht immer so amtlich zu sein scheint. Der Klassiker wäre da die Schreibweise einer Straße, die nicht dem BEV-Datensatz entspricht (irgendwelche Straßennamen die Personennamen beinhalten und dann Bindestriche gesetzt haben oder Abkürzungen oder gar Tippfehler).

Solche Sonderschreibweisen sind tatsächlich amtlich gültig. Als deine ZMR Adresse steht dann eben “Austragshaus des Altbauern”.

Datenbanken kennen keine Gnade.

Gnade kennt leider nur Google, die Macher von Nominatim haben hingegen offensichtlich keinerlei Interesse Goolge nachzueifern. Daher klare Sache, sobald uns eine amtliche Bezeichnung zur Verfügung steht, ist diese anzuwenden. Und wenn sich ein Bindestrich im nächsten BEV Satz ändert, dann ist das dann eben die neue gültige amtliche Bezeichnung.

Manchmal machen wir es uns wirklich kompliziert, dabei ist das so Simpel.

Die Amtliche Schreibweise ist Trumpf.

weil eine weltweite, schnelle, fehlertolerante Suche für beliebige Eingaben ja völlig trivial ist und von 2 Leuten mal schnell so nebenbei gemacht wird :roll_eyes:

Und Bindestriche stellen übrigens normalerweise kein Problem dar
https://www.openstreetmap.org/search?query=Franz-Josef-Straße%2C%20Leoben
https://www.openstreetmap.org/search?query=Franz%20Josef-Straße%2C%20Leoben
https://www.openstreetmap.org/search?query=Franz%20Josef%20Straße%2C%20Leoben

Ich meine solche Fälle: https://www.openstreetmap.org/way/34599974/history
Das Thema Schreibweise behandeln wird nun wohl bereits zum X ten mal. Leider gibt es für romantische OSM- Naturerhebungen heute keine guten Karten. Wir müssen uns wohl langsam vom Märchen, OSM Mappen erfolge mit Stift und Block, verabschieden.

Angesichts einer in Österreich mehr als kooperationswilligen öffentlichen Hand, dürfen wir deren Unterstützung nicht leichtfertig ausschlagen. Zu behaupten Österreichs Behörden würden systematisch nur fehlerhaftes produzieren, daher sei es gerechtfertigt dass wir weite Landstriche in OpenStreetMap mit unter 25% Adressabdeckung in Stagnation betonieren, das ist ziemlich abgehoben.


Es gibt in anderen friedlichen Initiativen eine Entsprechung. In solche mischen sich unter dem Deckmantel der Anonymität gegnerische Anarchisten, diese sprengen dann die friedliche Veranstaltung von innen. Leider werden in OSM ähnliche Versuche aktuell nicht ausreichend vehement zurückgewiesen.

Es gibt Häuser offenbar, die einen Namen tragen: Pritschenhof, Birnenhaus usw. Oftmals auch Vulgonamen sind darin enthalten. Das ist durchaus eine wichtige, lokale Information und die sollte man schon in OSM auch eintragen, eben beim Gebäudenamen.

Diese Bezeichnung stehen in amtlichen Schreiben anschließend in der Adresszeile:
ZB. Briefanschrift:
Feldweg 12/Top1
Feldweg 12/Top2
Feldweg 12/Top3
Feldweg 14/Austragshaus
Feldweg 14/Wohnhaus

Demnach müssten unsere Einträge in OSM dann folgendermaßen lauten:
addr:street=Feldweg
addr:housenumber=12/Top1
addr:unit=Top1

addr:street=Feldweg
addr:housenumber=12/Top2
addr:unit=Top2

addr:street=Feldweg
addr:housenumber=12/Top3
addr:unit=Top3

addr:street=Feldweg
addr:housenumber=14/Austragshaus
addr:unit=Austragshaus

addr:street=Feldweg
addr:housenumber=14/Wohnhaus
addr:unit=Wohnhaus

Fazit:
Gewerbeobjekte oder Nebengebäude einer Adresse werden im GWR mittels Sub Adresse identifiziert. Typisch sind G1,G2,G3 oder auch Realnamen wie Werkstatt, Wohnhaus, Nebengebäude

Beispiel
addr:street=Neubauweg
addr:housenumber=3/G1
addr:unit=G1

alternativ

erhoben durch lokales Mappen

addr:street=Neubauweg
addr:housenumber=3/Werkstatt
note=Werkstatt

wenn wir die Adresse dem BEV Satz entnehmen

addr:street=Neubauweg
addr:housenumber=3/Werkstatt
addr:unit=Werkstatt

Alle drei Varianten erreichen per Post Ihr Ziel
Neubauweg 3/G1
Neubauweg 3/Werkstatt
Neubauweg 3/Werkstatt

edit: Beispiele ergänzt

Faszinierend, bei einzelnen Bindestrichen ist dir die exacte amtliche Adresse heilig und dann erfindest du hartnäckig Adressbestandteile aus irgendwelchen beliebigen Beschreibungstexten. Zugegeben Top1…n gehört eigentlich als unit und hin und wieder findet es sich stattdessen nur in der Gebäudebezeichnung (so wie auch ein Note “a” darauf hin deutet, dass es eigentlich überhaupt eine eigene Adresse mit Suffix “a” geben sollte), der Großteil davon hat in der Adresse aber nichts verloren und schon gar nicht doppelt und dreifach wie bei deinem Vorschlag, wo dann die Adresse “Feldweg 14/Wohnhaus Wohnhaus” gerendert wird.

Was gerendert wird, ist die eine Sache, was Nominatim auswertet wieder eine völlig andere.
Ich übertrage hier lediglich meine Erfahrung aus dem GWR ZMR, und wie die Tür oder Top Nummer dann in amtlichen Schreiben dargestellt wird. Also keine Erfindung von mir.

Irgendwie sollten wir es aber schaffen, BEV Daten sinnvoll mit dem Datenrahmen von OSM zu verknüpfen. Hier bin ich wirklich um jeden Input Dankbar.

Mein Traum wäre ein verbindliches und einheitliche Umschlüsselungs Schema. Einer künftig möglichen Normdaten Verschränkung BEV-OSM wäre das sicher sehr dienlich.

Du erfindest hier Sachen, kommt mir vor. In OSM wird die Adresse als Zahl eingetragen, vielleicht mit einem a, b, c dabei, wie es eben auch auf der Hausnummerntafel steht.
Wenn ich das hier kontrolliere, wird das auch grundsätzlich so gemacht: https://taginfo.openstreetmap.org/keys/?key=addr:housenumber#values
Und Top als einfacher Wert ohne dem Wort “Top” dabei, mit dem Wert scheint es bisher insgesamt(!) (mit allen Top 1 bis Top 7 oder so) 7 add:unit=* zu geben. Alle anderen relevanten Werte sind einfach nur Zahlen.

Bei deinen Beispielen würd ich eher so vorgehen:
addr:street=Feldweg
addr:housenumber=12
addr:unit=1

oder

addr:street=Feldweg
addr:housenumber=14
name=Austragshaus

oder

addr:street=Neubauweg
addr:housenumber=3
name=Werkstatt
(Plus alle benötigten Tags für eine Werkstatt)

So könnte man theoretisch auch mehrere Adressen mappen, da sich das ja unterscheidet. Ist halt nur die Frage, ob auch wirklich auf jeden Haus ein anderes Taferl oben hängt. Ich würde wohl eher die Finger davon lassen und das Vorortmappern über lassen.

Deine Beispiele oben sind imho eher falsch.

EDIT: Bisschen gekürzt.

Es gab mal auf Statistik Austria AT den Bericht einer Arbeitsgruppe welche die Aufgabe hatte, aus verschiedenen Adressquellen eine einzige Adressbasis genannte AGWRII zu bilden. Ich habe deren Bericht fasziniert gelesen, einfach nur Professionelle Arbeit.
Genauso stelle ich mir das auch hier vor. Wir haben da einen OpenStreetMap Austria Verein, ein Bundesamt für Eich und Vermessungswesen, eine Statistik Austria. Was wir hier benötigen ist erneut eine Arbeitsgruppe von Professionisten. Das Ergebnis dieser Arbeitsgruppe sollte anschließend in unser OSM Wiki einfließen.

Das OSM Nominatim Team, und auch Adressanwender, hätten dann einen verbindliches Schema wie man Adressen in Österreich interpretiert.

edit: Austria

So generische Beschreibungen sind kein Name. Für addr:housename gilt im Prinzip das gleiche, auch wenn der in der Praxis für alles mögliche und anders als gedacht war verwendet wird. Ich verwende ihn gelegentlich für tatsächliche Haus- oder Hofnamen, wie zB Pitkahof, aber er wird u.a. auch dafür ge- oder missbraucht um Unteradressen wie “Stiege 1” anzugeben. Ich bin mir nicht sicher, ob aus Zufall oder Pragmatismus, es hat jedenfalls den Effekt, dass diese Einträge dann sowohl von osm-carto gerendert, als auch von Nominatim als “Haus Stiege 1” gefunden werden (mehr oder weniger). Ich halte es aber auf jeden Fall nicht für sinnvoll, oder besser gesagt schlicht falsch, die Karten und Suchergebnisse mit tausenden identischen “Namen” Wohnhaus, Lagerhalle oder Werkstatt zuzupflastern. Am ehesten passt das noch unter description.

Also ich habe noch nie ein amtliches Schreiben auf “Haupstraße 42/Wohnhaus (rechtes Haus) Wohnhaus (rechtes Haus)” zugestellt bekommen.