Multipolygone, z.B. See oder Gebäude in Waldfläche

Hallo tippeltappel

Auch das OSM-Wiki unterliegt dem Problem, dass es dort veraltete Informationen gibt. :wink:
Weiter oben steht in Anmerkungen Punkt 2: Die Richtung der Linien spielt keine Rolle.

Als erster Punkt wird erwähnt, dass outer oder inner auch aus mehreren Wegstücken
zusammengesetzt sein dürfen.
Eine Begrenzungslinie kann aus mehreren Teillinien “zusammengestückelt” werden,
solange die Linien in ihrer Gesamtheit einen geschlossenen Ring bilden.

Der beste Weg ist in der Tat Multipolygone zu verwenden.
Damit wird das Verhältnis von Flächen in Flächen beschrieben.

Es ist dabei unerheblich, ob die Flächen-Typen sich gegenseitig ausschliessen
(See in Wald) oder die innere spezifischer ist als die äussere (Fußballfeld im Stadium).

Edbert (EvanE)

Ja, ich denke auch, daß die Verwendung der Multipolygone letztendlich die sauberste Methode ist, die Verhältnisse der Flächen zueinander darzustellen. Da kann man trotz der ärgerlichen Löcher keine Rücksicht auf die Renderer nehmen. Wer einmal vor dem Problem gestanden hat, Renderregeln für eine Karte zu erstellen, in der gleichartige Flächentypen völlig unterschiedlich übereinander gestapelt werden, der weiß dieses System zu schätzen.

Beispiele:

(1)
kleines Gewässer
^
Lichtung
^
Wald
^
Insel
^
großes Gewässer

wurden beide Gewässer mit demselben Tag versehen, liegt bei der Stapelmethode das kleine Gewässer entweder mit dem großen Gewässer zusammen unter Insel und Wald, oder beides liegt oben.

(2)
Lichtung
^
Wald

und auf derselben Karte

kleine Waldstücke
^
ausgedehnte Wiesenflächen

Solche Situationen sind mit “Stapelregeln” nicht in den Griff zu bekommen, wenn dieselben Kartenobjekte in verschiedenen Ebenen auftauchen bzw. in verschiedenen Folgen gestapelt werden sollen. Egal, was man macht, irgendein kleines Polygon wird unter einem großen verschwinden.

Mit Multipolygonen ist es dagegen einfach. Die Inner-Konturen stanzen gewissermaßen Löcher in das Outer-Element. Innerhalb dieser Löcher legt man dann paßgenaue Puzzlesteine, indem man für die Inner-Kontur eine Flächen-Definition vergibt. Da man für die Inner-Kontur gleichzeitig eine zweite Relation definieren darf, die dieses Element als Outer-Kontur interpretiert, kann man auch in diese Fläche wieder mit Hilfe von Inner-Konturen Löcher schneiden, in die dann ebenfalls Puzzlesteine gesetzt werden.

So jedenfalls habe ich das System verstanden. Korrigiert mich bitte, wenn ich falsch liege.

Gruß
tippeltappel

Ich kenne keinerlei Probleme bei der Kombination gleichartiger Flächentypen (landuse in landuse, natural in natural, …) in Multipolygonen. Mal bitte ein Beispiel für ein derartiges Problem.

Das einzige mir bekannte, was nicht funktioniert, ist etwas wie landuse=forest in landuse=forest. Dann wird innen ein Loch ausgeschnitten. Das ist aber wohl eher ein Fallback-Mechanismus, um das allererste veraltete Multipolygonkonzept von OSM zu berücksichtigen, wo Innen- und Außenrand noch gleich getaggt wurden (Da wurden Innen- und Außenpolygon über die Drehrichtung unterschieden).

Die OpenCycleMap bleibt natürlich außen vor.

Hallo, die mapnik Karte schaut im Bereich des Teichs großräumig nun blau aus. Hat das was mit meinen Änderungen zu tun? Das sehe ich zum ersten Mal.

Ist richtig, mit Advanced Multipolygonen geht es noch einfacher, das wird aber nur von wenigen Renderern
unterstützt.

Siehe Fig.7 in:

http://wiki.openstreetmap.org/wiki/Multipolygon#Advanced_multipolygons

EDIT: Sehe gerade, dass das Beispiel nicht ganz passt. Falls die mittlere Fläche keine “Lochfläche” ist, benötigt man
wohl wieder 2 Multipolygone.

Chris

Hallo Ebbe

Das ist wohl ein Missverständnis. Ich meinte Situationen in denen die üblichen
Renderer auch ohne Multipoligone mit Flächen in Flächen klar kommen.

Warum einiges auch ohne Multipolygone funktioniert, liegt an der Reihenfolge
in der verschiedene Objektarten gerendert werden.

  • Häuser werden nach (=über) Landnutzung gerendert.
  • Straßen werden nach Landnutzung und Häusern gerendert.
    Deswegen braucht es ein Multipolygon wenn ein Haus (z.B. Kirche)
    innerhalb einer Fußgängerzone (=Straße) steht.

Was meistens nicht geht, sind einzelne Sportplätze (leisure=pitch) innerhalb
eines Sportgeländes (leisure=sport_centre). Da braucht es Multipolygone,
damit die Renderer die Zusammenhänge erkennen können.

Macht ja im Prinzip wenig Sinn, es sei denn die innere Fläche hat einen
eigenen Namen oder andere abweichende Eigenschaften wie Baumart.
Aber dann sind Innen und Aussen auch unterschiedlich getaggt.

Es gibt noch eine Situation, wo die Renderer mit advanced Multipolygonen
nicht klar kommen: (Wald (See (Insel=Wald)))
Den Wald auf der Insel darf man bei advanced Multipolygonen im Prinzip
wieder als outer mappen. Das raffen die Renderer aber bisher nicht.

Das kann man allerdings mit zwei geschachtelten Multipolygonen
problemlos darstellen.

Tja, leider.

Edbert (EvanE)

Stimmt, für Häuser und Straßen verwende ich (und die meisten anderen Multipolygon-Mapper, oder nicht?) normalerweise keine Multipolygone. In solchen Fällen braucht man auch dort welche.

Etwas spät, aber vielleicht ist das http://www.openstreetmap.de/karte.html?lon=8.61138&lat=49.99501&zoom=16&layers=0B0FT ein Beispiel für so ein Problem. Es geht um das Gebiet, welches durch einen Rahmen mit dem Text “Ehemaliges Munitionsdepot und Pilzzucht” bezeichnet ist. In diesem Gebiet sollte es keine Löcher geben, d.h. keine grauen Flächen. Diese grauen Flächen enthalten Wald.

Egal, ob ich das falsch verstehe, es falsch ist, es ein Beispiel für so ein Problem ist oder nicht, die Karte bildet die Realität nicht ab und es wäre schön, wenn das korrigiert werden könnte – ich weiß nicht, wie es geht.

Erste Erkenntnis auf die Schnelle:
Osmarender stellt den Wald dar, sogar unterschiedliche Arten.
Mapnik nicht.

Mal was grundsaetzliches zu Multipolygonen:

Eine Multipolygon-Relation drueckt aus, dass die inneren Bereiche nicht zu der Gesammtflaeche gehoeren. Es geht dabei nicht darum, die Anzeige beim Renderer huebscher zu machen!!!

Wer also ein Spielfeld per Multipolygon aus dem Stadium ausschneidet, der traegt Muell in die Datenbank ein. Genauso gehoert z.B. auch ein Haus zur Gesamtflaeche Wohngebiet. Umgekehrt gehoert eine Insel aber definitiv nicht zur Wasserflaeche.

Die Frage, ob Multipolygon oder nicht, sollte nicht anhand des Renderer-Ergebnisses entschieden werden sondern immer Anhand des logischen Zusammenhangs zwischen Innerem und Aeusserem. Denn es gibt ja noch andere Anwendungsmoeglichkeiten ausser den Renderern, und die wuerden sonst einfach nur schrott leiefrn, ob wohl doch alles “gut aussieht”.
Es sollte also vollkommen egal sein, ob die “üblichen Renderer auch ohne Multipoligone mit Flächen in Flächen klar kommen”. Wir taggen ja NICHT NUR fuer die Renderer, sondern wollen shcon moeglichst richtige Daten in der Datenbank haben.

Gruss
Torsten

Das ist mir leider nicht genau genug. Was würde denn zu einer Gesamtfläche gehören und was nicht? Ursprünglich ging es ja darum, ob landuse innerhalb von landuse oder natural innerhalb von natural funktioniert, oder nicht. Dafür wurde ein nicht funktionierendes Beispiel gesucht. Wenn die Gesamtfläche landuse=forest ist, und die einzelnen Teile darin für Laub- Nadel- bzw. Mischwald stehen, ist da also nach Deiner Intention Multipolygon richtig oder “Müll”? Wenn sich hier keine eingängige Abgrenzung finden läßt, wird das wohl wieder jeder machen, wie er will… – bzw. für richtig hält.

Ack.

Ich weiß und ich stimme dem generell auch zu. Dieser Fall ist leider etwas anders. Es könnte sein, daß eine Bürgerinitiative die OSM-Karte demnächst verwendet. Ob aber überhaupt und wenn ja wie, steht alles noch nicht fest. Sollte dies jedoch passieren, wäre es schon wichtig, daß die Karte die Realität abbildet. Diesen “Anwendern” wären die inneren Regeln und Motive der OSM-Community nämlich egal, die würden die Karte verwenden, um ihre Ziele zu verfolgen. Und da wirken solche Löcher in der Karte vielleicht etwas – hmmmm – eigenartig.

Und jetzt noch einmal konkret zu der Beseitigung der Löcher: Im Wiki steht http://wiki.openstreetmap.org/wiki/DE:Key:landuse, daß landuse=forest und natural=wood nicht gemeinsam verwendet werden sollen. Genau dies wurde hier aber getan. Und wenn ich das richtig geprüft habe, werden genau diese Flächen als Löcher dargestellt. Ich probiere das mal aus. In JOSM macht das schon mal keinen Unterschied in der Darstellung.

Scheint, als hätte sich in Bezug auf Mapnik da kürzlich was geändert: Auf höchstem Zoom-Level sind einige Kacheln der Löcher noch grün, jedoch verschwindet dieses jetzt – vermutlich, weil die Kacheln durch meinen Zugriff nach und nach neu gerendert werden…

Renaturiert und landuse=forest passen auch irgendwie nicht zu natural=wood :wink: Entweder das eine oder das andere - oder ineinander verschachtelt.
Beim größten Teilstück sollte man ja bald den Unterschied sehen, den Rest würd’ ich auch noch anpassen. Bei der Gelegenheit könnte man auch gleich noch name=Laub-|Mischwald entfernen, wood ist ja überall schon korrekt gesetzt.

HiHo

bezieht sich das auf das Problem der absaufende Gelände?

http://www.openstreetmap.org/?lat=52.39931&lon=13.22032&zoom=16&layers=C

oder die trockengelegte Havel bei Werder/H

http://www.openstreetmap.org/?lat=52.38263&lon=12.94051&zoom=15&layers=C

Kopfkratz
Lars

Die momentane Darstellung der Realität ist verwirrend. Nach längerer Betrachtung nehme ich an, es soll folgendes dargestellt werden:
Im großen Wald “Forst Mörfelden Ost” liegen die Flächen “Ehemaliges Munitionsdepot und ehemalige Pilzzucht” und “ehem. Nummernsender E5”, die aus dem Wald ausgeschnitten werden sollen. Das weitere Polygon, das “ehem. Nummernsender E5” einschließt und keine Tags hat, ist überflüssig und wäre zu löschen. Darüberhinaus könnten die Begrenzungen der beiden Flächen auch ganz entfallen und durch die angrenzenden Wege ersetzt werden. Dies wird jedoch unterschiedlich gesehen und gezeichnet. In diesem Gebiet scheint es üblich zu sein für Wege und landuse getrennte Linien zu zeichnen.


Multipolygon (3 Elemente):
  outer  "Forst Mörfelden Ost" 
  inner  "Ehemaliges Munitionsdepot und ehemalige Pilzzucht" 
  inner "ehem. Nummernsender E5", 

Die Fläche “Ehemaliges Munitionsdepot und ehemalige Pilzzucht” besteht überwiegend auch aus Wald, jedoch ist dieser je nach Art des Waldes in viele Stücke geteilt worden. Es gibt keine außenliegende, größere Fläche aus der Löcher ausgeschnitten werden könnten. Also kein Multipolygon, sondern


Boundary (1 Element):
  "Ehemaliges Munitionsdepot und ehemalige Pilzzucht"

Das große Waldstück im Westen mit “wood=deciduous” beiinhaltet eine Farm, also


Multipolygon (2 Elemente):
  outer  (Aussenlinie) 
  inner  (Farm) 

Entsprechend das Waldstück mit dem See.
Die übrigen Flächen (forest, brownfield, scrub) haben keine Löcher, also einfache Flächen durch landuse= gekennzeichnet.

Da ich nicht weis ob diese Interpretation stimmt, ist sie nur skizzenhaft dargestellt und ich habe keine Änderungen vorgenommen, um nichts zu zerstören oder falsches einzuführen. Auf Wunsch und bei entsprechender Bestätigung kann ich die Änderungen gern durchführen, kann aber nicht versprechen, dass dann auch wie erwartet gerendert werden.

Willi

Wie bei OSM ueblich ist das natuerlich nicht klar definiert sondern es wir din Einzelfaellen unterschiedliche Meinungen geben. Das finde ich auch nicht problematisch. Was es aber nicht geben sollte, ist ein Einsatz von Multipolygonen, der allgeimen als unlogisch angesehen wird und ausschliesslich in der Verbesserung des Rendererergebnisses motiviert ist. In diesem Zusammenhang sein noch mal auf das Beispiel Spielfeld innerhalb einer Sportanlage verwiesen.

Das funktioniert NIE. Zwei sich ueberdeckende Landnutzungen sind einfach ein logischer Widerspruch. Ob das beim Renderer dann richtig angezeigt wird, hat nur was mit Zufall zu tun aber nichts mit ordentlichem Tagging.

Das kommt darauf an, wie man die einzelnen Polygone markiert. Z.B.:

a) Man hat eine grosse Flaeche landuse=forest ohne weitere Tags, mit der man ein zusammenhängendes Waldgebeit kennzeichnet, mit unterschiedlichem bzw. unbekanntem Bewuchs. Und innerhalb dieses Gebietes hat man eine Flaeche reinen Nadelwald, der mit landsue=forest und wood=c… (weiss das Tag gerade nicht :slight_smile: gekennzeichnet ist. Dann macht es logisch durchaus Sinn, wenn diese Innere faleche aus dem auesseren per Multipolygon “ausgeschnitten” wird.

b) Wenn die innere Flaeche nur mit wood=* gekennzeichnet ist, dann ist ein Multipolygon sicherlich falsch. Denn im inneren Bereich gilt ja sowohl das landuse=forest als auch das wood=*.

Interessant wird die Sache dann, wenn der Wald als ganzes einen Namen hat. Da muss man sich dann halt beim Tagging genau ueberlegen, was wo gelten soll und was nicht.

In diesem Zusammenhang sei noch bemerkt, dass in einer heilen OSM-Welt die Tags bei einem Multipolygon eigentlich wie folgt anzubringen waeren:

  1. die gesammte Flaeche: beim aeusseren Polygon
  2. nur die innere Flaeche: beim inneren Polygon
  3. die aeussere Flaeche ohne den inneren Teil (also 1. ohne 2.): bei der Multipolygon-Relation

Historisch bedingt, da die Tags bei der Multipolygon-Relation meist nicht berücksichtigt werden, hat sich bislang folgendes am meisten verbreitet:
i. die gesammte Flaeche: entweder sowohl beim inneren und auch beim aeusseren Polygon, oder halt eine einfaches Polygon ohne multipolygon-Relation
ii. nur die innere Flaeche: beim inneren Polygon
iii. die aeussere Flaeche ohne den inneren Teil: beim aeusseren Polygon

Welches Schema man auch immer verwendet, vorher sollte man sich auf alle Faelle klar machen, in welchem Gebiet welches Tag gelten soll.

Gruss
Torsten

@Willi2006 und @de_muur

Schon mal vielen Dank für Eure Hinweise. Ich werde erst einmal selbst versuchen, das Problem damit zu lösen. Vielleicht kann dann ja noch mal jemand drüber schauen – möglicherweise brauche ich aber auch noch weitere Hilfe. – Jetzt will ich versuchen, etwas dabei zu lernen.

Ich habe mir das noch einmal angeschaut und bin nun der Meinung, daß Mapnik hier ein Problem hat. Im Allgemeinen scheint Mapnik Multipolygone schon richtig darstellen zu können, aber folgender Fall funktioniert nicht:

Man hat ein größeres Waldgebiet der Art landuse=forest, das an der Relation – und nur an der Relation, wie es laut Wiki sein soll – z.B. als Mischwald gekennzeichnet ist. Wenn es in diesem Waldgebiet nun Bereiche von Laubwald gibt und man diese über die Multipolygon-Relation als Löcher darstellt und diesen Löchern dann die Eigenschaften landuse=forest und wood=deciduous gibt, so werden diese Löcher durch Mapnik als Löcher dargestellt, nicht als Laubwald – sie sind nicht mal grün. Osmarender macht das alles richtig.

Das geht auch dann bei Mapnik schief und bei Osmarender gut, wenn die Löcher falsch gekennzeichnet sind. Falsch ist ja z.B. die Auszeichnung mit landuse=forest, natural=wood und wood=deciduous. Lediglich eine Loch-Kennzeichnung stellt Mapnik grün dar: natural=wood und wood=deciduous das ist nun zwar formal korrekt, entspricht aber leider nicht der Realität, denn das fragliche Gebiet ist leider ein forest und kein wood.

Oder habe ich die richtige Version noch gar nicht probiert? Eigentlich müßte man diesen Fall laut Wiki folgendermaßen abbilden:

Name des Waldes am Outer Polygon der Multipolygon-Relation, denn er gilt ja für das ganze Gebiet.

landuse=forest ebenfalls am Outer Polygon, aus demselben Grund.

wood = mixed an der Relation

wood = deciduous an den Löchern.

Ist das so korrekt? Ich werde das Ergebnis mal ausprobieren.

Nein, Du musst beide Relationen mit landuse=forest taggen. Mapnik kann nur ein Objekt aufs Mal bearbeiten, daher weiss Mapnik bei der inneren Relation nicht, dass dort “irgendwo aussenrum” noch ein landuse=forest ist.

(Ohne es genauer zu wissen behaupte ich jetzt mal, dass es bei Osmarender nur Zufall war, dass das Ergebnis richtig aussah. Wie immer wäre ein Link zum entsprechenden Gebiet sehr nützlich.)

Der Link war schon weiter oben – vermutlich zu weit oben, sorry. Meine letzte Vermutung geht aber auch gar nicht, dann sie würde nur funktionieren, wenn alle Löcher landuse=forest haben, was aber nicht der Fall ist.

Hier noch einmal der Link mit den Löchern, ich habe das Ganze schon etwas aufgeräumt. http://www.openstreetmap.org/?lat=49.9951&lon=8.61147&zoom=16&layers=M