Multipolygonwahnsinn - oder: Durchblick war gestern!

streckenkundler · 2013-06-01 17:07:26

Hallo,

morjak wrote:

Also ich würde das in mindestens 20 Teile zerhacken.

20?? beim überfliegen des Monsters hab ich in der Masse der Fläche keine Berechtigung eines Multipolygons gesehen. Da werden gleich ganze residentals zu Acker, Bahnstrecken Bundesstraßen, die Aue der alten Oder und anderer Gewässer, diverse Wiesen- und Weidebereiche und Gehölzinseln und -streifen.

We macht sich ran, daß Monster zu zerhacken?

Sven

fx99 · 2013-06-01 18:12:58

Ich denke, da hilft nur löschen und neu anfangen!

morjak · 2013-06-01 18:48:22

streckenkundler wrote:

Hallo,
morjak wrote:
Also ich würde das in mindestens 20 Teile zerhacken.
20?? beim überfliegen des Monsters hab ich in der Masse der Fläche keine Berechtigung eines Multipolygons gesehen. Da werden gleich ganze residentals zu Acker, Bahnstrecken Bundesstraßen, die Aue der alten Oder und anderer Gewässer, diverse Wiesen- und Weidebereiche und Gehölzinseln und -streifen.

Ich meinte damit allein von der Größe her.

streckenkundler · 2013-06-01 19:58:38

Guten Abend,

morjak wrote:

Ich meinte damit allein von der Größe her.

hm... ich hätte noch einfügen sollen:

20?? noch mehr aber...

Denn an die Bahnstrecken gehört ein landuse=railway, an Bundes- und Landesstraßen landuse zu trennen gehört eigentlich schon zum Standard.

fx99 wrote:

Ich denke, da hilft nur löschen und neu anfangen!

Nun, das Multipolygon hat ob seiner Größe recht erstaunlich wenige Fehler: nur ein paar touching inner Rings. Es ist weitestgehend aus geschlossenen Linienzügen zusammengesetzt, was ein entlassen einzelner Flächen einfacher macht. Mit einem strukturierten zerschneiden kann man auch Geomefehler die Lücken, überlagernde Linien und so verringern.

meint Sven

SunCobalt · 2013-06-01 20:32:35

streckenkundler wrote:

Nun, das Multipolygon hat ob seiner Größe recht erstaunlich wenige Fehler: nur ein paar touching inner Rings.

Touching Inner sind keine Fehler. Kleines Beispiel: Jemand malt eine Wiese und einen See die aneinander grenzen und nutzt für beide Ways die gleichen Nodes an den Schnittstellen -> Kein Fehler. Jetzt malt noch jemand den Wald ringsrum und trägt die beiden Flächen, See und Wald, als Inner in ein MP ein. Jetzt ist es ein Fehler wenn sich die Flächen berühren? Man muss also künstlich einen Zwischenraum schaffen, wo evtl gar keiner ist? Aber nur in einem MP?

Last edited by SunCobalt (2013-06-01 20:36:17)

Basstoelpel · 2013-06-01 20:46:02

Es kann syntaktisch noch so fehlerfrei sein, wenn erhebliche Bereiche die es beschreibt eben kein Acker sind und nicht sauber ausgeschnitten sind, ist es fehl am Platz.

Baßtölpel

rayquaza · 2013-06-01 20:57:07

Man könnte interpretieren, dass zwischen See und Wald so noch ein 0 Meter breiter Streifen Acker wäre. Anwendungen, die die Grenzen des Ackers darstellen zeichnen so auch meist eine zusätzliche Linie zwischen Wald und See (z.B. Leaflet auf osm.org).
Ich versuche Multipolygone zu vermeiden wo es sinnvoll möglich ist und würde daher vermutlich die Linie, die um See *und* Wald herum geht nochmal ziehen, um nicht für beide jeweils ein Multipolygon erstellen zu müssen.

SunCobalt · 2013-06-01 21:12:36

rayquaza wrote:

Man könnte interpretieren, dass zwischen See und Wald so noch ein 0 Meter breiter Streifen Acker wäre.

kann man. Aber dann sollte man keine Unterscheidung machen zwischen See und Wald innerhalb eines MP und ausserhalb.

Basstoelpel wrote:

Es kann syntaktisch noch so fehlerfrei sein, wenn erhebliche Bereiche die es beschreibt eben kein Acker sind und nicht sauber ausgeschnitten sind, ist es fehl am Platz.

Ich habe nicht gesagt, dass dieses (oder irgend ein anderes) MP richtig oder falsch ist. Es ging mit nur darum, den Widerspruch bei Touching Inner aufzuzeigen.

morjak · 2013-06-01 21:12:46

SunCobalt wrote:

streckenkundler wrote:
Nun, das Multipolygon hat ob seiner Größe recht erstaunlich wenige Fehler: nur ein paar touching inner Rings.
Touching Inner sind keine Fehler. Kleines Beispiel: Jemand malt eine Wiese und einen See die aneinander grenzen und nutzt für beide Ways die gleichen Nodes an den Schnittstellen -> Kein Fehler. Jetzt malt noch jemand den Wald ringsrum und trägt die beiden Flächen, See und Wald, als Inner in ein MP ein. Jetzt ist es ein Fehler wenn sich die Flächen berühren? Man muss also künstlich einen Zwischenraum schaffen, wo evtl gar keiner ist? Aber nur in einem MP?

Touching inner rings sind Fehler: Die Berührungskante zwischen Wiese und See kann keine innere Kante des Waldes sein, da sie ja gar nicht an den Wald grenzt.

SunCobalt · 2013-06-01 21:19:23

morjak wrote:

SunCobalt wrote:
streckenkundler wrote:
Nun, das Multipolygon hat ob seiner Größe recht erstaunlich wenige Fehler: nur ein paar touching inner Rings.
Touching Inner sind keine Fehler. Kleines Beispiel: Jemand malt eine Wiese und einen See die aneinander grenzen und nutzt für beide Ways die gleichen Nodes an den Schnittstellen -> Kein Fehler. Jetzt malt noch jemand den Wald ringsrum und trägt die beiden Flächen, See und Wald, als Inner in ein MP ein. Jetzt ist es ein Fehler wenn sich die Flächen berühren? Man muss also künstlich einen Zwischenraum schaffen, wo evtl gar keiner ist? Aber nur in einem MP?
Touching inner rings sind Fehler: Die Berührungskante zwischen Wiese und See kann keine innere Kante des Waldes sein, da sie ja gar nicht an den Wald grenzt.

und ein künstlicher Abstand, der in der Realität nicht vorhanden ist, macht es besser?

fx99 · 2013-06-01 21:22:26

Bei 180 km2 Fläche, 540km Umfang und 355 Elementen ist in diesem kleinflächig strukturierten Gebiet eine Aufteilung sicherlich sinnvoll.
Da das outer insbesondere im Nordwesten sehr grob und willkürlich gezeichnet ist, lohnt sich die Erhaltung dieses mMn nicht.
Hier das diskutierte Objekt:
http://www.openstreetmap.org/browse/relation/63597

streckenkundler · 2013-06-01 21:28:14

fx99 wrote:

Bei 180 km2 Fläche, 540km Umfang und 355 Elementen ist in diesem kleinflächig strukturierten Gebiet eine Aufteilung sicherlich sinnvoll.

Ich hab mir das in JOSM mal genauer angesehen... Da Monster zu bändigen wäre extrem aufwendig... Du hast recht... Löschen und neuerfassen ist besser... oder vielmehr... inner-Flächen des MP's aus diesem entlassen, MP auflösen und nur die outer-Fläche löschen...

Sven

morjak · 2013-06-01 21:28:36

SunCobalt wrote:

und ein künstlicher Abstand, der in der Realität nicht vorhanden ist, macht es besser?

Nein. Man kann Wiese und See als zwei Multipolygone eintragen, die eine gemeinsame outer Kante haben. Die übrigen Kanten bilden den inner ring des Waldes.

SunCobalt · 2013-06-01 21:33:15

morjak wrote:

SunCobalt wrote:
und ein künstlicher Abstand, der in der Realität nicht vorhanden ist, macht es besser?
Nein. Man kann Wiese und See als zwei Multipolygone eintragen, die eine gemeinsame outer Kante haben. Die übrigen Kanten bilden den inner ring des Waldes.

Ohje, technisch hast Du Recht, aber viele Freunde wirst Du damit nicht finden. Nicht umsonst ist dieses Thema ein Dauerbrenner.

morjak · 2013-06-01 21:38:28

SunCobalt wrote:

morjak wrote:
SunCobalt wrote:
und ein künstlicher Abstand, der in der Realität nicht vorhanden ist, macht es besser?
Nein. Man kann Wiese und See als zwei Multipolygone eintragen, die eine gemeinsame outer Kante haben. Die übrigen Kanten bilden den inner ring des Waldes.
Ohje, technisch hast Du Recht, aber viele Freunde wirst Du damit nicht finden. Nicht umsonst ist dieses Thema ein Dauerbrenner.

Deswegen finde ich die ganze Diskussion auch etwas unverständlich. In vielen Situationen führt an Multipolygonen einfach kein Weg vorbei, wenn man es geometrisch korrekt machen will.

streckenkundler · 2013-06-01 22:18:59

morjak wrote:

In vielen Situationen führt an Multipolygonen einfach kein Weg vorbei, wenn man es geometrisch korrekt machen will.

Mit den Möglichkeiten bisher ist das richtig. Ich versuche solche Geometriefehler zu vermeiden.

Aber wenn man es geometrisch korrekt machen will brauchen wir echte Polygone.
http://portal.opengeospatial.org/files/ … t_id=25355

The boundary of a Polygon consists of a set of LinearRings that make up its exterior and interior boundaries;

Ein Multipolygon ist eine "GeometryCollection".

The interiors of 2 Polygons that are elements of a MultiPolygon may not intersect.

Das heißt, wenn ich als outer ein Wald habe und als inner ein See, gilt per Definition die Outerfläche auch für die Inner... was eigentlich nicht beabsichtigt ist.

Als echtes Multipolygon würde mir ein Naturschutzgebiet einfallen, deren inner-Fläche ein Totalreservat des Naturschutzgebietes ist.

Sven

morjak · 2013-06-02 07:46:01

streckenkundler wrote:

The boundary of a Polygon consists of a set of LinearRings that make up its exterior and interior boundaries;

Wenn ich das richtig verstehe, machen Multipolygone genau das Beschriebene. Sie bestehen aus mehren Ringen, die innere und äußere Grenzen bilden.

Im Gegensatz zur Beschreibung sind Multipolygone sogar noch flexibler, da die Ringe aus mehreren Kanten bestehen. können. Ansonsten müsste man wirklich im oben genannten Beispiel die Fläche von Wiese und See insgesamt erstmal mit einen eigenen geschlossenen Weg aus dem Wald herausstanzen und die neu entstandene Fläche bzw. das Loch dann mit Wiese und Wald als eigenständige Polygone füllen, was die Sache unnötig verkompliziert, da man zusätzliche Wege benötigt.

malenki · 2013-06-02 08:13:59

Ich werde derweil das MP zersägen.

Edit: Ich habe das MP in vier Teile zerlegt und werde jetzt am nördlichsten weiterarbeiten.

Last edited by malenki (2013-06-02 08:32:28)

chris66 · 2013-06-02 08:32:39

morjak wrote:

SunCobalt wrote:
und ein künstlicher Abstand, der in der Realität nicht vorhanden ist, macht es besser?
Nein. Man kann Wiese und See als zwei Multipolygone eintragen, die eine gemeinsame outer Kante haben. Die übrigen Kanten bilden den inner ring des Waldes.

oder man laesst die inneren flaechen und zieht eine neue linie drumherum die man dann als inner ins MP uebernimmt.

streckenkundler · 2013-06-02 08:51:48

morjak wrote:

streckenkundler schrieb:
The boundary of a Polygon consists of a set of LinearRings that make up its exterior and interior boundaries;
Wenn ich das richtig verstehe, machen Multipolygone genau das Beschriebene. Sie bestehen aus mehren Ringen, die innere und äußere Grenzen bilden.

Das ist das Kennzeichen eines echten Polygons!!

A Polygon is a planar Surface defined by 1 exterior boundary and 0 or more interior boundaries. Each interior
boundary defines a hole in the Polygon.

Das ist das, was wir mit einem See in einem Wald bezwecken wollen, wenn wir dafür eine Multipolygon-Relation anlegen.

Aber der Wichtige Satz für das Multipolygon ist:

The interiors of 2 Polygons that are elements of a MultiPolygon may not intersect.

Das heißt, die Innerfläche ist per Definition nicht ausgestanzt. Daraus ergibt sich im übrigen daß Tags an die outer- und inner-Elemente gehören, und nicht an die Relation.

morjak wrote:

Ansonsten müsste man wirklich im oben genannten Beispiel die Fläche von Wiese und See insgesamt erstmal mit einen eigenen geschlossenen Weg aus dem Wald herausstanzen

Bei echten Polygonen ist das per Definition erlaubt und wäre bei See im Wald die geometrisch saubere Lösung.

morjak wrote:

und die neu entstandene Fläche bzw. das Loch dann mit Wiese und Wald als eigenständige Polygone füllen, was die Sache unnötig verkompliziert, da man zusätzliche Wege benötigt.

Nicht unbedingt, wenn alle Elemente saubere Polygon-Flächen mit korrektem Tagging sind, da Polygon ein eigener, von closed LineString unterschiedlicher Datentyp ist.

Bei echten Polygonen funktioniert es aber nicht mehr, die Inner und/ oder Outergrenzen aus Linien zusammenzusetzen, ist eigentlich auch schon bei Multipolygon nicht zugelassen, da Multipolygon eine geometryCollection von Polygonen ist.
Bei OSM haben wir aber nur Punkte und Linien. Letztere entweder als einfache Linien (LineString) oder geschlossene Linien (LinearRing). Diese geschlossenen Linien (LinearRings) werden als Flächen interpretiert, können aber immer nur als einfache Polygone (ohne ausgestanzte Inner-Flächen) interpretiert werden, das er bisher verwendete Datentyp solche komplexen Elemente nicht vorsieht. Die so interpretierten einfachen Polygone sind entweder für sich allein stehende Elemente, oder eben Elemente einer Multipolygon-Relation.

Vergleiche zu diesem Thema auch die Datentypen-Definitionen unter: http://portal.opengeospatial.org/files/ … t_id=25355

Sven

Weide · 2013-06-02 09:08:24

Hi,

streckenkundler wrote:

Das heißt, wenn ich als outer ein Wald habe und als inner ein See, gilt per Definition die Outerfläche auch für die Inner... was eigentlich nicht beabsichtigt ist.
Als echtes Multipolygon würde mir ein Naturschutzgebiet einfallen, deren inner-Fläche ein Totalreservat des Naturschutzgebietes ist.

Mit den OSM-Multipolygonflächen bekommst Du alle Möglichkeiten. Stell Dir einen Kreis vor und drinnen -- nicht berührend -- ein Quadrat; ferner haben wir eine Multipolygonrelation mit dem Kreis als "outer" und dem Quadrat als "inner".

Wenn das MP jetzt nicht nur "type=multipolygon" enthält, dann können alle drei interessanten Flächen mit Tags versehen werden:

1. Die Tags am Kreis beziehen sich entweder auf die gesamte Kreisfläche oder die Kreislinie -- je nach verwendeten Tags.

2. Die Tags am Quadrat beziehen sich entweder auf die gesamte Quadratfläche oder die Quadratlinie -- je nach verwendeten Tags.

3. Die Tags in der Relation beziehen sich auf die Fläche zwischen Kreis und Quadrat.

1. und 2. ergeben sich dabei nicht aus irgendwelchen Regeln über Multipolygone, sondern sind einfach klassische Flächen, wie sie schon vor Existenz der Multipolygone in OSM benutzt wurden. Diese Regeln gelten voll und ganz weiter. (Außer wenn das MP gar keine Tags außer type=multipolygon enthält. In diesem Fall -- den es m.E. niemals hätte geben dürfen, aber jetzt ist es zu spät -- gelten die Tags der geschlossenen outer-Linie nicht für die davon umschlossene Fläche, sondern ausnahmsweise für die Multipolygonfläche.)

MfG
Weide

Weide · 2013-06-02 09:16:25

Hi,

SunCobalt wrote:

und ein künstlicher Abstand, der in der Realität nicht vorhanden ist, macht es besser?

Da bin ich Deiner Meinung. Es ist ja sogar noch schlimmer. Da ist nicht nur ein Abstand, das ist etwas! Es gibt ja gute Gründe dafür, Abstand zwischen der Straße und einem Acker lassen -- ich sehe es anders, aber ok. Wenn man das aber in einem Wald-MP macht, dann hat man dort einen 50cm breiten und 500m langen Wald angegeben und das ist ganz einfach falsch. Es gibt nunmaol keine 50cm breiten Wälder und meistens steht da nicht einmal ein Baum.

MfG
Weide

SimonPoole · 2013-06-02 09:19:08

streckenkundler wrote:

Vergleiche zu diesem Thema auch die Datentypen-Definitionen unter: http://portal.opengeospatial.org/files/ … t_id=25355
...

Da es noch niemand gesagt hat, mach ichs halt. Die OSM Geometrien sind keine OGC Simple Features (speziell die Multipolgone nicht) deshalb ist es auch nicht sinnvoll auf die Definitionen dort zu verweisen.

Simon

morjak · 2013-06-02 09:38:03

streckenkundler wrote:

Aber der Wichtige Satz für das Multipolygon ist:
The interiors of 2 Polygons that are elements of a MultiPolygon may not intersect.
Das heißt, die Innerfläche ist per Definition nicht ausgestanzt. Daraus ergibt sich im übrigen daß Tags an die outer- und inner-Elemente gehören, und nicht an die Relation.
Sven

Ich habe das Dokument nur mal kurz überflogen. Die inneren Ringe scheinen ausgestanzt zu sein. Nur ist es komplizierter gelöst, weil sich inner und outer über den Drehsinn der Polygone definieren.

Die Multipolygone in OSM sind da das wesentlich einfachere Datenmodell, auch, weil man durch die Möglichkeit der Zusammensetzung der Ringe aus mehreren Kanten nicht so viel Overhead produziert.

streckenkundler · 2013-06-02 09:43:56

Hallo,

Weide wrote:

(Außer wenn das MP gar keine Tags außer type=multipolygon enthält. In diesem Fall -- den es m.E. niemals hätte geben dürfen, aber jetzt ist es zu spät -- gelten die Tags der geschlossenen outer-Linie nicht für die davon umschlossene Fläche, sondern ausnahmsweise für die Multipolygonfläche.)

Welchen Fall hätte es niemals geben dürfen? MP's, an deren Relation nur type=multipolygon ist?
Oder deren outer-Fläche stets leer ist und das Flächenbeschreibende Tag an der Relation hängt??

Fälle 1 und 2 sind Klar. Fall 3 widerspricht aber der Datendefinition eines Multipolygons... http://portal.opengeospatial.org/files/ … t_id=25355 Seite 31.

Sven

Announcement

#301 2013-06-01 17:07:26

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#302 2013-06-01 18:12:58

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#303 2013-06-01 18:48:22

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#304 2013-06-01 19:58:38

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#305 2013-06-01 20:32:35

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#306 2013-06-01 20:46:02

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#307 2013-06-01 20:57:07

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#308 2013-06-01 21:12:36

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#309 2013-06-01 21:12:46

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#310 2013-06-01 21:19:23

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#311 2013-06-01 21:22:26

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#312 2013-06-01 21:28:14

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#313 2013-06-01 21:28:36

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#314 2013-06-01 21:33:15

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#315 2013-06-01 21:38:28

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#316 2013-06-01 22:18:59

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#317 2013-06-02 07:46:01

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#318 2013-06-02 08:13:59

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#319 2013-06-02 08:32:39

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#320 2013-06-02 08:51:48

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#321 2013-06-02 09:08:24

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#322 2013-06-02 09:16:25

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#323 2013-06-02 09:19:08

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#324 2013-06-02 09:38:03

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#325 2013-06-02 09:43:56

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

Board footer