Sinnvolle maximale Größe von Multipolygonen?

Ebbe73 wrote:

Hallo Leute,

der Harz bestand bisher aus insgesamt ca. 50 Waldpolygonen. Jedes Multipolygon hatte ein outer- und 20 bis 100 inner-Elemente. Dieser Aufbau hat sich als robust gegenüber versehentlichen Veränderungen erwiesen.

Nun hat jemand angefangen, einige dieser Multipolygone zu einem großen zusammenzufassen (http://www.openstreetmap.org/browse/relation/93882). Technisch geht das. Allerdings besteht das neue Multipolygon nun aus 434 Elementen, die zusammen ca. 10.000 Punkte umfassen.

Ich halte ein derartiges Multipolygon für unsinnig groß, fehleranfällig und unhandlich. Sollte ich jenes trotzdem so belassen?

Viele Grüße
Ebbe73

Ich würde erstmal versuchen, die Gründe für dieses Vorgehen zu erfahren. Allerdings tendiere ich auch dazu, Multipolygone nicht zu groß werden zu lassen, um die Übersicht zu behalten. Die ursprüngliche Größe erscheint mir unter diesem Gesichtspunkt durchaus als sinnvoll. Wenn es nicht wirklich handfeste Gründe für die Zusammenlegung geben sollte, würde ich sie wieder aufspalten, jedenfalls dann, wenn ich vorhätte, in diesem Zusammenhang etwas zu taggen.

Mehrere Multipolygone zusammenzufassen halte ich für Blödsinn.
Besser ist es pro outer-Way ein Multipolygon azulegen.

Besser als aus mehreren Relationen eine (allzu) große zu machen dürfte es sein, eine Elternrelation (parent relation) zu erstellen. Dies wurde unlängst für die französische Grenze eingeführt: Die Elternrelation France Metropolitaine besteht aus 15 Grenzsegmenten (boundary_segments) als Kindrelationen (child relations). Es gibt auch eine Wiki Seite in Englisch dazu France boundary pyramidal construction.

Die sinnvolle maximale Groesse fuer ein Multipolygon ist genauso gross wie die sinnvolle maximale Groesse fuer ein normales Polygon. Denn genau wie ein normales Polygon tut ein Multipolygon nichts anders, als ein Flaechenobjekt zu repraesetieren. Der einzige Unterschied ist, dass dieses Flaechenelement Loecher haben kann.

Den gesammten Harz als ein einziges Waldgebiet zusammen zu fassen ist sowieso bloedsinnig, da es sich hierbei ja auch nicht um EINEN Wald handelt. Bei dem Harz handelt es sich um ein Gebirge, das zwar zum Grossteil bewaldet ist, trotzdem hat der Wald am einen Ende nichts mit dem Wald am anderen Ende zu tun.

Gruss
Torsten

Ebbe73 wrote:

Ich halte ein derartiges Multipolygon für unsinnig groß, fehleranfällig und unhandlich. Sollte ich jenes trotzdem so belassen?

+1

Unübersichtlich, umständlich und unnötig.

Natürlich erst mal mit dem Menschen reden, aber das ist ein großer Schritt in die falsche Richtung.

bye
Nop

Nop wrote:

Ebbe73 wrote:

Ich halte ein derartiges Multipolygon für unsinnig groß, fehleranfällig und unhandlich. Sollte ich jenes trotzdem so belassen?

+1

Unübersichtlich, umständlich und unnötig.

Vor allem dann, wenn man den beim rendern nicht komplett im Datensatz drin hat.

gruß,
ajoessen

ajoessen wrote:

Nop wrote:

Ebbe73 wrote:

Ich halte ein derartiges Multipolygon für unsinnig groß, fehleranfällig und unhandlich. Sollte ich jenes trotzdem so belassen?

+1

Unübersichtlich, umständlich und unnötig.

Vor allem dann, wenn man den beim rendern nicht komplett im Datensatz drin hat.

gruß,
ajoessen

+1
Bildlich ausgedrückt:
Da werden mühsam riesige Schränke zusammengesetzt, die anschließend doch wieder zerteilt werden müssen, weil sie durch keine normale Tür mehr passen. In Messehallen wohnen die wenigsten. 😉

Die Idee mit den Elternrelationen ist die einzig sinnvolle Lösung, wenn z.B. jemand ausdrücken will, daß die ganzen Waldgebiete zum Harz gehören.

Die Aufteilung riesiger Waldpolygone auch mit geraden Schnitten quer durch den Wald läßt sich sinnvoll mit der Erfassung von Flurstücken begründen, die in amtlichen Plänen mit Nummern erfaßt sind. Außerdem tragen viele Teilgebieten von Wäldern und Fluren eigene Namen.

Gruß
tippeltappel

tippeltappel wrote:

...
Bildlich ausgedrückt:
Da werden mühsam riesige Schränke zusammengesetzt, die anschließend doch wieder zerteilt werden müssen, weil sie durch keine normale Tür mehr passen. In Messehallen wohnen die wenigsten. 😉

Die Idee mit den Elternrelationen ist die einzig sinnvolle Lösung, wenn z.B. jemand ausdrücken will, daß die ganzen Waldgebiete zum Harz gehören.

Die Aufteilung riesiger Waldpolygone auch mit geraden Schnitten quer durch den Wald läßt sich sinnvoll mit der Erfassung von Flurstücken begründen, die in amtlichen Plänen mit Nummern erfaßt sind. Außerdem tragen viele Teilgebieten von Wäldern und Fluren eigene Namen.
...

Das ganze Thema und die Problematik ist vergleichbar mit den "verschwundenen Seen":
http://forum.openstreetmap.org/viewtopic.php?id=10964

Ich wiederhole mich bewusst:
Wir brauchen mit zunehmender Detaillierung dringend eine transparente Vorgehensweise oder Hilfe für das Mappen großer Flächen unter Beachtung der nodes-Obergrenze, die auch der einfache Mapper nachvollziehen und anwenden kann. Mal abgesehen davon, dass Darstellungsfehler in Anwendungen infolge fehlerhafter oder unzureichender Erfassung eine negative Außenwirkung haben, brauchen wir auch engagierte Laien zur Vervollständigung unserer Daten, die auf solche Hilfen oder ggf. mindestens Warnungen in den Tools angewiesen sind.

naja, einen zusammenhängenden Wald aufzuteilen ist sachlich auch nicht der Weisheit letzer Schluss. Aber ich habe das auch gemacht, wenn der Wald zu groß wurde. Die MP-Relationen sind nicht so das Problem. Ob da nun ein oder mehrere Outer-Ways drin sind, finde ich eigentlich egal.
Was mich an zu großen Wäldern stört, ist, dass die so unübersichtlich sind. Man muß weit rauszoomen um den ganzen Wald zu sehen. Dann verschwimmen aber die Ränder in einer "Node-Suppe"
Achja, Mapnik und Osmarender scheinen keine geteilten Wäder zu mögen. Die malen einen weißen Strich an der Schnittlinie. Und Osmarender kriegt komplizierte Wälder scheinbar nicht richtig hin und rendert weiße Blöcke in den Wald.

Willi2006 wrote:

Besser als aus mehreren Relationen eine (allzu) große zu machen dürfte es sein, eine Elternrelation (parent relation) zu erstellen.

Und das ist auch bei Multipolygonen erlaubt? Und wird von Mapnik unterstützt?
Chris

hurdygurdyman wrote:

Wir brauchen mit zunehmender Detaillierung dringend eine transparente Vorgehensweise oder Hilfe für das Mappen großer Flächen unter Beachtung der nodes-Obergrenze, die auch der einfache Mapper nachvollziehen und anwenden kann. Mal abgesehen davon, dass Darstellungsfehler in Anwendungen infolge fehlerhafter oder unzureichender Erfassung eine negative Außenwirkung haben, brauchen wir auch engagierte Laien zur Vervollständigung unserer Daten, die auf solche Hilfen oder ggf. mindestens Warnungen in den Tools angewiesen sind.

Da kann ich dir nur voll zustimmen. Obwohl sich viele auf die Brust klopfen, wieviele Daten sie beigetragen haben, ist gerade, selbst in Deutschland, die Datenlage in der Fläche noch viel zu dünn. Ebenso dürfte die hohe Zahl der "Karteileichen" in OSM, also Registrierte, die nie etwas gemappt haben, auch damit zu tun haben, dass der Zugang zur "Welt des Mappens" nicht gerade leicht gemacht wird. Das gilt insbesondere auch für die Verwendung von Relationen.

Was das Wälderaufteilen betrifft, versuche ich, dies entlang von Straßen und Wegen zu tun. Dort ist ohnehin oft eine kleine Schneise, so dass sich das meines Erachtens geradezu anbietet. Dann gibt es auch das Problem mit Schnittlinien, was mir auch schon aufgefallen ist, nicht.

miraculixOSM wrote:

Was das Wälderaufteilen betrifft, versuche ich, dies entlang von Straßen und Wegen zu tun. Dort ist ohnehin oft eine kleine Schneise, so dass sich das meines Erachtens geradezu anbietet. Dann gibt es auch das Problem mit Schnittlinien, was mir auch schon aufgefallen ist, nicht.

+1
Nur bei Seen würde ich das nicht so machen (laufen ja auch keine Straßen durch 😉 ).

Chris

tippeltappel wrote:

Die Idee mit den Elternrelationen ist die einzig sinnvolle Lösung, wenn z.B. jemand ausdrücken will, daß die ganzen Waldgebiete zum Harz gehören.

+1

Die logische Information, daß hier etwas zusammengehört, kommt in die Elternrelation.
Die Geometrie wird trotzdem nicht komplizierter.

bye
Nop

Hi,

brauchen wir überhaupt eine Zusammenfassung der Wälder? Kann man nicht einfach eine große Fläche mit dem Namen "Harz" haben und einen Haufen Wälder, die in diesem Gebiet liegen? Wäre das nicht auch realistischer (schließlich ist der Harz kein Wald sondern eine Region)?

Eine Straße in Bochum gehört ja auch zu Nordrhein-Westfalen und keiner kommt auf die Idee, sie in eine NRW-Relation zu stecken.

MfG
Weide

Klar wäre das ausreichend. Aber ich bin ja schon froh, solange gewisse Leute nicht jeden Baum im Harz einzeln einzeichnen und verlinken wollen. :-)

bye
Nop

Nop wrote:

Klar wäre das ausreichend. Aber ich bin ja schon froh, solange gewisse Leute nicht jeden Baum im Harz einzeln einzeichnen und verlinken wollen. :-)

bye
Nop

Du hast die Fuchsbauten vergessen... 😉

hurdygurdyman wrote:

Du hast die Fuchsbauten vergessen... 😉

Wär doch mal was für ein proposal:

animal_made:de: {loch,damm,nest,pfad,hügel}
animal:de: {Fuchs,Maus,Maulwurf,Ratte,Reh,Hund,Katze,Vogel,...} 😉

c0bRa wrote:

hurdygurdyman wrote:

Du hast die Fuchsbauten vergessen... 😉

Wär doch mal was für ein proposal:

animal_made:de: {loch,damm,nest,pfad,hügel}
animal:de: {Fuchs,Maus,Maulwurf,Ratte,Reh,Hund,Katze,Vogel,...} 😉

Nicht zu vergessen aus meiner Erfahrung mit den Hundespaziergangen:
dog_made=dug_hole

dog_made=contact_mine auf Gehsteigen sind zu kurzlebig zum taggen oder? 😉

hachja Freitag *G*

c0bRa wrote:

dog_made=contact_mine auf Gehsteigen sind zu kurzlebig zum taggen oder? 😉

Hoffentlich, denn dafür gibt es ja wieder die mit Aufhängehöhen gemappten Hundekottütenspender.

c0bRa wrote:

dog_made=contact_mine auf Gehsteigen sind zu kurzlebig zum taggen oder? 😉

Wieso? Wenn die opendogshitmap.org minütlich aktualisiert wird brauchen wir das unbedingt! :-)

bye
Nop

Nop wrote:

Wieso? Wenn die opendogshitmap.org minütlich aktualisiert wird brauchen wir das unbedingt! :-)

Finde ich nicht gut. Denn wenn die Ordnungshüter die Karte verwenden und mit den durch mein Handy erzeugten Bewegungsmustern abgleichen, da ich als Hundesteuerzahler als potentieller Handlungsstörer infrage komme, kann das für mich ganz schön teuer werden. Es sei denn, die Hundekottütenspender sind endlich mal vollständig gemappt.
Projekt der Woche?

Hat leider alles nix mit Multipolygonen zu tun, aber die diskutieren wir ja ernsthaft bei den verschwundenen Seen weiter. 😉

hurdygurdyman wrote:

Hat leider alles nix mit Multipolygonen zu tun, aber die diskutieren wir ja ernsthaft bei den verschwundenen Seen weiter. 😉

Naja, die ernsthafte Diskussion ist an dem Punkt angelangt:
1. Wir sind uns einig, wie eine bessere, verständlichere Anwendung aussehen müßte.
2. Es interessiert niemanden und es wird sich nix ändern.

Also wieso nicht ein wenig Spaß haben?

bye
Nop

Au Mann! Ich lach mich noch schlapp hier! 😄

Nop wrote:

hurdygurdyman wrote:

Hat leider alles nix mit Multipolygonen zu tun, aber die diskutieren wir ja ernsthaft bei den verschwundenen Seen weiter. 😉

Naja, die ernsthafte Diskussion ist an dem Punkt angelangt:
1. Wir sind uns einig, wie eine bessere, verständlichere Anwendung aussehen müßte.
2. Es interessiert niemanden und es wird sich nix ändern.

Also wieso nicht ein wenig Spaß haben?

bye
Nop

Warte mal ein wenig. Ich verschnaufe gerade nur 😉

zu 1. Wenn wir uns einig sind, dann sollten wir auch für eine verständlichere Anwendung sorgen.
zu 2. Es interessiert doch einige und wenn man will, kann man was ändern.

Ich schaue mir gerade verschiedene MP an, um zu ergründen, ob die sinnvoll angelegt sind und ob man Muster bei typischen Fehlern erkennen kann, aus denen man dann allgemeingültig Empfehlungen, Warnungen, howto's oder so basteln kann, damit der ganze Datenhaufen auch vernünftig weiter zu bearbeiten/verwenden ist.
Immer schön den Endanwender im Auge behalten 😎

Große MP aufzuteilen, befürworte ich auch. Sonst sucht man sich bei MP-Fehlern (offene Ringe, doppelte Members usw.) zum Krüppel.

miraculixOSM wrote:

Was das Wälderaufteilen betrifft, versuche ich, dies entlang von Straßen und Wegen zu tun. Dort ist ohnehin oft eine kleine Schneise, so dass sich das meines Erachtens geradezu anbietet. Dann gibt es auch das Problem mit Schnittlinien, was mir auch schon aufgefallen ist, nicht.

Die Schnittlinien sind ein Renderer-Problem und mir offen gesagt wurscht, weil ich davon ausgehe, dass die Renderer-Entwickler das eines Tages in den Griff kriegen werden.

In einem Heimwerker-Forum wurde diskutiert, ob man Löcher besser zwischen die Kacheln oder mitten in die Kacheln bohrt. Diese 2 Ansätze gibt es im Grunde auch bei Multipolygonen. Ich gehöre zu denen, die am liebsten mitten in die Kacheln bohren. D.h. ich lege die Wald-MP-Grenzen mitten durch den Wald, wo weit und breit nichts ist, was stören könnte. Nutzt man eine Straße als Grenze, dann hat man das Problem, dass beim Aufteilen der Straße (wegen Brücken, Geschwindigkeitsbeschränkungen, verschiedener tracktypes o.ä.) die Multipolygone eine Vielzahl an Außengliedern bekommen, was der Intention zur Vereinfachung widerspricht.

Außerdem verlaufen Straßen oft durch kleine Wiesen oder an deren Rand. Wenn man die Wiesen am Rand eines MP als "inner" einfügt, dann meckern bestimmte Validatoren, und es dauert nicht lange, bis jemand in der Wahnvorstellung das MP reparieren zu müssen irgendwas zerstört.

Mit den Querwaldein-Grenzen hat man alle diese Probleme nicht.

Thema Harz: Das ist AFAIK ein Gebirge. Da es bestimmt nicht nur mit Wald bedeckt ist, sondern auch mit Wiesen usw., kann man nicht einfach die Waldflächen zu einer Relation name=Harz zusammenfassen. Das gleiche Problem hatte ich im Leithagebirge, wo es eine Waldfläche mit name=Leithagebirge gab. Als ich begann, den Wald genauer zu zeichnen, hab ich fürs Leithagebirge eine eigene, gob umrissene Fläche (ID 94453497) angelegt mit natural=mountain_range. Überraschend rendert Mapnik sogar den Namen, allerdings falsch (an der Umrandung, obwohl area=yes gesetzt ist.) Es wird allmählich Zeit, wichtige natural=* wie valley, ridge und mountain_range zu proposen.

Das Aufteilen an Straßen hatte ich so interpretiert, dass man einen parallelen way zu der Straße zeichnet. So zumindest praktiziere ich es schon länger. Natürlich nur, wenn der Wald wirklich geteilt wird.

hurdygurdyman wrote:

2. Es interessiert niemanden und es wird sich nix ändern.

Dann trete ich einen Schritt beiseite um die Optimisten nach vorn zu lassen. Ich würde mich freuen wenn Du tatsächlich was bewegen kannst - ich habe die Hoffnung aufgegeben. Ob OSM verständlich und für Otto Normalverbraucher nutzbar ist, interessiert einfach viel zu wenig Leute - insbesondere unter denjenigen, die das Format der Dinge festlegen.

bye
Nop

Ein neuer Typ area (zusätzlich zu way und node) wäre wünschenswert. Das ändert aber nichts an diesem Problem. Es wäre lediglich für die Auswerter einfacher Flächen von Wegen zu unterscheiden. Das bisherige area=yes wäre dann überflüssig und eine Vermischung von Weg- und Flächentags wäre endlich vorbei.

Ich denke eher, es ist an euch Kritikern, ein Schema zu entwickeln, was eine gleichbleibende Funktionalität mit sich bringt und einfacher zu verstehen ist.

Meiner Meinung nach liegt es primär an den Editoren, das Thema für jeden verständlich zu machen. Bei CAD ist das recht trivial und man bekommt von der technischen Struktur nichts mit. Man zeichnet bspw. in ein Rechteck einen Kreis und sagt dem Programm, dass es den Kreis von der Fläche abziehen soll. Ähnlich sollte es auch bei OSM sein und der Editor sollte selbstständig die Relation anlegen und die Tags richtig setzen. Eine Auswahl der Fläche sollte auch über einen Klick in die Fläche erfolgen und in den Eigenschaften sollten dann die Eigenschaften der ausgewählten Fläche angezeigt werden, unabhängig davon, wo sie getagt sind.

Zusätzlich kann der heutige Modus als Expertenmodus erhalten bleiben.

Das Problem ist, daß sich ohne ersichtlichen Grund das Handling einer Fläche komplett ändert. Die jetztige API ist nur darauf ausgelegt, es für den API-Server möglichst leicht zu machen - die Komplexität trifft die Mapper, Editoren und Renderer. Denn die müssen aus den Einzelteilen wieder ein Gesamtbild machen, ändern, und wieder für die API auseinanderbrechen. Sozusagen "Alle für Einen", weil mit sehr primitiven Mitteln wesentlich komplexere Dinge beschrieben werden sollen. Die Fehlerquote ist auch entsprechend hoch.

- Normales Polygon: Der Way ist das Polygon, die way-id identifiziert das Polygon
- Multipolygon: Der way ist das Polygon, über eine Relation werden andere Ways als Löcher assoziiert, die way-id identifiziert das Polygon
- Advanced Multipolygon: Die Relation ist das Polygon, die relation-id identifiziert das Polygon

Hier ist dreimal dieselbe Sache mit unterschiedlichen Mitteln dargestellt - und das macht das Ganze so unverständlich.

Was ich mir spontan als bessere Variante vorstellen könnte: Trennung von Geometrie und Information und Darstellung der Objekte in einer versändlichen Hierarchie, also sowas wie:

Geometrie (ohne Tags):
- <node>
- <line>

Objekte (mit Tags)
- <poi>: hat <nodes>
- <way>: hat <lines>
- <area>: hat outer-<lines>, hole-<lines>

Gruppierungen
- <relation>: <alle objekte>

Damit ist ein polygon nur noch der einfachste Fall eines multipolygons und es ändern sich nicht je nach Komplexität das gesamte Handling.

Die heutige DB sollte sich ohne Datenverlust automatisch auf so eine Struktur übernehmen lassen - zumindest alles was ein Renderer versteht. Und da wo jemand was besonders abgefahrenes konstruiert hat - müßte es so oder so von Hand repariert werden.

bye
Nop

fkv wrote:

Nutzt man eine Straße als Grenze, dann hat man das Problem, dass beim Aufteilen der Straße (wegen Brücken, Geschwindigkeitsbeschränkungen, verschiedener tracktypes o.ä.) die Multipolygone eine Vielzahl an Außengliedern bekommen, was der Intention zur Vereinfachung widerspricht.

Es ist ja auch dringends davon abzuraten, fuer den rand der Flaechen den selben Way zu benutzen, der auch fuer ein anderes Objekt genutzt wird. Denn besser verstecken koennte man die Information fuer die Gelegenheitsmapper gar nicht.
Also fuer den Flaechenrand immer einen eigenen Way benutzen, ob der die selben Nodes benutzen sollte wie die Strasse oder leicht daneben liegt ist Geschmackssache.

Außerdem verlaufen Straßen oft durch kleine Wiesen oder an deren Rand. Wenn man die Wiesen am Rand eines MP als "inner" einfügt, dann meckern bestimmte Validatoren, und es dauert nicht lange, bis jemand in der Wahnvorstellung das MP reparieren zu müssen irgendwas zerstört.

Wenn man entlang der Strassen schneidet, dann braucht mal solche an die Strassen angrenzenden Objekte ja auch nicht mehr per Multiplogon-Relation aus dem Wald ausschneiden. Denn sie liegen ja durch den Schnitt gar nicht mehr mitten im Wald. Durch geschicktes Schneiden kann man sich also haeufig auch noch die Relation sparen, und schon wird das ganze Konstrukt wieder eine Nummer einfacher. Was will man mehr?

Gruss
Torsten