Hallo, Am Freitag, 20. April 2012 02:20:24 schrieb Christian Müller: > Moin, > > ich mag in diesem Zusammenhang noch einmal kurz auf das Thema > Flächennetzwerk zurückzukommen. > Have a fun read..
Da hast du dir ja richtig Arbeit gemacht ;-) > > Am 19.04.2012 13:05, schrieb Wolfgang: > > -1 Das Multipolygon sollte rein Fläche bleiben, und Fläche sollte > > nur im Multipolygon erfasst werden. Wer was dazu "sammeln" will, > > kann das über eine site verbinden. Wieder das Thema Relationen > > verbiegen. > > Damit würdest Du z.B. sämtliche Parks als type=site Relationen > erfassen, in denen Du dann die MP der Einzelflächen sammelst. Aber > was ist überhaupt eine Einzelfläche? Ich glaube, an dieser Stelle missverstanden zu sein. Solange es nur um zusammengehörige Flächen gleichen Typs geht, reicht das Multipolygon völlig aus. Ich will nicht Multipolygone durch Sites ersetzen, sondern verhindern, dass - das Multipolygon mit Elementen verwässert wird, die mit der Fläche nichts zu tun haben (place etc) und - die Flächenberechnung / Darstellung im Multipolygon konzentrieren (wenn sie komplizierter ist als ein einfacher Umring) > > Betrachten wir beispielsweise einen Schlosspark bestehend aus > mehreren Teichen, Rabatten, Wiesen, etc. die im Park verteilt sind - > das Schloss selbst steht auf einem Sockel im Zentrum des Parks. > > 1. MP - Teiche > 2. MP - Rabatten > 3. MP - Wiesen > 4. MP - Sockel > 5. MP - Schloss 6. Schlosspark-Verwaltung Wenn du das Schloss (mit Sockel :-) ) als nicht zum Schlosspark zugehöriig betrachtest, brauchst du in der Tat ein Multipolygon für den Park mit inner = Schlosssockel. Die Seen, Wiesen etc würde ich als zum Schlosspark zugehörig ansehen und nicht aus der Parkfläche ausschließen wollen. Die Seen werden natürlich extra gemappt und erhalten wegen der Inseln ein Multipolygon, wobei ein Multipolygon für alle Seen reicht. Da die ganze Fläche außer dem Schloss zum Schlosspark gehört, ist für den Renderer auch klar, dass die Inseln ebenfalls leisure=park zu rendern sind. Verwaltungsmäßig gehören sie sowieso zum Schlosspark. Die Seefläche wird nicht als Loch im Park definiert, weil sie 1. zum Park gehört und 2. üblicherweise der Renderer damit klar kommt, die Wasserfläche hat insofern Vorrang. Für das Schloss würde mir eine einfaches Polygon mit building=castle/yes reichen. Beim Sockel kommt es drauf an, wie der aussieht. Das könnte ein building=sockel (?) sein. In dem Falle bekäme das Schloss dann den layer=1, denn es liegt ja tatsächlich auf dem Sockel. Jetzt haben wir ein Multipolygon für den Schlosspark, eins für die Seen, jeweils ein Polygon für den Sockel und das Schloss. Einzelheiten des Parks wie Rabatte etc erhalten einfache Polygone. Es ist eine reine Frage der Logig, dass sie, wenn gewünscht, "über" dem Park gerendert werden. Dass sie zum Park gehören, muss ggf. aus der Lage ermittelt werden. Wenn jemand eine Statistik aller Rosenbeete in den Schlossparks des Landes erstellen will, dann muss er eben abfragen, welche Beete sich räumlich in einem solchen Park befinden. Für die Verwaltung kommt eine Site hinzu, name = "Staatliche Verwaltung der Beispielhaften Gärten, Schlösser und Seen", Members sind der Schlosspark, das Schloss und weitere Anlagen, die zu der Verwaltung gehören, sowie ggf. das Verwaltungsgebäude, das vermutlich in der Landeshauptstadt des Beispielhaften Freistaates steht. :-) [...] > > Leider sind verschachtelte MP-Relationen (nestedMP) unpraktikabel, > wenn es um die Berechnung der Fläche geht, die sich aus den > Einzelflächen der Kinder und Kindeskinder (..) ergibt. Schließlich > sind nur die outer/inner Mitglieder der Kinder und Kindeskinder (..) > interessant, die tatsächlich einen Beitrag zu Außen- oder > Innenringen des nestedMP liefern. Ab einer bestimmten > Schachtelungstiefe wird die > Grenzbestimmung daher unbeherrschbar - um die Flächengrenze eines > nestedMP zu ermitteln, müssten alle Blätter des MP-Baumes durchsucht > werden, also alle Relationen, die dann tatsächlich way-members als > Mitglieder haben und nicht selbst ein nestedMP sind. Je tiefer > dieser Baum, desto höher die Wahrscheinlichkeit, dass es mehr > irrelevante members als relevante gibt. So ganz kann ich deinen Ausführungen nicht folgen. Im Prinzip ist das Multipolygon überraschend einfach zu berechnen und gleichzeitig geschickt aufgebaut. Regel 1: Jeder Umring kann aus einer beliebigen Anzahl von Polygonen bestehen, dabei müssen Anfangs- und Endpunkte auf einander folgender Polygone identisch sein und der Umring als Ganzes ein geschlossenes Polygon ergeben Regel 2: Alle geschlossenen Polygone (Umringe), die innnerhalb eines geschlossenen Polygons liegen, bilden ein "Loch" in diesem, sie dürfen das äußere Polygon nicht berühren. Regel 3: Die Umringe werden geschachtelt und liegen in beliebiger Tiefe ineinander. Inner und Outer können, müssen aber nicht angegeben werden. Sie dienen der Übersicht des Mappers und können zur Fehlerkontrolle benutzt werden. Regel 4: Die Eigenschaften des Multipolygons beziehen sich auf alle Polygone einer ungeraden Schachtelungstiefe. Die Umringe der geraden Schachtelungstiefen sind Löcher. Das heißt auch, dass nur die Umringe als Typ "outer" definiert werden dürfen, die tatsächlich vom Typ des Multipolygons sind. Beispiel dazu: Geschlossenes Korallenatoll mit Lagune und Vulkaninsel. Das Multipolygon vom typ "Koralleninsel" hat als Outer den Umring des Atolls, als Inner den Umring der Lagune. Der Umring der Vulkaninsel wird hier nicht reingesetzt, weil er "outer" wäre und nicht vom Typ "Koralleninsel" ist. Er gehört aber als "inner" in das MP der Lagune. > > Bsp.: Kreisgrenzen und Landesgrenze - es gäbe 'zig innenliegende > Kreisgrenzen, die für die Berechnung der Landesgrenze nicht relevant > sind - deshalb macht es für die Berechnung der Grenzgeometrie keinen > Sinn, die Landesgrenze über ein nestedMP mit allen > Kreisgrenz-Relationen als Mitglieder zu erfassen. Dennoch > interessiert evtl. der Flächenbezug der Kreisflächen zur > Landesflächen in einem anderen Kontext. Beide Wünsche ließen sich > vereinen. Für Grenzen bietet sich das Multipolygon an - nicht um irgendwelche "inner" zu definieren, sondern weil es möglich ist, das "outer" aus einer größeren Anzahl von (nicht geschlossenen) Polygonen zu definieren, die zusammen einen geschlossenen Umring ergeben. Ähnlich wie bei der coastline hat es gewisse Vorteile, nicht immer den ganzen Umring der z.B. USA laden zu müssen. Die Landesgrenze ist ein MP, die Kreisgenzen jeweils auch. Wer die Hauptstadt, Verwaltungszentrale oder was auch immer da rein bringen will, kann das dann über die Site machen. Members sind dann das Multipolygon mit der Grenze und der place-Node der Zentrale. Land und Kreise untereinander brauchen keine weitere Relation, da sich ihre Zusammengehörigkeit aus der Lage ergibt, im Gegensatz zur Zentrale einer Grenze. Da die Grenze in der Regel eine Vielzahl von places umschließt, kann hier nicht gefolgert werden, welcher place als Hauptort gemeint ist. > > > > Um auf das Beispiel zurückzukommen: Ich kann mir auch den gesamten > Park als Einzelfläche vorstellen, ohne die Grenzen der Rabatten, > Teiche, Wiesen, etc. Weil ich das kann, möchte ich den Park auch > als type=multipolygon anlegen und nicht als type=site (Anm.: > type=site entspräche einem nestedMP, wenn man daraus die Geometrie > der Gesamtfläche des Parks ermitteln will). Wenn ich dich richtig verstehe, willst du für jede kleine Enzelfläche ein MP anlegen. Wie oben beschrieben, ist das nicht notwendig. Um das nochmal klar zu stellen: es gibt eine vereinfachte Flächendarstellung mit verschiedenen tags (building=*, natural=water, landuse=*, ...). Solange das nur ein ganz einfaches geschlossenes Polygon ist, würde ich immer das benutzen. Sobald aber kompliziertere Gebilde auftreten, die entweder Löcher haben oder/und durch mehrere zusammenhängende Abschnitte sinnvollerweise definiert sind, sollte nur das Multipolygon für die Fläche genutzt werden. Nicht-Flächen-Elemente werden dann per Site dazugesetzt. Gruß, Wolfgang _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de