Hallo Wolfgang Du bist ein Profi, das merkt man. Wenn es nur nicht jeweils regionale Besonderheiten gäbe.
Damit Einzelpersonen ihre Inhalte einbringen können, wurde OSM als redundantes System konzipiert. das ist nun einfach so. Auch wenn Du findest dass das unschön ist, OSM ist eine Ansammlung doppelter und mehrfacher Daten. Das bedeutet für mich, dass wir im Extremfall -wie mir Wiener Wohnen erklärt hat, 200.000 Wohnungen- als redundante Daten Mappen sollten. Das wird uns aber wohl nicht gelingen. Aber wir sind in der Lage, sämtliche Treppenhäuser von Wiener Wohnen in OSM abzubilden. Dazu gehört je Treppenhaus der vollständige Adress- Satz. Also die Baisisadresse laut Wiener Wohnen, die Hausnummer, und die Türe. Damit man das auch noch findet, und das mit der von der Post verlangten Anschrift kompatibel ist, gibt es die Variante Hausnummer/Türe Beispieldatensatz: Roterdstraße 12/7 addr:city=Wien addr:country=AT addr:housenumber=12/7 addr:postcode=1160 addr:street=Roterdstraße Adress Unit https://i.imgur.com/yMQCTl5.png wird bislang in Wien eher wenig verwendet, und stiftet daher bislang auch nur Verwirrung. LG aus St. Johann in Tirol, meine primäre Mapping Region: https://youtu.be/uKO5M1wwXTchttp://hdyc.neis-one.org/?wikithemap micromapping mapping exempel:https://www.openstreetmap.org/#map=19/47.52588/12.39863 Am 18. Februar 2018 um 21:24 schrieb wolfbert <osm...@posteo.de>: > Johann, das ist exakt, worauf ich in meinem vorigen Post hinaus wollte: es > ist ** irrelevant ** was die Adress-Suche liefert, das ist ein Problem von > Nominatim (es würde schon reichen, wenn es zusätzlich zur Allerweltssuche > eine strukturierte Maske nebst Indizes gäbe, dann wäre das alles kein > Thema). > > > > Unsere Aufgabe ist es, die Daten möglichst strukturiert und auswertbar > bereit zu stellen. Befindet sich auf einem Punkt address:unit, dann kann > man zur Suche z.B. wie folgt vorgehen (hierarchisch vom Spezifischen zum > Allgemeineren, und in Kombination; gemappt wird umgekehrt): > > > > · (Prio 3) Man beachte die weiteren Adressdaten auf diesem Punkt, > > · (Prio 2) die Adressdaten des Gebäudes auf dem Umriss, > > · (Prio 1) die Adressdaten in Relationen und umgebenden > Polygonen, (-> Anlage) > > · (Prio 4) an nahen Adresspunkten innerhalb des Umrisses, > > · (Prio 5) ev. noch interpolierte Adressen / anliegende Straßen, > > · ev. Ergänzung noch fehlender Bestandteile (z.B. aus > PLZ-Relationen, nahen Straßen, etc.) > > > > Lautet die Hausnummer auf „*/*“ dann legt man addr:unit eben implizit an. > > Wenn das alles noch nicht reicht, und es tatsächlich zwei Adressen auf > gleicher Ebene gibt, dann bliebe noch Friederichs Vorschlag mit den > Identadressen. In der Suche können alle diese Adresskombinationen gefunden > werden. > > > > Zur Veranschaulichung siehe z.B. die Adresse Vorgartenstraße 158-170/11 ( > https://osm.org/go/0JrJmG1KX) > > Mit obigem Verfahren ergibt sich: > > > > · Vorgartenstraße 158-170/11 (die offizielle Adresse) > > · Vorgartenstraße 164/11 (alternativ/halb-offiziell und genauer > für den Zusteller) > > · Jungstraße 9/11 (auch damit kommt man hin) > > > > Was mich dazu bringt, dass komplexe Anlagen mit Ortskenntnis und manuell > modelliert werden sollten, und nach einem Schema (das aber verschiedene > Wege zulässt). Überspezifikation (also z.B. komplette Adresse auf allen > Stiegen) ist unschön, aber kein Hindernis (der Renderer z.B. hat es aber > ungleich schwerer, weil er ermitteln müsste, was denn nun die „gemeinsame“ > Adresse ist, um dann die redundanten Bestandteile weg zu lassen – in obigem > Beispiel gibt es 158-170 ja auch mehrfach, weil die Anlage implizit in der > gemeinsamen Hausnummer steckt). > > > > So, das wurde wieder viel zu lang, LG > > Wolfgang > > > > > > _______________________________________________ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at > > -- Elektronikermeister Johann Haag Innsbruckerstraße 42 6380 St. Johann in Tirol ÖSTERREICH Tel: +43 664/174 7414 Mailto:johannh...@hxg.at
_______________________________________________ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
