Multipolygon-Relation oder separater geschlossener Weg

Ich überlege gerade anhand von Naturschutzgebieten (NSGs), ob man diese besser als Relation vom Typ Multipolygon oder als separaten geschlossenen Weg erfassen soll. Beides hat gewisse Vor- bzw. Nachteile:

Für eine Relation spricht, daß die Grenzen eines NSG i.d.R. entlang von Wegen, Gewässern, Straßen, Gemeindegrenzen… gezogen werden – zumindest in meiner Umgebung. Die begrenzenden “Weg”-Stücke existieren dabei meistens schon in der OSM-DB, so daß diese Stücke nur in einer Relation zusammengefügt werden müßten. Damit hätte man auch keinen weiteren Aufwand, wenn etwas (e.g. ein Stück Weg oder Gewässer) verschoben oder im Verlauf genauer kartiert werden müßte. Es kommt schließlich öfter vor, daß irgendein Mapper einen Weg etc. anhand seiner GPS-Tracks o.ä. im Verlauf etwas verändert. Dabei wird häufig vergessen, die Grenze des NSG entsprechend anzupassen – und schon hat man einen Fehler… Eine Relation bildet die Realität also eigentlich korrekter und fehlertoleranter ab.

Gegen eine Relation spricht, daß man bestehende Wege, Gewässer, etc. manchmal zusätzlich teilen müßte, damit die “Weg”-Stücke passen. Ganz selten fehlt auch ein Stück Grenze, so daß man dafür ein Stück Weg ohne Attribute(?) kartieren müßte, damit sich die Relation “schließt”.

Ich weiß auch nicht (habe mich noch nicht damit beschäftigt), wie Relationen in einer PostGIS-DB abgebildet werden, i.e. ob PostGIS-Operationen wie z.B. “liegt ein Punkt in einem Gebiet”, “was ist die kürzeste Entfernung eines Punktes zu einem Gebiet”, … bei Relationen genauso gut funktionieren, wie bei separaten Flächen. Meine Vermutung ist allerdings, daß das bei Relationen vom Typ Multipolygon ohne Einschränkung funktionieren sollte.

Bitte nicht wieder das übliche, pauschale Relation-Bashing.

ich würds als extra Way anlegen. Ist etwas robuster, da mit Wegen oft merkwürdige Dinge passieren und dann ist die Relation kaputt. Ich bin auch nicht so der Freund von gestückelten Wegen. Postgis ist das egal. Da werden die Relationen eh vor dem Import wieder in einen geschlossenen Way umgewandelt und so importiert.

Ganz klar ein separater, geschlossener Way. Einfach, verständlich, robust.

Wenn eine MP-Relation nicht zwingend notwendig ist, sollte man sie auch nicht benutzen. Denk immer daran: Jede Karte oder andere Auswertung muß diesen Typ von MP-Relation explizit unterstützen, ansonten ist sie sowieso nicht sichtbar.

Du hast die Vor- und Nachteile richtig beschrieben. Wenn die NSG-Grenze wirklich oft an existierenden Geometrien entlanglaeuft, wuerde ich auf jeden Fall eine Multipolygon-Relation einsetzen. Wenn hingegen nur ab und zu mal so ein gemeinsamer Verlauf vorliegt, kann man auch einen normalen Way nehmen und ihn an den Stellen einfach auf die gleichen Nodes legen. Das sollte man aber nicht uebertreiben.

Ein weiterer Vorteil der Multipolygon-Relation ist, dass sie in aller Regel gerade bei grossen Gebieten viel Datenverkehr spart. Angenommen, der Umriss des NSG hat 1000 Punkte, dann wuerde jedesmal, wenn irgendwo jemand einen weiteren einfuegt oder einen entfernt die Uebertragung eines 1000-Punkte-Ways (sowohl vom Editor zum Server als auch vom Server, via Diff-Updates, an all jene, die eigene Datenbanken betreiben) erforderlich. Besteht das NSG aber aus 10 Ways mit je 100 Nodes, dann muss bei einer Aenderung auch nur der betr. Way veraendert werden.

Wie das in einer PostGIS abgebildet wird, haengt davon ab, welche Importmethode Du benutzt. In einer mit osm2pgsql angelegten PostGIS wuerden beide Methoden zum gleichen Resultat fuehren.

Bye
Frederik

Und ein weiterer Nachteil der Multipolygon-Loesung ist, dass die Auswertung solcher Objekte (z.B. Renderer) viel aufwendiger ist als bei einem einfachen Weg. Denn alle Wegabschnitte muessen erst vorliegen (wenn sie ausserhalb des Kartenbereichs liegen, werden sie ja von der API nicht automatisch mitgeliefert, s.o.), und dann muessen sie sortiert und zu dem geschlossenen Weg zusammen gesetzt werden, ehe das Programm da ist, wo es beim einfachen Weg von Anfang an waere.

Hauptargument ist aber, dass der einfache Weg fuer die Mapper-Gemeinschaft viel leichter zu bearbeiten ist. Bei den komplexen Relationskonstrukten verlieren (nicht nur Anfaenger) sehr schnell den Ueberblick.

Gruss
Torsten

+1

Na dann lasst uns in Zukunft alles als zusätzliche Flächen/Linien erfassen. Also mit dieser Begründung ist es doch wesentlich besser ÖPNV Routen als Linien über Straßen zu zeichnen. Und bei Wanderrouten ginge das auch ganz toll. Dann braucht auch keiner mehr irgendwelche Kreisverkehre oder Wege dafür zu teilen.

Es geht hier doch um Multipolygone. Und da hat de_muur IMHO einfach Recht.

Gruß

Solange es keine Flächenelemente in der DB gibt, sind Multipolygone unverzichtbar. Ob man eine Fläche besser als neuen in sich geschlossenen Way zeichnet, oder vorhandene Ways nutzt,
muss immer im Einzelfall entschieden werden.

Dass eine Relation von der API nicht gleich vollständig geliefert wird, liegt an der API und ist kein prinzipielles Problem. Bei den zu einem Way gehörigen Einzelpunkten geht es doch auch.

Es gibt hier zwei Ansätze, Flächen wie z.B. NSGs in der Datenbank abzubilden, Multipolygon-Relationen und geschlossene Wege. Beide Ansätze haben gewisse Vor- und Nachteile. So, wie es aussieht, wird mal das eine und mal das andere besser sein. Also geht es hier nicht darum, einen dieser Ansätze dogmatisch vorzuziehen.

Wenn ein NSG erst mal als Relation erfaßt worden ist, wird ein Bearbeiten in den meisten Fällen bedeuten, daß man eine Grenze (Weg, Gewässer, …) korrigiert, verfeinert, etc., vielleicht auch mal einen Weg splittet. Dabei braucht man die Relation selbst aber gerade nicht anzufassen, sondern nur ein Stück Weg.

Damit sollte Dein "Haupt"argument in dem hier diskutierten Fall im Wesentlichen entkräftet sein – zumal es ambitioniert ist, dies auf “die Mapper-Gemeinschaft” (als Ganzes) anwenden zu wollen.

Software wird seit Jahrzehnten immer leistungsfähiger und wächst mit den Anforderungen. Damit sehe ich hierin keinen prinzipiellen Hinderungsgrund.

Das Problem ist nicht, wenn jemand noch mal das NSG aendern will, sondern wenn jemand was an den Randelementen aendert und dabei unbeabsichtigt das Gebiet kaputt macht.

Reine Statistik. Bei keinem anderen Mapping-Schema gibt es so haeufig Fragen hier im Forum oder auf der Mailingliste und bei keinem anderen Schema findet man so viel Muell in der Datenbank.

Der Strom kommt in Deutschland ja auch aus der Steckdose. Da braucht man keine Kraftwerke und an kann auch ruhig die Rechner nur so aus Spass belasten. Die werden ja sowieso immer leistungsfaehiger.

Nichts fuer ungut. Aber auch wenn das kein “prinzipieller Hinderungsgrund” ist, so ist das doch immer noch ein sehr starker praktischer Hinderungsgrund.

Man kommt zwar z.Z. nicht ohne Multipolygon aus, aber nur so zum Spass sollte man es trotzdem nicht verwenden.

Gruss
Torsten

Meines Erachtens ist dieses Argument beim Beispiel Naturschutzgebiet fehl am Platze. Dieses kann als einfaches Multipolygon bestehend aus mehreren Wegen dargestellt werden. Ein komplexes Relationskonstrukt ist nicht erforderlich.

Worauf stützen sich diese Behauptungen?
Wo sind die Zahlen dazu?
Woher die Berechtigung für die “Mapper-Gemeinschaft” zu sprechen?

Die immer wieder geführte Debatte separater Weg oder Multipolygon zeigt doch gerade, dass es Kartierende gibt, die generell den separaten Weg nehmen, andere, die generell das Multipolygon nehmen und wiederum andere, die flexibel je nach Situation das eine oder andere einsetzen. Die Behauptung kann wohl nur für die erste Gruppe und nicht für die gesamte Gemeinschaft gelten.

Passt nur bedingt hier her, aber wie könnte man diesen OSM-I error auflösen?
http://tools.geofabrik.de/osmi/debug.html?view=multipolygon&lon=9.10349&lat=49.34559&zoom=17&opacity=0.80&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary
Relations Nr. 1459197

4 Gebäudeteile, davon eines mit Loch, haben gemeinsame Kanten. Das Loch verlangt ein MP, ohne dieses könnte man eine site relation daraus machen.

schaus dir mal an: immer noch 4 Teile, davon nur 1 MP. kannst du jetzt gerne mit dem Rest in eine Site packen.

MPs sind notwendig, um Flächen mit Löchern zu definieren und nicht zum Zusammenfassen diverser Einzelteile gedacht.

Die hier ist die “kleine” Lösung - absolut minimale MP-Verwendung.

Gruss
Walter

@wambacher:
Bei Deiner Aktion ist der Name verloren gegangen. Konnte ihn aus der alten Mapnik Darstellung ablesen und habe ihn an die Site Relation gepackt.
Mal sehen, wie das gerendert wird. Vorher war der Name ca. 4 Mal vorhanden.

na ja, “verloren gegangen” ist nett formuliert - ich hab ihn gelöscht, da er jetzt bei dem Teilgebäude nicht passte. Ich dachte mir, dass du die Ecke kennst :wink:

aber wieso in mapnik nachsehen? dafür gibt es doch die History.

Gruss
Walter

Besonders gut sieht das aber nicht aus: http://www.openstreetmap.org/?lat=49.345068&lon=9.103881&zoom=18&layers=M
Das “Loch” ist kaum sichtbar, und der Name wird gar nicht mehr dargestellt.

war ne schwere Geburt (2 Köpfe und Steißlage):

obwohl ich kein Fan von “Taggen für die Renderer” bin, hab ich es mal ausprobiert.

  • warum das mit dem Loch nicht geklappt hat, kann ich nicht mehr nachvollziehen. Auf jeden Fall muss das Gebäude ein MP mit outer/inner sein und dann ist das ok.
  • er nimmt auf Biegen und Brechen nicht den Namen der Site-Relation (Bug?). Dafür aber die Namen der Member.
    Ich hab hier EIN Gebäude und den Umriss benannt. Beides funktioniert - such dir das passende aus.
    Den Perimeter hab ich mal geschätzt. Eventuell benutzen die ja die Halle als Aula/Turnhalle mit.
  • Der Name des Perimeters wird nur genommen, wenn der Perimeter auch amenity=school hat (Bug?)
  • Label wird ignoriert; daher setzt er den Namen ins Zentrum des Perimeters.

Also wird die Site-Relation noch nicht gut gerendert. Ist ja auch nur ein offenes Proposal.

  • die Parkplätze waren doppelt - einmal als Node und dann noch als Area. Daher wurden die doppelt dargestellt.

Gruss
Walter