Multipolygonwahnsinn - oder: Durchblick war gestern!

Communities Deutschland (Germany)
106

In der Tat, ein interesanter Ansatz (positiv!).

Richtig, Konsens aus 100% Übereinstimmung wird es bei einer so großen Anzahl von Leuten nicht geben. Davon abgesehen, dass die Mehrheit sich wohl nicht äußert. Ein Kompromis kann sich vielleicht schon entwickeln, jedoch wird es aufwändig Argumente abzuwägen und Lösungen zu entwickeln.

Bis zu dem Zeitpunkt, als ich das wiki editiert habe, haben sich ca. 5 Gegen und ca. 23 +3x0,5 Für “die Sache” geäußert. Das sind mehr als 82%. Es ist auch korrekt, dass es nicht die weltweite Meinung wiederspiegelt. Durch die überwigende Mehrheit hab ich “einfach mal gemacht”, da es auch hieß "wenn es nicht klar genug erscheint, ist es jedem freigestellt es klarer zu beschreiben (möglicherweise aus dem Zusammenhang gerissen?). Es ist auch leicht rückgängig zu machen.
Ich habe keine Ahnung wer die Datentypen und ihre Funktion bestimmt, wer die Aufwertung zu erweiterten Multipoligonen beschlossen hat, und unter welchen Richtlinien. (Damals war ich noch nicht dabei.) Ich war/bin der Ansicht (so wie es auf der wiki-Seite noch zu finden ist), dass mehrere outer “für Grenzen und verry large areas” eingeführt und für solche “hilfreich sind”. Klar, es steht nichts (in positiver/negativer Hinsicht) über Verwendung kleinerer Flächen oder Highways als outer.

Nein, nicht Abschaffung, sondern softe Beschränkung auf die vorgesehenen Einsatzzwecke. Argumente wie “das haben wir schon jahrelang so gemacht” lass ich nicht ganz gelten! OSM entwickelt sich genau so wie die MPs weiter, und so kann auch darüber diskutiert werden. Wie gesagt, einfach Ändern war vielleicht nicht ganz ok! (Auch wenn dadurch die Diskussion angeheizt wurde.)

Man kann auch den Zaun und die Mauer auf den Rand der Grundstücke malen (doppelte Linie/selbe Punkte). Beide Möglichkeiten haben ihre Vor- und Nachteile (die es Abzuwägen gilt).

Ich habe keine Probleme, sondern kann MPs einsetzten und auch lesen. Jedoch finde ich () die Übersichtlichkeit derjenigen mit mehreren outern meist als extrem unübersichtlich.
OT: hehe, “master” ist gut :slight_smile: (der namenszusatz aber eher zufällig entstanden und hat keinen Bezug auf können/wissen/Meinung oder sonstwas)

Das mag teilweise stimmen, wenn man jedoch Shortcuts oder Plugins einsetzt, ist es erstens kein Problem mehr, und zweitens geht es auch noch viel schneller.

Bezogen auf den Beitrag von wambacher fallen mir 2 Unterschiede auf:
-Grenzen sind idR sehr große Flächen.
-Grenzen ändern sich bei weitem nicht so oft wie landuses. Wenn man zB zwischen Wiese und See einen Strand oder Hecke hinzufügen möchte, ist es ohne MP wesentlich einfacher.

Eins ist klar, unabhängig wie sich die Diskussion weiterentwickelt: Die Editoren können sich weiterentwickeln, so dass jetztige Mappinghindernisse erleichtert werden können. Auch hierfür kann eine Auflistung der Argumente sinnvoll sein.

Gruß
Masi

108

Das ist kein Problem der MP, sondern der Editoren.

Solche=Welche? Unabhängig davon handelt es sich hierbei auch nicht um ein Problem der MP, sondern um funktional falsches Mapping.

Das ist kein Problem der MP, sondern der Editoren.

Wenn die Werkzeugunterstützung für MPs nicht ausreicht, dann spricht das nicht gegen MPs, sondern für unzureichende Werkzeuge.

Ob die Existenz von MPs dazu führt, daß häufiger funktional falsch gemapped wird, müßte auch erst bewiesen werden.

109

Wenn ich das Argument richtig verstehe, spricht es eher für MP: Polygone entsprechen einer geordneten Menge von Punkten, MP einer solchen von Polygonen.

110

Genau. Aber die Frage ist, ob wir in Objekten denken oder die Welt als eine Scheibe flachklopfen. In Objekten ist der Wald auf einer Insel etwas anderes als der Wald auf dem Kontinent. Das Flachklopfen wiederum würde ich gerne dem Renderer überlassen. Wir sollten eher entscheiden, welche Eigenschaften parallel existieren können und welche exklusiv sind (hier greift dann das “oberste zählt”).

Schon richtig. Relationen ohne Rollen sind genau die gewünschte Gruppierung. Mit den Stiefmuttern hast du wohl auch recht.

Ja. Und das eine schließt das andere nicht aus. Layer bezeichnet räumliche Höheninformation (“Tunnel tiefer als Bergspitze”). Ein Renderer kann dennoch entscheiden, den tieferen Layer zu zeichnen. Stapelung bezeichnet logische Position innerhalb einer Eigenschaft. Will sagen, wenn der Renderer einen Konflikt hat, von welchem dieser überlappenden Objekte er nun die entsprechende Eigenschaft darstellen soll, nimmt er die logisch oberste.

Beispiel:

  1. Tunnel und Acker sind Objekte unterschiedlicher Qualität, der Layer sagt, was weiter oben ist, der Renderer kann das Ziel haben, die Oberfläche zu kartieren und läßt den Tunnel weg. Er muß aber nicht.
  2. Insel und Forest sind Objekte gleicher Qualität (auch gleicher räumlicher Höhe). Hier legt die logische Stapelebene fest, was gezeichnet wird.

Warum wäre das ein Graus - es entspricht der Realität? Ein Fluss kann zu zwei Landesgrenzen gehören, mehreres Bezirks (…-)grenzen und diversen Wassertraßen. Analog mit Straßen, Buslinien, Wanderwegen etc.
Hier sehe ich wieder die Gruppierung (= Relation). Weg X ist Mitglied verschiedener Relationen. Haben wir ja heute schon. Gesucht ist eine Methode, das übersichtlich zu handeln. Da sind die Programmierer der Editoren gefragt.

Gruß,
Zecke

111

+++1

Ich habe das sogar schon mal gemacht, aber mangels Unterstützung wieder zurückgebaut. Es ist schließlich schade, wenn plötzlich Straßen nicht mehr gefunden werden. Ich glaube, es steht sogar was dazu irgendwo im Wiki. [1]

Ich finde diesen Ansatz sehr interessant. Du sprichst hier meiner Meinung nach allerdings einen Grabenkampf an, den es schon länger gibt, als ich bei OSM aktiv bin, und der vermutlich nie enden wird. Er findet sich überall und immer wieder. Nur ein anderes Beispiel: Kommen die addr:* Daten, welche nicht hausspezifisch sind (city, country, postcode) an das einzelne Gebäude, oder an eine Relation vom Typ associatedStreet?

Nachtrag: [1], auch wenn es noch nicht ausgegoren ist: Collected Ways und Street

112

Da leg ich mich nicht pauschal fest sondern entscheide je nach Situation. Wobei solche Entscheidungen natürlich subjektiv sind:

  • Wie bereits geschrieben: Aus einer Straße wie der B251 würde ich keinen Weg mit 80 m und 4 Knoten herausschneiden, um ein 80 x 10 m “kleines” Buschland darzustellen.

  • Tracks, die zugleich Grenze sind und nicht schon Mitglieder mehrerer Relationen sind, nehme ich dagegen gern.

  • Wasserstraßen sind häufig auch Grenzen und sehr lang. Da ist meines Erachtens ein Multipolygon klar einfacher und fehlerfreier erstell- und pflegbar als eine doppelte Linie.

113

Arbeiten Renderer inzwischen wirklich so? Oder ist das Spekulation und Wunschdenken?
Meines Wissens arbeiten Renderer heute noch wie in diesem Beitrag beschrieben.

114

Wenn es Shortcuts und Plugins gibt, die so etwas wie in diesem Beispiel beanstanden oder gar verhindern, so sollten sie meines Erachtens unbedingt und schnellstens genannt und bekannt gemacht werden.

115

Bitte gründlich lesen und sich nicht auf etwas beziehen oder gegen etwas argumentieren, das nicht geschrieben wurde:

  • “Völlig unbeanstandet und von Vielen so verstanden und benutzt steht dort seit Jahren, dass ein Multipolygon aus mehreren Wegen bestehen kann.”
    ist nicht das selbe wie
    “das haben wir schon jahrelang so gemacht”.

  • Wer hat Diskussionen abgelehnt?
    Ich sicher nicht. Ich nehme sogar daran teil obwohl ich einen Konsens für illusorisch halte und somit die Diskussion als ziemlich nutzlos ansehe und in der Zeit eigentlich lieber kartieren würde. Da die Diskussion jedoch wie leider häufig sehr einseitig und ignorant geworden war, habe ich mich dennoch entschlossen teilzunehmen. Auch wenn das meiste eh schon mehrfach in früheren Beiträgen geschrieben wurde. Anscheinend wird lieber alles nochmal durchgekaut anstatt gründlich zu lesen oder sorgfältig zu kartieren.

Ich denke nicht, dass die Diskussion hierdurch angeheizt wurde. Und eine sachliche Diskussion ist eh besser als eine hitzige. Wer Hitze will kann in die Sauna gehen. Da ich in den Tropen wohne, habe ich mehr als genug davon. :)
116

Kann sein. Ich versuche mit meinen Überlegungen auch eher einen Anstoß zu geben, wo die Reise hingehen könnte.

Gruß,
Zecke

117

Dann ist ja alles klar.
Aber nicht vergessen, noch sind die Daten für die heutigen Renderer einzugeben. Bitte nicht mit “tagging for the renderer” verwechseln. :slight_smile:

118

Wenn man darüber nachdenkt, wie das Datenmodell verändert/optimiert werden könnte, schließt das logischerweise Konsequenzen für die Implementierung der Renderer nicht aus.

119

Auch ich habe erhebliche Probleme mit Multipolygonen und finde deren Aufbau unintuitiv; schwer nachvollziehbar und sehr fehleranfällig beim Editieren.

Der Geburtsfehler liegt meiner Meinung nach darin daß die Umrisse durch eine Sammlung von Linien definiert werden, Linien die nicht prinzipiell miteinander verbunden sein müssen und zugleich noch andere Funktionen haben können. Das hat nebenbei fast zwangsweise zur Folge daß vorhandene Linien (Straßen und Feldwege) zerbrochen werden wie schon von anderen angemerkt wurde.

Noch komplizierter wird es wenn ein ansonsten sehr intuitiver und übersichtlicher Editor wie Merkaartor die Multipolygone nicht oder nur fehlerhaft darstellen und man seine Gegend voller zerrisener Wälder nicht mehr wiedererkennt. Dafür daß ich nicht als Hobby kartiere sondern nur mein “Revier” aktuell halten will ist das ein massives Hindernis.

Ich bin noch nicht in der Lage ein offizielles Proporsal zu schreiben, aber ich möchte schon einmal hier im Forum meinen Vorschlag für ein einfaches Universal-Polygon vorstellen:

Das Universalpolygon ist eine einfache Fläche die über eine Liste von Eckpunkten definiert wird wobei die Punkte zugleich auch Bestandteil anderer Objekte sein können. Der Umriß entsteht dadurch daß beim Rendern die Eckpunkte der Reihe nach miteinander verbunden werden.

Zusatzbedingung 1: Der Umriß darf sich nicht selbst überkreuzen.
Zusatzbedingung 2: Der Umriß darf nicht mehr als 2000 Punkte haben, wenn mehr als ungefähr hundert nötig werden sollte die Fläche aufgeteilt (siehe Zusatzvorschlag 1)

Die Struktur wäre damit:
Punkte bestehen aus Koordinaten und Punkt-Tags
Linien bestehen aus Punkten und tragen Linien-Tags
Flächen bestehen aus Punkten und tragen Flächen-Tags
(Relationen bleiben kompliziert)

Diese Definition erlaubt es daß man Wege vollkommen unabhängig von Flächen bearbeiten kann. Leider habe ich jetzt keine einfache Möglichkeit ein Bild hochzuladen mit dem ich das ganze illustrieren könnte.

Zusatzvorschlag 1: Flächen aufteilen wenn der detailierte Umriß zuviele Punkte hätte

Es wird eine Kernfläche definiert die vollständig innerhalb des Umrisses liegt und den größten Teil der Fläche abdeckt. Außen herum werden zusätzliche Flächenstücke angehängt die Stücke von den Außenkanten im Detail wiedegeben.

Dies würde nebenbei das Rendern beschleunigen weil man für größere Gebiete nur die Kernflächen wiedergeben müßte.

Zusatzvorschlag 2: Ausschnitte aus Flächen durch “negative” Landuse-Tags ( z.B. Cutout genannt) kennzeichnen anstatt sich darauf zu verlassen daß der Renderer die Stapelebenen korrekt zuordnet

Eine Region die weitestgehend aus Futterwiesen besteht bekommt den Tag Landuse=Meadow
Ein See zwischen den Wiesen bekommt die Tags Natural=Water und Cutout=Meadow
Ein Wald zwischen den Wiesen bekommt die Tags Landuse=Forest und Cutout=Meadow
Eine Lichtung im Wald bekommt die Tags Landuse=Meadow und Cutout=Forest

Im See gilt dann + Meadow - Meadow + Water = Water
Im Wald gilt dann + Meadow - Meadow + Forest = Forest
Auf der Lichtung gilt + Meadow - Meadow + Forest - Forest + Meadow = Meadow

Gebäude; Wege dergleichen haben implizit Vorrang vor der “flachen” Landnutzung.

121

Wenn die Werkzeugunterstützung für MPs nicht ausreicht, so daß sie nur eine technisch versierte Minderheit editieren kann, spricht das meiner Meinung nach sehr wohl dagegen, sie zu verwenden wenn es nicht durch die schiere Größe des Objektes notwendig wird. Das ist ja der Kern des Themas.

MasiMaster hat die Aussagen hier im Forum ja schon mal gezählt und kommt auf ca. 82% Stellungnahmen gegen exzessive Multipolygone. Um die widersprüchlichen Einschätzungen mit weiteren Zahlen zu untermauern habe ich mal eine Statistik über die Nutzung der Mainstream-Editoren ausgegraben [1]

Potlatch1 ist nach wie vor der mit Abstand häufigste Editor und hält seine Position. Potlatch2 wird zunehmend beliebter und überholt JOSM klar.

Daraus ziehe ich den Schluß, daß im September 2011 84,5% der Mainstream-Edits mit einer Potlatch-Version erfolgten. Alle diese 177690
Mapper konnten mit Sicherheit keine Multipolygone bearbeiten, da die in Potlatch noch nicht mal als Flächen angezeigt werden. Umgekehrt kann man nicht annehmen, daß jeder JOSM Benutzer automatisch bei Multipolygonen durchblickt - ich selber habe zum Beispiel früher JOSM benutzt, aber niemals so ein komplexes Machwerk angefaßt. Selbst wenn wir optimistisch annehmen, daß immerhin die Hälfte der JOSM Nutzer maximale Powermapper sind, komme ich auf über 90% der Mapper, die mit den Multipolygonen nichts anfangen können. Und die Tendenz ist klar steigend.

Vor dem Hintergrund dieser Zahlen möchte ich nochmal den Appell an die Multipolygon-Powermapper richten: Seid Euch im Klaren darüber, daß Ihr mit Eurer Praxis mehr als 90% der aktiven Mapper davon ausschließt, nochmal etwas an Euren Konstrukten zu ändern oder zu ergänzen. Wenn man OSM als großes gemeinsames Projekt oder als Community sieht, kann das doch nicht Eure Absicht sein, oder?

bye
Nop

[1] http://wiki.openstreetmap.org/wiki/Editor_usage_stats

122

Das ist geradezu ein Lehrbeispiel wie man aus den Zahlen einer Statistik “Lügen” machen kann:

  • Die Werte der senkrechten Achse sind ohne Maßeinheit angegeben.
    Vergleicht man mit der Quelle so dürfte es die Zahl der Benutzer der jeweiligen Editoren sein.

  • Die Zahl der Benutzer wird dann munter mit “Mainstream-Edits” gleich gesetzt.
    Es ist nicht klar was das ist. Edits sind sicher keine Benutzer sondern Änderungen. Und da sind für September 2011 für Potlach 2.334.127, für Potlatch2 687.215 und JOSM 4.365.487 angegeben.

Meines Erachtens zeigt diese Statistik lediglich, dass die große Mehrzahl der aktiven Benutzer (84,5%) Potlach benutzt und damit weniger Changesets als die Minderheit der JOSM Benutzer (15,5%) erstellt. Nichts wird ausgesagt über die Größe der Changesets und deren Inhalt. Und da gibt es große Unterschiede. Es gibt Benutzer, die Provinzen praktisch allein kartieren, deren üblicher Changeset mehr als 1000 Punkte, 100 Linien und 10 Relationen enthält und andere, die nur einen Changeset mit einem POI, ihrem Lieblingsrestaurant oder -hotel haben. Achtung, mit dieser Feststellung ist keinerlei Wertung verbunden.

Die Aussage, dass 84,5% der Benutzer, Dinge wie das im Beitrag #87 genannte Farmland mit oder ohne Multipolygonen erstellen oder ändern wollen halte ich für verwegen. Und bis jetzt hat noch niemand hier ein vergleichbares Pendant ohne Multipolygone und dass dieses einfacher für einen Neuling ist, aufgezeigt.

Um mal den Lehrer zu geben (Lehrer tut’s auch, Oberlehrer ist ja wohl schon mehrfach besetzt): “Setzen! Sechs!” :wink:

123

Es handelt sich um die Anzahl der individuellen User-IDs in den Changesets und damit um die Anzahl der aktiven User in diesem Zeitraum.

Steht exakt auf der genannten Wikiseite. Bitte mach Dir wenigstens die Mühe, die Quellen genau durchzulesen, bevor Du etwas als Lügen bezeichnest.

Ich fest, daß Du zwar sofort dabei bist, starke Worte in den Mund zu nehmen und Forderungen zu stellen, daß aber von Dir nicht mal der Hauch eines Belegs gekommen ist.

Zu Deiner Polemik darf sich jeder selbst seine Meinung bilden. :slight_smile:

bye
Nop

124

Selbstverständlich habe ich die Quelle gelesen und dies auch im Beitrag #122 geschrieben. Beim Lesen eigentlich nicht zu übersehen. In dem Beitrag #121 steht jedoch nicht “Anzahl der individuellen User-IDs in den Changesets” sondern “Mainstream-Edits” und das ist sicher etwas anderes, wobei nicht erklärt wird was genau, und das hab ich mit “Lüge”, Achtung in Anführungszeichen, bezeichnet.

Zu welchen meiner Aussagen, nicht Aussagen von Anderen, ist denn ein Beleg erwünscht?

125

Nop, ich unterstütze Deine Aussagen und Schlussfolgerungen voll.

Vermutlich ist die Zahl der Potlatch 2-Nutzer mittlerweile noch bei weitem höher da er jetzt defaultmässig angeboten wird – dürfte jetzt “der” Standardeditor sein.

Bezüglich Multipolygone hat er leider die “Macke”, dass die (gerade für die “MP-Vermeider und -Vereinfacher” wichtige) Mausfunktion “Punkt dahin setzen wo schon einer von einem andern Objekt ist” in 1 von 100 Fällen schiefläuft und die Punkte leicht danebensetzt werden, was man im Zoomlevel 14 oder 15 (dem letzten wo man das Luftbild sieht) nicht erkennt. Vermutlich ist der Fehler zoomlevel-unabhängig. Und das führt dann leider, nicht beim Änderungen-Speichern, sondern im OSM Inspector zu den bekannten Fehlermeldungen und Warnungen.

Ich würde aber nicht sagen dass er gar nicht taugt um mit ihm Multipolygone zu editieren. Es ist etwas aufwendig, aber letztlich ist es möglich.

Die Aussage dass der Potlatch nur für “Grobmapping” taugt, stimmt wohl bestenfalls für die Version 1. Ich würde nicht gerade von mir behaupten wollen Grobmapping zu betreiben, und benutze Potlatch 2 ausschliesslich. Und zwar gerade wegen seiner Einfachheit, Flexibilität und Leistungsfähigkeit, auch der Schnelligkeit im Mapping. Einige die hier so über Potlatch daherschreiben sollten mit Potlatch 2 vielleicht einmal arbeiten.

126

Warum soll ich einen Editor benutzen, von dem du selber gerade Fehler beschrieben hast, wenn mit Merkaartor alles problemlos geht?

Kann man in Potlatch2 keine Changeset-Kommentare erfassen, oder ist das ein anderer User: http://www.openstreetmap.org/user/Taunide/edits

127

Kaum ist man mal zwei Wochen weg, um die Praxistauglichkeit der OSM-Daten zum Navigieren in Irland zu testen, entwickelt sich hier eine heiße Diskussion zu MP’s.

Um es kurz zu machen:
Ich bin voll auf Nop’s Seite und zu einigen Äußerungen erspare ich mir bewusst jeden Kommentar, weil Glaubenskriege nichts bringen.
Manches kommt mir so vor, als jammerten einige: “Mama, der will mir mein Spielzeug wegnehmen.” :roll_eyes: