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

Dann sollte man wohl eher Nominatim ändern und nicht OSM tags so hinpfuschen dass es zufällig für Nominatim passt aber für alles andere nicht mehr.

Hallo Woazbot, es wäre Super wenn Du uns hier in Github unterstützen könntest. Auch JM82 hat dieses Problem mehrfach in Angelegenheit addr:place Regionen thematisiert.

Ich klinke mich hier einmal in diese Changeset-Diskussion ein und erlaube mir, sie im Forum weiterzuführen:

Eine Adresse bezieht sich eigentlich auf eine Fläche, die ich allerdings nicht kenne. Ich kenne nur die Position der Zugangs-Adresse(n) dazu, sowie Positionen von Gebäuden auf dieser Fläche, wobei es eine Unterscheidung in “Haupt-” und “Nebengebäude” nicht wirklich gibt und diese ja auch nicht immer Sinn ergeben würde. Ich habe also die Option, so wie jetzt alle Gebäude auszugeben, mich aus irgendeinem Grund für eines zu entscheiden (das erste in der Liste, oder das eine gewisse Bezeichnung hat oder nicht hat), oder stattdessen eben nur einen Node bei der Zugangs-Koordinate auszugeben, was ich mir auch schon überlegt habe. Zum Teil gibt es das auch schon lange mit dem Kompatibilitätsmodus für den AddressHelper, wo dann allerdings auch die Einträge mit einer konkreten eigenen Subadresse und nicht nur einer Gebäudebezeichnung fehlen.

Da musste ich einmal kurz lachen :slight_smile: Die Nodes sind hier genauso oft irgendwo, direkt übereinander, oder völlig offensichtlicher Blödsinn, wie das “hintere Haus” vorne an der Straße, aber das ist halt auch wieder regional unterschiedlich.
Und wie gesagt, du kannst die Information als Description / Gebäudetyp / POI übernehmen, aber nicht jedes Nebengebäude braucht eine “eigene” Adresse und ich weiß nicht für wen es wertvoll sein soll, wenn bei einer Suche nach dieser Adresse jedes einzelne Nebengebäude aufscheint.

Dann leg einen POI für den KFZ Fachbetrieb oder das Sägewerk an (edit: wenn es diese nach Internet-Recherche tatsächlich noch gibt) oder ändere die building Kategorie der Lagerhalle. Ich weiß, das dauert 2 Minuten länger, aber bitte nicht einfach “fürs erste” Duplikate in die DB kippen, weil die Information vielleicht doch noch irgendwann irgendwer nochmal brauchen und richtig machen könnte. Wir haben heute noch irgendein Klumpert vom plan.at-Import herumliegen, in denen sicher auch mal jemand einen Mehrwert für OSM gesehen hat.

Wie gesagt, ich habe schon überlegt, die Gebäudebezeichnungen zu streichen und/oder bei mehreren Gebäuden ohne Subadresse nur die Zugangsposition auszugeben. Dann fehlen halt die gelegentlich hilfreichen Informationen zu POIs auch.

Praktisch gibt es zwei relevante Adressarten von Adressen:
NTZ geeignet für Wohnzwecke
NTZ Gewerbe Nutzungseinheiten

Ob eine NTZ nun z.B. den Zusatz Gerberei trägt, sagt vorerst nichts über die tatsächliche Nutzungsart aus.
Rein theoretisch kann eine NTZ geeignet für Wohnzwecke heute ebenso die Bezeichnung Gerberei tragen.

In den uns vorliegenden BEV Daten, gibt es auch nicht für jedes Nebengebäude Duplikat Adressen mit Phantasie Bezeichnungen, sondern diese sind sogar eher sehr selten. Solche Adresszusätze stammen tatsächlich von den Kommunen, welche steuerlich relevante Objekte so kennzeichnen. Auch wenn heute eine Gerberei gar nicht mehr existieret, bleiben der Adresszusatz als Bezeichnung für die Örtlichkeit meist erhalten. Wohnbauträgern übernehmen solche historische Bezeichnungen gerne auch für ihre Projekte. Weswegen solche Bezeichnungen durchaus relevant sind, und vielfach bei neuen Projekten mit völlig anderer Nutzungsart wieder auftauchen.

Ich habe jetzt ein paar Änderungen vorgenommen:

Bei Adressen mit mehreren Gebäuden, die nur Gebäude ohne Subadresse haben wird jetzt nur noch die Zugangskoordinate ausgegeben.
Wenn alle Gebäude Subadressen haben, ändert sich nichts und auch bei den restlichen 1.534 Adressen, wo sowohl Gebäude mit, als auch ohne Unteradresse vorkommen, habe ich vorerst noch nichts geändert und überlasse es dem verantwortungsvollen Mapper im konkreten Fall eine sinnvolle Entscheidung zu treffen, weil das in der Vergangenheit schon so super funktioniert hat

Es gab ein paar Nodes mit einer leeren Hausnummer, die werden jetzt herausgefiltert. Sie sollten eigentlich auch bisher von niemand übersehen worden sein, da JOSM eine Warnung ausspuckt, wenn man versucht solche Einträge hochzuladen

Mglw. ist das jetzt auch schon etwas zu vorsichtig, aber Einträge wo addr:housenumber keine Ziffern enthält werden jetzt auch gefiltert. Das ist oft “Parz.”, “Stand”, “Weg”, oder “Obj.”, tlw. mit Subadresse, wo die Adress- und Gebäudeebene eigenartig vermischt ist, aber auch ohne, was überhaupt nutzlos ist. Die mit Subadressen könnten schon interessant sein (das gesamte IZ NÖ Süd hat hier bspw. ein recht eigenwilliges Adress-Schema), aber nicht mit diesem Mapping, also habe ich es vorsichtshalber dennoch heraus gestrichen. Es scheint allerdings auch bisher kein großes Problem gewesen zu sein, ich konnte aktuell per overpass-turbo nur 4 Einträge in OSM finden, wovon 3 per AddressHelper eingetragen wurden und eine Parz. von addr*org

Vglw. häufig bekommt ein einzelnes Gebäude in einer klaren Wohnsiedlung (wo auf dem Grundstück oft noch nicht einmal ein anderes Gebäude Platz hätte) die sinnlose Gebäudebezeichnung “Wohnhaus”. In solchen Fällen wird die Bezeichnung jetzt raus gelöscht, andere Gebäudebezeichnungen sind aber fürs erste noch vorhanden.

Hallo Luzandro, an sich habe ich das Jahr 2018 damit begonnen, PLZ Polygone in AT zu vervollständigen.
Solche wären nun natürlich zum Einspielen Deiner nach PLZ sortierten Adressen hilfreich. Nun haben wir nach PLZ sortierte BEV Sätze, aber leider nur Gemeindegrenzen.
Allein für das Aufbereiten eines mit den Gemeindegrenzen kompatiblen BEV Satzes, allein von Stainz https://drive.google.com/open?id=1llAEF7zZC97T4dBOKk6DIl14igJtIQJn habe ich mehrere Stunden benötigt.
Geht das nicht irgendwie besser. Zum Beispiel BEV Sätze je Gemeinde.

Die Marktgemeinde Stainz https://de.wikipedia.org/wiki/Stainz ist aus der Zusammenlegung mehrere Gemeinden hervorgegangen. Daher nun addr:City = Stainz
man könnte noch addr_alt:City = Stainz in der Weststeiermark hinzufügen.
Katastralgemeinden und Ortschaften sind niederrangig und haben daher im Feld addr:city nichts verloren.
https://de.wikipedia.org/wiki/Stainz#Gemeindegliederung Anmerkung:das ad_Helper Plugin liefert tatsächlich duchgängig als addr:City korrekt Stainz

Bereits hilfreich wäre zum Beispiel anstatt
8510_ettendorfbeistainz_(stainz).osm
Stainz_8510.osm man könnte dann per JOSM öffnen Dialog gleich mehrere Stainz PLZ Sätze selektieren und auf einmal öffnen.

Eigentlich würde ich mich in OSM gerne auf für OSM wesentliche Arbeiten, wie dem vervollständigen von Adressen beschäftigen. Aktuell arbeite ich bereits an der Aufbereitung des BEV Satzes bis spät in die Nacht. Um halb drei in der Früh ladet man dann den Satz hoch, um am Morgen dann von Negreheb über aus den BEV stammende Fehl- Verortungen -unsanft geweckt zu werden.

edit: Katastralgemeinden + Adress- Kater am Morgen

Nein, das sind jetzt meistens handliche Größen, die man auf Dateinamensebene nach PLZ, Orts- oder Gemeindenamen suchen kann. Wenn du also alle Ortschaften der Gemeinde Stainz haben möchtest, brauchst du nur nach “(stainz)” suchen und kannst sie per drag&drop in JOSM öffnen.
Durch die Aufgliederung sollen auch Fehler leichter auffallen, da unterschiedliche Ortschaften nicht mehr vermischt werden und zum einen Ausreißer wie dieser Node sofort auffallen, der sicher nicht zu “Neudorf bei Stainz” gehört, sondern zu “Neurath” und andererseits die Zuweisung von addr:city aber auch addr:place für diesen Bereich gleich überprüft werden kann, denn die übliche Logik, dass addr:place verwendet wird, wenn der “Straßenname” ident mit dem Ortsnamen ist, greift hier oft nicht, da bspw. die Ortsnamen noch ein “bei Stainz” enthalten, oder der “Straßenname” Neudorfegg lautet, der Ortsname aber “Neudorf bei Stainz”. Den ersten Fall könnte man prinzipiell noch recht einfach erraten, genauso wie man von gewissen Namen darauf schließen könnte, ob das eher nach Straße oder Ort klingt, aber unterm Strich musst du beim Eintragen darauf achten, ob es dort eine entsprechende Straße mit diesem Namen gibt, oder ob das ein Place ist.
Es gibt auch keinen Grund, warum du ein riesiges Changeset für eine komplette Gemeinde anlegen musst und das nicht auf mehrere Ortschaften aufteilst, wo dann auch solche Fehler auf diese beschränkt sind.

edit: und wie JM82 schon richtig festgestellt hat, waren große Teile hier schon korrekt erfasst und jetzt sind die Adressen nicht nur sinnloserweise vom Gebäude getrennt, sondern auch noch falsch, wie bei dem Neudorfegg-Beispiel (wobei auch davor der entsprechende Place für Neudorfegg schon gefehlt haben dürfte). Das grenzt schon an Vandalismus, oder um es positiver auszudrücken: das Gegenteil von gut ist gut gemeint. Bitte überdenke endlich einmal deine Vorgangsweise, es ist keine groß angelegte Verschwörung, dass ausgerechnet deine Changesets immer wieder kritisiert werden, egal wo in Österreich mit egal welchen Hilfsmitteln du großflächige Änderungen vornehmen möchtest.

Was uns wirklich fehlt ist eine funktionierende Vorgangsweise, wie man die von Dir aufbereiteten BEV Adressdaten mit bestehenden OSM Adressen abgleicht. In bislang adresslosen Regionen, ist manuelles Sichten zwar zeitaufwendig, aber irgendwie zumindest für eine engagierte lokale OSM Community noch machbar. Bei einem künftigen BEV Adress- Release, wird dies schon wesentlich schwieriger.
Es gäbe zwar die Strategie einfach den jeweiligen BEV Satz zu priorisieren, und sämtliche alte OSM Adressen zu löschen. Und es anschließend so wie JM82 zu machen, Behörden mit Fehlerlisten zu konfrontieren. Die Hoffnung dass beim nächsten BEV Relais solche Korrekturen berücksichtig worden sind mag trügerisch sein.

Eine Strategie wäre Adressen als BEV geprüft zu kennzeichnen. Aktuell mache ich das so, dass ich sofern ich eine BEV Adresse verändere, den Referenz Eintrag zum BEV entferne. Das müsste sich dann aber auch auf die Verortung beziehen. Sobald wir eine BEV Adresse auch nur minimal anderst positionieren, müsste der Verweis auf die BEV Herkunft raus.

Also, Stainz macht´s vor, sämtliche alte OSM Adressen raus, aktuelle BEV Adressen rein. Sofern anschließend “Negrehebs” Leidenschaft neu Positionierung notwendig ist, BEV Verweis jeweils rausnehmen.
Beim nächsten BEV Release, sämtliche verbliebene Alt- BEV Adressen löschen, aktuelle BEV Adressen wieder rein, und anschließend auf Duplikate prüfen. Sofern eine BEV Adresse nun erneut nicht passt, fliegt dann diese raus.

Leider lässt die aktuelle Genauigkeit der BEV Verortung derart zu Wünschen übrig, dass nur wenige BEV Adressen diese Aktion überleben würden. So schaut´s aktuell mit der BEV Verortungs- Qualität aus.
Also nur ein Leider.

So ein quatsch. Warum entfernst du den Referenzeintrag? Dazu unten mehr.

Wie, wer ist jetzt Stainz? Es gehören nicht alte Adressen gelöscht und dann die, mehr oder weniger, gleichen, wieder reingepackt. Das ist NICHT, wie bei OSM gearbeitet werden sollte. Und du brauchst meinen Usernamen nicht in Anführungszeichen setzen und eine Adresse gehört bei OSM nun mal aufs Gebäude und nicht daneben oder auf die Straße. Völlig egal, wo das BEV die verortet.
Und die BEV Info sagt aus, wo die Daten herkommen und das bleibt die BEV. Die Position hat damit nichts zu tun, da hast du leider mal wieder ein Verständnisproblem. Wenn die Lizenz, unter der wir die Daten verwenden dürfen, besagt, dass wir das BEV nennen müssen, hast du damit durchaus ein Lizenzproblem geschaffen, welches geklärt werden muss.

Und wie du sagst, nur weils vom BEV ist, sagt das noch lange nichts über die Qualität davon aus. Da gibts massig Probleme. Genau deswegen wäre ein “BEV geprüft” schwachsinnig. Da wäre noch eher ein “Vor Ort geprüft” sinnvoll.

Zum x-ten Mal: dein Löschen und Import drüberbügeln ist völliger Irrsinn und destruktiv.

Bzgl. Abgleich: ich habe ein Python-Script, das die in OSM vorhandenen Adressen aus einem .osm-File herausfiltern kann. Ursprünglich hatte ich überlegt das evtl. auch noch irgendwie in ein JOSM-Plugin zu übersetzen, aber daraus ist bisher nichts geworden. Ironischerweise hatte ich mir da auch noch Sorgen gemacht, dass die restlichen dann einfach völlig unkontrolliert importiert werden könnten, ich hatte nicht wirklich damit gerechnet, dass du stattdessen einfach alles vorhandene löscht.

Auch die Unterschiede zw. den Stichtagsdaten können wir auswerten, seien es jetzt die kompletten Diffs, oder nur geänderte/neue Straßen etc., denn es bringt sowieso nichts automatisch irgendwelche neuen Adresspositionen zu importieren, wenn dort dann niemand die entsprechenden Straßen, Places, Landuses, Gebäude, POIs, Beschränkungen etc. anlegt.

edit:

Und abgesehen vom grundsätzlich schwachsinnigen Vorgehen - du lest schon, was ich dir im Post direkt davor geschrieben habe?

Natürlich ändern sich die Koordinaten dann im BEV-Datensatz, mit dem wir hier alle arbeiten. Denn diese BEV-Daten basieren ja auf den Daten, die von den Gemeinden gepflegt werden. Ich habe so auf diesem Weg mehrere Hundert bis vielleicht 2000 Adressen in SO korrigieren, richtigstellen lassen und dann eben 1 Jahr später in OSM eingearbeitet, als eine Update vom BEV zur Verfügung gestellt wurde.
Meine Vorgehensweise damals war eben sehr “manuell lastig” - im Grunde jede Adresse auf Plausibilität mal zu prüfen. Wenn der BEV-Node offensichtlich ein Holler ist und war, kam er auf die “schwarze Liste”, welche der jeweiligen Gemeinde zur Prüfung übermittelt worden ist.
Natürlich ist diese Vorgehensweise nicht zu 100% präzise, und es können immer noch Fehler bei den Hausnummern samt derer korrekter Verortung passiert sein. Ein Bsp. wäre nämlich, wenn ein Haus die No. 100 hat (und diese pickt auch auf dem Gebäude drauf), in der Realität/Natura hat es aber die No. 10. Auf solche Fehler kommt man mit meiner Methode natürlich nicht drauf, ausser man hat lokales Wissen und weiß in der Tat, dass es die No. 10 ist. Davon gehe ich aber in den seltensten Fällen aus - bei vielleicht 10 Mappern in AUT, die sich mit Adressen beschäftigen oder beschäftigt haben, kann man kein lokales Wissen erwarten.
Ich betone nochmals die Wichtigkeit, Behörden Fehler in den Adressen anzuzeigen. Denn, nur so werden alle auf Behördendaten basierende Adresszuordnungen a la longue besser; so auch OSM.
Die Variante mit den lokalen Mappern kann man ja praktisch vergessen, da sich zu wenig bis keine lokalen Mapper finden in AUT, die strittige Adressen verifizieren - ich selbst habe das in meiner Heimatgemeinde auch nur punktuell gemacht, meist bei Gebäuden, die mehrere Hausnummern haben.
100% fehlerfrei werden die Daten niemals sein - ich denke an das wird man sich gewöhnen müssen. Jedoch bin ich der Überzeugung, dass man auf etwa 95-98% Korrektheit über ganz AUT gesehen, hinkommen wird - über die Jahre hinweg. Das ist eben ein langfristiges Projekt. Das gute ist ja, dass die Adressen sich - so sie korrekt sind - nicht mehr nachträglich ändern. Der Waldweg 10 bleibt wohl bis in die heiligen Zeiten der Waldweg 10. Ausnahmen dürften auch das bestätigen.

@adresshistory*org: warum ergänzt du addr:suburb vielfach in den Adressen, wo es diese gar nicht gibt? Wie ich feststellen musste, hast du in der Südsteiermark vielfach den Namen der Katastralgemeinde dort reingepackt, obwohl dieser in der Adresse eines Gebäudes gar nicht vorkommt.

EDIT: Tippfehler und Eränzungen

Basierend auf meiner Erfahrung mit Katastralgemeinden, im speziellen mit der Gemeinde Wildschönau, ist das aktuell die einzig funktionierende Vorgangsweise.

Natürlich spielt bei Katastralgemeinden die übergeordnete Zentralgemeinde eine Rolle, deren korrekter Platz ist im Datenfeld addr:city

Funktionierend in welcher Hinsicht? Die Adresssuche funktioniert via Nominatim ja auch ohne diesen Tag - die hat ja andere Probleme wir hinlänglich bekannt ist.

Das mache ich doch nicht absichtlich, ich weis aber nun über welche Möglichkeiten Du verfügst.

Leider liegt vieles in OSM im Dunkeln: wer bist Du du schreibst öfters im Plural, wer ist Negreheb, wer ist auf Talk-at aktiv, wie weit können wir auf eine Unterstützung seitens das BEV zählen, warum bremsen einige User auf Talk, warum zeichnen in OSM professionelle User systematisch unscharfe Gebäudeumrisse, und wie stehen Tile Verwerter wie Mapbox und geofabrik zu diesem Handeln. Warum gibt es eine so geringe Beteiligung bei der Adressergänzung, wer patzt regelmäßig meine Arbeit bei der OSM Data Workling Group an.

Liebe Leute Rätsel über Rätsel.

Du machst offensichtlich gute Arbeit, ich habe aber das Gefühl diese ist nicht zu Ende gedacht. Wir benötigen dringend ergänzend zu Deinen BEV Adresssätzen einen funktionierenden Workflow. Leider habe ich den Eindruck, dass vier von fünf Pferden in unserem Gespann genau das mit aller zur Verfügung stehender Kraft zu verhindern versuchen.

Edit: +Gespann

Eine interessante Frage:
Dürfen wir vom BEV stammende Daten, verändern, und trotztem “Daten stammen vom BEV” weiterhin drauf-schreiben.
In einem Notruf vertauen vielleicht einige OSM speziell wegen der BEV Referenz, wer haftet anschließend für unsere offensichtliche Fälschung?

Noch einmal: OSM ist Redundant. Der Ortsname im Grenzpolygon sowie im Datenfeld addr:city muss daher gleichlautend sein.

Nun meine Frage, wo packst du die Katastralgemeinde rein. Ich kann mich mit der Katastralgemeinde im Datenfeld addr:city nur dann anfreunden, sofern du sämtlichen Katastralgemeinden auch jeweils ihr eigenes Grenz Polygon spendierst. Viel Spaß in der Steiermark bei manchmal 16 Katastralgemeinden je Gemeinde mit jeweils nur 5 Häusern.

Ich habe bisher bei keiner Adresse die Katastralgemeinde als addr:suburb eingetragen, da diese auch so nicht vorkommt.
Entweder, die Katastralgemeinde kommt als addr:place vor (der Klassiker in der Steiermark und wohl sonst auch in ländlichen Gebieten in AUT) und wird dort eingetragen. z.B. Mühldorf 5, 8081 Wildon. Damit ist addr:place = Mühldorf und add:city = Wildon. Soweit klar.

  1. Variante ist, dass diese mit im Straßennamen steht, der als addr:street getaggt wird - das machen unsere burgenländischen Nachbarn seit einigen Jahren so - dort wird systematisch von Ortsnamen in der Adresse weggegangen hin zu Katastralgemeinde + Straßenname. Also z.b. addr:street = Welten, Hauptstraße 5, 8380 Jennersdorf. Damit ist addr:street = Welten, Hauptstraße und addr:city = Jennersdorf.
    Ist eine Adresse z.b. Mühldorf 5 und Mühldorf ist eine Katastralgemeinde von Sankt Veit in der Steiermark, dann addr:place. Gibt es Mühldorf, Hauptstraße 5 > addr:street und die Straße davor heißt so.
    Es hängt aber ganz klar vom BEV-Datensatz ab: in der Regel steht in Ländlichen Gebieten die Katastralgemeinde im Straßennamen und die Hausnummer extra. Das wäre meine 1. Variante oben.

Ich habe grad in der Gemeinde Sankt Veit in der Südsteiermark geschaut: dort hast du flächendeckend als suburb St. Veit am Vogau angegeben und dann als addr:street die jeweilige Straße. Die Adresse lautet aber: Schulstraße 9, 8423 Sankt Veit in der Südsteiermark. Der Zusatz St. Veit am Vogau ist irrelevant und auch nicht offiziell, da es in der Gemeinde Sankt Veit in der Südsteiermark nur eine Schulstraße 9 gibt. Ergo ist es eindeutig. Der Suburb Tag wäre zwar eine zusätzliche Information (schließlich könnte die Schulstraße 9 ja auch in einer anderen Katastralgemeinde liegen), ist aber für die Adresse per se belanglos.

Hallo JM82, Danke für die ausführliche Erklärung. So ist das plausibel. Leider bildest sich das so nicht in Luzandros BEV Sätzen ab. Wir sind dort im Feld addr:city vielfach mit der Katastralgemeinde konfrontiert. Damit ich dieses Datenfeld für den tatsächlichen Gemeindenamen frei bekomme, wandle ich addr:city daher in addr.suburb um, und erstelle ein neues addr:city für den tatsächlichen Gemeindenemn. Das Feld addr:suburb müsste nun weiter nach den von dir genannten Kriterien aufgeräumt werden. Ich frage mich aber warum solches nicht bereits in der Aufbereitung der BEV Adressen durch Luzandro erfolgt. Meine Variante ist daher lediglich eine Verlegenheitslösung, löst die Problematik nicht vollständig, aber immerhin besser als nichts.

In der Gemeinde Wildschönau bin ich mit dem Problem konfrontiert dass es mehrere Dorfstraßen gibt. addr:suburb aber in Nominatim nicht greift. Daher verwende ich dort ergänzend das Format addr:street = Straße, Katastralgemeinde das wird von Nominatim korrekt aufgelöst.

vielleicht könnte man Katastralgemeinden in OSM auch einen spezifischen Tag z.B addr:cadastral-subdivision spendieren.

Edit:+ Beispiel in Wildschönau Ref: https://www.openstreetmap.org/way/133306346

Wie ist das wieder zu verstehen? Das passiert dir so zufällig, du empfiehlst es zwar jetzt regelmäßig so zu machen, aber es ist nicht Absicht?

Das “wir” ist das gleiche, das du dauernd verwendest. Ich habe zumindest einmal angenommen, dass du nicht den Pluralis Majestatis meinst, sondern “wir als OSM-Community”. Gänzlich sicher bin ich mir dabei allerdings auch nicht mehr, denn was bei all deinen Fragen leider immer noch fehlt, ist die eigene Vorgangsweise zu hinterfragen und ob das “regelmäßige Anpatzen” tatsächlich immer völlig unbegründet ist und die Probleme nur von allen anderen ausgehen.

Das Thema addr:city war von Anfang an etwas unbefriedigend, darum habe ich auch mehrfach darauf hingewiesen, man soll darauf achten, ob diese Zuweisung im konkreten Fall passt. Warum sollte es bei diesem Mapping überhaupt irgendwelche Unklarheiten geben? Bei größeren Katastralgemeinden ist es üblich, dass diese in der Anschrift an Stelle der Gemeinde aufscheint, das ist mMn. auch das, was unter addr:city stehen sollte und in etlichen Gemeinden würden ansonsten auch Adressen existieren, die nur mit Gemeinde und Straße nicht mehr eindeutig sind, wobei da die von JM82 angesprochenen noch gar nicht dabei sind, denn die Straße heißt dort tatsächlich “Welten, Hauptstraße” und somit sind in der Gemeinde Sankt Martin an der Raab damit auch alle Adressen eindeutig. In der Gemeinde Großebersdorf dagegen gibt es zB in allen 4 Katastralgemeinden eine Feldgasse.
Ob etwas eine Katastralgemeinde ist, weiß ich rein aus diesem Datensatz im Übrigen gar nicht, denn hier gibt es nur die Unterscheidung zwischen Gemeinde und Ortschaft, was alles sein kann zw. einzelnen Häusern und gesamten Wiener Bezirken - eine simple 1:1 Übertragung der Ortschaft auf einen einzelnen OSM-addr-Tag, der in allen Fällen passt und sinnvoll ist gibt es somit nicht (3 Häuser sind kein addr:suburb - evtl. noch ein addr:hamlet wobei da auch fraglich ist, wie nützlich das ist, das steht dann meistens vermutlich sowieso unter addr:place), die bisherige Logik hat aber sicherlich oftmals einen Blödsinn geliefert, daher werden jetzt die Gemeinden mit mehrdeutigen Straßennamen bestimmt und dort die Ortschaft als addr:city gesetzt, alle anderen erhalten die Gemeinde. Man könnte bei den Mehrdeutigen stattdessen auch ein addr:suburb setzen, aber soweit mir bekannt ist das für solche Ortschaften bei uns bisher unüblich.

Eine andere kleine Änderung, die ich noch vorgenommen habe und die evtl. nicht jedem einzelnen passt: Straßennamen, die auf “str.”/“g.” enden, werden jetzt zu “Straße” und “Gasse” erweitert.

edit: “Gasse” wieder entfernt - kommt nicht oft vor und ist nicht eindeutig genug

Amtlich (ZMR und AGWR-II) entsprechende Straßenbezeichnungen:

Zur Dokumentation habe ich die letzte BEV-Aufbereitung

-Letzte Luzandro Version, noch mit den Amtlich (ZMR und AGWR-II) korrekten Straßenbezeichnungen-

unter http://www.addresshistory.org archiviert.
Direktlink auch in meiner Signatur.

edit: Link in meiner Signatur