@ Frederik/woodpeck: + 1000 In Worten: Tausend Dank für dieses Statement. Danke auch an alle anderen dafür, dass die konstruktive Diskussion nun weitergeht. Ich hatte schon gefürchtet, dass wir uns wieder mal auf Holzwegen (seltsame Anschuldigungen gegen Nop etc.) verlieren und Cmuelle8 so freie Bahn für beliebige Änderungen hat …
Frederik betont hier einen wichtigen Aspekt, den wir (ich) bisher tatsächlich nicht deutlich genug gesehen habe(n). Tatsächlich betreffen Cmuelle8s Änderungen ja nicht etwa nur die Art und Weise, wie die Mapping-Praxis im Wiki beschrieben wird (darüber könnte man eher auf der jeweiligen Talk-Seite des Artikels diskutieren), sondern seine Änderungen sind inhaltliche, tlw. normative Änderungen, welche auch die Mapping-Praxis in eine bestimmte Richtung lenken und verändern würden. Insofern erfordern sie, wenn sie überhaupt erwägenswert sind, eine breite Diskussion, die (wie alle Diskussionen der Mapping-Praxis) nicht im Wiki verschwinden, sondern im Forum und auf den Mailing-Listen geführt werden sollte.
@ gormo: Siehste, so hat er uns reingelegt, der Gute. Erst auf einer Diskussion im Wiki bestehen, damit sie dann dort versandet und er freie Bahn hat … ist das nicht ein raffinierter Trick?! Wir sind drauf reingefallen. Und die Geschichte gehört doch ins Forum und auf die Mailing-Listen, weil sie eben das ganze MP-Mapping betreffen – Frederik hat recht.
Hallo reneman
Hallo an alle anderen in diesem Thread
Ausgehend davon, dass ich einer der von dir genannten Laien (Anfänger) bin und ich das mappen jetzt aber irgendwie als Hobby entdeckt habe, (dementsprechend sauge ich auch alle Infos in mich auf) habe ich zu den MP’s mal eine Frage die sich auf deinen Text bezieht.
Ich mappe komplizierte Dinge normalerweise mit JOSM. Für einfache Anpassungen nutze ich aber gern auch den ID Editor im Browser. MP’s mag ich von Natur aus irgendwie nicht - ich finde, dass sie die Wirklichkeit oft nicht abbilden (z.B. sehe ich einen See in einem Wald nicht als MP) sondern als eine! äußere Fläche mit Loch (geht das überhaupt in OSM?) und eine Fläche für den See. Eine Fläche kann meiner Meinung nach nur dann eine andere Fläche “enthalten” wenn sie topologisch z-Achsenabhängig (weiß nicht wie ich es besser ausdrücken soll) ist. z.B. ein Haus das “auf” der Wiese steht… oder Tiefgarage die “unter” einem Parkplatz ist. Ansonsten würde ich gerne sowas vermeiden - und jetzt stellt sich mir da eine Frage. Leider findet man wenig Hilfe zu generellen “Verfahrensweisen” - nicht weil es die Infos nicht gäbe - sondern weil man so schwer danach suchen kann. Daher hier:
Wenn ich jetzt nun zwei Flächen in ID aneinanderziehe… dann verschmelzen (snappen) die ja zusammen. Das heißt optisch wird eine Kante draus und die Verschiebung der Nodes verändert danach auch beide Polygone - wird dabei auch automatisch ein MP generiert? (Dann würde ich nämlich in Zukunft darauf achten, da einen kleinen Abstand zu lassen, so dass es nicht zusammen snappt).
Entschuldigt, wenn meine Frage doch seeehr Laienhaft ist - aber ich habe bisher noch nichts dazu finden können.
Aber genau das ist in der OSM-Welt ein Multipolygon: Ein Flächengebilde mit Außen- und Innengrenze, wobei beide aus mehreren bis vielen einzelnen Teilstücken bestehen und auch mehrere unabhängige geschlossene Wege bilden können. Die Innengrenze muß nicht sein, man kann aus dreißig Linien (Straßen, Bächen, Zäunen, Brückengeländern, Landkreisgrenzen), die insgesamt einen geschlossenen Zug ergeben, ein Multipolygon definieren und diesem Flächeneigenschaften zuweisen.
Wir verstehen das semantisch. Ein See in einem Wald gehört nicht zum Wald, denn dort stehen keine Bäume → Wald als MP, See ist Innengrenze. Aber ein Schwimmbecken (leisure=pool) in einem Schwimmbad (leisure=water_park) ist ein Teil davon. Da kann die kleinere Flächen durchaus innerhalb der umgebenden liegen, ohne „ausgeschnitten“ werden zu müssen.
Probier’s aus. Bei iD weiß ich nicht. JOSM wird zwei einfache Flächen (geschlossene Ways) zu einem großen Way verheiraten. Wenn sich aber dabei ein „Innenhof“ ergibt (etwa wenn ich zwei U-förmige Flächen mit den Enden aneinanderpappe), dann erzeugt JOSM automatisch ein MP, überträgt das Tagging des/der Ways auf das MP und setzt Außen- und Innengrenze korrekt ein.
Eine äußere Fläche mit Loch geht in OSM, und zwar mit einer Multipolygon(-Relation) Die äußere Umrandung bekommt die “role” outer, und das was aus der Fläche herausgeschnitten ist die “role” inner. Das Multipolygon bekommt dann die Flächen-tags, die dann für die äußere Fläche minus innere Fläche gelten.
Nein das verschmelzen von Punkten erzeugt kein Multipoligon.
Edit: Ergänzend noch: Manche hier bei OSM mögen keine überlappenden Linien. Sie würden bei zwei nebeneinander liegende Flächen die mittlere Linie nur einmal zeichnen, allerdings mit keiner die beiden anderen “Halb-Flächen” verbinden. Um aus den Liniensegmenten die beiden Flächen darzustellen nutzen sie jeweils ein MP. Dort bekommen die beiden umschließenden Linienzüge die role outer. Die role inner wird hierzu nicht gebraucht. Die mittlere Linie ist damit Bestandteil beider MPs.
Andere OSM-ler finden das editieren solcher MP mit gestückelten outer (und ggf. auch inner) als äußerst lästig, besonders für Neulinge blicken bei dieser komplexeren Beschreibung von Flächen nicht mehr durch und es kommt zu Fehlern.
Das als “lästig” beschriebene Problem stammt noch aus der Frühzeit von OSM.
Multipolygone wurden damals vorwiegend für sehr sehr große Waldflächen verwendet. Bei einem Multipolygon welches sich vielleicht über 20 oder 30 und mehr Kilometer erstreckt, genügt eine einzige von einem Anfänger versehentlich verursache Lücke und das gesamte Wald-Polygon verschwindet insgesamt von der Landkarte.
Diese Probleme hat man heute weitgehend im Griff. Die Lösung besteht darin möglichst kleine Multipolygone zu zeichnen. Bei einem Defekt verschwindet so nur eine kleine Fläche von der Landkarte. Ein von Anfänger (und auch von Profis) verursachter Fehler wirken sich dadurch nicht mehr so gravierend aus. Solche MP-Fehler sind mit wenigen Maus-Klicks wieder repariert.
Das ist ein gutes Vorstellungsbild. Nur die MPs sind anders als Du denkst. MPs erzeugen kein “Übereinanderliegen”, sie vermeiden es. Das Übereinanderliegen bekommt man gerade ohne die MPs.
Nehmen wir einen rechteckigen Wald mit einem dreieckigen See drin: Wenn man das Dreieck mit “Wasser” markiert, dann ist alles innerhalb des Dreiecks Wasser. Wenn man das Rechteck mit “Wald” markiert, dann ist alles innerhalb des Rechtecks Wald. Jetzt liegen die Flächen übereinander, denn jeder Punkt im Dreieck liegt auch im Rechteck und ist daher sowohl Wasser als auch Wald.
Das liegt daran, dass wir den Waldrand falsch angegeben haben … wir haben nur das Rechteck als Waldrand angegeben. Der Waldrand ist aber das Rechteck und das Dreieck. Rechtecke und Dreiecke gehören zu den Polygonen. Wenn wir zur Beschreibung der realistischen Waldfläche mehrere Polygone brauchen, nennt man das logischerweise “Multi-Polygon”. Im Wald-Multipolygon steht dann “Das Rechteck ist der Außenrand und das Dreieck ist der Innenrand”. Durch die Benutzung des MPs überschneidet sich also nichts mehr.
Für geeignete Werte von „weitgehend“. Der Yorkshire Dales National Park oszilliert etwa wöchentlich, weil er so viele Wege, Bahngleise etc. als outer nutzt, daß dort ständig neue Lücken entstehen.
+1 für die Erklärung, welche mir auch auf der Zunge lag und ihren Weg über die Tastatur ins Forum suchte…
Wenn wir endlich aufhören, von “Auschneiden” zu reden und statt dessen den Begriff “innererRand” verwenden, fällt vielleicht bei einigen eher der Groschen zum Verständnis unserer MP. Und dann würde es manchen auch leichter fallen, statt “touching inner” separate Flächenarten in den “inneren Rand” zu plazieren. Schon wären wir wieder ein kleines Stück weiter auf unserem mühsamen Weg zur Akzeptanz der simple features für die Datenhaltung in OSM.
In derselben Zeit wie wir hier über Multipolygone diskutieren, wäre auch gleich das MP Schutzgebiet -Yorkshire Dales National Park- von anderen Polygonen isoliert.
Ich bin diese Endlose MP Diskussion satt.
Wir sollten dort wo wir Probleme erkennen, dieses Problem nicht wie eine Trophäe herumzeigen, sondern ein einmal erkanntes Problem, unkompliziert und sofern notwendig gemeinsam lösen.
Gelöst: http://forum.openstreetmap.org/viewtopic.php?id=52639
In Worten: Tausend Dank für dieses Statement. Danke auch an alle anderen dafür, dass die konstruktive Diskussion nun weitergeht. Ich hatte schon gefürchtet, dass wir uns wieder mal auf Holzwegen (seltsame Anschuldigungen gegen Nop etc.) verlieren und Cmuelle8 so freie Bahn für beliebige Änderungen hat …