Hartmut Holzgraefe (2016-02-04 17:38:03+00:00): "Redundante Daten sorgen für einen nicht zu vernachlässigenden Zuwachs an Datenmenge, der auch aus Sicht des Nutzers nicht erwünscht ist: " 

Jein, redundante Daten nehmen natürlich mehr Platz ein, aber erlauben zum Teil auch deutlich schnellere Abfragen. Stichwort Denormalisierung.

Gerade hier mit unserem doch recht komplexen Relationen-Modell und mit zweidimensionalen Bezügen zwischen Daten.

Wenn ich vom osm2pgsql Schema ausgehe dann kann ich im denormaliserten Fall mit addr_* Tags direkt am Node die Adresse eines Nodes direkt abfragen mit 

  SELECT addr_street, ... FROM plantosm_point WHERE osmid=...

Wären die Daten nur am Gebäude dann bräuchte es statt dessen drei mit UNION verknüpfte Abfragen, einmal die von oben und dann je eine über planetosm_line und planetosm_polygon in der Form

SELECT way.addr_street, ...
FROM planetosm_node node
JOIN planetosm_line way
ON ST_CONTAINS(way.way, node.way)
WHERE node.osmid=...

Und da hast Du noch den Vorteil dass beim osm2pgsql Import alle Relations-Polygone schon passend zusammengefasst worden sind.

Wenn Du eine Anwendung hast die direkt auf den OSM XML oder PBF Rohdaten arbeitet musst Du Dich um den Schritt auch noch kümmern.

Gerade wenn Du direkt Daten zu einer Bounding Box über das OSM API herunterlädst bekommst Du ja erstmal nur einfaches XML. Bei "Adresse am Node" kannst Du da einfach Adressen auswerten indem Du nur über die <node> Tags iterierst und dann die addr_* Attribute direkt Tag für Tag auswertest. Versuch das gleiche mal von Hand wenn Du auch noch die <way> und <relation> Tags mit einbeziehen und erstmal Geometrien dafür aufbauen musst.


"Große Datenmengen müssen z. B. jedesmal durchs Netz nach einem Aufruf mit dem Browser, was die Ladezeiten spürbar verlängert. Desweiteren wird mehr als unbedingt erforderlich Speicherplatz auf dem Nutzer-Gerät belegt,"

Das ist dann Aufgabe der Serverseite das passend vorzubearbeiten und nur das nötigste zur Clientseite zu schicken.

" was zu erhöhten Berechnungszeiten und Stromverbrauch führt (durchaus relevant für Smartphone/Tablet-Nutzer; Umwelt-Aspekt)."

Die erhöhten Berechnungszeiten hast Du gerade durch ein normalisiertes Datenmodell, denormalisiert brauchst Du zwar mehr Speicher aber sparst beim Recehnaufwand (mal abgesehen davon dass der eh nicht auf der Clientseite passieren sollte)

Du kannst schwer davon ausgehen dass zB. in dem Datenmodell von OsmAnd auch denormalisiert wird (allerdings werden dort doppelte Werte vermutlich nicht doppelt vorgehalten sondern es wird darauf passend verzeigert. Da das ein in-memory Datenmodell ist hat man die Option da ja)

"Im Übrigen hat redundante Datenhaltung ein nicht unerhebliches Fehlerpotential, da sicherlich im Laufe der Zeit Inkonsistenzen auftreteten, insbesondere durch Nutzer die meinen etwas Gutes zu tun"

Jein, ich denke der Fall "User macht Relation kaputt, oder übersieht dass ein Gebäude tatsächlich als Relation erfasst ist und sieht die daran erfassten Adressdaten nicht einmal" leider häufiger ist als "User hat einem POI node innerhalb eines Gebäudes eine andere Adresse verpasst als dem Gebäude"

Auch haben wir schon Fälle gehabt wo Gebäude verschoben oder aus neueren Luftbildern neu erfasst wurden und dabei dazu gehörende POI Nodes einfach nicht mitverschoben wurden. Bei denen die eine Adresse hinterlegt hatten war das leicht zu reparieren wenn man auf so einen Fall gestoßen ist. Bei denen ohne eigene Adresse war die Zuordnung dagegen zum Teil nicht mehr klar.


Und im Prinzip wäre das ja auch vernünftig auswertbar, ein Tool wie Osmose könnte Meckern wenn innerhalb eines Gebäudes POIs mit abweichender Adresse vorhanden sind.

Es ist nur die aktuelle Implementation des Osmose "Doppelte Hausnummer" Checks die das Thema so unangenehm macht.