Moin,
ich mag in diesem Zusammenhang noch einmal kurz auf das Thema
Flächennetzwerk zurückzukommen.
Have a fun read..
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?
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
Die ersten drei MP werden Löcher haben (alles mit ways in der Rolle
"inner" machbar). Kommen wir zum Park, wir erstellen unsere type=site
Relation, packen die ersten drei MP hinein und stellen uns dann die
durchaus interessante Frage, ob das Schloss zum Schlosspark gehört, es
demnach ebenfalls mit in die Sammelrelation aufgenommen werden sollte.
Bevor wir diese Frage beantworten, stellen wir aber fest, dass mehrere
der Teiche kleinere Inseln haben, wir splitten also die Teiche in
1.a. MP - Wasserflächen
1.b. MP - Inseln
Man beachte, dass die Löcher lt. MP-Definition nicht zur Fläche gehören,
also ist (1.a.) nicht das gleiche wie (1.). Nach deiner Einschätzung
legen wir also (1.) neu an, als type=site Relation
(1.neu.) type=site - name=Teiche
Möchten wir nun unseren Park zusammenbauen, können wir das auf zwei
Arten tun:
type=site Mitglieder:
MPs (1.a.) (1.b.) (2.) (3.) ...
type=site Mitglieder:
(1.neu.) + MPs (2.) (3.) ...
Ich tendiere zu letzterer Variante, allerdings enthielte type=site dann
eine Relation vom gleichen Typ. Wir beschäftigen uns also mit
verschachtelten type=site Relationen.
Das wir den Namen von type=multipolygon auf type=site ändern,
verschleiert IMHO nur die Tatsache, dass auch Flächensammlungen nichts
anderes sind als Flächen. Das geht übrigens schon aus der einfachen,
bisherigen Definition von MP hervor. Betrachten wir z.B. das zweite MP
des imaginären Schlossparks - die Rabatten. Schon dieses kann eine
(Einzel-)Flächensammlung sein - je nachdem, wieviele Rabatten der Park
hat. Die momentane Definition von Multipolygonen erlaubt es uns also,
mehrere Flächen zusammenzufassen, solange sie gleichen Typs sind,
sprich, solange der Mapper sie als zusammengehörig empfindet und sie mit
den gleichen Tags beschreiben kann.
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.
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.
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). Um mit der bestehenden
Definition von MP zu arbeiten, würde ich also alle relevanten Mitglieder
aus (1.) (2.) (3.) und evtl. (4.) und (5.), je nachdem ob das Schloss
zum Schlosspark gehört oder nicht, ermitteln und diese in ein neues MP
6. MP - Schlosspark
übertragen. Das geschieht händisch, nach Ermessen des Mappenden. Der
einzige explizite Zusammenhang in OSMs Daten zwischen Schlosspark und
zugehörigen Teilen (Wiesen, Teichen, Rabatten, etc.) wäre dann über die
Flächengrenze des Schlossparks ersichtlich - eine komplett innenliegende
Wiese, die sich keine Grenze mit Flächengrenzen des Schlossparks teilt,
hätte keinen expliziten Zusammenhang in den Daten.
Geht es nicht um die Geometrie, sondern einfach nur um die Navigation
zwischen Flächen, machen nestedMP durchaus Sinn. Sie bilden dann ein
verlinktes Flächennetzwerk, das interessierte Anwender durchforsten
können. Unter der Annahme, dass für die Berechnung der Geometrie nur
die Rollen outer/inner interessant sind, könnten in einer durch
Geometrietools zu ignorierenden Rolle ("info", "child", "" o.ä.)
(1.) (2.) (3.) und evtl. (4.) und (5.) MPs einfach als Kinder
dem 6. MP, dem Schlosspark hinzugefügt werden. Diese Flächenlinks wären
aufwandslos zu crawlen und für Flächen-Beziehungsfragen, die nicht
geometrischer Natur sind, extrem schnell zu verarbeiten.
Die bisherige Definition von MP lässt bis auf ways in der Rolle
outer/inner keine weiteren Mitglieder zu.
Evtl. macht eine Verschachtelung der Geometrie mit einer
Schachtelungstiefe von "1" Sinn, d.h. MP dürfen genau dann __als
inner/outer__ in anderen MP auftauchen, wenn diese selbst
unverschachtelt sind - unbegrenzte Schachtelungstiefe (der Geometrie)
dürfte aus o.g. Gründen sicher nicht umsetzbar sein. Nach meinem
Empfinden müssten die Konsequenzen erlaubter, geometrisch relevanter
Schachtelung aber noch näher durchdacht werden, bevor man das umsetzt -
schließlich ist der aktuelle Reifegrad der MP-Unterstützung auch nicht
über Nacht erschienen.
Gruß
Christian
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
