On 15.02.2018 21:16, Robert Kaiser wrote:
man muss (leider) zu jeder addr:unit-Node die vollständige Adresse mit allen Feldern dazu mappen, denn die OSM-Datenbank ist nicht wirklich dafür gebaut, zu erkennen, dass Tags von anderen Elementen auf diese Node zutreffen könnten.
OSM ist nicht mal eine richtige Datenbank, sondern ein Datenbestand. Sogar schon ein DBMS wie PostGIS stellt Funktionen zur Verfügung, mit denen sich ermitteln lässt, ob ein Objekt innerhalb von einem anderen liegt. Die Attribute eines Gebäudes den Nodes im Gebäude zu vererben ist damit genauso eine triviale Aufgabe wie die Postleitzahlen einer boundary=postal_code an die Objekte in dem Gebiet zu vererben.
Wenn du auf einen Eingang sowohl addr:housenumber als auch addr:unit setzt, wird nur eines davon gerendert. Damit wird dein in <[email protected]> geäußerter Wunsch nicht erfüllt. Nur wenn du die Hausnummer aufs Gebäude und die Stiegennummer auf die Stiege (oder den Eingang zur Stiege) setzt, werden beide Nummern gerendert.
OSM ist nicht für "saubere" Datenbankstrukturen gebaut, sondern für einfache Strukturen mit wenigen Abhängigkeiten und dafür absichtlich eher viel Redundanz - nicht ganz ideal für's Mappen, aber relativ gut zum Abfragen von Daten, da man komplexe Verschachtelungen von Flächen und Relationen oft komplett ignorieren kann, wenn man Anwendungen (inkl. Renderer) schreibt.
Vom Satzanfang bis zu den wenigen Abhängigkeiten stimme ich dir zu. Steve Coast hat OSM bewusst mit simplen Tag-Value-Paaren erschaffen, damit das Mappen leicht fällt. Viel Redundanz war aber keine Absicht, sondern eine unerfreuliche Folge. Die Daten mit einem Einzeiler auswerten zu können, war in der Anfangszeit von OSM ein Vorteil, aber heute wär ein relationales, normalisiertes Datenmodell zweckmäßiger. Mit dem, was in OSM "Relationen" genannt wird, wurde ein Schritt in diese Richtung gesetzt, doch es wird aus einem Walross nie ein Tiger werden.
-- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria _______________________________________________ Talk-at mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-at
