Hallo Wolfgang,
Am 20.04.2012 12:04, schrieb Wolfgang:
Ich glaube, an dieser Stelle missverstanden zu sein. Solange es nur um
zusammengehörige Flächen gleichen Typs geht, reicht das Multipolygon
völlig aus. Ich will nicht Multipolygone durch Sites ersetzen, sondern
verhindern, dass
- das Multipolygon mit Elementen verwässert wird, die mit der Fläche
nichts zu tun haben (place etc) und
- die Flächenberechnung / Darstellung im Multipolygon konzentrieren
(wenn sie komplizierter ist als ein einfacher Umring)
Weshalb verwässern? Anhand der inner/outer Rolle, die nur durch ways
besetzt werden darf, ist doch klar, was zur Flächenberechnung
herangezogen wird. Weshalb fürchtest Du die Aufnahme weiterer Elemente
in anderen Rollen? Oder geht es Dir nur um die Größe, auf die ein MP
dann u.U. anwachsen kann?
Die Seefläche wird nicht als Loch im Park definiert, weil sie 1. zum
Park gehört und 2. üblicherweise der Renderer damit klar kommt, die
Wasserfläche hat insofern Vorrang.
Die Zugehörigkeiten fasse ich genauso auf wie Du - damit sind wir bei
der Überlappung der Flächen angekommen. Das Beispiel wird von den
jetzigen Renderern sicher erwartungsgemäß priorisiert und richtig
dargestellt. Spätestens wenn sich landuse=* und leisure=* MPs
überlappen, kann ich mir aber nicht mehr vorstellen, wie eine
Renderregel das sinnvoll priorisieren will - Nehmen wir an ein kleinerer
Stadtpark überlappt auf den Rand einer großflächigeren Wiese. Es ist
durch geographische Gegebenheit zu erkennen, dass die Überlappungsfläche
je nach Sichtweise beiden MP zugeordnet werden kann, also erfasst ein
OSMler das auch so - in klassischen Karten würde man vermutlich im
Überlappungsgebiet schraffieren oder punkten. Da das ganze sehr
theoretisch ist, lohnt eine Fortsetzung an dieser Stelle vermutlich erst
mit einem echten Beispiel. Belassen wir es also dabei..
Wenn jemand eine Statistik aller Rosenbeete in den
Schlossparks des Landes erstellen will, dann muss er eben abfragen,
welche Beete sich räumlich in einem solchen Park befinden.
-> Etwas in der Richtung hatte ich im Hinterkopf. Für komplexe
Statistiken ist der Rechenaufwand über die räumlichen Abfragen evtl.
unnötig hoch und wenn es viele Anwender gibt, die unabhängig voneinander
die gleichen Statistiken erstellen, verschwendet man Energie ;.-) Ist
es nicht gerade für die Erstellung solcher Statistiken von Vorteil, wenn
Schachtelungszusammenhänge explizit in den Relationen wären? Klar
können wir uns auch von diversen Rechenzentren abhängig machen, aber
eine intelligente Lösung ist das nicht, klingt eher wie brute force..
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.
So ganz kann ich deinen Ausführungen nicht folgen. Im Prinzip ist das
Multipolygon überraschend einfach zu berechnen und gleichzeitig
geschickt aufgebaut.
Es ging um (gedachte) nested MP, in denen MP Mitglieder anderer MP sind
- das ist bisher nicht erlaubt. Für die gewöhnlichen MP, stimme ich Dir
zu - schicke Sache. Mir fällt auf, dass der Terminus "geschachtelte MP"
auch für die durch alternierende inner / outer Ringe konstruierten MP
verwendet wird - von diesen habe ich ausdrücklich nicht gesprochen - mir
ging es um die Verschachtelung von Flächen verschiedenen Typs, weil sie
logisch Teil einer oder mehrerer anderer Flächen sind.
[...] Das heißt auch, dass nur die Umringe
als Typ "outer" definiert werden dürfen, die tatsächlich vom Typ des
Multipolygons sind.
Ich verweise dann einfach immer auf
http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon - spart
Tipp-Arbeit ;-)
Für Grenzen bietet sich das Multipolygon an - nicht um irgendwelche
"inner" zu definieren, sondern weil es möglich ist, das "outer" aus
einer größeren Anzahl von (nicht geschlossenen) Polygonen zu
definieren, die zusammen einen geschlossenen Umring ergeben. Ähnlich
wie bei der coastline hat es gewisse Vorteile, nicht immer den ganzen
Umring der z.B. USA laden zu müssen. Die Landesgrenze ist ein MP, die
Kreisgenzen jeweils auch. Wer die Hauptstadt, Verwaltungszentrale oder
was auch immer da rein bringen will, kann das dann über die Site
machen. Members sind dann das Multipolygon mit der Grenze und der
place-Node der Zentrale. Land und Kreise untereinander brauchen keine
weitere Relation, da sich ihre Zusammengehörigkeit aus der Lage
ergibt, im Gegensatz zur Zentrale einer Grenze. Da die Grenze in der
Regel eine Vielzahl von places umschließt, kann hier nicht gefolgert
werden, welcher place als Hauptort gemeint ist.
-> Das ist mir alles bekannt, aber dennoch, danke.
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).
Wenn ich dich richtig verstehe, willst du für jede kleine Enzelfläche
ein MP anlegen. Wie oben beschrieben, ist das nicht notwendig.
Nein, ich schrieb "unterschiedlichen Typs", meinetwegen auch "gleichen
Typs" aber dann logisch nicht mehr zusammengehörig (wobei das u.U.
Geschmackssache des Mappenden ist). Grob nach der Regel:
unterschiedliche Tags -> neues MP.
Mir geht es darum, Zusammenhänge zwischen MP explizit herzustellen, mit
einer Erweiterung von MP selbst. Schließlich sind diese selbst nur eine
Definition der allgemeineren OSM-Relation, die für die Verlinkung und
Verschachtelung von MP untereinander einfach einen neuen Rollen-Namen in
Betracht ziehen kann, ohne die bisherige Verwendung zu ändern, zu
verwässern, bzw. zu stören. Problematisch könnte in bestimmten
Szenarien allenfalls die Anzahl der Mitglieder werden, die dadurch
entstehen - das ist aber bereits jetzt ein Thema - Ausnahmefälle die
üblicherweise durch einen Split in separate MP (trotz "gleichen Typs")
gelöst werden.
Um das nochmal klar zu stellen: es gibt eine vereinfachte
Flächendarstellung mit verschiedenen tags (building=*, natural=water,
landuse=*, ...). Solange das nur ein ganz einfaches geschlossenes
Polygon ist, würde ich immer das benutzen.
Ich weiß, ich habe vor einiger Zeit ein wenig mitgeholfen, diese
Variante der Flächenerfassung mit einem SelectAction-Patch für
overlapping ways in JOSM salonfähig zu machen.. Gut ist das aber nicht
- teilweise sind selbst einfache Polygone riesig (Wälder). Während man
mit MP vor einem versehentlichen Gesamtdownload halbwegs verschont
bleibt, klappt das mit closed ways nicht.. Zudem sieht man overlapping
ways erst durch Verwendung an, wieviele closed ways dahinter stecken.
Linien, die auf der höchsten Zoomstufe imaginär nebeneinander gezeichnet
werden, gibt es auch noch - das sieht aber nicht hübscher aus als MP und
aufwendiger ist es auf Dauer auch noch.
Gruß
Christian
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
