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

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

Link zum Problem: http://www.openstreetmap.org/?lat=49.99463&lon=8.60812&zoom=15&layers=M

Der Name des Waldes muss an das outer-Polygon (Way 68082483). Der Name darf nicht ans Multipolygon, wenn er auch für die Löcher darin gelten soll. Ist das Tagging als ref statt name eigentlich Absicht?

Beim Mischwald (Way 68082483) sollte der landuse-Tag entfallen, weil diese Eigenschaft im Multipolygon (1074432) anzugeben ist – dort gehört auch wood=mixed hin. Der Landuse gilt ja nur für das Multipolygon, nicht für die Löcher darin. Die Löcher müssen separat als landuse=forest beschrieben werden, weil der Render nicht annehmen darf, dass alle Löcher landuse=forest sein sollen. In deinem Beispiel wäre sonst das Antennenfeld nie darstellbar.

An die Löcher muss landuse=forest und wood=deciduous. Damit sind diese als Laubwälder definiert.

Dein Beispiel sollte damit korrekt gezeichnet werden, das wird aber in Mapnik und JOSM nicht passieren! Der Grund hierfür ist die Kompatibilität mit einem alten Schema: Die Löcher wurden damit dargestellt, sie wie das outer-Polygon zu taggen. Bitte das alte Schema nicht mehr benutzen.

Du kannst dir damit behelfen, dass du auch die Laubwälder (inner-Polygone) nicht taggst. Stattdessen müsstest du jeweils ein Multipolygon mit landuse=forest und wood=deciduous erstellen und nur das Laubwald-Polygon (das ohne Tags) in der Rolle outer zuordnen. Das hat die selbe Bedeutung wie die Tags direkt am Laubwald-Polygon anzubringen.

Wünschenswert wäre es, wenn die Editoren Multipolygone im Hintergrund erstellen würden und Flächen immer mit Multipolygonen dargestellt würden. Eine einfache Benutzeroberfläche hierfür will mir aber leider noch nicht einfallen. Die Render sollten ihrerseits die Kompatibilität zum alten Schema aufgeben, weil dies der Beschreibung mit Multipolygonen widerspricht und viele Fälle nicht darstellen kann.

Halten wir für derzeitige Implementierungen fest: Wenn die inner-Polygone die selbe Art Inhalt haben wie das Multipolygon (also beispielsweise jeweils Wald), dann muss für das innen liegende Polygon ein Multipolygon erstellt werden. Dem ist dann nur ein Mitglied, das innen liegende Polygon, zugeordnet und es trägt die Beschreibung des Inhalts. Das innen liegende Polygon bekommt keine Tags.
Hiermit besteht kein Widerspruch zum alten Schema und die Render sollten sich wie erwartet verhalten.

Danke, Augustus, das wäre genau die nächste Vermutung gewesen, die ich angestellt hätte… :wink:

Edith meint: die innere Wiese sollte dann auch noch in ein Multipolygon verpackt werden. :wink:

Auch wenn ich den Text drei mal lese, dann verstehe ich das so, dass du vorschlaegst, eine MULTIpolygon-Relation zu erzeugen, die nur ein einziges Polygon enthaelt. Das scheint mir doch arg widersinnig. Kannst du vielleicht anhand eines Beispiels nochmal erlaeutern, was du genau meinst?

Gruss
Torsten

Es ist wirklich so gedacht, eine Multipolygon-Relation mit nur einem Polygon zu erstellen. Normalerweise ist dies unnötig und verkompliziert die Angabe des Inhalts nur, aber in dem genannten Fall entspricht die einfache Angabe einem veralteten Schema zur Beschreibung von Löchern. Obwohl das Multipolygon eigentlich unnötig ist, wird damit die Verwendung des alten widersprüchlichen Schemas umgangen, womit die Render keine Löcher mehr erzeugen.

Nehmen wir als Beispiel einem Mischwald (außen) in dem ein Laubwald (innen) liegt:
Hierfür brauchen wir erst einmal ein Multipolygon für den Mischwald mit Loch. Die Relation enthält die Tags type=multipolygon, landuse=forest, wood=mixed. Die Objekte in der Relation sind das äußere Polygon (role=outer) und das innere Polygon (role=inner).
Anschließend brauchen wir ein zweites Multipolygon für den Laubwald. Die Relation enthält die Tags type=multipolygon, landuse=forest, wood=deciduous. Die Relation enthält nur das innere Polygon (role=outer).

Nehmen wir als anderes Beispiel einen Wald mit Lichtung nach altem Schema:
Wir brauchen keine Relationen, weil diese zu der Zeit noch nicht erfunden waren. Das äußere Polygon bekommt den Tag landuse=forest, das innere Polygon bekommt den Tag landuse=forest.
Weil beides Mal das Tag landuse=forest genutzt wird, schneidet der Render das innere Polygon aus und erzeugt die Lichtung.

Der gestern beschriebene Fall ist ein komplexeres Beispiel Mischwald mit Laubwald. Hierbei wird unbeabsichtigt das alte Schema verwendet, was dazu führt, dass die Löcher erzeugt werden, wo der Laubwald sein sollte.
Das erste Beispiel ließ sich mit dem alten Schema übrigens nicht darstellen. Deshalb haben wir heute Multipolygon-Relationen.

Die nachfolgende Erläuterung hat nicht mehr direkt mit der Frage zu tun und ist eine allgemeine Erklärung.

Der Name „Multipolygon" ist etwas unglücklich gewählt, darstellen lassen sich damit:

  • Löcher in Polygonen.
  • Flächen ohne Löcher, aber Begrenzung durch mehrere Linien statt eines Polygons.
  • Objekte, die aus unterschiedlichen Polygonen bestehen ohne einander zu berühren.
  • Beliebig komplexe Kombinationen aus der Liste.

Im Bild [1] ist genau ein Multipolygon dargestellt. Es besteht aus 3 getrennten Polygonen, 2 davon mit Löchern. 5 Polygone werden dabei durch Linien und nicht durch Flächen beschrieben.
Die 3 außen liegenden Polygone werden durch Objekte mit der Rolle outer beschrieben – unabhängig davon ob sie ungeschlossene Linien oder Ringe sind. Im Bild haben die Objekte in der Rolle outer die Bezeichnungen: (1, 2, 3, 4), (12, 13, 14, 15) und (20). Die Klammern stellen die einzelnen gebildeten Polygone dar. Dies bildet schon einmal die 3 Polygone (noch ohne Löcher) und markiert sie als 1 Objekt (beispielsweise nicht zusammenhängender Verwaltungsbezirk).
Um darin nun die Löcher zu erzeugen, müssen Objekte in der Rolle inner hinzugefügt werden. Im Bild sind diese beschrieben als: (5, 6), (7, 8, 9, 10), (11), (16, 17, 18, 19). Die Löcher werden nun vom Render aus den 3 Polygonen (Rolle outer) ausgeschnitten. Übrig bleibt alles, was im Bild grau ist.
Das Graue beschreibt 1 Objekt. Alle Tags an der Multipolygon-Relation gelten für das Graue. Die Tags an der Relation gelten nicht für Dinge außerhalb des Grauen – also nicht innerhalb der Löcher.

[1] http://wiki.openstreetmap.org/wiki/File:Multipolygon_Illustration_6.svg

Jetzt verstehe ich was du meinst. Mit dem Einsatz von Multipolygonen sollte man aber moeglichst sparsam umgehen. Die Advanced-Multipolygone erlauben theoretisch extrem komplexe Gebilde. Nur taugt sowas fuer ein freies Projekt nicht: Das versteht dann keine Gelegenheistmapper mehr und die Fehlerquote explodiert.
Aus diesem Grund wird ja auch nach vorherschender Meinung abgelehnt, irgendwelche Flaechen einfach als ein Multipolygon der umgebenden Linien zusammenzubauen. Stattdessen traegt man die Flaeche lieber als eigenes, geschlossenes Polygon ein und hat dann am Rand doppelte Linien.

Genauso wuerde ich auch in deinem Beispiel lieber mit mehreren, uebereinanderliegenden Polygonen arbeiten. Z.B. koennte man das innere Polygon doppeln, einmal ist es leer und dient ausschliesslich als (innere) Grenze fuer die aeussere Flaeche und einmal markiert es komplett eigenstaendig die innere Flaeche. Das halte ich fuer verstaendlicher, als wenn eine Linie gleichzeitig zwei verschiedene Flaechen definiert.

Das Beispiel passt so nicht, denn wenn man keine Relationen hat/kennt, dann gibt es auch keine Loecher. Die Multipolygon-Relationen sind ja gerade dafuer erfunden worden, um Loecher in Flaechen definieren zu koennen.
Ohne Relation ist es dann reiner Zufall, welches der Polygone ueber dem anderen gezeichnet wird.

Der erste Punkt ist der urspruengliche Zweck von Multipolygonen, die erst nachtraeglich unter dem Titel Advanced Multipolygon erweitert worden sind.

Der zweite Punkt ist aeusserst umstritten. benutzt wird er in Deutschland hauptsaechlich bei den Grenzrelationen, wobei das aber eine deutsche Besonderheit ist, die Flaechen-Relationen ueberhaupt auf die Grenzlinien anzuwenden.

Der dritte Punkt ist relativ harmlos, da man das auch problemlos ohne Relation darstellen kann.

Und der vierte Punkt zeigt ganz klar, wo das Problem liegt. OSM ist kein Wettbewerb, bei dem es darum geht, moeglichst komplizierte Konstrukte zur Beschreibung zu verwenden. In einem freien Projekt ist die einfachste Loesung immer die beste Loesung.

Gruss
Torsten