… und um auch zum eigentlichen Thema beizutragen: Ich mag Multipolygone auch nicht soooo sehr und meide sie deshalb eher, aber:
Ist es möglich “Daumenregeln” zu definieren. Also dergestalt:
Ein Multipolygon kann entweder mehrer outer ways oder inner enthalten. Sind beide Elemente nötig ist auf eine Superrelation auszuweichen."
Oder: “Ein Multipolygon mit mehr als n verschiedenen Typen von inner ist ‘schlechte Praxis’.”
Gruss Christian
Ein großer Wald mit einem Teich und einer Wiese drin benötigt eine “Superrelation”? Was ist das eigentlich? Und wird das nicht noch komplizierter?
Ehrlich gesagt finde ich das eingangs von Nop erwähnte Beispiel nicht besonders gelungen. Teils war ein MP wirklich nötig und teils war es nun nicht so schlimm wie er dargestellt hat. Ich persönlich habe kein Problem mit MP und finde, dass man die beherschen sollte wenn man in OSM Flächen erfasst. Aber krampfhaft MP zu verwenden wenn es auch anders geht, mache ich auch nicht. Wenn im Wald eine Lichtung ist, nehme ich ein MP statt den Wald zu teilen…wobei ich keine Ways von anderen Objekten wie Straßen, Feldwegen etc mitbenutze
Nein, aus meiner Sicht benötigt der grosse Wald eine Relation und die im Vergleich dazu kleinen Flächen der Wiese und des Sees werden ohne Zusammenhang zum Wald “darüber geklatscht”. Ist nicht schön im Sinne der “reinen Lehre” aber bis wir wirklich mehr Datentypen als “Punkt und Strich” haben ein m. E. akzeptabler Kompromiss, der sich darauf verlässt, dass existierende Renderer kleine Flächen über grosse “malen”.
Meine Frage zu den Daumenregeln zielt ja gerade darauf ab, “Krampf” greifbar zu machen …
Gruss Christian
P. S. Mit “Superrelation” meine ich Relationen, deren Member auch Relationen sind.
Ich bin sehr dafür.
Das muss man nie. Die Multipolygon-Elemente werden in ihrer Bedeutung durch das Multipolygon niemals verändert und behalten ihre Bedeutung (Außer bei dieser grauenhaften alten Multipolygonart, bei der die Tags nicht ins Multipolygon kommen).
Das ist ganz normal. Bei den Wegen machen wir das dauernd. Die angegebenen Punkte haben meist keine Bedeutung und wo sie doch eine haben, spielt sie überhaupt keine Rolle. Kein Mensch denkt darüber nach, was mit dem Straße passiert, wenn einer seiner Punkte eine Ampel ist – und zwar zu Recht. Kein Mensch kommt auf die Idee, der Weg würde sich verändern, wenn man die Tags eines seiner Punkte ändert. Multipolygone verhalten sich zu Wegen genauso wie Wege zu Punkten. Kein Mensch kommt auf die Idee, man müsste alle Wege durchsuchen, um einen Punkt verstehen zu können. (Mit “Weg” und “Punkt” meine ich hier OSM Way und Node.)
Es gibt auch jetzt kein Ausstanzen. Das ist nur ein immer wieder abgeschriebener Fehler der Beschreibung, der das eigentlich einfache Multipolygon kompliziert erscheinen lässt. Die Elemente des Multipolygons werden alle ausnahmslos als Linien betrachtet, ihre Tags spielen nur für sie selbst eine Rolle und sie geben schlicht und einfach den Rand der zu beschreibenden Fläche an.
Weide
Dem kann ich Weide nur in allen Punkten voll zustimmen.
Gruss
Walter
+1
Hallo,
kann mir jemand den Sinn dieses Multipolygons erklären?
http://www.openstreetmap.org/browse/relation/164755
Gruß
ja, eigentlich gehören die Tags dieses Wegs
http://www.openstreetmap.org/browse/way/19046066
ins MP. Das ist eine Fussgängerzone. Und da wo die Gebäude stehen, wurde Löcher in die Fussgängerzone geschnitten. Ist formal auch korrekt…wo ein Gebäude ist, ist keine Fussgängerzone.
Vielleicht werden dort auch Multipolygone von dieser Person bewußt verwendet, um Änderungen von nicht versierten OSMlern`zu verhindern.
Gruß
Peter
Stimmt, wenn man bedenkt dass die Fußgängerzone ein highway ist und kein landuse macht das natürlich Sinn.
Der absolute Standardfall eines Multipolygons. Ein outer-Way, mehrere inner-Ways als “Löcher”. Hat meiner Meinung nach mit dem Thema hier absolut nix zu tun. Das sind nämlich Multipolygone mit vielen outer-Ways, die mit anderen geteilt werden.
Unterlass bitte solch unsinnige und absurde Behauptungen.
Danke Nop, für deinen erneuten Aufruf des Themas.
Wie ich bereits in dem Thema Multipolygon - Verwendungszweck angedeutet haben, habe ich (hoffendlich) nach Meinung der überwiegenden Mehrheit die englische und deutsche Multipolygonseite ein wenig angepasst.
(Es sind nur Dinge, die anfangs so bestimmt wurden, aber nicht deutlich genug beschrieben wurden.)
ich hatte mal einen Wald (nicht in DE) mit 110,000 Hektar, dessen Outer-Ways ca. 65,000 Nodes hatten und aus insgesamt 350 inner/outer Ways bestand. Ich habe ihn dann in ein paar Teile zerbrochen. Wenn man einige hier hört, hätte ich da mindestens 50 einzelne Wälder draus machen müssen.
Ich verstehe, dass solche Objekte nicht gut handhabbar sind. Andererseits ist das Auseinanderbrechen eines eigentlich zusammen gehörigen Objekts auch nicht korrekt…es ist ja ein einzelnes Objekt. Ein Auseinanderbrechen würde nicht der Realität entsprechen und nur den Unzulänglichkeiten unserer Editoren geschuldet sein.
Die alternativen zu outerpolygonen sind doch auch nicht wirklich besser.
Normale Flächen, deren Kanten übereinander liegen finde ich noch viel schwieriger zu bearbeiten. Wenn ich ersteinmal bei den Kanten rumprobieren muss damit ich die Fläche ausgewählt bekomm, nur um ein Tag abzuändern, da hab ich schon deutlich schneller die Relation rausgesucht und das Tag schnell abgeändert.
Wenn man zwischen Flächen (und Wegen) Platz lässt, gibt das sehr häufig die Realität nicht gut wieder, und ist mit der Verschieberrei auch nicht umbedingt unproblematisch zu bearbeiten.
Das ganze ist ein Grundsätzliches Problem. In den Editoren lassen sich Flächen nicht wirklich gut bearbeiten (nur genauso wie Linien) und die zugrundeliegenden Datenstrukturen sind auch nicht ganz unproblematisch (geschlossener Weg, Multipolygon)
Die Diskussion hier erweckt bei mir eher den Eindruck eines Glaubenskrieges statt einer sachlichen Diskussion:
Die Meinung Andersdenkender wird nicht akzeptiert.
Persönliche statt sachliche Äusserungen:
[list=*]
“Unterlass bitte solch unsinnige und absurde Behauptungen.”
“Vielleicht werden dort auch Multipolygone von dieser Person bewußt verwendet, um Änderungen von nicht versierten OSMlern`zu verhindern.”
In dieser Situation halte ich es für dreist, unverschämt und einen Affront gegen Andere, das Wiki ohne vorherige Abstimmung zu ändern. Dies insbesonders wenn Änderungen
grammatikalisch inkorrekt sind: “don’t works”
inhaltlich schlechter oder falsch sind: “However, this model don’t works for very huge areas, and which have holes.”
persönliche Ansichten darstellen: “Please take the examples … with care!”
Nee, Relation 2015472. Da kann man die Hausnummer ändern. Die Relation 2015473 ist nur der nordwestliche Trakt des Gebäudes.
Ich sehe da mehr das Problem “Detailmapping”. Beim Detailmapping kommt es immer zu Aufspaltungen. Straßen werden gesplittet, weil Geschwindigkeitbegrenzungen eingetragen werden und hier wurde ein Gebäude gesplittet, weil Geschosshöhen eingetragen wurden. Ich würde sowas nicht machen … aber mich interessieren Geschosshöhen ja auch nicht. Ich denke, damit muss man leben.
Weide
Hallo!
Ich bin einer dieser Mapper, die Landuse-Flächen grundsätzlich nur noch als Multipolygon erfassen, und bin ehrlich gesagt etwas erschreckt darüber, wie hier auf uns eingedroschen wird.
Ich muss vorweg sagen, dass ich in einer Gegend mappe, wo es auf 100 km² vielleicht 2-3 aktive Mapper gibt. Hin und wieder zieht mal einer durch, der ein paar POIs oder Wege hinterlässt, manchmal bleibt jemand auch mal ein paar Monate, aber ansonsten konzentriert sich eben alles auf einige wenige Mapper. Da versucht man natürlich, so effizient wie möglich zu arbeiten, denn es gibt so viel zu tun, dass jede Mannstunde sinnvoll investiert sein will, vor allem so lange die Grunddaten (Wegenetz, Landnutzung) nicht vollständig erfasst sind.
Ich empfand es immer als Krampf, wenn Wegenetz und Landnutzung mit getrennten Linien erfasst waren, und man dann den schlecht erfassten Wegverlauf (3 Knickpunkte pro km Weglänge oder so) detaillierter erfassen wollte. Statt einer Linie durfte man dann derer 3 bearbeiten. Bei gestapelten Linien war immerhin die Geometriekorrektur einfacher, aber da nervte es dann, dass es schwierig war im Editor die richtige Linie auszuwählen (was aber bei nebeneinanderliegenden Linien je nach Abstand und Zoomstufe genau das gleiche ist).
Ein Nachbarmapper fing vor einiger Zeit an, neue Flächen als Multipolygon zu mappen und dabei vorhandene Linien (Wege, Bäche etc.) als Begrenzung zu nutzen. Ich war begeistert, dass es nun in OSM möglich war auf eine derart elegante Weise Flächen zu erzeugen, und ich möchte diese Möglichkeit nicht mehr missen. Geometriekorrekturen, das nachträgliche Einfügen von Details, Vergrößern und Verkleinern von Landnutzungsflächen, all das geht in den Bereichen, die schon als MP gemappt sind, wesentlich schneller und einfacher von der Hand.
Ich versuche, zumindest für meine Heimatgemarkung, auch die Flurnamen flächenhaft zu erfassen. Zuerst hatte ich die Namen direkt an den Landuse-Flächen, was ich aber ziemlich schnell wieder aufgeben musste, da Landuse und Flurnamen selten deckungsgleich waren. Danach probierte ich es mit site-Relationen. Dabei störte mich aber immer die fehlende optische Kontrollmöglichkeit. Mittlerweile erfasse ich sie ebenfalls als Multipolygone und bin froh über die einfache Editiermöglichkeit, da ich doch oft etwas ändere, wenn ein Gespräch mit einem älteren Mitbürger mal wieder neue Erkenntnisse gebracht hat. Vorher hätte das nämlich bedeutet, dass ich zunächst die Landuse-Flächen hätte neu zuschneiden und dann noch die Mitglieder der site-Relation hätte ändern müssen - mühsam!
Gerade in den Waldgebieten ziehe ich oft die Luftbilder von Bing heran um die Grenzen zwischen Laub-, Nadel- und Mischwald zu kartieren, weil das vor Ort ja meistens eher schwierig ist. Leider sind die Luftbilder im hiesigen Bereich mindestens 8 Jahre alt und deshalb würde ich gern kennzeichnen, welche Daten aus Bing stammen und welche vor Ort aufgenommen wurden. Bisher habe ich das immer über ein source-Tag an den Flächen resp. Multipolygonen gemacht. Das empfinde ich mittlerweile aber als unbefriedigend, da es viele Flächen gibt, die ich teilweise per GPS und teilweise mit Bing erfasst habe. Ich möchte in Zukunft also die entsprechenden Begrenzungslinien der Fläche mit dem source-Tag kennzeichnen und spätestens an dem Punkt komme ich gar nicht mehr um Multipolygone herum.
Dass durch die Nutzung der Wege als Landuse-Geometrien diese Wege zerstückelt werden ist klar. Aber das passiert durch Brücken, Route-Relationen, Ver- und Gebotsstrecken, detailliertes Fahrspur- oder Feldweg-Beschaffenheits-Mapping usw. usf. genauso und je detaillierter der Datenbestand wird, desto häufiger werden auch die Wege aufgetrennt.
Meiner Meinung nach sollte es für Wege ebenfalls eine Möglichkeit geben, diese als Relationen zu erfassen. D. h. anstatt an jedes Teilstück alle Tags dranpappen zu müssen, erzeuge ich nur noch eine Linien-Relation für highway=primary, ref=B 1 und ordne dieser alle (zusammenhängenden) Linien zu, auf die diese Attribute zutreffen.
Ich möchte das ganze noch etwas ketzerischer formulieren: Ich fände eine komplette Trennung zwischen Karteninhalt und Kartengrafik gut. Als Vorbild denke ich da an HTML und CSS. Ich stelle mir das so vor: Auf der einen Seite wird eine Kartengrafik aus Punkten und Linien erzeugt. Auf der anderen Seite erzeuge ich den Karteninhalt, der aus Attributen besteht. Jedem dieser Attribute weise ich einen oder mehrere Punkte bzw. Linien zu. Will ich also die Nummer einer Bundesstraße ändern, kann ich das an einer Stelle machen und muss mir nicht erst 527 Linien zusammensuchen (und übersehe dann doch wieder 3). Hat sich nur bei einem Teil der Bundesstraße die Nummer geändert, verschiebe ich halt die betroffenen Elemente zu einem neuen Attribut. Es wären auch neue geometrische Zusammenhänge möglich. Setze ich z. B. ein Attribut natural=tree und weise ihm drei Punkte zu, habe ich eine Baumgruppe erzeugt, die später im Renderer auch so behandelt werden kann (z. B. für Generalisierung).
Anstatt einer Geometrie Attribute zuzuweisen, würde man also Attributen eine Geometrie zuweisen. Ist das nun komplizierter oder weniger intuitiv als andersherum? In meinen Augen nicht, ich empfinde es sogar als logischer. Und effizienter zu bearbeiten wäre es allemal. Die Multipolygone sind ein erster Schritt in diese Richtung und ich würde eine weitere Entwicklung dorthingehend durchaus begrüßen.
Ich hoffe, ich habe mich einigermaßen verständlich ausgedrückt.
Waldgraf
Moins,
Und du bist nicht alleine.
Ich hab die kompletten Allgäuer Alpen auf diese Wesie bearbeitet, von einer weißen Ödnis bis zur vollständigen Erfassung.
Ich kann es nicht besser ausdrücken. Danke.
Bei den Wasserläufen (zumindest in AT) entwickelt sich das gerade.
100% Zustimmung.
Die konsequente Trennung zwischen Geometrie und Semantik/Features ist bei unserer professionellen Konkurrenz seit mehr als einem Jahrzehnt Standard.
Oder aus einem Punktfeature “Gasthaus” wird ein Flächenfeature “Gasthaus” und dann ein Flächenfeature, das auch den Biergarten auf der anderen Straßenseite umfasst. Ohne dass ich Adresse und Namen des Objektes umhängen müsste auf ein andere Objekt. Das Feature behält seine id unabhängig von Änderungen andere Geometrie.
Andererseits kann man einem Geometrieobjekt auch mehrere Features zuordnen - damit sind mehrere Läden in einem Gebäude trivial darzustellen.
Ich schließe mich auch hier zu 100% an.
(Wenn ich mich auch als Memverbreiter in Sachen Google sehen würde, würde ich hier ein “+1” hinsetzen.)
Du hast. Danke nochmal. Wobei ich nicht glaube, dass es etwas nützen wird 
Gruß Wolf
In der Gegend: http://www.openstreetmap.org/?lat=52.4307&lon=13.5346&zoom=14
Weiß nicht, ob man das noch als Normal betrachten kann, eher irrsinnig, IMHO.
@Netzwolf und Waldgraf: Eure Ausführungen klingen natürlich sehr gut und sind vermutlich auch der einzige Weg aus dem zunehmenden Datenwust (es wird ja nicht weniger). Dem steht aber entgegen, dass die meisten Mapper (mich eingeschlossen) keine Profis sind. Die meisten haben wohl -wie auch ich- mit Potlach angefangen und sind dann, falls sie nicht schon vorher das Handtuch geschmissen haben, eventuell irgendwann zu JOSM gewechselt, weil sie gemerkt haben, dass da -nach einer gewissen Einarbeitungszeit- vieles einfacher zu bearbeiten ist. Mit anderen Worten, ich müßte mich mal intensiv mit der Bearbeitung von Multipolygonen mittels JOSM beschäftigen, so wie man es bei html mit CSS auch machen müßte, um damit etwas auf die Beine stellen zu können?!?! 
Das hättet Ihr aber auch gleich klarer sagen können! Ob das die meisten Hobby-Mapper auch tun werden, ich meine “intensiv mit der MP-Materie befassen” ?