Multipolygon - Verwendungszweck

Wo gibts günstig Popcorn. Benötige größere Mengen :roll_eyes:

popcorn gibts hier: http://www.youtube.com/watch?v=B7UmUX68KtE
:wink:

Von den Mappern welche Relationen verstehen, sind es nicht 99, sondern meine Einschätzung nach vielleicht 90-95%. (jeder 10./20.)
Macht bei den OSMern eine stattliche Anzahl von Leuten, denen man durch ein nicht so schwammiges wiki helfen kann.

P.S.: wenn man nichts (konstruktives) zur Disskussion beizutragen hat, ist es auch erlaubt, nichts zu schreiben, anstatt das Thema zu verwässern. :wink: :slight_smile:

Es macht auch wenig Sinn, ständig wieder dieselben Argumente in neuen Threads darzulegen, ohne wirklich etwas zu ändern oder zu verbessern.

Steter Tropfen höhlt den Stein.

Das kann man so verstehen, deswegen sollte dieser Satz raus.

Solche “Ausnahmen” sind leider nicht so selten.

Sollte empfohlen werden.

Gehört auch raus (gottseidank scheint wohll niemand so einen Quatsch zu mappen)…

Ich kenne als sinnvolle größere Multipolygone eigentlich nur Waldflächen. Da würde ich in der Regel drauf verzichten den outer-way als landuse=forest zu taggen und diese Eigenschaft dem MP zuweisen. Das hat den Vorteil dass im Potlatch die Fläche nicht grüngefärbt wird was das Erkennen und Mappen von Wegen nach den Luftbildern erleichtert. Dass hier Wald ist, zeigt das Luftbild ja deutlich genug.
Soweit es aber “unfertige” Waldflächen mit schlampig getaggten Rändern angeht, kann es sinnvoller sein diese “grün zu lassen” (outer way als landuse=forest) damit die Outer Flächen stärker auffallen und man leichter erkennt dass hier noch “Arbeit” nötig ist.

Man **kann **so etwas beschreiben, um zu zeigen “was technisch geht” und wie das MP funktioniert. Aber als Mappingempfehlung (wurde hier im Forum auch schon drauf verwiesen) ist die Seite einfach 'ne Katastrophe!

Vielleicht macht es mehr Sinn das auf der betreffenden WIKI Diskussionsseite auszudiskutieren (die Seite muss ja doch geändert werden), dann braucht man sich hier durch nicht soviel Müllbeiträge durchscrollen. Und diejenigen die das Thema nicht interesiert werden nicht motiviert mitzudiskutieren was in einem Forum leider immer wieder geschieht…

Dann schau mal richtig nach. Du wirst Dich wundern.

Eine sehr gute Idee!
Hatte es erstmal hier angesprochen, um die verschiedenen Meinungen abzuklopfen (ob ich alleine der Meinung bin), ehe ich mein klägliches Englisch bemühe. :wink:

P.S.: Lese mich grade durch die Diskussion auf der englischen MP Seite. Werde im Anschluss dort die verschiedenen Punkte vorstellen…

Bevor das Ganze einschläft, darf auf der Multipolygon-Talk-Seite weiter diskutiert und Meinungen geäußert werden.
Je mehr Befürworter sich äußern, desto eher besteht die Möglichkeit einer Anpassung des wikis. :slight_smile:

In diesem Zusammenhang ist auch noch diese Seite und deren Verweise nicht uninteressant: http://wiki.openstreetmap.org/wiki/The_Future_of_Areas

Hallo,

ich möchte hier auch noch mal meinen Senf dazugeben.

Mein Favorit war auch immer Methode 1, bis ich vor einigen Monaten begann, gezielt Multipolygone in meiner Umgebung zu reparieren. Die meisten Fehler resultieren nicht, wie angenommen aus Methode 2, sondern aus Methode 1. Dadurch, dass mehrere Wege übereinanderliegen, kommt es duch Unachtsamkeiten beim Setzen von Knoten häufig zur minimalen Überlappung von Flächen und die Fehlersuche kann sich bei größeren Konstrukten über Tage erstrecken. Nutzt man eine Linie gemeinsam für mehrere Multipolygone, schließen sich diese Fehler von vornherein aus.
Auch wenn Flächenmultipolygone mit z.B. 100 outer-Elementen ziemlich abschreckend wirken, sind sie bei Änderungen weitaus einfacher zu handhaben als mehrere angrenzende Einzelne Flächen, da man nur einen Weg anpassen muss. Das schlimmste was passieren kann, sind nicht geschlossene Ringe, die sich aber leicht aufspüren lassen.

Nein, gibt es nicht. In der Wiki-Seite ist alles gut erklärt.

Ja. Aber selbst wenn es nicht sinnvoll wäre, ist es zu spät die Spezifikation zu ändern, da Multipolygone schon millionenfach auf diese Weise genutzt werden.

Nein, mehr, da Anfänger gern Abstände zwischen benachbarten Flächen lassen oder sogar die unselige JOSM-Funktion nutzen um dort, wo noch keine Abstände sind, die Linien voneinander zu trennen. Das wird mit gemeinsam genutzten Grenzlinien unterbunden.

Wie wärs mit einer Editor-Schulung?

Im übrigen siehe Antwort von woodpeck.

Ich z.B. Und ich finde es mühsam, dauernd gegen solche Manipulationen ankämpfen zu müssen.

Ignorier OSMI.

Hast du den Thread nicht ganz gelesen? Es ist nicht alles im wiki gut erklärt, und aufgrund dessen gibt es wohl die halbjährlich wiederkommende Diskussion zu MP.

Ja/Nein lässt sich schnell sagen, weil man keine Argumente vorbringen muss :wink: 2. Wird es keine Änderung der Spezifikation geben, sondern eine Empfehlung. Die Funktionalität muss für große MP ja erhalten bleiben.

(Aha, und es deshalb möglichst komplex machen, damit keiner durchblickt und es ändert? :wink: ) Was du ansprichst hat weniger damit zutun, es ist die Philosophie (mMn eher nicht von Neulingen), dass der Feldweg nicht zum Feld, oder der Zaun zwischen den Feldern auch nicht zum Feld gehört.

Schulung für wen? 1-2 Linien zu verschieben ist einfacher, als mehrere Linien aufzutrennen, und in mehreren MP herumzueditieren usw. Im Übrigen ist das taggen eines einzelnen langen Feldweges leichter, als 50 Segmente (die durchs auftrennen entstanden sind) dafür auszuwählen.

So wie ich es sehe, wurde (vermutlich ohne die Konsequenzen zu sehen) damals das Freigeben mehrerer Segmente die einen ‘outer’ bilden, ohne Diskussion auch für kleine MP und auch Flächen aufgeweicht. Es ist doch legitim diese “Manipulation” infragezustellen!?

Ja, das ist in der Tat ein Problem. Das sind die Fehler die hauptsächlich(?) bei touching inner-inner vorkommen, bei denen ein Punkt nicht mitgenommen wurde und dort zwischen den Flächen eine Lücke entstehen lässt oder sich die Flächen dort überlappen. (-> Key-F verfolgen hilft beim zeichnen)
Ein verbesserter OSMI könnte schneller auf das Problem hinweisen. (das war keine Meldung es zu programmieren :wink: )

Ich habe http://wiki.openstreetmap.org/wiki/Multipolygon auf Anhieb verstanden, obwohl ich sonst von langsamer Auffassung bin. Wenn dennoch etwas schlecht erklärt ist, dann steht es jedem frei, die Erklärungen zu verfeinern (oder wenn zu kompliziert, in Absprache mit dem ursprünglichen Autor zu vereinfachen). Was du in deinem Ausgangsposting (auf das ich geantwortet habe) vorgeschlagen hast, war aber eine semantische Änderung (hineinzuschreiben »dass Methode 2 nicht “gut” ist«).

Ein Argument wurde eh schon gebracht: damit man einen Way mit vielen Nodes nicht mehrfach zeichnen muss. Im Wiki steht außerdem: “…very large areas, where it would be impractical to have one way run around the whole of it”

Mit einer Empfehlung, dass outer mit wenig Nodes (z.B. einfache Gebäude) eher nicht aufgeteilt werden sollten, kann ich leben. Aber das liegt sowieso auf der Hand, also wozu extra reinschreiben und die Seite unübersichtlich machen?

Das würde ich nicht so direkt aussprechen.

Der User, der mir den kompletten Wald verschoben hat, um ihn vom Weg zu trennen, war tatsächlich kein Neuling, aber doch ahnungslos. Wenn man das Micromapping richtig macht, muss man konsequenterweise den Zwischenraum als Wiese o.ä. mappen, aber dann werden die Multipolygone noch viel komplizierter.

Einen Weg extra für Multipolygone in viele kleine Stücke aufzuteilen finde ich auch nicht optimal, da ziehe ich die MP-Grenzen lieber als eigene Ways, wo das Aufteilen nicht so die Wartbarkeit der Straßentags und ggf. der Routenrelationen beeinträchtigt.

Dazu kann ich nichts sagen, das war vor meiner Zeit. Es wär vielleicht geschickter gewesen, für die neuen MP einen neuen type=* einzuführen. Aber das ist jetzt Geschichtsforschung.

Meine Meinung:
Ways (gemäß OSM) repräsentieren die Mittellinie der Straßen, Feldwege usw., welche sie abbilden sollen. Da an diese Straßen angrenzende Wälder, Wiesen, Felder usw. aber nur maximal bis an den Wegesrand gehen, ist es für mich logisch, dass zwischen der Linie für den Weg und der äußeren Flächenbegrenzung ein Abstand bleiben muss, der etwa der halben Wegesbreite entspricht. Das wäre auch vorteilhaft, falls wir irgendwann mal Straßen als Flächen erfassen.
Ein möglicher Einwand gegen meine Logik könnte sein, dass landuse “überwiegend” bedeutet und wir große zusammenhängende landuses auch über Wege hinweg anlegen :confused:

Es ist schon ein Unterschied, ob Wege als landuse-Grenzen benutzt werden oder ob landuse über Wege gemappt werden.

Danke, sehe ich auch so. Hoffe nur wir meinen den selben Unterschied. Ich mappe “überwiegend” als größtmögliche Fläche, zur Not bis 2000 nodes pro closed way über alle Wege hinweg außer der Weg bildet die Grenze zwischen verschiedenen landuse; dann bis an den way für den Weg mit Abstand von etwa einer halben Wegbreite oder wie in bing usw erkennbar.

+1

Meine Meinung:
Also ich mappe Strassen und keine Mittellinien. Strassen werden in OSM nun Mal als Way in der Mitte des Strassenverlaufs erfasst und nicht als Fläche. Angrenzende Landflächen gehen halt bis zur Strasse und solange OSM Strassen nicht als Flächen enthält, grenzen Flächen halt an die Linie an. In der Realität ist ja auch kein “unbekanntes Land” zwischen Strasse und Wiese.

Ich finde häufig Regionen, in denen Wege und Flächen getrennt gemapped werden. Wenn man wirklich mehrere Meter Zwischenraum lässt, gibt es hässlicher Blitzer beim Rendern, die für ein unruhiges und verwirrendes Kartenbild sorgen. Wenn der Landuse hingegen nur 10 cm neben der Strasse liegt, ist das Realitätsargument hinfällig.

Mir fällt auch auf, das häufig landuse Begrenzungen und Wege kreuz und quer übereinander gezeichnet sind. Zum einen ist es sicher Schludrigkeit, aber ich kenne auch Mapper, die mit Landuse nichts am Hut haben und diese Daten in JOSM ausfiltern. Wenn solch ein Mapper nun den Verlauf eines Weges korrigiert, kann es auch zu solch einem Durcheinander kommen. Wenn der Landuse jedoch mit der Strasse verbunden ist, passen solche User der Landuse (zum Teil) mit an, auch ohne ihn zu sehen.