Es gibt genügend Prüftools, außerdem schaut man sich Änderungen eh nachher in Mapnik an und dann fällt ein Fehler gleich auf. Ich finde es sogar gut, wenn ein Fehler auffällt. Wenn man beim Nachzeichnen von Linien einen Fehler macht, bleibt der Fehler jahrelang drin und nachher weiß man nicht mal, ob das mit Absicht so gezeichnet wurde.
Solche Performanceprobleme gehen gehen null, weil die Systeme immer leistungsfähiger werden.
Siehe oben. Obwohl der Datenbestand immer umfangreicher wird, ist Mapnik immer schneller geworden.
So große Relationen sollte man aufteilen. Nicht wegen Speicherplatz, sondern wegen Übersichtlichkeit.
Hört sich nach SW-Bug an.
Das tun sie sowieso, egal wie man die Daten erfasst.
Darüber kann man streiten.
Wege werden sowieso zerschnibbellt: für Brücken, maxspeed- und tracktypeänderungen, neuerdings auch für Spurmapping… Darum sehe ich das Problem eher umgekehrt: Die vielen kurzen Straßenstücke als Grenzabschnitte machen das MP unübersichtlich. In beiden Fällen ziehe die Straßen gern 1x für die MP-Grenze nach. Das ist ein Kompromiss: Straßen und Flächen beeinträchtigen einander nicht, und man muss die Straßen nicht mehrmals nachzeichnen, sondern nur 1x.
Das größte Problem, wenn man mit vielen MP arbeitet, und das hast du gar nicht gelistet, ist vielleicht, dass man dann im Editor eine lange Liste an Relationen hat. Da ist kaum mehr zu sehen, was was ist. Aber das ist ein Problem von Relationen generell.
Bei administrativen Grenzen ist das absolut sinnvoll, weil entweder jeder Weg eine eigene Bedeutung hat (Straßenmitte, Eisenbahn, Fluß/Bach, …) oder nur eine Grenze ist (kann man mit boundary=administrative am Weg kennzeichnen). ALs Grenze gehört ein Weg jedoch zu mindestens zwei Gebieten.
Bei Häusern an Häusern jedoch würde es einen erheblichen Mehraufwand bedeuten, Außenwände und Zwischenwände einzeln zu zeichnen und für jedes Haus noch eine passende Relation zu erzeugen. Aus dem Grund wird das auch kaum gemacht.
Ich denke (wie schon von anderen angemerkt), dass man großflächige Objekte (mehrere zig Quadrat-Kilometer) und kleinflächige Objekte (z.B. Häuser an Häuser) getrennt betrachten sollte.
Wenn man, wie im Wiki vorgeschlagen, die Taggs an die Relation macht (unabdingbar bei mehreren Wegen für einen outer-Ring), dann hat man das Problem, dass nicht mehr unmittelbar erkennbar ist, um was für ein Objekt es sich handelt.
Das Aufsplitten des äusseren Weges ist mit und ohne MP nötig.
Bei MPs kommt jetzt noch das Kopieren der Relation und das manuelle umsortieren der Wege zu den zugehörigen Relationen dazu.
Ohne MP (bzw auch bei MPs, deren outer aus einem Weg besteht) gibt es eine super Hilfe: utilsplugin2 “Split Object”. Zwei Punkte und eventuell noch den zugehörigen Weg selektieren. “Split” (Alt-X). Fertig (Tags werden mit kopiert)
Willst du deinen Beitrag eventuell noch einmal überdenken und gegebenenfalls korrigieren? Analog zur Meinung von “mdk” steigt auch in meiner kleinen Welt die Anzahl der Fehler mit wachsender Komplexität der Aufgabe. Das ist dann der Grund, warum die erste praktische Fahrstunde auf einem Parkplatz oder Privatgelände beginnt.
Die laxe Art, mit der du m. E. fundierte Argumente “abbügelst” lässt jetzt nicht gerade eine grosse Bereitschaft, Argumente des Gegenübers auch Ernst zu nehmen, erkennen.
… 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’.”
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.
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.
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.
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.”
[/*]
[/list]
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!”
Ich habe mir deshalb erlaubt, die Änderungen zu revertieren.