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 
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 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.
+1
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
edit: detail
dann eben
unit=Werkstatt
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 
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.
