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
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
