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
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.
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.
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.
Im ZMR steht tatsächlich:
Straße: Haupstraße
Hausnummer: 42
Im Feld Tür oder Top: Wohnhaus (rechtes Haus)
PLZ: 9999
Ort: Amtshausen
Die Anschrift in Amtlichen Schreiben:
Fritz Lustig
Haupstraße 42/Wohnhaus (rechtes Haus)
9999 Amtshausen
OSM Nominatim wertet leider Unit oder Top nicht aus
Folgende Formatierung wird hingegen von Nominatim anerkannt
Straße: Haupstraße
Hausnummer: 42/Wohnhaus (rechtes Haus)
unit: Wohnhaus (rechtes Haus)
PLZ: 9999
Ort: Amtshausen
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 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.
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.
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.
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.