Multipolygone verstehen und deren Render- Darstellungsprobleme Lösen.

Im OSM- Wiki wird empfohlen im freien Kartenprojekt Openstreetmap möglichst geschlossene Uni-Polygonringe, (Kreise bestehend aus einer einzigen Linie) zu zeichnen.

Dieses Modell sei für Anfänger leichter verständlich, weiter wird nicht darauf eingegangen warum es diese Empfehlung gibt.

Ich versuche eine Erklärung.

Bei einer zu einem Kreis geschlossenen einzelnen Linie -die zum Beispiel einen Wald beschreibt-, ist klar welche Fläche innerhalb, und welche Flächen außerhalb des Waldes liegt. Dementsprechend einfach ist es für den Rendererer die innere Kreisfläche grün auszumalen.

Handelt es sich hierbei um einen Wald mit großen Ausmaßen, und ich Zoome auf eine im Wald befindliche Forsthütte, so benötigt der Renderer trotzdem die komplette Information des Äußeren Ringes damit der Wald richtig gezeichnet wird.

Bei einer Kreisform ist Innen und Außen ziemlich klar, nicht jedoch wenn die Kreisform wie bei Multipolygonen aus vielen einzelnen Teilstücken besteht.

Linien im Openstreetmap Projekt haben eine Richtung. Dreht man die Linien Richtung, zum Beispiel einer Einbahnstraße um, so erkennt dieses der Editor und ändert das Einbahn Attribut von oneway=1, auf oneway=-1.

Teilsegmente eines Multipolygons haben ebenfalls eine Richtung. Zusätzlich mit der Linienrichtung ist im OSM Datenmodell für uns unsichtbar das Attribut “Innen oder Außen” verknüpft. Dieses Attribut ist für den Renderer wichtig, damit dieser weiß wie er wie im Obigen Beispiel beschrieben, Flächen richtig Rendern (ausmalen) kann.

Soweit kein Problem.

Bearbeitet man nun von einem Großen Multipolygon nur ein kleines Teilsegment, so besteht die Gefahr dass, sofern im Editor nicht das gesamte Multipolygon geladen wurde, die Information “Innen” oder “Außen” bricht.
Zur Interpretation dieser Information sind alle Teile eines Polygons nötig.

(Andere GIS Datenmodelle kennen dieses OSM spezifische Problem nicht, da bei diesen, Innen und Außen an die Linienrichtung gekoppelt ist.)

Bei der Bearbeitung an Teilen eines Multipolygons ist es daher unabdingbar immer darauf zu Achten das komplette Polygon zu laden, und durch Sortieren der Polygon Teile die für den Renderer wichtige Information über Außen und Innenseite des Polygons zu aktualisieren. Bei großen Multipolygonen mit vielleicht mehreren Tausend Node´s, wird dadurch das Arbeiten an MP- Details zeitaufwendig. Eine Lösung ist hier das Vermeiden, oder verkleinern Großer Multipolygone.

Typische Fehlerbilder von Multipolygonen bei denen die “Außen/Innen” Information verloren gegangen ist: Entweder wird die Polygon Fläche gar nicht gerendert, oder bei gewissen Zoom Stufen einstehen Weiße Flecken in der Landkarte.

Bei Multipolygonen deren Formen stark von der Kreisform abweicht kommt es übrigens manchmal zu ähnlichen “Flecken” Effekten. Manche raten von einer weiteren Unterteilung von MP-Flächen ab, und sehen eine Lösung für dieses Problem, in künftigen Verbesserungen der Renderer.

Und was lehrt uns dies? Multipolygon-Relationen nur dann verwenden, wenn es unbedingt nötig ist!

Auch wer Multipolygone nicht mag, muss sich mit diesen letztlich doch auseinandersetzen. Eine besondere Blüte im Zeichnen von Polygonen, unter Einbeziehung von Straßen ist diese Relation. https://www.openstreetmap.org/relation/4569438#map=18/47.47098/13.23076

Unter Verwendung von Polygon Ringen, neigen Mapper- hier gut ersichtlich zum Zeichnen nur grober Umrisse. Für einen Religionskrieg ist die Ablehnung von Multipolygonen daher nicht geeignet. Diese Ablehnung erzeugt leider vielmehr überwiegend minderwertig gezeichnete OpenStreetMap Karten.

Beispiel einer hochaufgelösten OSM-Karte unter Verwendung von Multipolygonen und feingliedrig gezeichneten Linien: https://www.openstreetmap.org/#map=16/47.4955/12.3684

Der Städte und Gemeindebund Österreich stellt uns Österreicher hoch aufgelöste Luftbilder zur Verfügung. Es besteht daher kein Anlass dass wir uns an der nur groben Openstreetmap Zeichnung anderer Ländern wie Deutschland orientieren.

Edit: Link

Es ist leider müßig, mit dir über das Thema zu diskutieren. Das zeigen zahlreiche andere Threads, die dieses Thema behandeln. Ich finde es verwerflich, User, die mit MP-Relationen sparsam umgehen, als schlampig oder oberflächlich zu bezeichnen. Bei meinen Streifzügen durch die OSM-Welt ist mir alles untergekommen - genau gezeichnete Polygone und ungenau gezeichnete Multipolygone. Jedem das Seine, genau wie er es mag, aber niemand soll einem Anderen seine Arbeitsweise aufzwingen.

Hallo Wolfgang. Im Streben nach Perfektion darf man sich der nötigen Hilfsmittel bedienen. Multipolygone zu verstehen ist daher keinesfalls verwerflich. Die eigene Erfahrung weiterzugeben ist freundlich.

Wer selbst meint in einer 8 Bit Pixelgrafik Welt verbleiben zu wollen, darf sich anschließend über den Erfolg von z.B. Google Maps nicht beschweren.
Google kennt keine Ecken. https://www.google.co.uk/maps/@47.4717753,13.2271189,17z

Meiner Meinung nach sind Multipolygone tatsächlich das Mittel, um den aktuellen Ecken in OpenStreetMap zu entkommen.

Edit: Link

Beispiel Wald westlich von Sankt Martin am Tennengebirge
Zoom Stufe 12, große Flächen Bereiche werden von Mapnik nicht gerendert.
https://www.openstreetmap.org/#map=12/47.4556/13.3257

Meine derzeitige Lösung für solche Probleme ist:

1.) Kontrolle des Gebietes auf Polygon Fehler: http://tools.geofabrik.de/osmi/?view=multipolygon&lon=13.32644&lat=47.47277&zoom=12&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes

2.) Bei Großen Waldflächen, Multipolygone in JOSM einzeln öffnen und durch Sortieren deren Teilfragmente in Reihe bringen, darauf achten dass es keine Lücken im Polygon gibt.

3.) Verkleinern von stark von der Kreisform abweichenden Polygonen.

Solche “Löcher” in gewissen Zoom Stufen kommen aktuell in der Landschaft öfter vor. Man muss sich mit diesen nicht abfinden.

Edit: Typo

Als den Wald bei St. Martin habe ich mal behoben - wenn man sich mit OSM auskennt, kann man diese “Probleme” ganz leicht lösen. Das hat aber nichts mit MP oder sonst was zu tun.

Zusatz:

Ich möchte aber hinzufügen, dass Almböden und Almwiesen keine “natural=heath” sind - Heiden gibt es in Österreich in dieser Form nicht. Hier wird Unfug getagged.

Edit: Orthographie

Hallo Thomas,
bitte nicht so geheimnissvoll, es wäre speziell zu diesem Fall interessant wie du das Rendering Problem gelöst hast.
Ich habe es bewusst nicht angetastet um es als Beispiel zu zeigen.

Es scheint dass ich doch selbst den rendering Fehler mittels folgendem Changeset (oben angeführte Anleitung) behoben habe. https://www.openstreetmap.org/changeset/36711555
Kacheln in geringen Zoom Level werden nicht sofort neu gerendert. Da hat sich wohl Thomas mit fremden Federn geschmückt. :confused:

Ich weiß was ich gemacht habe und dass es danach gepasst hat. Ich würde dich bitten, dass du dich in Zukunft nicht mehr derart im Ton vergreifst.

Damit man versteht was hier geschehen ist folgende Erklärung:
http://wiki.openstreetmap.org/wiki/DE:Slippy_Map#Rendern_der_Kartenkacheln

Thomas hat also nichts anderes gemacht als bei seinem Browser den Reload Knopf zu betätigen, dadurch wurde vom OSM Server -unter Umgehung diverser Proxies- die neu gerenderte Karten- Kachel abgerufen.

Hat er nicht - da das Neuladen eines Kartenausschnitts keine Kachelregeneration auslöst. Somit wäre es günstig, wenn du den exakten Sachverhalt nicht kennst, einfach mal leiser zu treten.

Und somit habe ich mich nicht mit fremden Federn geschmückt - wie du mir vorwirfst - sondern wirklich das Rendern neu ausgelöst.

Siehe auch den Status der Kachel:

Das war kurz nach meinem Post - während dein CS gar nichts dergleichen bewirkt hat (es sei zudem angemerkt, dass der Server in UK steht und somit um eine Stunde differiert)

EDIT: Beitrag von geocodec gequotet, da sonst wieder was geändert wird.

Also halten wir noch einmal fest.
Ich habe mit einigen Change Sets in diesem Bereich einige aber womöglich noch nicht alle defekten Multipolygone gefixt.

Anschließend hast du neben einem Browser Reload auch noch eine vorzeitige Kachel Regeneration ausgelöst.
https://help.openstreetmap.org/questions/1049/how-to-trigger-a-repaint-for-a-specific-osm-map-tile

Es wird wohl aktuell, noch einige Tage dauern bis der Zoom Level 12 wirklich bei jedem ohne Browser Reload fehlerfrei angezeigt wird. https://www.openstreetmap.org/#map=12/47.4556/13.3257

Edit: Typo

Am Leoben-Stammtisch wurde ueber dieses Thema diskutiert, soweit ich der Diskussion richtig gefolgt bin, war der Konsens dort, dass ein MP im Josm vollstaendig geladen sein muss, damit es nach dem Editieren korrekt in die Datenbank geladen wird.

Wie ist Eure Meinung dazu?

Es kann nicht schaden, die ganze Relation herunterzuladen, es ist aber nicht notwendig. Man muss halt nur aufpassen, ein MP ist auch schnell zerstört.

Ich lade prinzipiell immer die gesamte Relation und schließe den Edit mit dem sortieren der Polygone ab. Nur so erkennt man, ob nicht durch den Edit Lücken entstenden sind. Sehr große Polygone zu bearbeiten ist daher sehr zeitaufwendig. Ich löse diese wo es geht -sofern es sich um Flächen beschreibende Polygone handelt- in kleinere Polygone auf.

Beschreibende Grenz- Polygone hingegen sollten möglichst große Segmente enthalten. Daher diese möglichst unabhängig von Wegen, Straßen und Gewässern führen. Hier eine solche Auflösung: https://www.openstreetmap.org/relation/307985
Stand 5.3.2016, seit 18 Tagen kein Bruch des Polygons mehr: https://www.openstreetmap.org/relation/307985#map=19/54.15754/-2.49265

Ref: http://forum.openstreetmap.org/viewtopic.php?pid=577359#p577359

edit: +link ref

Satz 1 ist falsch. Es gibt keine irgendwo festgelegte Definition, dass das so sein muß. Zumindest kenne ich keine.
Satz 2 ist insofern richtig, dass man Grenzways und andere Ways nicht gemeinsam als Rel-Member verwenden sollte. Als Begründung für Satz 1 taugt er allerdings nicht.

Gruss
wambacher

Satz 1 ist keine Regel sondern ein Praxis Tipp, der Fehler vermeiden helfen soll.
Sehr hilfreich ist auch die JOSM Erweiterung reltoolbox.