[Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel

[Christian Müller]

Hi Martin,


Am 28.09.2011 19:40, schrieb Martin Koppenhoefer:
> nochmal: wie sollte das denn sonst gehen? Liegt sehr wohl am 
> Datenmodell. (klar, die Version entsteht erst beim Hochladen, nicht 
> bereits beim Splitten im Editor). 

Ah, ok -  Du beziehst Dich in der Tat auf den Versionszähler /eines/ 
Multipolygons und nicht darauf, dass /mehrere/ Multipolygone entstehen - 
das kam in der ursprünglichen mail nicht so rüber - meine Frage an Dich 
muss also anders lauten:

         Wo liegt für Dich das Problem, wenn der Versionsstand eines 
Multipolygons bei 249.000 steht?  Schließlich beschäftigen wir uns beim 
Editieren eigentlich nur mit dem aktuellen Stand.  Und beim Editieren 
ohne MP entstehen schließlich auch Unmengen an Versionsständen (z.B. von 
ways oder nodes).


> , dann musst Du beim Rendern das komplette Monster in jedem
> einzelnen zoom18-Tile betrachten (glaube ich zumindest), obwohl nur
> ein winziger Teil in Deinem Kartenausschnitt liegt. Wenn man den Wald
> an jeder größeren Straße auftrennt, wird er kleiner (weniger Versionen
> bzw. kleinere Versionen, schneller zu rendern, weniger potentielle
> Konflikte).

Folgen wir dieser Argumentation, ohne zu Betrachten, wie 'teuer' die 
Beantwortung der Inklusionsfrage von Z18-Tiles bezüglich MP-Monstern 
wirklich ist.  Das einzige, was Du dann erreichst, ist, dass die 
Renderzeit für Kacheln auf hoher Zoomstufe sinkt, auf niedriger aber 
enorm steigt.  Was wir aber eigentlich wollen, ist das beides vernünftig 
läuft.  Also MP-Monster für niedrige Zoomstufen, und "normale" MPs als 
inners von inners von inners (..) vom MP-Monster.

Es ist nicht ganz wahr, dass für jede Z18-Kachel das ganze Monster jedes 
Mal von neuem betrachtet wird - Du musst für die meisten Kacheln nur 
wissen, ob sie innerhalb oder außerhalb des Monsters liegen.  Das wird 
im Zusammenhang mit ein paar Rechteck-Bäumen als cachende Datenstruktur 
für die Bounding-Boxes dieser Monster i.d.R. vernachlässigbar.  Dazu 
unten mehr.


> Es ist natürlich richtig, dass man sowohl mit Einzelflächen als auch
> mit Multipolygonen eher groß oder eher fragmentiert arbeiten kann,
> aber wenn man von vornherein riesige Flächen erzeugt ist es sehr
> wahrscheinlich, dass der nächste Mapper da einfach per Multipolygon
> was rausschneidet. Je mehr das machen, um so eher wird das ein
> Monster. Wenn man dagegen fragmentiert beginnt, dann ist die Chance
> größer, dass der nächste Mapper so weitermacht und irgendwann aus
> diesem Flickenteppich ein Bild wird (übrigens ein detailliertes, weil
> von vornherein kaum Vergröberung drin ist).

Auf welchem Zoomlevel entsteht denn da ein Bild?  Auf einem ganz 
bestimmten..  Es ist nicht immer auf einfache Weise möglich, per 
render-regel ein microgemapptes Gebiet sinnvoll auch für niedrigeren 
Zoom zu erzeugen.

Ich sehe das, mal nur für die Renderinggeschichte, so:

         Wenn es einen 2500 km² großes Multipolygon als Wald gibt und 
eine Kachel für niedrigen Zoom gerendert werden soll, dann reicht es 
ggf. aus (hängt vom Zoom ab), nur den outer-way zu betrachten, und die 
'inner' zu ignorieren.  Das heißt, ich muss mir dieses Waldgebiet nicht 
erst zusammenbauen, bzw. mehrere Fetzen davon rendern, im Falle dass es 
an jeder Straße aufgetrennt vorliegt (evtl. werden ja auch manche 
Straßen auf einem niedrigen Zoom nicht angezeigt).  Mehrere Fetzen auf 
einem niedrigen Zoom zu rendern ist aufwendiger, als den "großen Batzen" 
zu rendern:  weil dann alle innenliegenden Grenzen mitberechnet werden 
müssen, nicht nur die wichtige, entscheidende, außen umliegende Grenze 
des Gebietes.

         Umgekehrt, wenn wir uns auf Z18 befinden, und das Tile liegt 
komplett innerhalb eines Polygons, dann ist auch nur dieses kleinste 
umliegende MP für eine Färbung interessant.  Für den Fall, dass die 
kleineren Strukturen des großen Waldgebietes als 'inner's und 'inner's 
von 'inner's gemappt sind, muss also für das Z18-Tile nicht der "große 
Batzen" betrachtet werden.  Angenommen das kleinste umliegende MP ist 
aber dieses 2500 km² Waldgebiet, dann stellt sich für die meisten 
Z18-Tiles nur die Frage, ob sie innerhalb oder außerhalb der Fläche 
liegen.  Dieses Problem hast Du sowohl mit einem "closed way", als auch 
mit einem MP und die Inklusionsfrage ist mittels gecachten 
bounding-boxen des MP in annehmbarer Zeit lösbar.

         Dein Ansatz, nach bottom-up Manier erst kleine Gebiete zu 
erfassen, ist in der Praxis gerade für große, unbesiedelte Gebiete nicht 
brauchbar - da existieren oft nur grobe Satfotos mittels derer man grob 
ein riesiges Gebiet erfassen kann - und das ist besser als gar nichts, 
bzw. besser, als darauf zu warten, dass in 10 Jahren dasselbe Gebiet auf 
Z16 detailiert erfasst ist.  Das wir beide zusammenbringen können (den, 
der von unten auf Z16 mappt, und den, der mittels Grobfoto auf Z8 mappt) 
verdanken wir der Schachtelungsmöglichkeit von MPs.

         Die Frage also, ob Du für ein Z18-Tile ein MP-Monster (sehr 
grobe Daten), ein "normales" MP (detailierte Daten) oder gar kein MP 
(keine Flächendaten), betrachten musst, ist nur von der Datenlage 
abhängig.  Allgemeiner gesagt, um den landuse eines Z18 zu kolorieren, 
musst Du nur das kleinste umliegende (oder "die kleinsten umliegenden", 
wenn eine landuse-Grenze durch das Z18-Tile verläuft) MP betrachten - 
das kann komplex oder weniger komplex sein, aber Du musst i.d.R. nicht 
die Kette hinaufwandern und alle Eltern im Flächennetzwerk betrachten, 
um auf Z18 zu kolorieren..


> Mit Deinem Plädoyer für Multipolygone bei Grenzen rennst Du offene Türen ein.

Ok..  Dann bleibt nur noch zu erreichen, dass Flächen als ihre Grenzen 
verstanden werden ;-)


Gruß
Christian