Bitte um Rat zu meiner erstmaligen Verwendung von Multipolygon

Willi2006 wrote:

Nachdem ich mich über Multipolygon informiert hatte, erschien mir dies die elegantere und richtigere Methode.
Ist dies der Fall und habe ich dies korrekt umgesetzt?

Elegant ist Geschmackssache und richtig oder falsch gibt es bei OSM nicht. Aber deine Loesung finde ich unnoetig kompliziert, kein Wunder, dass sie den Renderern Probelme bereitet.

Den Park wuerde ich einfach als einzelnes outer-Polygon einzeichnen, unabhaengig von den Zaeunen. Die Zaeune wuerde ich dann als eigene Polygone einzeichnen, wobei man je nach Geschmack die Knoten vom Park-Polygon mitbenutzen kann oder leicht versetzt parallele Linien eintraegt (so wie du das wohl erst gemacht hattest).

Grundsaetzlich ist es noch eine Ueberlegung, ob fuer den Park ueberhaupt ein multipolygon noetig ist. Der See im Park ist doch Teil des Parks, oder? Dann duerfte er naemlich nicht als inner vom Park ausgeschnitten werden, denn per Definition gehoeren die Flaechen innerhalb der inner-Teile ja nicht zu der Multipolygon-Flaeche.

Gruss
Torsten

Wenn der Sportplatz, der Wald und die Seen an den Rand angrenzen (da also kein zum Park gehörender Rand mit Wiese o.ä. ist), dann würde ich den Park nur um diese Flächen außenrum zeichnen und nicht über die gesamte Fläche und dann mit Multipolygon alles wieder ausschneiden. Die zugehörigkeit zu einem Gesamtgebilde (dem Park also), wäre am besten mit einer site-Relation oder etwas in dieser Richtung ausgedrückt.

Just my 2 cent.

Willi2006 wrote:

• einen Sportplatz (pitch) http://www.openstreetmap.org/?lat=16.41 … rs=B000FTF und
  

Der Sportplatz in seiner jetzigen Lage sollte NICHT als Mitglied der Relation eingefügt werden, es sei denn als INNER-Element, WENN die Grenze des Sportplatzes innerhalb der Parkgrenze liegt.

Es gibt übrigens die Möglichkeit, in Potlatch mit der Taste P zwei Linien zu erzeugen, die genau 1 (bzw. X) Meter links und rechts neben der Mauer bzw. dem Zaun verlaufen.

Der Wald müsste ebenfalls als INNER-Element eingetragen werden.

Gruß FK270673

Danke für die Antworten.

de_muur wrote:

Grundsaetzlich ist es noch eine Ueberlegung, ob fuer den Park ueberhaupt ein multipolygon noetig ist. Der See im Park ist doch Teil des Parks, oder? Dann duerfte er naemlich nicht als inner vom Park ausgeschnitten werden, denn per Definition gehoeren die Flaechen innerhalb der inner-Teile ja nicht zu der Multipolygon-Flaeche.

Das verstehe ich nicht. Sicher ist der See Teil des Parks. Ich sehe dies wie im typischen Beispiel für Multipolygon nach http://wiki.openstreetmap.org/wiki/DE:R … ltipolygon: die Lichtung ist Teil des Waldes aber selber kein Wald; oder wie in Bild 8 von http://wiki.openstreetmap.org/wiki/Rela … ltipolygon.

FK270673 wrote:

Der Sportplatz in seiner jetzigen Lage sollte NICHT als Mitglied der Relation eingefügt werden, es sei denn als INNER-Element, WENN die Grenze des Sportplatzes innerhalb der Parkgrenze liegt.

Der Sportplatz liegt komplett innerhalb des Parkes. Es gibt keinen Zwischenraum, der Zaun des Parkes begrenzt zugleich den Sportplatz, er fängt in Richtung Straße fliegende Bälle ab. Zunächst versuchte ich, wie beim Zaun, das entsprechende Stück des Outer-Multipolygon Park für das Inner-Objekt Sportplatz mitzuverwenden. Zwar konnte ich dies in JOSM so eingeben, es wurde aber falsch gezeichnet.

Somit sehe ich im Moment nur die Möglichkeit, den Sportplatz als separate Fläche zu erstellen, wobei entlang der Parkgrenze

• entweder leicht versetzte parallele Polygone mit zusätzlichen Knoten
  
• oder doppelte aufeinanderliegende Polygone unter Mitverwendung der Knoten der Parkgrenze gezeichnet werden.
  

Letzteres kommt meines Erachtens der Wirklichkeit näher, da eine Doppellinie ja nicht wirklich vorhanden ist.

Grüße Willi

Willi2006 wrote:

Das verstehe ich nicht. Sicher ist der See Teil des Parks. Ich sehe dies wie im typischen Beispiel für Multipolygon nach http://wiki.openstreetmap.org/wiki/DE:R … ltipolygon: die Lichtung ist Teil des Waldes aber selber kein Wald; oder wie in Bild 8 von http://wiki.openstreetmap.org/wiki/Rela … ltipolygon.

Eine Lichtung liegt innerhalb eines Waldes, aber auf der Flaeche der Lichtung ist selber kein Wald. Insofern gehoert die Lichtung also auch nicht zu dem Gebiet, dass mit landuse=forst gekennzeichnet ist.
Etwas unsauber wird die Sache, wenn man innerhalb eines OSM-Objektes die Waldflaeche (landuse=forst) mit dem Gebiet vermischt, dass als XYZ-Wald bezeichnet wird. Letzteres ist ja haeufig mehr als nur die reine Waldflaeche. Wenn man das aber sauber in der Karte haben will, dann kann man dafuer nicht das selbe Element benutzen wie fuer den landuse.

Bei einem Park mit einem See drin ist das aber nicht so zwingend getrennt wie bei der Waldflaeche und der Lichtung. Ein Park ist normalerweise eine Gesamtanlage. Da gibt es beispielsweise Grasflaechen, Blumenbeete, Baumgruppen und eben auch Seen, die alle Teil des Parkes sind. Solche Flaechen als Multipolygon aus dem Park ausschneiden zu wollen ist falsch, weil sie damit dann nicht mehr zum Park dazugehoeren wuerden.

Nimm statt des Parkes mal eine Stadt mit einem Gewerbegebiet als Beispiel. Wenn man da die Stadt als Multipolygon eintragen und dann das Gewerbegebiet als inner-Element daraus ausschneiden wuerde, so wuerde das bedeuten, dass das Gewerbegebiet nicht zur Stadt dazugehoert. So ist es ja aber nicht, und deshalb macht man das auch nicht so.

Gruss
Torsten

Willi2006 wrote:

Somit sehe ich im Moment nur die Möglichkeit, den Sportplatz als separate Fläche zu erstellen, wobei entlang der Parkgrenze

Wie von Dir schon selbst im allerersten Posting genannt, sollten die Innenpolygone eines Multipolygons komplett innerhalb des Außenpolygons liegen, d.h. ein Innenpolygon darf nirgendwo an den Außenrand angrenzen. Bei dem Sportplatz, dem Wald und den Springbrunnen ist jenes momentan aber der Fall.

Wie wohl auch von Dir angedacht, wäre eine erste Lösungsmöglichkeit, die entsprechenden Flächen mit geringem Abstand vom Außenpolygon anzulegen. Dann liegen sie innerhalb desselben und es gibt keine Überschneidungen mehr.

Die zweite Lösungsmöglichkeit wäre, die Parkfläche als eigenständige einzeln Fläche einzuzeichnen und an der Innenseite des Sportplatzes, des Waldes und der Springbrunnen entlang zu führen. Jene Flächen fallen dann aus dem Multipolygon heraus. In diesem Fall ermöglicht das sogar den kompletten Verzicht auf das Multipolygon, wie von de_muur schon mal angedeutet (Die Landfläche des Parks wird als in sich geschlossene Fläche gezeichnet und am Zaun, dem Sportplatz, den Springbrunnen und dem See entlang geführt. Der See liegt dann aufgrund des Waldes nicht mehr innerhalb dieser Fläche. Auf das Multipolygon kann verzichtet werden). Diese Lösung halte ich hier für am besten.

Der einzige Nachteil jener zweiten Lösung ist, dass der Name des Parks dann nur noch für die Landfläche gilt und nicht mehr für den See, die Springbrunnen, den Sportplatz und den Wald, welche man ggf. noch zum Park zählen könnte. Dies halte ich aber für das kleinere Problem. Hier tritt sowieso das von de_muur angesprochene Dilemma auf. Was gehört überhaupt wozu? Schon im Alltagsgebrauch wird derartiges nach dem jeweiligen Nutzungszweck variiert. Dementsprechend lässt sich dies auch bei OSM nicht eindeutig festlegen.

Bei Multipolygonen war ein entscheidenden Ziel, überlagernde Flächen zu vermeiden, also z.B. Wasserflächen, die auf Landflächen liegen. Das sollte man meiner Meinung nach so beibehalten. Deshalb schneide ich einen See ggf. per Multipolygon auch aus einer Parkfläche aus. Nun mit Argumenten wie "der See ist auch Teil des Parks" von dieser Regel abzuweichen, bringt unnütze Unklarheiten. OSM kann nun einmal nicht alle Beziehungen und Zusammenhänge abdecken!

de_muur wrote:

Bei einem Park mit einem See drin ist das aber nicht so zwingend getrennt wie bei der Waldflaeche und der Lichtung. Ein Park ist normalerweise eine Gesamtanlage. Da gibt es beispielsweise Grasflaechen, Blumenbeete, Baumgruppen und eben auch Seen, die alle Teil des Parkes sind. Solche Flaechen als Multipolygon aus dem Park ausschneiden zu wollen ist falsch, weil sie damit dann nicht mehr zum Park dazugehoeren wuerden.

Hallo Torsten

Ich denke, du versuchst eine semantische Bedeutung mit dem Multipolygon
zu verknüpfen. Das ist weder in OSM insgesamt, noch speziell bei den
Multipolygonen gewollt oder dokumentiert. Dort steht im Detail:

type multipolygon Tells applications to use area-building rules on the members.

Da wird nur auf Fächen innerhalb von größeren Flächen eingegangen.
Eine semantische Beziehung wie "weil sie damit dann nicht mehr zum Park
dazugehoeren", entspricht meiner Meinung nach weder der Absicht noch der
Definition von Multipolygonen.

Edbert (EvanE)

EvanE wrote:

Ich denke, du versuchst eine semantische Bedeutung mit dem Multipolygon
zu verknüpfen. Das ist weder in OSM insgesamt, noch speziell bei den
Multipolygonen gewollt oder dokumentiert. Dort steht im Detail:

type multipolygon Tells applications to use area-building rules on the members.

Da wird nur auf Fächen innerhalb von größeren Flächen eingegangen.
Eine semantische Beziehung wie "weil sie damit dann nicht mehr zum Park
dazugehoeren", entspricht meiner Meinung nach weder der Absicht noch der
Definition von Multipolygonen.

Genau darum geht es aber bei den inner-Mitgliedern von multipolygonen. Mit den outer Polygonen definiert man den aeusseren Rand einer Flaeche (oder auch mehrerer), und mit den inner Polygonen definiert man innere Raender, also Ausschlussbereiche. Da gibt es eigentlich nichts an der Beschreibung zu deuten, und auch die Beispielbilder sind da ganz eindeutig.

Wie bei OSM so ueblich werden auch die multipolygone haeufig eher recht lax gebraucht (oder eher missbraucht), viele Leute machen sich einfach keine Gedanken darueber, was sie da logisch eigentlich eintragen und sind zufrieden sobald das Ergebnis im Renderer ihren Wuenschen enstspricht.

Wenn aber einer nachfragt, wie er ein multipolygon einrichten sollte, dann sollte man ihm auch die logisch korrekte Nutzung nennen und nicht irgendwelchen Murks.

Gruss
Torsten

de_muur wrote:

EvanE wrote:

Ich denke, du versuchst eine semantische Bedeutung mit dem Multipolygon
zu verknüpfen. Das ist weder in OSM insgesamt, noch speziell bei den
Multipolygonen gewollt oder dokumentiert. Dort steht im Detail:

type multipolygon Tells applications to use area-building rules on the members.

Da wird nur auf Fächen innerhalb von größeren Flächen eingegangen.
Eine semantische Beziehung wie "weil sie damit dann nicht mehr zum Park
dazugehoeren", entspricht meiner Meinung nach weder der Absicht noch der
Definition von Multipolygonen.

Genau darum geht es aber bei den inner-Mitgliedern von multipolygonen. Mit den outer Polygonen definiert man den aeusseren Rand einer Flaeche (oder auch mehrerer), und mit den inner Polygonen definiert man innere Raender, also Ausschlussbereiche. Da gibt es eigentlich nichts an der Beschreibung zu deuten, und auch die Beispielbilder sind da ganz eindeutig.

...
Wenn aber einer nachfragt, wie er ein multipolygon einrichten sollte, dann sollte man ihm auch die logisch korrekte Nutzung nennen und nicht irgendwelchen Murks.

Hallo Torsten

Da bin ich anderer Meinung. Es geht um Geometrie, nicht um Semantik. Es geht
um Flächen in Flächen, wobei die innenliegenden Flächen andere Eigenschaften
haben als die sie umgebende Fläche.
Ob diese Eigenschafen (semantisch) gegensätzlich oder zusätzlich sind spielt keine
Rolle. Wir interpretieren die Semantik beim Betrachten der Daten/Karten hinzu.

Um das beliebte Beispiel See im Wald zu bemühen.
- Der See ist nicht Teil des Waldes.
- Der See ist Teil des Waldgebietes.
Es ist also die Frage wie jemand landuse=forest semantisch interpretiert ,die darüber
entscheidet, welche der beiden obigen Aussagen richtig ist und welche falsch.

Welche unserer gegensätzlichen Meinungen logisch (wieder ein semantischer Begriff)
richtig ist, ist reine Ansichtssache, was ein Multipolygon beschreiben soll: die Geometrie
oder die Semantik. Meiner Meinung nach die Geometrie, weil eine semantische
Interpretation der Daten nur zu widersprüchlichen Ergebnissen führen kann.

Der Ärger mit diesen unterschiedlichen Interpretationen der Multipolygone stammt
leider von der Wiki-Seite dazu. Der Begriff 'Loch in Fläche' (hole in area) mag eine
semantische Interpretation nahelegen. Dies ist meiner Meinung nach jedoch nicht
beabsichtigt.

Ansonsten stimme ich dir zu, dass wir die unterschiedlichen Interpretation der
Multipolygone durchaus kundtun sollten.

Edbert (EvanE)

Moin,

EvanE wrote:

Es geht um Flächen in Flächen, wobei die innenliegenden Flächen andere Eigenschaften haben als die sie umgebende Fläche.

Ja, aber was heisst das denn?
Entweder sagt ein multipolygon aus, dass die innenliegenden Flaechen anders sind, weil sie NICHT die Eigenschaften des aeusseren Bereiches haben, oder aber ein multipolygon sagt was aus?
Eigentlich bleibt gar keine andere Moeglichkeit ueber. Soll es eine Und-Verknuepfung ausdruecken? Oder ein "ich-weiss-es-nicht"? Wie wuerde man dann das Gilt-Nicht-Im-Innern ausdruecken? Und wozu braucht man dann ueberhaupt das multipolygon, was sagt es mehr aus, als die reine Geometrie der Polygone?

- Der See ist nicht Teil des Waldes.
- Der See ist Teil des Waldgebietes.

Ich denke eher, dass das der Punkt ist, ueber den man anderer Meinung sein kann. Mit landuse=forest meint man einerseits die Flaeche, wo die Baeume wachsen. Haeufig traegt man allerdings an dieses Polygon auch ein name-Tag ein, dass das gesamte Waldgebiet, also inklusive Lichtungen, Seen usw. bezeichnet. Dass diese beiden Sachen aber nicht identisch sind, machen sich die meisten Mapper gar nicht klar. Eigentlich muesst eman zwei Objekte eintragen, also die reine Waldflaeche unabhaengig vom gesammten Waldgebiet. Erstere waere dann ein multipolygon, letztere i.A. ein einfaches Polygon, das alles beinhaltet.

Und eine aehnliche Situation hat man auch bei leisure=park. Meint man damit ausschliesslich die Flaechen, die einen parkartigen Charakter haben? Oder meint man damit die Parkanlage in ihrer Gesamtheit? Wobei sich ein name-Tag nur auf das zweite Beziehen wird, und es deshalb auch logisch zwangslauefig eine Interpretation fuer das erste vorgibt, jenachdem, wo man das name-Tag fuer die Parkanlage anbringt.

Gruss
Torsten

de_muur wrote:

Entweder sagt ein multipolygon aus, dass die innenliegenden Flaechen anders sind, weil sie NICHT die Eigenschaften des aeusseren Bereiches haben, oder aber ein multipolygon sagt was aus?
Eigentlich bleibt gar keine andere Moeglichkeit ueber. Soll es eine Und-Verknuepfung ausdruecken? Oder ein "ich-weiss-es-nicht"? Wie wuerde man dann das Gilt-Nicht-Im-Innern ausdruecken? Und wozu braucht man dann ueberhaupt das multipolygon, was sagt es mehr aus, als die reine Geometrie der Polygone?

Nehmen wir mal einen Way 1: 3km nach rechts, 3km runter, 3km nach links, 3km rauf. Der Way ist also in sich geschlossen und hat als Fläche 9 Quadratkilometer.

Der Way 2 ist genauso, aber mit 1km Kantenlänge und schön mitten drin. Er gibt eine Fläche von 1 Quadratkilometer an.

Ein Multipolygon mit Way1 als outer und Way 2 als inner gibt eine Fläche von 8 Quadratkilometer an. (Die Fläche hat ein Loch.)

Will man etwas über die 9 Quadratkilometer große Fläche sagen, dann sollte man das mit Tags von Way1 ausdrücken.
Will man etwas über die kleine Fläche in der Mitte sagen, dann kommen entsprechende Tags in Way 2.
Wenn man etwas über die 8 Quadratkilometer große Fläche sagen will, dann sollte man die entsprechenden Tags in das Multipolygon schreiben.

Man kann drüber streiten, ob -- wenn wir das Beispiel mal als See mit Insel betrachten -- man das natural=water an Way1 oder das Multipolygon schreiben sollte (ich denke, man sollte letzteres tun). Aber wir sollten uns darüber einig sein, dass natural=water an Way 1 über einen 9 Quadratkilometer großen See redet und natural=water als Tag des Multipolygons über einen 8 Quadratkilometer großen See redet. Das meine ich deshalb, weil es doch nicht sein kann, dass sich die Bedeutung von Tags in Way 1 ändert, ohne dass man Way 1 ändert ... einfach nur dadurch, dass Way1 als outer in einem Multipolygon erwähnt wird. Sowas wäre widersinnig und inkompatibel zur der Zeit, als es noch keine Multipolygone gab.

Weide

Weide wrote:

Will man etwas über die 9 Quadratkilometer große Fläche sagen, dann sollte man das mit Tags von Way1 ausdrücken.
Will man etwas über die kleine Fläche in der Mitte sagen, dann kommen entsprechende Tags in Way 2.
Wenn man etwas über die 8 Quadratkilometer große Fläche sagen will, dann sollte man die entsprechenden Tags in das Multipolygon schreiben.

Das wäre logisch, aber es entspricht leider nicht der historisch gewachsenen Definition der Relation - dass nämlich bei Multipolygonen mit einem einzigen outer-Member die Multipolygon-Tags statt an der Relation auch ohne Bedeutungsunterschied an diesem einen Member angebracht werden können.

Relation:multipolygon wrote:

If you have one closed way making up the outer ring and it does not describe something in its own right, you may also put these tags on the outer ring and leave the relation untagged.

Es heißt natürlich auch

Therefore it is suggested (for consistency) to always put the multipolygon tags on the relation.

aber diese Empfehlung wird zumindest meiner Beobachtung nach noch eher selten befolgt. Es ist aber durchaus anzustreben, dass man sich zunehmend daran hält.

Weide wrote:

Nehmen wir mal einen Way 1: 3km nach rechts, 3km runter, 3km nach links, 3km rauf. Der Way ist also in sich geschlossen und hat als Fläche 9 Quadratkilometer.

Der Way 2 ist genauso, aber mit 1km Kantenlänge und schön mitten drin. Er gibt eine Fläche von 1 Quadratkilometer an.

Ein Multipolygon mit Way1 als outer und Way 2 als inner gibt eine Fläche von 8 Quadratkilometer an. (Die Fläche hat ein Loch.)

Will man etwas über die 9 Quadratkilometer große Fläche sagen, dann sollte man das mit Tags von Way1 ausdrücken.
Will man etwas über die kleine Fläche in der Mitte sagen, dann kommen entsprechende Tags in Way 2.
Wenn man etwas über die 8 Quadratkilometer große Fläche sagen will, dann sollte man die entsprechenden Tags in das Multipolygon schreiben.

Diesen Ansatz halte ich fuer ziemlich fehleranfaellig, da man nur schwer erkennen kann, was wo gilt.

Stattdessen wuerde ich zwei andere Varianten bevorzugen:

A) Man traegt einen way 3 ein, der vom Verlauf her mit way 1 identisch ist. Dann kann man way 1 als outer fuer das multipolygon benutzen und way 3 fuer die Gesamtflaeche. Das ist ein wenig klarer, aber auch nicht viel besser, weil genug Mapper auch mir uebereinander leigenden Wegen ihre Probleme haben.

Deutlich klarer finde ich deshalb:

B) Way 1, way 2 und multipolygon wie oben.
Will man etwas ueber die 8 Quadratkilometer große Fläche sagen, dann sollte man die entsprechenden Tags in das Multipolygon oder an way 1 schreiben, beide Varianten lassen sich in der Nutzung faktisch nicht unterscheiden.
Will man etwas über die kleine Fläche in der Mitte sagen, dann kommen entsprechende Tags in Way 2.
Will man etwas über die 9 Quadratkilometer große Fläche sagen, dann sollte man diese Tags bei way 1 UND bei way 2 eintragen. Denn die 9 Quadratkilometer Gesamtflaeche ergibt sich ganz einfach aus der Summe der beiden Einzelflaechen.

Tordanik wrote:

Das wäre logisch, aber es entspricht leider nicht der historisch gewachsenen Definition der Relation - dass nämlich bei Multipolygonen mit einem einzigen outer-Member die Multipolygon-Tags statt an der Relation auch ohne Bedeutungsunterschied an diesem einen Member angebracht werden können.

Wobei es ja auch durchaus Gruende fuer dieses Vorgehen gibt.
Zum einen ist da die Abwaertskompatibilitaet. Wenn eine Auswertung die Relation nicht erkennt, dann erkennt sie wenigstens die beiden Einzelpolygone, weiss allerdings nciht, in welchen Zusammenhang die stehen. Das Ergebniss wird zwar fehlerhaft sein (das Loch wird halt nicht erkannt), aber es ist immer noch besser, als wenn die grosse Flaeche komplett fehlen wuerde.
Zum anderen ist die aktuelle Loesung einfacher, wenn man nachtraeglich ein "Loch" in eine Flaeche eintraegen will. Man braucht das urspruengliche Polygon nicht zu veraendern, sondern traegt einfach das "Loch" als neues Polygon ein und stellt ueber die Relation den Zusammenhang her.

Noch schimmer waren da sicherlich die Anfaenge der multipolygone, als es statt inner- und outer-Eigenschaft auf die Richtung der Polygone drauf an kam. Oder als die inneren Polygone genauso markiert werden sollten wie die aeusseren (was sich uebrigens auesserst schlecht mit der von mir vorgeschlagenen Variante B vertraegt).
Zum Glueck sind diese Sachen aber nahezu ausgestorben. Ob das mit der Vermischung von Relations-Tags und Tags am outer-Polygon auch mal passieren wid, bin ich eher skeptisch. Im Moment muss man einfach das aktuell uebliche Vorgehen akzeptieren.

Gruss
Torsten

de_muur wrote:

Noch schimmer waren da sicherlich die Anfaenge der multipolygone, als es statt inner- und outer-Eigenschaft auf die Richtung der Polygone drauf an kam.

Na ja, die Richtung zu ignorieren ist eigentlich schlicht und einfach ein Fehler :-)
Auf einer Kugeloberfläche kann man innen und außen nicht anhand der Linie unterscheiden. Wenn ich den Äquator als Begrenzungslinie nehme, habe ich dann die Nordhalbkugel oder die Südhalbkugel markiert?

Die jetzige Regelung fällt also wohl unter "praktisch brauchbarer Irrtum".

Weide

Danke für die Antworten. Es war sehr lehrreich. Mein Eindruck ist, dass Multipolygone sehr konträr gesehen werden, unterschiedlich verwendet werden (können) und vielleicht auch noch nicht ausgereift sind. Ich denke, dass ich mich noch länger damit beschäftigen werde, um sie besser verstehen und einsetzen zu können.

Willi2006 wrote:

Danke für die Antworten. Es war sehr lehrreich. Mein Eindruck ist, dass Multipolygone sehr konträr gesehen werden, unterschiedlich verwendet werden (können) und vielleicht auch noch nicht ausgereift sind. Ich denke, dass ich mich noch länger damit beschäftigen werde, um sie besser verstehen und einsetzen zu können.

Betrachte Multipolygone erst mal als Zusatzinformationen für Renderer und
andere Programme wie ineinander leigende Flächen dargestellt werden sollen.

Das vereinfacht das Modell im eigenen Kopf und lässt Zweifel, ob dadurch etwas
innenliegendes semantisch von aussenliegenden ausgeschlossen wird, erst
einmal aussen vor.

Edbert (EvanE)

Ich hoffe es ist nicht der Eindruck entstanden, ich sei jetzt verwirrt und würde Multipolygone bleiben lassen. Im Gegenteil: Ich habe jetzt ein besseres Verständnis. Ich bin aber noch nicht zu einem abschließenden Ergebnis gekommen, sofern dies überhaupt je möglich ist. "Die Theorie von heute ist der Irrtum von morgen."

Momentan neige ich zu der Ansicht von Edbert "Es geht um Geometrie, nicht um Semantik." Geometrie ist eindeutig(er), Semantik ist vieldeutig(er) und somit mehr vom Betrachter abhängig. Konzentration oder Beschränkung auf die Geometrie erleichtert somit das Verständnis für Mapper und Renderer.

In meinem obigen Beispiel Park gibt es noch mehr innenliegende Flächen. Diese werde ich noch erfassen und eintragen. Und ich denke, Multipolygon ist zur Beschreibung der Geometrie dann besser. Einen weitaus komplexeren und lehrreicheren Fall eines Waldes habe ich inzwischen in dieser Diskussion gefunden Anfänger möchte sich an Multipolygon versuchen.

EvanE wrote:

Betrachte Multipolygone erst mal als Zusatzinformationen für Renderer und
andere Programme wie ineinander leigende Flächen dargestellt werden sollen.

Genau das halte ich fuer den komplett falschen Vorschlag. Hier ist mal wieder einer der Faelle fuer den alten Spruch: "Wir mappen nicht fuer die Renderer"

Wenn einer ein Tag einzig und alleine dafur benutzt, damit das Renderer-Ergebnis besser aussieht, dann ist das ein gutes Zeichen dafuer, dass er was falsch macht.

Gruss
Torsten

Willi2006 wrote:

Momentan neige ich zu der Ansicht von Edbert "Es geht um Geometrie, nicht um Semantik." Geometrie ist eindeutig(er), Semantik ist vieldeutig(er) und somit mehr vom Betrachter abhängig. In meinem obigen Beispiel Park gibt es noch mehr innenliegende Flächen. Diese werde ich noch erfassen und eintragen. Und ich denke, dann ist Multipolygon zur Beschreibung der Geometrie genau das richtige.

Die Geometrie ergibt sich alleine aus den Koordinaten der Eckpunkte. Da hat die multipolygon-Relation ueberhaupt nichts mit zu tun. Wenn die Koordinaten des einen Polygons innerhalb der Koordinaten eines anderen Polygons liegen, so ist der geometrische Zusammenhang alleine dadfurch vollstaendig bestimmt. Von der Geometrie her ist es dann auch voellig egal, ob eines der Polygone als inner oder als outer bezeichnet wird, die Lage aendert sich dadurch ja nicht.

Gruss
Torsten

Die Sache mit dem Renderer sehe ich etwas differenzierter:

• Ich zeichne und beschreibe (auf neuhochdeutsch "mappe") gemäß der Wirklichkeit.
Aber ich kann niemals die Wirklichkeit zeichnen, auch nicht mit einem Foto, sondern es ist stets eine Abstraktion, eine Abbildung.
• Ich verfälsche die Wirklichkeit nicht, damit das Renderer-Ergebnis besser aussieht.
• Aber ich zeichne und beschreibe so, dass Andere und Renderer verstehen was ich meine.
Verstehen ist jedoch eine Interpretation und somit selbst bei verschiedenen Programmen und erst recht bei Personen unterschiedlich.

Grüße Willi

Willi2006 wrote:

Die Sache mit dem Renderer sehe ich etwas differenzierter:

Normalerweise bringe ich den Spruch auch nicht, weil ich mich in anderem Zusammenhang durchaus dazu bekenne, fuer den Renderer (im Sinne von: fuer eine Nutzung der Daten) zu mappen.

• Ich verfälsche die Wirklichkeit nicht, damit das Renderer-Ergebnis besser aussieht.
• Aber ich zeichne und beschreibe so, dass Andere und Renderer verstehen was ich meine.
Verstehen ist jedoch eine Interpretation und somit selbst bei verschiedenen Programmen und erst recht bei Personen unterschiedlich.

Was falsch und was richtig ist, kann man natuerlich nur entscheiden, wenn man sich auf eine Bedeutung der Tags geeinigt hat.

Wenn die multipolygon-Relation aber eine Bedeutung hat, dann ist eine widersinnige Benutzung sehr wohl eine Verfaelschung der Wirklichkeit.

Und wenn die eigentlich allgemein akzeptierte, semantische Bedeutung der multipolygon-Relationen hier verneint wird, so fehlt immer noch eine Erklaerung, welche Bedeutung die Relation dann haben soll. Es wird doch wohl keiner ersnthaft behaupten wollen, dass die Relation nur zur Steuerung des Renderers da ist (auch wenn sie haeufig faelschlicherweise so genutzt wird).

Gruss
Torsten

Relation:multipolygon wrote:

If you have one closed way making up the outer ring and it does not describe something in its own right, you may also put these tags on the outer ring and leave the relation untagged.

Dieses Zitat ist interessant. Der von mir fett hervorgehobene Satzteil macht meines Erachtens den Unterschied. Wie wäre es im Beispiel von Weide mit

• natural=water an die Relation. Der See, die Wasserfläche ist 8 und nicht 9 qkm groß.
• place=island an way 2. Die Insel ist 1 qkm groß.
• eventuell leisure=park und name=Wasserpark an way1, falls das 9 qkm große Gesamtgebiet etwas Eigenes ist ("something in its own right").

Die Frage gehört die Insel zum See oder nicht kann man sicherlich unterschiedlich sehen. Aber natural=water gilt sicher nicht für die Insel. Und wenn der See der Atlantik und die Insel Großbritannien ist, gehört dann Großbritannien zum Atlantik. Man könnte nun anfangen, die Semantik von "gehört" zu diskutieren und käme gar nicht mehr zum "mappen". Da es mit der Semantik also so eine Sache ist, gilt bei mir: Davon besser nur so viel wie nötig. Die Geometrie ist eindeutig(er): Die Insel liegt im See und ist ausserdem etwas anderes (role=inner), nämlich kein Wasser, sondern ein schwarzes Loch oder etwas, das dieser Fläche als Merkmal gegeben wurde. Ob man role=inner nun zur Geometrie oder schon zur Semantik zählt halte ich für Ansichtssache.

Prima Diskussion, sehr sachlich und vor allem ich lerne durch jeden Beitrag hinzu.

Grüße Willi

Hi,

... die Geometrie...die Semantik...

mit der Geometrie und der Semantik ist das so 'ne Sache.

Geometrisch sollte man erstmal Punkte (nulldimensional), Linien (eindimensional) und Flächen (zweidimensional) unterscheiden.

OSM hat aber nur Punkte und Linien (und Relationen). Flächen haben keine eigene Datenstruktur in OSM und werden nur semantisch erkannt; eine Linie oder mehrere Linien bezeichnen je nach Tagging und je nach Relationsmitgliedschaften eine Fläche. Tags wie area, landuse, roundabout, coastline und Relationsmitgliedschaften bei gleichem Tagging entscheiden darüber, ob es eine Fläche ist und wie dann die Linie in Beziehung zur Fläche steht.
Hätten wir keine Linien, dann würden die Punkte einer Straße Markierungen wie "line=yes" und "streetpointnumber=127" bekommen. Für komplizierte Straßen (solche mit Kreuzungen) würden wir dann Multipointrelationen benutzen. :-))
Lustig ist auch, dass die eigentlich in den semantischen Bereich zielende Relation (inhaltlich zusammengehörige Dinge zusammenfassen) nun das Einzige ist, mit dem man komplizierte Flächen darstellen kann (also ein rein geometrisches Problem).

Vielleicht sollten wir versuchen, für das nächste API einen brauchbaren Area-Typ zu definieren. Vielleicht so eine Punktliste mit Markierungen midpoint und endpoint. Die einzelnen zusammenhängenden Stücke könnten so funktionieren wie bei coastline. Auch unvollständig bekannte Flächen könnte man so erfassen und wären genauso schlecht zu rendern wie heute (z.B. coastline unvollständig). Dann könnte man auf die Dauer alle Flächen darauf umstellen.

Weide

Willi2006 wrote:

Relation:multipolygon wrote:

If you have one closed way making up the outer ring and it does not describe something in its own right, you may also put these tags on the outer ring and leave the relation untagged.

Dieses Zitat ist interessant. Der von mir fett hervorgehobene Satzteil macht meines Erachtens den Unterschied.

Das hatten wir neulich schon mal, ich weiss jetzt nicht, ob in dieser Diskussion oder in einer aehnlichen. Kann sein, dass ich mich hier jetzt also ziemlich wiederhole.

In einer schoenen klaren Welt, wuerde man die Tags fuer die durch das multipolygon-Flaeche (der Bereich zwischen outer und inner) in die Relation eintragen und die Tags an den Polygonen selber waren dafuer egal.

Zum Teil historisch bedingt, zum Teil um dem Verfahren etwas Robustheit mitzugeben, zum Teil um das Eintragen zu vereinfachen, ist das in der Praxis aber nicht so sauber getrennt.

Wie du oben ja zitierst, ist es unter bestimmten Bedingungen erlaubt/gewuenscht/vorgesehen, die Tags fuer die multipolygon-Flaeche an das outer-Polygon zu setzen. Und hinzu kommt dann noch, dass sich die Mapper auch nicht sauber an diese Bedingungen halten, so dass man momentan letztendlich wohl sagen muss, dass man praktisch nicht zwischen den Tags der multipolygon-Flaeche und des outer-Polygons unterscheiden kann.

Da gibt es drei Arten, das Problem zu loesen.
1. Man traegt die Heile-Welt-Loesung ein und vertraut darauf, dass sich langfristig diese Sicht schon durchsetzen wird.
2. Man verdoppelt das outer-Polygon. Eins wird dann fuer das multipolygon benutzt und das andere fuer die Gesamtflaeche.
3. Man setzt die Gesamtflaeche aus der multipolygon-Flaeche und den inner-Polygonen zusammen, d.h. die Tags fuer die Gesamtflaeche werden gleichzeitig an die outer- und die inner-Polygon eingetragen.

Gruss
Torsten

Weide wrote:

Flächen haben keine eigene Datenstruktur in OSM und werden nur semantisch erkannt ...

Und ich dachte mit Multipolygonen wurde dies geändert: "Relations of type multipolygon are used to represent areas of all sorts. The multipolygon relation is OpenStreetMap's area data type."

de_muur wrote:

1. Man traegt die Heile-Welt-Loesung ein ...

Genau dies habe ich heute bei dem Park gemacht. Ich habe weitere innenliegende Flächen eingetragen. Das Multipolygon hat jetzt 19 Elemente. JOSM scheint dies zu mögen. Sobald role=inner zugewiesen ist wird die jeweilige Fläche nicht mehr in einer Mischfarbe sondern der "richtigen" Farbe dargestellt. Mapnik zeigt noch die alte Version. Osmarender hat schon aktualisiert, sieht gut aus.

Selbst bei dieser momentanen "Heile-Welt-Loesung" musste ich Linien mehrfach übereinander eintragen, was ich eigentlich vermeiden wollte. Jedoch sind es weniger als es bei den anderen vorgeschlagenen Methoden der Fall wäre. Doppelt gemoppelt hält zwar besser. Aber bei Datenstrukturen habe ich in Theorie und Praxis gelernt, dass mehrfaches Anlegen des eigentlich selben Datums dazu führt, dass die Daten oft schon beim erstmaligen Eingeben und erst recht nach mehreren Aktualisierungen, insbesondere durch verschiedene Personen, inkonsistent werden. Und dies trotz oder eigentlich gerade wegen dem mehrfachen Aufwand. Wenn ich die Karte von Hand auf Papier zeichnen würde, so würde ich eine Linie auch nicht mehrfach einzeichnen nur weil sie verschiedenen Flächen gemeinsam ist. Ich denke, dass unsere Beschreibungsmittel (object types, tags, relations) und die Algorithmen (in Editoren und Renderern) noch besser werden sollten.

Grüße Willi

Willi2006 wrote:

Weide wrote:

Flächen haben keine eigene Datenstruktur in OSM und werden nur semantisch erkannt ...

Und ich dachte mit Multipolygonen wurde dies geändert: "Relations of type multipolygon are used to represent areas of all sorts. The multipolygon relation is OpenStreetMap's area data type."

(Hast recht, ab und zu kehr ich mal den Datenstrukturfundamentalisten raus. :-) )

Ja, sowohl Relationen mit type=multipolygon als auch geschlossene Linien mit z.B. landuse=forest als auch geeignete Gruppen von Linien mit natural=coastline definieren Flächen.

Ich wollte nur sagen, dass es eigentlich vier und nicht drei grundlegende Typen geben sollte: Punkte, Linien, Flächen und -- für abstraktere Zusammenfassungen von bereits vorhandenen Objekten -- auch noch Relationen.

Mit Relationen kann man ganz gut Flächen definieren, aber eigentlich sollte die Relation doch OSM-Objekte zusammenfassen; Objekte wie Bushaltestellen, Straßenstücke kennzeichnen in der Zusammenfassung eine Buslinie. Aber bei Multipolygonen machen wir und mache ich was ganz anderes. Bei überstrapazierten See wird die Insel in der Relation erwähnt, aber sie wird nicht mit anderen Objekten zu einem größeren Ganzen zusammengefasst -- man will nur ihre Begrenzungslinie haben. Genauso könnten wir auch auf alle "Way"s verzichten und statt dessen Relationen von Punkten bauen. Es ginge -- aber es wäre konzeptioneller Müll.

Weide