Das Tagging ist korrekt, doch der Renderer ist defekt.
Mit einem zweiten MP mit nur einem outer ohne inner gehts (Tagging für den Renderer):
relation1:
type=multipolygon
landuse=forest
wood=deciduous
outer: way1
inner: way2
inner: way3
way1:
(keine Tags)
way2:
landuse=meadow
way3:
(keine Tags)
relation2:
type=multipolygon
landuse=forest
wood=coniferous
outer: way3
Gruß Wolf
Das möchte ich doch nicht unkommentiert so stehen lassen. Multipolygone eignen sich nunmal besonders gut, größere Flächen zu beschreiben. Die einzige Alternative ist sonst ein geschlossener Weg. Wenn dieser nur einmal unterbrochen ist, hat man keine Fläche mehr. Eine Kette von Wegen mit landuse=forest ist aber kein Wald, sondern eine weiße Fläche, auch wenn es einmal die volle Runde macht. Dagegen ergibt eine Kette von Wegen mit einer gemeinsamen Multipolygon-Relation und Tag landuse=forest eine Fläche. Man muss nur noch aufpassen, dass es keine Lücken gibt und keine Verzweigungen in mehrere Wege. Solche Fehler sind aber einfach zu lokalisieren, wenn man alle Wege markieren lässt, die zu einer Relation gehören.
Das Problem mit unscharfen Übergängen in natürlichen Landschaftsformen hat man bei Multipolygonen und einfachen Flächen gleichermaßen. Beim Kartieren in den Alpen ist es häufig der Fall, dass die Baumgrenze eigentlich keine klare Linie hat, sondern halt einfach immer weniger Bäume in der Wiese stehen. Aber gerade hier lässt sich gut klarmachen, dass Multipolygone gut geeignet sind, die Vegetationsstufen eines Berges (den wir uns mal mit einem Gipfelfelsen vorstellen) abzubilden, von oben nach unten:
oben ein Punkt mit dem Gipfel,
darunter ein Weg mit Multipolygon “natural=grassland” (oder “landuse=meadow”, falls bewirtschaftete Alm)
darunter ein Weg mit Multipolygonen “natural=grassland” und “natural=scrub” (Latschen)
darunter ein Weg mit Multipolygonen “natural=scrub” und “landuse=forest” (Bergwald)
darunter ein Weg mit Multipolygonen “landuse=forest” und “landuse=meadow” (Talwiese)
Das alles spannt sich naturgemäß über mehrere Kilometer und ist mit Multipolygonen definitiv einfacher zu verwalten, als mehrere miteinander verhakte einfache Wege.
Nur mal so als Beispiel: http://www.openstreetmap.org/relation/1128535
Das ist doch mal ein hervorragendes Beispiel wie man es nicht machen sollte.
Das sind ein haufen voneinander unabhängier Waldstücke die man jeweils einzeln
als einen way mappen solllte. Ausser vielleicht jenen mit Löchern, die macht man
als eigenes MP.
Das wäre viel einfacher zu verwalten, bzw.: was will man denn da verwalten? Einmal
gemappt lebt sowas doch 20 Jahre.
Die Wiederverwendung von ways in mehreren MP ist doch komplexer als die Wiederverwendung
von nodes in zusammenklebenden Flächen. Da sollte man IMHO das einfachere Konstrukt wählen.
Da gibt es einen Thread mit ‘Multipolygonwahnsinn’ im Titel.
Nebenbei:
Ich finde die Zusammenfassung von mehreren unabhängigen Landstücken
durch ein MP als eine Art Sammelrelation ‘Wälder um Pertisau’, die werden
üblicherweise gerne gelöscht:-) Nee, ich mach’ das nicht, doch scheint es
breiten Konsens bzgl. Sammelrelationen zu geben.
So isses! Denn es widerspricht der Regel, dass eine in sich geschlossene Linie mit Flächentags eine Fläche beschreibt, die das gesamte umschlossene Gebiet umfasst. Multipolygone spielen da gar keine Rolle.
Die Multipolygonrelation ist nur ein Ersatz für den fehlenden Flächendatentyp. Der andere Ersatz ist die in sich geschlossene Linie, aber nur wenn sie mindestens ein Flächentag hat.
Das Multipolygon verhält sich zu seinen Linien wie die Linie zu ihren Punkten.
Wenn alle Punkte einer Linie highway=traffic_signals enthalten, dann ist das für die Linie völlig egal – sie hat ihre eigenen Tags wie etwa highway=tertiary. Man kann auch nicht das highway=traffic_signals aus den Punkten löschen und ersatzweise an die Linie schreiben. Man kann genausowenig das highway=tertiary von Way entfernen und an die Punkte schreiben. Ganz genauso ist es mit den Multipolygonen.
Wenn ich ein großes Quadrat (3km Kantenlänge) G und drinnen ein kleines Quadrat (1km Kantenlänge) K und ein Multipolygon M (outer:G, inner:K) habe, dann sind das drei verschiedene Flächen.
-Die Tags an G gelten für die 9km²-Fläche, wenn ein Flächentag dabei ist.
-Die Tags an K gelten für die 1km²-Fläche, wenn ein Flächentag dabei ist.
-Die Tags an M gelten für die 8km²-Fläche.
Weide
Ob Multipolygon oder zusammengeklebte Flächen: da sollte man keine Ideologie daraus machen. Ich komme jedenfalls besser mit der MP-Lösung klar. Wichtig ist in beiden Fällen, dass die gezeichneten Flächen tatsächlich ungefähr so in der Realität zu finden sind. Als echtes Negativbeispiel sehe ich http://www.openstreetmap.org/way/62226481 : Angeblich eine “meadow”-Wiese, aber darin finden sich fast mehr Wäldchen und Felder, und auch die Ränder verlaufen willkürlich durch Flächen, die eigentlich ganz anders gekennzeichnet sein müssten. Hier wäre es besser, erstmal nur die Flächen als Wiese zu taggen, die wirklich eine Wiese sind. Wenn die Lücken erstmal weiß bleiben, ist das kein Schaden.
Ich habe heute zum Jahresabschluss die Wildenkaralm mit ein paar Multipolygonen “ausgemalt”: http://www.openstreetmap.org/relation/1876760 und http://www.openstreetmap.org/relation/3409416
Und freue mich, wenn andere das als Vorlage für’s eigene Mappen verwenden.
Ehrlich gesagt, warum so kompliziert, wenn es einfach auch geht?
Nein, das ist nicht vergleichbar. Linien und Punkte sind simple Datentypen. Flächen als simple Datentypen haben wir nicht, nur als solche interpretierte geschlossene Linienzüge. Multipolygone wie auch andere Relationstypen gehen eher in die Richtung Geometry Colletion.
Wenn du highways erwähnst, dann so:an der Linie ist der Tag: highway=tertiary, an der Relation z.B. der ref-Tag. Nach Deiner Lesart würde dann der ref-Tag nicht mehr für alle gelten… Dem ist aber nicht so. Tags, die das Objekt definieren, sind am Objekt. Tag, die alle Elemente der Relation betreffen, sind an der Relation.
Das ist derzeit einzig und allein eine Interpretationsfrage. Man kann es auch (meiner Ansicht nach) einfacher definieren.
Tags an G gelten nur für die Outer-Fläche exklusive der Inner-Fläche (also für die 8m²)
Tags an K gelten nur für die Inner-Fläche (also 1m²)
Tags an M gelten für Outer-Fläche incl. deren Inner-Flächen (also 9m²)
Zum einen ist das nach meinem GIS-Denken logischer und damit wäre man meiner Meinung nach auch etwas näher an OGC-Definitionen.
Meine Sichtweise deckt sich im Übrigen mit meiner Beobachtung in anderen Regionen, wo es so, wie ich es denke, daß es richtig ist, auch gemacht wird. Das ist also nicht so eindeutig, wie es propagiert wird. Heraus kommen wir aus der Situation nur, wenn wir einen echten Datentyp Fläche haben. Denn das ist genau das, was wir mit der MP-Relation eigentlich immer machen. Ein MP im Sinne OGC ist anders definiert. Da ist per Definition die Inner-Fläche NICHT ausgeschnitten. Die ganze Disskussion hatte wir aber zur Genüge… 
Sven
Ja. Aber es ist sinnlos überhaupt noch Multipolygone zu machen, wenn wir nicht zu einem Ergebnis kommen.
Wenn beides nebeneinander existiert, dann haben wir nur Datenmüll.
Die die von Dir angegebene Fläche ist ein Multipolygon, denn ihre Grenze besteht aus zwei Polygonen.Die Tags für diese Fläche willst Du an eine der beiden Grenzlinien schreiben.
Die von Dir angegebene Fläche ist ein Polygon, denn ihre Grenze besteht aus dem Polygon G. Die Tags für diese Fläche willst du ein das Multipolygon M schreiben, obwohl dort auch noch K erwähnt wird, das an der Flächendefinition garnicht beteiligt ist.
Find ich nicht logisch.
Weide
Auch woanders ist ein Multipolygon eine Fläche, deren Rand aus mehreren Polygonen besteht. Deshalb heißt es doch Multi-Polygon.
Weide
Wenn man ausschließlich in Flächen denkt, wie ich, dann schon. Ich gebe die Eigenschaft nicht einer Linie, sondern einer Fläche. Inner- und Outerflächen sind dann noch immer simple, eigenschaften-behaftete Flächen. Bei Vorhandensein von zwei Flächen in einer Relation (Multipolygon) heißt das dann Outer-Fläche ist gleich Fläche der Outer-Rolle Minus der Fläche der Inner-Rolle. Es ist im Prinzip mit der Clip-Funktion im “großen” GIS vergleichbar. Dann erfüllen die Inner- und outer-Rollen entscheidende Funktionen. Ich könnte nun die Outer-Fläche als simple Fläche hernehmen und mit der Clip-Funktion die Inner-Fläche zum ausstanzen benutzen. Im Ergebnis hab ich ein Polygon A mit einem Loch da, wo ich das Inner-Polygon habe und ein Polygon B, dieses da, wo das Lich ist. Einfache, simple Gis-Aufgaben…
…und was anderes wollen wir mit MP-Relationen nicht darstellen.
Sven
Wo? Das verstehe ich nicht. Meinst du diese aus mehreren Liniensegmenten zusammengesetzten Dinger? Das ist glaube ich ein MultiLineString…
http://portal.opengeospatial.org/files/?artifact_id=25355
Sven
Nein, das meine ich nicht.
Es gibt Flächen, deren Rand als **ein ** Polygon darstellbar ist – also Polygonflächen. Es gibt aber auch Flächen, deren Rand nicht als ein Polygon darstellbar ist – alle Flächen mit Löchern gehören dazu. Das sind die Multipolygonflächen.
Polygonflächen lassen sich in OSM als geschlossene Linien darstellen, wenn mindestens eines der Tags klar macht, dass keine Linie sondern eine Fläche gemeint ist. Diese Regel (die älter ist als die Erfindung der Multipolygone) gilt beim von mir vertretenen Konzept immer und ausnahmslos.
Multipolygonflächen haben mehrere Ränder und kommen daher (nach meiner Meinung) mit allen Rändern und den Tags in eine Pseudorelation mit dem Typ Multipolygon.
Weide
PS: Ich nenne die MP-Relationen Pseudorelationen, weil sie im Gegensatz zu Relationen nicht aus mehreren Objekten ein Gesamtobjekt bilden, sondern nur die Geometrie der Member-Objekte nutzen, ohne dass deren Tags irgendeine Rolle spielen würden.
Das ist das Problem an OSM. OSM kennt keinen Datentyp Polygon. Ein echtes Polygon darf eben auch eine Fläche mit einem Loch sein und genau in diese Richtung interpretiere ich diese MP-Relationen
Von einem Tag abhängig zu machen ob aus einem Objekt eine Fläche wird, halte ich für äußerst problematisch und wird in GIS-Kreisen nicht gemacht… nun gut, ist aber nun mal so. Eigentlich muß es andersrum sein: ein Tag ist zulässig für nur einen, zwei, oder alle Datentypen.
Hm… durch das Vorhandensein von mehr als einem Objekt in der Relation und der Angabe von Tags und den Rollen bilde ich aber ein Gesamtobjekt.
Sven
Nein. Ein Polygon ist ein Vieleck: Dreieck, Viereck, Fünfeck, usw.
Die Fläche eines Polygons kann kein Loch haben.
Weide
Ja, wir sollten Flächen als eigenen Datentyp bekommen.
Weide
Ja, auf Ebene der Darstellung ist das so. Aber inhaltlich gesehen ist es doch so, dass etwa eine Buslinie sich verändert, wenn sich eine ihrer Haltestellen ändert. Beim MP – etwa für eine Fläche in einem Autobahnkreuz – spielt das angegebene Objekt an sich gar keine Rolle. Wenn etwa aus der als Flächenrand angegebenen Autobahnabfahrt ein Waldlehrpfad wird, dann hat sich das im MP angegebene Objekt total verändert. Das mit dem MP beschriebene Objekt hat sich dadurch aber garnicht verändert. Es werden also inhaltlich nicht die angegebenen Objekte zusammengefasst, sondern nur ihre geometrischen Eigenschaften.
Weide
Ein Grundproblem im momentanen Datenmodell ist, dass Geometrie/Topologie und Bedeutung/Semantik/Eigenschaften teilweise vermischt sind.
Je nach Attribut/Tag gibt es Linienzüge (ways), die geschlossen sein müssen (landuse=) oder nicht (highway=).
Bei den Attributen für MPs als Relationen gibt es welche, die nur die Geometrie betreffen (inner/outer), andere meinen das gesamte Objekt (name=* für den gesamten Wald incl. Lichtungen, ebenso Gebäude mit Innenhof), wieder andere nur Teilflächen zwischen inner und outer (roof:colour, wood=coniferous).
Nach der Definition des Open Geospatial Consortium (OGC) sehr wohl - siehe Figure 11 in http://portal.opengeospatial.org/files/?artifact_id=25355
Und übrigens, Du widersprichst dir selbst:
Das hieße ja, der Rand eines MP bestünde aus Vielecken.
Das wird immer wieder gefordert. Aber wie sollte dieser Datentyp denn aussehen, worin sollen sich z.B. eine kreisförmige Fläche und eine kreisförmige Linie wie bei einem Kreisverkehr unterscheiden?
Und welch Probleme sollen damit gelöst werden?
Franz
Dann hast du das schon öfters verlinkte Domument nicht gelesen: http://portal.opengeospatial.org/files/?artifact_id=25355: Nummer 6.1.11: Polygon,Triangle
Sven
Wenn ich eine Linie zeichne, dann zeichne ich eine Linie Ob diese dann einen delben Anfangs- und Endpunkt haben oder nicht ist dann primär egal. Die Linien der Straßen, Wasserwege und Bahnstrecken stellen im Prinzip primär Vektoren zum Routing dar, (mit Tags zu Geschwindigkeit, diverse Abbiegebeschränkungen, ect.)
Welche Probleme: Darstellung von Flächenobjekten als Fläche, bessere Auswertemöglichkeiten, bessere Kontrolle und Überprügung vin Topologiefehlern. Bei immer besserer Luftbildbasis wird immer feiner ind detaillierter gemappt. Das Vorhandensein von Z19 macht es meiner Ansicht nach erforderlich, in städtischen Bereichen verstärkt Flächen Straßen, Fußwege, Grünflächen ect. zu mappen.
Sven