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

[Christian Müller]

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. Bei umfriedeten Grundstücken kann man z.B. einen (im
> einfachsten Fall) way für  Zaun/Mauer haben, der dann als outer einer
> Multipolygon-relation dient, die das Gesamtareal beschreibt. Alles
> Darinliegende (Schloßteich, Blumenrabatte, Mülltonnen und
> Hundekottütensp...) ist dann automatisch erstmal Bestandteil, sofern
> man es nicht explizit als inner way wieder ausschließt, eine Site
> braucht man dazu nicht. Ich würde in die site (falls man sie überhaupt
> benötigt für das, was man abbilden will) dann auch nicht unbedingt
> alle Einzelteile reintun, sondern dieses Gesamtobjekt. Für so was wie
> die Teiche in einem Schloßpark würde ich keine eigene site-Relation
> anlegen.
>
> Die von Dir beobachtete "Verschachtelung", die Du gerne mit Relationen
> abbilden willst, ergibt sich bereits geometrisch aus den Daten, auch
> ohne jegliche Relation.

Das sie implizit durch mehrfach als Ringelemente verwendete ways 
vorhanden ist, war mir klar - das ist aber dennoch nicht das gleiche.  
Ich habe das Beispiel mit den Kreisgrenzen gebracht - für eine komplett 
innenliegende Kreisgrenze innerhalb eines Landes ist der Flächenbezug 
zwar herstellbar, aber ohne explizite Sammelrelation nur mit 
rechnerischem Aufwand.  Der Unterschied nochmal dargestellt anhand des 
Schlossparks:

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.



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.  Einen 
gedachten expliziten MP-Baum zu crawlen und alle Teilflächen ohne 
geometrische Berechnung zu ermitteln, dürfte abhängig vom Anwendungsfall 
die bessere Variante sein - manche Anwendungsfälle werden durch ein 
solches Netzwerk evtl. praktisch erst möglich.  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.  Andererseits könnte ein Verschnitt sehr komplex werden - wenn 
das MP aus mehreren Einzelflächen besteht, also mehrere Verschnitte 
berücksichtigt werden müssen.

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.  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.  Gleiches gilt für beliebige Sammelrelationen, die Flächen auf 
die ein oder andere Weise sammeln und taggen.   Momentan lungern die 
alle mehr oder weniger zusammenhangslos in der DB - würde man sich auf 
ein paar Regeln für die Verschachtelung einigen, könnten die alle 
mittels nestedMP verlinkt bestehen.



Was Du als "schlichtes Polygon" beschreibst, ist das, was übrig bleibt, 
wenn man die Flächenlinks (nachgeordnete MP-Mitglieder) innerhalb des 
gedachten 6. MP meiner letzten mail entfernt.  Der Zusammenhang zu den 
Kindern ist dann nicht mehr explizit erkennbar, allenfalls implizit 
"geometrisch".  Der Komplexitätsgrad aller Relationen ist dann gleich, 
sie sind alle gewöhnliche Multipolygone.

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?  Die Verschachtelung entsteht schon 
implizit durch gewöhnliche MP.

Um es festzuhalten:  Die Überlappung kann dadurch entstehen, dass je 
nach Sicht auf eine Einzelfläche,
     sie entweder ein Loch innerhalb einer anderen Fläche (sie wäre dann 
nur deren Grenze),
     sie selbst eine Gesamtfläche,
     sie eine Teilfläche von einer oder mehrerer größerer Flächen
darstellt.


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.  Ohne die Geometrie zu berechnen, ließe sich entscheiden, 
welche Flächen dann beispielsweise nicht opaque bzw. nur mit Namen 
gerendert werden.  Zugegeben, das Argument ist mit "wir taggen nicht für 
renderer" zu erschlagen..

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.  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..



Gruß