Das sind einfach zwei unterschiedliche herangehensweisen an das tagen. Man braucht Multipolygone nicht unbedingt. Man kann auch ganz ohne auskommen. Dann verläuft das äußere Polygon c-förmig um das innere Polygon. Bei einfachen Flächen wäre das auch kein Akt. Wenn das ganze aber komplexer wird, ist das Multipolygon im Vorteil, weil einfacher.
Meiner Meinung nach ist ein See, ein Polygon und nicht aus vielen kleinen Polygonen zusammengesetzt. Will ich die Fläche von einem Polygon haben, ist die Berechnung beim MP einfach. Relation raussuchen und go. Bei den Einzelflächen muss man erst alle Einzelflächen finden (Automatismus dürfte versagen) und dann jede einzeln berechnen. Auch wäre es kompliziert, den Namen des Polygons irgendwohin zu rendern, ohne das er gleich n-mal auftaucht (für jedes Polygon extra).
Oh, das ist aber sehr verwirrend, wenn Du die als Teilpolygone bezeichnest!
Was lernen wir:
Nachdem man die Drehrichtung von inner und outer Polygonen nicht mehr beachten muß,
ist dagegen die Richtung der Wege bei der Verkettung zu einem Polygon von ähnlich großer Bedeutung wie z.B. in Busrouten
Hmmm - - - Muß das sein?
Oder anders gefragt (an die Programmierer der Renderer gerichtet) kann man das nicht so programmieren, daß die Richtung der ways egal ist?
Ist am Ende wohlmöglich auch noch die Reihenfolge der Wege innerhalb der Relation von Bedeutung?
Das ist dann aber verflixt fehleranfällig.
ob das wirlich eiine notwendige Bedingung ist, keine Ahnung.
Wenn ich ein multipolygon bastle, sind die ways eigentlich immer ringförmig geschlossen.
Vielleicht geht’s auch so
oder nach dem Können eines Renderers oder eines Navigationsprogrammes. Zusätzliche Angaben, die Programmen die Auswertung erleichtern sind meines Erachtens in Ordnung. Eine große Fläche wie einen See oder Fluss durch nicht vorhandene, willkürliche Linien in viele kleine zu unterteilen hat mit der Wirklichkeit nichts zu tun und ist auch nicht (mehr) notwendig.
Wird für die Ufer eines ganzen Flusses ein Multipolygon verwendet, so kann diese Relation leicht identifiziert und global geändert werden. JOSM kann mit Eingabe der ID die Relation auf einmal herunterladen. Sollte eine Relation zu groß werden, so kann sie in Elternrelation und Kindrelationen unterteilt werden.
Im August habe ich etwa 1000 km Ufer des Ping River in Thailand als ein Multipolygon Ping River eingetragen. Die einzelnen Wegsegmente sind etwa 10 km lang. Die äußeren Ringe schließen am Anfang, an der Mündung und an den beiden Seen durch die der Fluss fließt. Einer der Seen ist ein großes Reservoir mit einem Staudamm. Im Fluss sind über 60 Inseln, die als innere Ringe eingetragen sind. Die Seen sind ebenfalls Multipolygon Relationen mit Inseln. Mapnik hatte keine Probleme. Osmarender inzwischen auch nicht mehr. Und die neue zweisprachige Thaimap kann dies auch.
Aber es sollte sich nach dem Können der Menschen richten - und diese Linienzüge verstehen nur noch Experten - und auch die sind sich nicht sicher wie die Diskussionen und vor allem die ganzen “ich vermute” in diesem Thread zeigen.
Ansonsten macht sich OSM gezielt zu einem Techniker Eliteclub mit enormer Lernkurve, bei dem normale Nutzer einfach nicht mehr mitspielen können. Bzw. es versuchen und ahnungslos Multipolygonzüge zerschießen oder Duplikate anlegen, weil sie aus den unmarkierten ways nicht schlau geworden sind.
Leider ist es nicht so einfach. Bei der Verarbeitung von einem Planetfile nacheinander siehst Du diese Daten nie im Zusammenhang - alles auf einmal paßt nicht in den Speicher. Liest Du die Relationen auf Vorrat, kannst Du Mulitpolygone erkennen. Sie zu verändern ist schon wieder schwieriger: Du kannst bei der Verarbeitung eines ways nicht feststellen, ob er ein paar Gigabyte später noch eine Fortsetzung hat, die mit einem anderen Multipoly geteilt ist, so daß er anders behandelt werden muß. Wenn Du alles durch brutale Kopie löst, hast Du das Problem, daß neue IDs entstehen und Du auch alle Referenzen darauf finden und umschreiben mußt. Und Du brauchst eine Strategie für Mischformen, wenn sowohl ways als auch Relationen getaggt sind: Was wird kopiert, was nicht? Solches Mischmasch gibt es allein in D hundertfach. Außerdem mußt Du dann alle Daten nochmal neu sortieren, weil z.B. osm2pgsql sie nur nach ID und Typ sortiert annimmt. Das ist bei der Datenmenge auch nicht trivial.
So, der update ist durch. Der Starnberger See ist jetzt kein Wohngebiet mehr - der Fehler ist behoben. Allerdings weigert sich der Renderer nach wie vor, die Polygonzüge auf der Karte darzustellen. Es darf also weiter debuggt und gemutmaßt werden.
Moin
Jetzt ist der See leer.
Fragt sich nur, ob er wirklich leer ist, oder ob da jetzt eine unsichtbare Wiese drin ist. hust
Grund meiner Überlegung: In der Wanderreitkarte werden grundsätzlich keine Wiesen und Äcker dargestellt. Aber nicht, weil der Renderer das nicht kann, sondern weil sie bewußt aus dem Renderschema weggelassen wurden.
(Siehe auch http://forum.openstreetmap.org/viewtopic.php?id=10554 “Was ist da faul mit dem Waldpolygon?”)
Jetzt müssen also die angrenzenden Wiesen abgesucht werden, um Überschneidungen auszuschließen bzw. zu korrigieren.
Im Umfeld des Starnberger Sees stimmt leider noch mehr nicht:
Der Wald zwischen Oppenried und Seeseiten fehlt.
Ebenso das Sumpfgebiet bei Seeseiten.
Der unsichtbare Wald hat mit dem unsichtbaren See mit großer Wahrscheinlichkeit nichts zu tun.
Die “Unsichtbarkeit” könnte jedoch in beiden Fällen die gleiche Ursache haben: Überschneidung mit einem anderen Multipolygonelement, das eine in der Wanderreitkarte unsichtbare Eigenschaft wie z.B. landuse=meadow hat.
Was meinst du, wie die Experten Experten geworden sind. Durch die Beschäftigung mit der Materie. Ebenso wie das Busroutenschema oder dein Wanderwegsymbolschema etc…
Von letzteren hab ich keine Ahnung. Das bedeutet aber doch nicht, dass diese Schemas zu kompliziert sind und deshalb nicht verwendet werden sollten.
Wenn ich von etwas keine Ahnung hab, dann muss ich mich entweder damit beschäftigen oder ich Frage den Ersteller bzw. die Community.
OSM ist/war erfolgreich, weil es möglich ist/war durch kleine Bausteine das Große wachsen zu lassen.
Im Moment besteht die Gefahr, daß es immer öfter anders herum läuft: immer wieder werden kleine Bausteine das Große stören oder gar zerstören, wenn Grundelemente für Otto-Normal-Mapper nicht mehr auf Anhieb erkannt werden können.
Wanderwegsymbolschema und Busrelationen sind keine Grundelemente. Die kann man beim Mappen erst einmal ignorieren, wenn man ein paar Vorsichtsregeln einhält.
Ich habe aber auch schon wiederholt erlebt, daß Wanderwegrelationen zerschossen wurden, weil jemand sie beim Editieren der Wege nicht beachtet hat. Da laufen dann plötzlich Wanderwegmarkierungen in Richtungen weiter, wo sie gar nicht hin führen, weil ein zur Relation gehörender Weg verlängert oder mit einem anderen Weg verbunden wurde. Oder es fehlen Routenabschnitte, weil jemand ein Wegstück rausgeworfen und durch ein neues ersetzt hat oder weil er das Wegstück mit anderen Wegstücken verband und dabei die Relation rausgeworfen wurde usw.
Nur solche Vorgänge wurden bislang kaum dokumentiert. Entweder hat sie ein Routenkenner zähneknirschend repariert oder der Fehler wurde nicht erkannt oder …
Deine Sicht der Dinge
"… Wenn ich von etwas keine Ahnung hab, dann muss ich mich entweder damit beschäftigen oder ich Frage den Ersteller bzw. die Community… "
ist zwar grundsätzlich korrekt. Nur leider träumst Du Dich damit an der Realität vorbei. Unsere Überlegungen sind doch grundsätzliche Betrachtungen, die nach einem Lösungsansatz für das Problem suchen, daß vor allem neu einsteigende Mapper ungewollt Fehler produzieren, weil die immer komplexer werdenden Multipolygongebilde immer schlechter zu durchschauen sind.
Dadurch wird mein oben geäußerter Verdacht bestätigt, wonach dies die Ursache der Übel ist, wobei wir nun das Problem und seine Lösungen über die Seen hinaus verallgemeinern müssen
@Nop: Verwendest du egtl. nicht Mapnik für deine Karte? Ich frage nur deshalb, weil Mapnik keine Probleme mit dem Starnberger See hat und ich auch keine Fehler in den Daten finden konnte.
@Tippeltappel:
Wer legt denn fest was Grundelemente sind? Das dürfte erstmal sehr verschieden sein, weshalb eine Wertung hier zu nichts führt.
Es gab auch Zeiten ohne Relationen und auch da wurden (zumindest Rad-)Routen erfasst. Das man sich vorher schlau macht, wenn man etwas unbekanntes in die Hand nimmt ist/sollte keine Träumerei sein, sondern die Grundlage unsereres Arbeitens.
@Michael:
Ja, aber das tun auch andere Wege. Das Problem ist nicht in den Daten. Diese werden von unterschiedlichen Renderern korrekt ausgewertet.
Ich habe mindestens für einen Renderer einmal irgendwo im Forum gelesen, dass dieser sich behilft, indem er die Teil-ways erst wieder zu einem geschlossenen way zusammensetzt, da sonst die Fläche nicht gerendert werden kann…
Wenn man dem Patienten eine Krücke gibt, ist er noch lange nicht geheilt
@ aighes
Wer legt fest, was Grundelemente sind?
Ganz einfach: Die Hierarchie, in der die Elemente zueinander stehen bzw. aufeinander aufbauen.
Punkte, offene Linien und geschlossene Linien
Das ist/war die Grundlage für alles.
Mit der Entscheidung mehrere offene Linien mittels Relation als Polygon und dann wiederum mit Hilfe weiterer Relationsdefinitionen als Multipolygon darzustellen, wurde ein neues komplexes System ermöglich, das auf dem Grundelement “offene Linie” aufbaut.
Dieses System muß in den Editoren so handhabbar werden, daß es auf Anhieb erkannt und problemlos bearbeitet werden kann, ohne daß sich durch Unwissenheit oder auch nur durch Unaufmerksamkeit einschleichende Fehler unbemerkt anhäufen und dadurch bislang funktionierende Renderprogramme massiv stören.
Der negative Nebeneffekt dieser Weg-Ketten-Polygone wird sein, daß nun einige User Mammutpolygone und Mammutmultipolygone erstellen werden, die sich z.B. in Potlach kaum noch vernünftig bearbeiten lassen, weil sich die Elemente gar nicht mehr alle laden lassen.
Auch die History solcher Elemente ist nicht mehr einsehbar.
Wenn neue Ideen in einem Efenbeinturm ausgeheckt und umgesetzt werden und die dadurch aufkommenden Probleme an der Basis ignoriert werden, kann von einem Gemeinschaftsprojekt keine Rede mehr sein.
möchte ich das in diesem Thread nicht weiterdiskutieren.
Es wäre schön, wenn wir uns hier darauf konzentrieren könnten, die Ursachen für die Fehldarstellungen zu finden.
Die Wegkettenpolygone spielen dabei zwar eine Rolle, sind dafür aber sicherlich nicht die alleinige Ursache.
