Am 20. April 2012 14:01 schrieb Christian Müller <[email protected]>: > Am 20.04.2012 03:14, schrieb Martin Koppenhoefer: >> Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als >> auch für die zukünftige Pflege bei Daten im Vergleich zu einer >> site-relation als bunte Mischung aller möglichen Elemente und >> Bestandteile ist ein schlichtes Polygon, das die Gesamtfläche >> beschreibt. > Das sie implizit durch mehrfach als Ringelemente verwendete ways vorhanden > ist, war mir klar - das ist aber dennoch nicht das gleiche.
+1 > Sammelvariante: > Eine Anfrage nach den Teichgeometrien innerhalb des Schlossparks ist > durch lookup in die Relation zu lösen. > Boundary-Only-Variante: (also nur die outers des Schlossparks) > Man benutzt die Grenze des Schlossparks zum Verschneiden und sucht sich > in den verbleibenden Daten die Teiche raus. genau, funktioniert immer, sofern die Grenzen aussen geschlossen ist, erfordert keine Relationen, und findet alle Elemente, nicht nur die, die ein Mapper eingetragen hat. Ausserdem sind Datenbanken mit Geofunktionen u.a. genau für Anfragen dieser Art optimiert. > Bezogen auf einen kleineren Park ist der Aufwand für beide Varianten sicher > vernachlässigbar. Für ein größeres Gebiet ergeben sich mit der > Sammelvariante aber Vorteile - da man nicht verschneiden muss. da man einer händisch erstellten und von zig Mappern (davon die überwiegende Menge keine Experten, manche auch Anfänger oder Wenigmapper, manche arbeiten auch mit Tools ohne Unterstützung für alle Relationen, d.h. sie sehen evtl. nicht einmal in ihrem Editor, dass ein Objekt, das sie bearbeiten evtl. Teil einer site-Relation ist, oder sie halten nichts von Site-Relationen und fügen ein Objekt das sie erstellen absichtlich nicht dazu, etc.) weiterbearbeiteten Relation sowieso nicht wirklich trauen kann, würde ich selbst wenn es die Relation gibt mich lieber auf die geographischen Gegebenheiten verlassen, als auf die Relationenzugehörigkeit einer site-Relation. > Es gibt natürlich auch Probleme: > z.B. könnten die Relationen schlecht gepflegt sein und man erwischt nicht > alle Ergebnisse, die man mit einem Verschnitt erhalten hätte. +1, s.o. > Andererseits > könnte ein Verschnitt sehr komplex werden - wenn das MP aus mehreren > Einzelflächen besteht, also mehrere Verschnitte berücksichtigt werden > müssen. dann werden die eben der Reihe nach abgearbeitet. Davon bekommst Du normalerweise gar nichts mit, die DB spuckt das Ergebnis aus und fertig. > Mir ging es darum, aufzuzeigen, dass egal wie man das Kind nennt - > type=collection, type=site, type=multipolygon - im Endeffekt über den > Flächenbezug gesprochen wird. -1, multipolygon unterscheidet sich hier von site und collection dadurch, dass es nur eine Fläche definiert, während die anderen eine Gruppe definieren, die nicht notwendigerweise räumlichen Bezug haben muss. Z.B. könnte man einer site-Relation ein Ticket-Office zuordnen, das ausserhalb der site liegt. Eine "collection" (und auch eine "site") kann alles enthalten, nodes, ways, Flächen, Relationen. Theoretisch müsste eine Relation überhaupt keine Geometrie haben und könnte trotzdem Sinn machen (weil sie als member in einer anderen Relation sitzt. So was haben wir bisher allerdings nicht oder kaum in der db, und ist auch mit unseren (Editier-)Mitteln eher schwer in Schuss zu halten). > Ich habe jetzt nicht nachgeschaut, aber ich > schätze Du findest Sammelrelationen aller Kreisgrenzen pro Bundesland - sie > bilden genau das ab, was auch ein nestedMP abbilden würde. das hoffe ich nicht, wäre ja komplett überflüssiger Ballast, ich denke aber, dass es üblicherweise auch nicht so ist. > Erhält ein Datenverwerter (e.g. renderer) diese MP, überlappen die Flächen > nun - entweder der Schlosspark wird als monotone Fläche opaque über die > Einzelflächen gezeichnet, oder darunter. Für einfache Sachen (etwa > "buildings on top of landuses") kriegt ein Renderer das per Regel hin, ob > das aber für jeden denkbaren Fall von (sinnvoller) Verschachtelung der Fall > ist? hast Du Dich schonmal mit den Render-Regeln von Mapnik auseinandergesetzt? Da spielt es bei den Flächen kaum eine Rolle, wie die getaggt sind, die sortiert er nach Größe (innerhalb desselben Layers, nicht alle Flächen sind in einem Layer). Es gibt aber auch überhaupt keinen Grund, Flächen grundsätzlich gefüllt darzustellen, manches macht als Grenze mehr Sinn. Wie gerendert wird, hat mit der Dateneingabe also dem Modell, wie die Welt in der DB abgebildet wird, nicht so viel zu tun. > Je nachdem, welches Thema ein Renderer hat, müssen nicht alle Sichten auf > diese Einzelfläche dargestellt werden. Wären Flächenlinks innerhalb der > Relation vorhanden, könnte ein Datenverwerter allerdings durch die schiere > Anwesenheit von Flächenlink-Mitgliedern erkennen, ob mehr Detail vorhanden > ist. mehr Detail von was? Dein Vorschlag zielt darauf hinaus, alles was sowieso schon über räumliche Bezüge verbunden ist, nochmal mit site- und collection-Relationen zu verbinden, im Endeffekt die komplette Datenbank von OSM ( -->site name=Earth), und alle denkbaren Verknüpfungen und Bezüge die vielleicht jemanden interessieren könnten schonmal vorab in Relationen anzulegen. (Dein Schloss könnte z.B. auch in einer Site "Schloß Rotzingen und Umgebung" stecken, oder "Ausflugsziele um Hintertupfingen"? und vielleicht will man da auch noch Eisdielen mit drin haben?). > Stellen wir uns stattdessen vor, dass wir gern die Anzahl aller Parks > innerhalb D, die mindestens x Teiche haben (x=0,1,2,3,...), wüssten. > Overpass holt uns alle leisure=park MPs - hätten wir (geometrisch nicht > relevante) Flächenlinks in diesen MP, wäre der nächste Schritt eine einfache > Iteration ohne geometrische Berechnungen. s.o. Stell Dir vor, jemand hat nicht nur die Teiche sondern auch die Mülleimer, die Bäume und größere Steine gemappt, und in die Site-Relation gepappt. Diese site-Relationen werden je nach Detailgrad immer größer und die Wahrscheinlichkeit, dass jemand da versehentlich was rauslöscht oder nicht einfügt ist riesig (d.h. man kann sich sowieso nicht auf das Ergebnis verlassen, selbst wenn die Teiche und Schlossparks in OSM drin sind). Sobald man da was ändert, z.B. einen Member splittet, müssen alle die eine Datenkopie aktualisieren wieder die komplette Relation in ihrer Kopie einspielen, ... > Implizit geht es auch, aber es > ist um ein vielfaches aufwändiger - alle Daten jeder bbox für jedes > leisure=park MP müssen geholt, verschnitten und auf Inklusion geprüft > werden. Das wäre der Unterschied zwischen beiden Varianten.. genau. Letzteres macht die DB automatisch (sie ist räumlich organisiert und daher optimiert für solche Anfragen), ersteres scheitert am Problem, dass es nur funktioniert, wenn alle Mapper perfekte Daten produzieren (d.h. die Site-Relation immer auf aktuellem Stand ist und es keine Teile gibt, die drin sein sollten aber nicht sind). Zusätzlich produziert ersteres einen riesigen Overhead und funktioniert nur für Dinge, die ein Mapper per Relation als zusammengehörig definiert hat. Da man die Welt unter unendlich vielen Gesichtspunkten betrachten kann, könnte man auch unendlich viele solcher Sammelrelationen anlegen. Ein ziemlich ähnliches Thema: http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Gruß Martin _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
