Multipolygon - Verwendungszweck

Hi,
mir ist klar, dass dieses Thema schon zum x-ten man angesprochen wurde, aber es gibt mit Sicherheit noch einigen Klärungsbedarf.

Es gibt 2 Methoden zur Verwendung von MP:

1. Verwendung ausschließlich um ein oder mehrere Löcher aus einer Fläche “auszustanzen” (Fläche und Löcher sind jeweils eine geschlossene Linie).
2. Vermeidung von doppelten Linien. (z.B. jedes landuse wird aus einzelnen kurzen Linien gezeichnet.) so wie unter DE:Multipolygon_Examples vorgeschlagen wird.

(Bei besonders großen Flächen oder MP bestehen 2 Möglichkeinten:
A: mehrere Geschlossene Flächen oder MP, welche in einer Elternrelation (z.B. site oder collection) zusammengefasst werden.
B: wenige lange Linien, die zusammen den outer-Ring Darstellen.)

Die Frage die sich stellt: Ist Methode 2 sinvoll?

Wenn Methode 2 nicht mehr verwendet würde, ergäben sich mehrere Vorteile:

• weniger Ressourcenverbrauch durch weniger MP
• Darstellung im Editor ist wesentlich übersichtlicher
• es entstehen weniger Fehler beim editieren
• Korrigieren von Fehlern (Stichwort: OMSI) und Editieren ist wesentlich einfacher

Nachteile:

• keine (leichter zu editieren zählt nicht, da es mit “Linie verfolgen - Taste F” und/oder ContourMerge Plugin nochmals einfacher/schneller geht)

Gibt es unter euch Gleichgesinnte/Befürworter die meinen, dass Methode 2 nicht “gut” ist, dann könnte man sich zusammen tun und im Wiki eine Anleitung (oder Richtlinien) zur Verwendung von MP erstellen. Oder ist jemand prinzipiell dagegen?

Gruß Masi

P.S.: sorry, aber ich bekomm jedes mal zuviel, wenn ich solchen **** im OSMI antreffe.

Ich weiss nicht, ob ich Dich richtig verstanden habe. Wenn Du gerade eben vorgeschlagen hast, dass man doch, anstatt eine gemeinsame Grenzlinie zwischen zwei Flaechen zu verwenden, lieber die Linie doppelt zeichnen soll, einmal fuer die eine und einmal fuer die andere Flaeche, dann ist die Antwort ganz deutich: Nein, das ist keine gute Idee; Ja, das ist sinnvoll, wie es jetzt gemacht wird; und Nein, bitte aendere nicht die Wikiseite.

Natuerlich gibt es da eine gewisse Wahlfreiheit. Wenn ich zwei aneinandergrenzende Gebaeude zeichne, dann mache ich mir nicht die Muehe, die gemeinsame Wand als eigenen Way zu formulieren und Multipolygone anzulegen, klar. Generell handhabe ich das so, dass das Uebereinanderlegen von Ways ok ist, wenn es nur ein paar wenige Nodes sind. Aber sobald es eine laengere Grenze ist, ist m.E. keiner der von dir vermuteten “Vorteile” richtig. Du erzeugst dann ja zwei uebereinanderliegende Ways, die die gleichen Nodes benutzen, d.h. die Datenmenge ist groesser, weil Du in zwei Ways auf die gleiche Nodeliste verweist. Leichter zu editieren ist das auch nicht, weli es nicht unbedingt immer gelingt, den “richtigen” der beiden uebereinanderliegenden Wege auszuwaehlen, besonders, wenn man z.B. aufsplitten will.

Bye
Frederik

Ich halte von der Darstellung “normaler” Flächen - also building, amenity, highway, … - als Multipolygon mit zerteilten outers derzeit wenig. Das erschwert aus meiner Sicht in aktuellen Editoren das Bearbeiten, es erschwert auch die Auswertung und ist in solchen Situationen schlicht unnötig. Gäbe es nur solche Fälle, würde ich die sofortige Abschaffung von nicht-geschlossenen Wegstücken als Member von Multipolygon-Relationen vorschlagen.

Nun gibt es halt auch Sonderfälle: Grenzen (auch wenn die, je nach aktuellem Stand der Bot-Editwars, ja ihren eigenen Relationstypen haben) oder bestimmte riesige Wald- oder Wasserpolygone. Hier haben die zerteilten outers schon unbestreitbare praktische Vorteile.

Das bedeutet, dass es manchmal eine Abwägungsfrage ist, was man wo einsetzt. Das ändert aber nichts daran, dass es mich beim Mappen nervt, wenn jemand Flächen wegen eines kurzen gemeinsamen Wegstücks auf Relationskonstrukte umgebaut hat.

Ich wüsste eigentlich gerne mal ob die Befürworter dieser Methode dies auch beim Zeichnen von Hand auf Papier so machen. Zum Beispiel ob sie beim Aufteilen eines Baugebietes auch jede Grenzlinie doppelt zeichnen, einmal für das Grundstück auf der einen und einmal für das Grundstück auf der anderen Seite. Zudem könnte man dann gleich noch zwei Zäune oder Mauern erstellen

Nein, auf Papier zeichne ich die Linie natürlich nur einmal. Dann gebe ich der Linie eine Nummer und trage sie in die Begrenzungslinien-Listen ein, die ich für jede meiner Flächen … ähm, eigentlich doch nicht.

Man kann doch aber 2. auch verwenden, weil man 1. schon anwenden muss - und dann ist es aus meiner Sicht sinnvoll so zu agieren.

Und generell wegen Editierbarkeit: Ich pflichte dir bei, dass die Editierbarkeit nicht unbedingt vorteilhafter wird, durch derartige Konstrukte - insbesondere für Anfänger.
Wobei die Editierbarkeit auch durch solche MP einfacher werden kann, wenn ich wirklich nur noch eine Grenzlinie habe - insbesondere, wenn ich die Fläche neu unterteilen muss, kann ich dies mit MPs einfacher durchführen als mit zwei geschlossenen Polygonen (einmal den Weg splitten und beide Hälften kommen sofort in die MP-Liste rein - danach kann ich die Fläche neu einteilen und ein weiteres MP erzeugen oder aber die bestehenden editieren.

Jedoch wäre mir neu, das OSMI solche Gebilde als Fehler auswirft. Da müsste ja jeder Fluß bzw. jede Landmasse als Fehler angemerkt werden. Sind da nicht eventuell noch andere Fehler enthalten?

1 muss man aber nicht immer anwenden (nicht jede Fläche hat ein Loch). Wenn man bei 1 auch 2 anwendet muss man auch bei Nachbarflächen ohne 1 2 anwenden.

Wenn ich eine Fläche aufteilen möchte muss ich bei:
einer Fläche ohne MP:
Knoten wählen, Knoten wählen, Fläche teilen, Fläche1 schließen, Fläche2 schließen, bei Fläche2 Tag(s) ändern → 6 Schritte
Variante 2:
Knoten wählen, Weg teilen, Knoten wählen, Weg teilen, neuen Weg zeichnen, neuen Weg in Relation einfügen, Relation kopieren, Relation2 überflüssige Wege entfernen, Relation2 Tag(s) anpassen, Relation1 überflüssige Wege entfernen → 10 Schritte

…das ist also imho auch nicht einfacher.

Einziger Vorteil wäre also imho geringerer Speicherverbrauch, da gibt es aber auch noch ganz andere Stellen wo man ansetzen könnte.

Ich bin auch kein Fan der Variante2.

Gruß
BBO

Wie Du an der - wie immer konsenslosen - Diskussion siehst ist es reine Geschmacksache.

Auch auf die Gefahr hin mich zu wiederholen: Bitte vergesst das Speicherverbrauchs-Argument. Teuer sind nicht einige zusätzliche Einträge in einer Knotenliste, sondern zusätzliche Objekte.

Beispiel: 2 Häuser mit zusammen 6 Nodes.

n1 - n2
| |
n3 - n4
| |
n5 - n6

Haus 1: n1, n2, n3, n4
Haus 2: n3, n4, n5, n6

1. Lösung ohne MP:
   w1 = n1, n2, n4, n3, n1
   w2 = n3, n4, n6, n5, n3

2. Lösung mit MP:
   w1 = n3, n1, n2, n4
   w2 = n4, n6, n5, n3
   w3 = n3, n4
   r1 = w1, w3
   r2 = w2, w3

in beiden Fällen werden 10 Knoten in den Wegen referenziert → Gleichstand
im zweiten Fall gibt es ZUSÄTZLICH 1 Weg und 2 Relationen.

Weniger Speicherverbrauch sieht für mich anders aus!

Erst wenn w3 noch zusätzliche Knoten hätte, würde sich die Situation beginnen zu ändern. Aber ich habe keine Ahnung, wie viele zusätzlich Punkte nötig sind, um den Overhead durch den zusätzlichen Weg und die Relationen auch nur auszugleichen. Jedes Objekt in der DB benötigt ja auch Verwaltungsinformatioen: id, timestamp, uid, version, changeset, etc.

Bitte haltet das Argument “Speicherverbrauch” aus dieser Diskussion heraus!

Klar, bei solchen “speziellen” Themen wird die Wikiseite nur bei einem breiten Konsens geändert. Die Findung/Bildung eines solchen habe ich versucht mit der Diskussion anzustoßen

Zu besonders großen Flächen (z.B. >1000 Punkte, Grenzen, …) schrieb ich in Klammern, dass diese davon ausgenommen sind und mit (langen) Linien erstellt werden. Ist vielleicht nicht ganz so deutlich rausgekommen.

Ok, sicherlich hat der JOSM noch nicht ganz sein Optimum erreicht, doch ist es momentan ein einfaches den “richtigen” Weg auszuwählen, anstatt mit mehreren Relationen rum zu jonglieren.

Natürlich nicht, damit meinte ich, dass diese “Konstrukte” sehr fehleranfällig sind, nicht nur für Anfänger. (Normalerweise sind solche Fehler schwerer zu verbessern sind, zumindest für mich )

Interessanter währe es, deine Meinung zu hören, statt dieses Kommentars
(ich geb die Hoffnung auf einen Konsens noch nicht auf… vielleicht bin ich auch noch nicht lang genug dabei, um es besser zu wissen )

Ich nutze MPs nur sehr sparsam und wenn dann Methode 1.

Konsens? Die Hoffnung stirbt zuletzt, heißt es. Aber, ist sie nicht schon gestorben.

Wenn ich dann z.B. lese, sinngemäß: da muß ein Kompromis her, dem ich zustimmen werde, aber komplett daran halten werde ich mich nicht.

Ich habe gerade (wie fast jeden Tag) Multipolygon Fehler behoben. Dabei bin ich in auf eine “geniale” neue Lösung zur Verringerung des Speicherverbrauchs gestossen:

In einem Ort gibt es je eine Relation für alle Spielplätze, 3 Relationen für die Gebäude (wobei einzelne Gebäude in mehreren Relationen enthalten sein können) etc. Interessanterweise werden die Changesets mit “FineTuning” bezeichnet Auf jeden Fall blüht die Gegend zur Zeit in OSMI in leuchtendem Rot auf.

Ich hoffe nur diese Lösung macht jetzt nicht Schule …

Gebäude und Spielplätze in MPs?

Please don’t ask me why…

Gebäude (schon etwas reduziert, vorher hatten sie je über 30 Elemente):
http://www.openstreetmap.org/browse/relation/2153142
http://www.openstreetmap.org/browse/relation/2153553

Spielplätze:
http://www.openstreetmap.org/browse/relation/2150506

omg

Leute kommen auf unsinnige Ideen…

“Unsinnig”? Diese Leute lesen alle die Multipolygon WIKI Seite, die ja auch hier empfohlen wird, in der nicht beschrieben wird was “unsinnig” ist, sondern was “technisch geht”… Und dann fangen sie an am Datenbestand rumzuspielen, haben vielleicht 5 Jahre Mathe studiert und Spaß an komplexen Konstrukten. Wer will ihnen einen Vorwurf machen? - wenn es keiner hinbekommt eine WIKI Seite zu erstellen mit Empfehlungen wie man MP’e sinnvoll und gut wartbar macht??? Hier kriegt man nix auf die Reihe außer über angeblich blöde Mapper herzuziehen!

Die erste Regel wäre die die chris66 empfhielt.

Ich kenne Wald-Polygone mit 400 Elementen die einfach strukturiert sind an denen man prima arbeiten kann.

Und dann gibt’ solche mit 1o Elementen, geteilten mit anderen zusammenhängenden Grenzflächen, n:m Beziehungen, und Du musst 5 Polygone mit ändern wenn Du eins ändern willst und machst am besten vorher 'ne Zeichnung. Für diejenigen die sowas “erfinden” die sicherste Art sich bei OSM zu “verewigen” und andere Mapper aus der Gegend fernzuhalten. Aber auch die halten sich nur an die WIKI MP-Regeln…

Punkt 1: KISS ist mehr oder weniger ein Grundsatz bei OSM.

Punkt 2: Schau dir die Seite Relation:multipolygon nochmal genau an. Besonders die ersten Abschnitte. Da steht ganz eindeutig sinngemäß drin: Einfache Flächen sollen als geschlossene Wege gemappt werden. Nur komplexe Flächen sollen als MP erfasst werden.

Punkt 3: Wenn es so missverständlich wäre, dann würden nicht 99% der Mapper simple Flächen als geschlossene Wege erfassen

Ok, hab mir die Seite nochmal angschaut und lese folgendes heraus:

“Relationen vom Typ Multipolygon werden zur Darstellung von allen möglichen Flächen verwendet. Die Multipolygon Relation ist OpenStreetMaps Datentyp für Flächen.”
→ Bei den ersten beiden Sätzen lese ich raus, dass jede Fläche als MP getaggt werden soll.
(Unterschied:EN: “used to represent complex areas.”)

“Der Einfachheit halber können Flächen auch durch einen geschlossenen Weg […] dargestellt werden.”
→ [Nur] Wenn man will, kann man auch einen geschlossenen Weg zeichnen.
(Unterschied:EN: “Simple areas are mapped…”)

“Für alle Flächen, die komplexer sind, ist die Multipolygon Relation erforderlich. Zum Beispiel wenn der Umriß aus mehreren Wegen zusammengesetzt ist, wenn die Fläche aus mehreren getrennten Wegen besteht […]”
→ Sowas sollte doch die Ausnahme sein, zB bei besonders großen/riesigen Flächen.

“Eine Multipolygon Relation kann eine beliebige Anzahl von äußeren (Umriß) und eine beliebige Anzahl von inneren Wegen (Löcher) aufweisen und diese müssen gültige Ringe bilden.”
→ Es wird leider nicht empfohlen, den outer und insbesondere die inner als geschlossene Linien zu zeichnen.

“Mitglieder [der Relation]”
→ hier dürfen nur Linien verwendet werden, um outer/inner zu bauen, nicht die geschlossene Linie (Fläche).

“Verwendung: Ist zum Beispiel ein Wald durch vier Straßen begrenzt, so erhalten die vier Straßen das Tag ‘highway’ und sind zugleich äußere Mitglieder der Relation ‘Wald’.”
→ wieder ein Beispiel, wie man Straßen auftrennen soll, um eine Fläche in eine Relationsfläche zu verwandel.

“Verwendung: Ist der Außenring ein einziger geschlossener Weg, der nur die Fläche beschreibt, könnte er mit Tags versehen werden und die Relation ohne Tags bleiben. [Nachsatz: Aber das soll man doch nicht machen.]”
→ ‘Man kann, aber man soll nicht’ kann man sich sparen.

“Beispiele: DE:Multipolygon_Examples”
→ Es gibt Leute die sich das anschauen und nach der ‘Empfehlung’ mappen.

“Tagging:
*Wenn die Relation keine Tags hat wird der Zeichenstil der äußeren Wege verwendet.
*Wenn die Zeichenstile der äußeren Wege nicht zusammenpassen oder kein Stil gefunden wird so ist dies ein Fehler.”
→ Sollten die tags nicht an die Relation? (Wenn ich Punkt 2 mal übertreibe, ist es möglich folgendes Konstrukt zu mappen: Einen Wald aus Einzellinien, und jede Linie bekommt landuse=forest, alle Linien sind in einer taglosen Relation.)

Wenn es nicht missverständlich wäre, würden ~100% der Mapper so mappen