Changeset: 36710953
(no comment)
Closed by OSMiumOxid
Tags
created_by | Vespucci 0.9.7.1.1085 |
---|
Discussion
-
Comment from Hartmut Holzgraefe
Hier sind jetzt alle Geschäfte (Sparkasse, Friseur, Bäcker, Fahrradladen) doppelt?
-
Comment from OSMiumOxid
Hallo.
Selbstverständlich nicht, da jedoch wegen der doppelten Hausnummern (Osmose: Multiple Numbers...) die POI-Symbole nicht angezeigt werden (mir wurde berichtet, daß man sich im Forum darauf geeinigt hat diese Fehlermeldung in kauf zunehmen), habe ich jeweils einen zusätzlichen node hinzugefügt, um das entsprechende Symbol zur Anzeige zu bringen. Das scheint aber Verwirrungen auszulösen, weshalb ich besagte nodes möglicherweise wieder entfernen werde.
mfg -
Comment from OSMiumOxid
PS: Das die POI-Symbole im Editor "Vespucci" bei "Osmose: Multiple Numbers" nich angezeigt werden könnte aber auch ein bug in "Vespucci" sein. Im browser werden sie offenbar angezeigt, weswegen die Symbole tatsächlich doppelt erscheinen.
-
Comment from Hartmut Holzgraefe
Mehrfache Hausnummern gibt es eigentlich nur wenn es keine Renderregel für die konkrete POI-Art gibt. "Zeige die Hausnummer" ist dann die letzte Regel die greift wenn vorher keine passende gefunden wurde.
Und die Osmose "Multiple Numbers / Multiple Address" Meldungen sind eh die Pest, diese spezielle Testregel in Osmose ist meiner Meinung nach in der bisherigen Form unbrauchbar.
Jetzt haben wir aber die POI Symbole *vor* den Gebäuden obwohl die Geschäfte eigentlich *in* den Gebäuden sind?
Und die Sparkasse immer noch doppelt ...
-
Comment from OSMiumOxid
Danke für die Hinweise.
In diesem konkreten Fall haben sowohl die buildings als auch die POI's Hausnummern als Eigenschaft, was die Fehlermeldung hervorruft. Da die Hausnummern ja schon Eigenschaften der jeweiligen Gebäude sind (genaugenommen eigentlich der jeweiligen Grundstücke), ist es nicht dann logisch auf die angabe der Hausnummer im dazugehörigem POI zu. verzichten, um die Osmose-Fehlermeldung zu vermeiden, die ja eigentlich Sinn macht, da einem Haus (Grundstück) eben nur eine Hausnummer zugewiesen wurde?
Das man die Hausnummer im POI einträgt macht sicherlich Sinn bei größeren Geschäftsgebäuden (auch mit Wohneinheiten), in de -
Comment from OSMiumOxid
...in denen mehrere Pächter ihre Ladenlokale bzw. Geschäftsstellen haben.
-
Comment from Hartmut Holzgraefe
Aus Datenbanker-Sicht wäre es natürlich Wünschenswert Redundanzen zu vermeiden.
Andererseits ist es nicht trivial herauszufinden in welchem Gebäudeumriss ein POI liegt, insbesondere wenn das Gebäude selbst als Relation erfasst ist.
Deshalb ist es mMn. OK die Adressdaten noch einmal in Kopie am POI, und somit im direkten Zugriff zu haben.
Osmose sollte vielmehr seine "doppelte Adresse" Auswertung auf building=* und reine Adress-Nodes beschränken und offensichtliche POI-Nodes wie shop=* ignorieren.
-
Comment from OSMiumOxid
Redundante Daten sorgen für einen nicht zu vernachlässigenden Zuwachs an Datenmenge, der auch aus Sicht des Nutzers nicht erwünscht ist: 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, was zu erhöhten Berechnungszeiten und Stromverbrauch führt (durchaus relevant für Smartphone/Tablet-Nutzer; Umwelt-Aspekt).
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 (ich zeige da auch mit drei Fingern auf mich selbst), indem sie in Anwendung ihrer eigenen Logik Änderungen am Datenbestand vornehmen. -
Comment from Hartmut Holzgraefe
"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.
-
Comment from Hartmut Holzgraefe
(hm, die Kommentarfunktion mag keine extra Leerzeichen als Absatztrenner ... :(
-
Comment from OSMiumOxid
Zunächst vielen Dank für die erfreulich ausführliche Antwort!
"Gerade hier mit unserem doch recht komplexen Relationen-Modell und mit zweidimensionalen Bezügen zwischen Daten..."
"...Wären die Daten nur am Gebäude dann bräuchte es statt dessen drei mit UNION verknüpfte Abfragen, ..."
Meine überlegungen gingen ungefähr in diese Richtung: So habe ich versucht, mittels (hierarchischer) Relation das Adress-Tag des Gebäudes an das POI-node gewissermaßen zu "vererben", was aber nicht funktionierte und zu neuen Fehlern führte. Das Verebungs-Konzept der Objektorienterten Programmierung mit ihren Hierarchien auf eine komplexe Datenbank übetragen zu wollen ist vermutlich weder zweckmäßig noch effektiv (Zugegeben: Da habe ich vermutlich Äpfel mit Birnen verglichen.^^). Wenn jedoch in einer Relation identische Daten "verzeigert" werden bzw. von mehreren stellen aus auf ein einzelnes Datum, heißt daß dann nicht auch zwangsläufig, daß redundante Werte durch den Algorithmus entfernt werden (können)?
Das Relationen-Konzept interessiert mich zur Zeit besonders. Gibt es dazu vielleicht weiterführende Seiten (wiki)?"Gerade wenn Du direkt Daten zu einer Bounding Box über das OSM API herunterlädst bekommst Du ja erstmal nur einfaches XML."
Ich vermute, daß meine Editor-Applikation (Ich mag diese neumodische Abkürzung nicht) genau das macht: Auschnittweise Rohdaten herunterladen, um sie nach der Bearbeitung wieder auf den Server zu laden.
Das Bearbeiten ist übrigens garnicht so einfach auf dem winzigen smartphone-display; nicht gerade effizient, und man muß aufpassen, daß man den editor verriegelt bevor man die map verschiebt."...leider häufiger ist als "User hat einem POI node innerhalb eines Gebäudes eine andere Adresse verpasst als dem Gebäude"..."
Das ist mir bei der Bearbeitung eines POI passiert, welches außerhalb eines zugeordneten Gebäudes angeordnet war. Mir wurde dann empfohlen, den POI-node mit den vorhandenen Daten neu zu erstellen und den verhunzten node zu löschen. Nun befindet sich derselbe POI-node innerhalb des Gebäudes.mfg
Nodes (3)
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |