[Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Christian Müller]

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