Bitte um Rat zu meiner erstmaligen Verwendung von Multipolygon

Die Sache mit dem Renderer sehe ich etwas differenzierter:

  • Ich zeichne und beschreibe (auf neuhochdeutsch “mappe”) gemäß der Wirklichkeit.
    Aber ich kann niemals die Wirklichkeit zeichnen, auch nicht mit einem Foto, sondern es ist stets eine Abstraktion, eine Abbildung.

  • Ich verfälsche die Wirklichkeit nicht, damit das Renderer-Ergebnis besser aussieht.

  • Aber ich zeichne und beschreibe so, dass Andere und Renderer verstehen was ich meine.
    Verstehen ist jedoch eine Interpretation und somit selbst bei verschiedenen Programmen und erst recht bei Personen unterschiedlich.

Grüße Willi

Normalerweise bringe ich den Spruch auch nicht, weil ich mich in anderem Zusammenhang durchaus dazu bekenne, fuer den Renderer (im Sinne von: fuer eine Nutzung der Daten) zu mappen.

Was falsch und was richtig ist, kann man natuerlich nur entscheiden, wenn man sich auf eine Bedeutung der Tags geeinigt hat.

Wenn die multipolygon-Relation aber eine Bedeutung hat, dann ist eine widersinnige Benutzung sehr wohl eine Verfaelschung der Wirklichkeit.

Und wenn die eigentlich allgemein akzeptierte, semantische Bedeutung der multipolygon-Relationen hier verneint wird, so fehlt immer noch eine Erklaerung, welche Bedeutung die Relation dann haben soll. Es wird doch wohl keiner ersnthaft behaupten wollen, dass die Relation nur zur Steuerung des Renderers da ist (auch wenn sie haeufig faelschlicherweise so genutzt wird).

Gruss
Torsten

Dieses Zitat ist interessant. Der von mir fett hervorgehobene Satzteil macht meines Erachtens den Unterschied. Wie wäre es im Beispiel von Weide mit

  • natural=water an die Relation. Der See, die Wasserfläche ist 8 und nicht 9 qkm groß.

  • place=island an way 2. Die Insel ist 1 qkm groß.

  • eventuell leisure=park und name=Wasserpark an way1, falls das 9 qkm große Gesamtgebiet etwas Eigenes ist (“something in its own right”).

Die Frage gehört die Insel zum See oder nicht kann man sicherlich unterschiedlich sehen. Aber natural=water gilt sicher nicht für die Insel. Und wenn der See der Atlantik und die Insel Großbritannien ist, gehört dann Großbritannien zum Atlantik. Man könnte nun anfangen, die Semantik von "gehört" zu diskutieren und käme gar nicht mehr zum "mappen". Da es mit der Semantik also so eine Sache ist, gilt bei mir: Davon besser nur so viel wie nötig. Die Geometrie ist eindeutig(er): Die Insel liegt im See und ist ausserdem etwas anderes (role=inner), nämlich kein Wasser, sondern ein schwarzes Loch oder etwas, das dieser Fläche als Merkmal gegeben wurde. Ob man role=inner nun zur Geometrie oder schon zur Semantik zählt halte ich für Ansichtssache.

Prima Diskussion, sehr sachlich und vor allem ich lerne durch jeden Beitrag hinzu.

Grüße Willi

Hi,

mit der Geometrie und der Semantik ist das so 'ne Sache.

Geometrisch sollte man erstmal Punkte (nulldimensional), Linien (eindimensional) und Flächen (zweidimensional) unterscheiden.

OSM hat aber nur Punkte und Linien (und Relationen). Flächen haben keine eigene Datenstruktur in OSM und werden nur semantisch erkannt; eine Linie oder mehrere Linien bezeichnen je nach Tagging und je nach Relationsmitgliedschaften eine Fläche. Tags wie area, landuse, roundabout, coastline und Relationsmitgliedschaften bei gleichem Tagging entscheiden darüber, ob es eine Fläche ist und wie dann die Linie in Beziehung zur Fläche steht.
Hätten wir keine Linien, dann würden die Punkte einer Straße Markierungen wie “line=yes” und “streetpointnumber=127” bekommen. Für komplizierte Straßen (solche mit Kreuzungen) würden wir dann Multipointrelationen benutzen. :-))
Lustig ist auch, dass die eigentlich in den semantischen Bereich zielende Relation (inhaltlich zusammengehörige Dinge zusammenfassen) nun das Einzige ist, mit dem man komplizierte Flächen darstellen kann (also ein rein geometrisches Problem).

Vielleicht sollten wir versuchen, für das nächste API einen brauchbaren Area-Typ zu definieren. Vielleicht so eine Punktliste mit Markierungen midpoint und endpoint. Die einzelnen zusammenhängenden Stücke könnten so funktionieren wie bei coastline. Auch unvollständig bekannte Flächen könnte man so erfassen und wären genauso schlecht zu rendern wie heute (z.B. coastline unvollständig). Dann könnte man auf die Dauer alle Flächen darauf umstellen.

Weide

Das hatten wir neulich schon mal, ich weiss jetzt nicht, ob in dieser Diskussion oder in einer aehnlichen. Kann sein, dass ich mich hier jetzt also ziemlich wiederhole.

In einer schoenen klaren Welt, wuerde man die Tags fuer die durch das multipolygon-Flaeche (der Bereich zwischen outer und inner) in die Relation eintragen und die Tags an den Polygonen selber waren dafuer egal.

Zum Teil historisch bedingt, zum Teil um dem Verfahren etwas Robustheit mitzugeben, zum Teil um das Eintragen zu vereinfachen, ist das in der Praxis aber nicht so sauber getrennt.

Wie du oben ja zitierst, ist es unter bestimmten Bedingungen erlaubt/gewuenscht/vorgesehen, die Tags fuer die multipolygon-Flaeche an das outer-Polygon zu setzen. Und hinzu kommt dann noch, dass sich die Mapper auch nicht sauber an diese Bedingungen halten, so dass man momentan letztendlich wohl sagen muss, dass man praktisch nicht zwischen den Tags der multipolygon-Flaeche und des outer-Polygons unterscheiden kann.

Da gibt es drei Arten, das Problem zu loesen.

  1. Man traegt die Heile-Welt-Loesung ein und vertraut darauf, dass sich langfristig diese Sicht schon durchsetzen wird.
  2. Man verdoppelt das outer-Polygon. Eins wird dann fuer das multipolygon benutzt und das andere fuer die Gesamtflaeche.
  3. Man setzt die Gesamtflaeche aus der multipolygon-Flaeche und den inner-Polygonen zusammen, d.h. die Tags fuer die Gesamtflaeche werden gleichzeitig an die outer- und die inner-Polygon eingetragen.

Gruss
Torsten

Und ich dachte mit Multipolygonen wurde dies geändert: “Relations of type multipolygon are used to represent areas of all sorts. The multipolygon relation is OpenStreetMap’s area data type.”

Genau dies habe ich heute bei dem Park gemacht. Ich habe weitere innenliegende Flächen eingetragen. Das Multipolygon hat jetzt 19 Elemente. JOSM scheint dies zu mögen. Sobald role=inner zugewiesen ist wird die jeweilige Fläche nicht mehr in einer Mischfarbe sondern der “richtigen” Farbe dargestellt. Mapnik zeigt noch die alte Version. Osmarender hat schon aktualisiert, sieht gut aus.

Selbst bei dieser momentanen “Heile-Welt-Loesung” musste ich Linien mehrfach übereinander eintragen, was ich eigentlich vermeiden wollte. Jedoch sind es weniger als es bei den anderen vorgeschlagenen Methoden der Fall wäre. Doppelt gemoppelt hält zwar besser. Aber bei Datenstrukturen habe ich in Theorie und Praxis gelernt, dass mehrfaches Anlegen des eigentlich selben Datums dazu führt, dass die Daten oft schon beim erstmaligen Eingeben und erst recht nach mehreren Aktualisierungen, insbesondere durch verschiedene Personen, inkonsistent werden. Und dies trotz oder eigentlich gerade wegen dem mehrfachen Aufwand. Wenn ich die Karte von Hand auf Papier zeichnen würde, so würde ich eine Linie auch nicht mehrfach einzeichnen nur weil sie verschiedenen Flächen gemeinsam ist. Ich denke, dass unsere Beschreibungsmittel (object types, tags, relations) und die Algorithmen (in Editoren und Renderern) noch besser werden sollten.

Grüße Willi

(Hast recht, ab und zu kehr ich mal den Datenstrukturfundamentalisten raus. :slight_smile: )

Ja, sowohl Relationen mit type=multipolygon als auch geschlossene Linien mit z.B. landuse=forest als auch geeignete Gruppen von Linien mit natural=coastline definieren Flächen.

Ich wollte nur sagen, dass es eigentlich vier und nicht drei grundlegende Typen geben sollte: Punkte, Linien, Flächen und – für abstraktere Zusammenfassungen von bereits vorhandenen Objekten – auch noch Relationen.

Mit Relationen kann man ganz gut Flächen definieren, aber eigentlich sollte die Relation doch OSM-Objekte zusammenfassen; Objekte wie Bushaltestellen, Straßenstücke kennzeichnen in der Zusammenfassung eine Buslinie. Aber bei Multipolygonen machen wir und mache ich was ganz anderes. Bei überstrapazierten See wird die Insel in der Relation erwähnt, aber sie wird nicht mit anderen Objekten zu einem größeren Ganzen zusammengefasst – man will nur ihre Begrenzungslinie haben. Genauso könnten wir auch auf alle "Way"s verzichten und statt dessen Relationen von Punkten bauen. Es ginge – aber es wäre konzeptioneller Müll.

Weide