Multipolygonwahnsinn - oder: Durchblick war gestern!

streckenkundler · 2013-06-02 09:59:36

SimonPoole wrote:

Die OSM Geometrien sind keine OGC Simple Features (speziell die Multipolgone nicht) deshalb ist es auch nicht sinnvoll auf die Definitionen dort zu verweisen.

Wiki sagt: http://wiki.openstreetmap.org/wiki/Rela … ltipolygon

Generally, the multipolygon relation can be used to build multipolygons in compliance with the OGC Simple Feature standard (Graphical examples of OGC validity). Anything that is not a valid multipolygon according to this standard (e.g., polygons with intersecting rings) should also be considered an invalid multipolygon relation, with the notable exception of touching inner rings (see below).

Multipolygone werden also im Sinne des "OGC Simple Feature standard" gesehen. Touching inner Rings werden entgegen des OGC-Standards bei OSM nicht als Fehler angesehen... OK... kann man aber trotzdem vermeiden, da sie ein Widerspruch zum Standard darstellen wie auch die Tagging-Regel mit Tag an der Relation und nicht am Outer.

Sven

Last edited by streckenkundler (2013-06-02 10:19:44)

Weide · 2013-06-02 11:25:13

streckenkundler wrote:

...Widerspruch zum Standard...

Bitte berücksichtige, dass "can be used to build" etwas ganz anderes ist als "ist dasselbe wie".

Da steht nur, dass ungültige Objekte des einen Regelsatzes auch in der Formulierung für den anderen Regelsatz ungültig sind -- außgenommen bei touching inners. Die Regelsätze sind verschieden.

MfG
Weide

Weide · 2013-06-02 11:35:36

streckenkundler wrote:

Welchen Fall hätte es niemals geben dürfen? MP's, an deren Relation nur type=multipolygon ist?

Genau.

streckenkundler wrote:

Oder deren outer-Fläche stets leer ist und das Flächenbeschreibende Tag an der Relation hängt??

Ich habe nie von einem Fall gesprochen, in dem die vom outer des MP umschlossene Fläche keinen Tag haben darf.

streckenkundler wrote:

Fälle 1 und 2 sind Klar. Fall 3 ...

Nein, nein, das sind keine Fälle. Das sind die drei Flächen.

MfG
Weide

streckenkundler · 2013-06-02 13:05:10

Weide wrote:

streckenkundler schrieb:
Welchen Fall hätte es niemals geben dürfen? MP's, an deren Relation nur type=multipolygon ist?
Genau.

Hm...

Weide wrote:

streckenkundler schrieb:
Fälle 1 und 2 sind Klar. Fall 3 ...
Nein, nein, das sind keine Fälle. Das sind die drei Flächen.

Fälle war nicht dar richtige Wort, ich wußte aber wie es gemeint war.

Das war ich von der Disskussion mitnehme: Viele Probleme hätten wir nicht, wenn wir echte Polygone hätten, denn ich behaupte mal, daß das, was wir mit der Anlage eines Multipolygons bezwecken wollen (eben jenes See im Wald-Problem) ist zu 90-95% der Fälle mit dieser Polygon-Definition lösbar. Eine Anwendung des OGC-Standards als Basis wäre dann meiner Ansicht nach die logische Folge. Ohne dem wird es ein herumwurschteln bleiben...

Das wäre mein Wunsch für API 0.7 Implementierung der OGC-Geometrie-Klassen und deren Anwendung.

Sven

rayquaza · 2013-06-02 16:19:50

Da einige der Antworten hier nach Missverständnissen wirken versuche ich mal, die Möglichkeiten eine "Fläche mit Loch" zu erfassen zusammenzufassen:

Die Beispielsituation ist ein Weinberg mit angrenzendem Waldstück (oder was auch immer das ist) innerhalb von Feldern. (Bild)

Ohne Relation: (Bild) Hierbei wird auch für die Äcker nur eine Linie benötigt. Es wird von der äusseren Linie ein Wegstück zur Inneren gezogen und am Ende der inneren Begrenzung wieder zurück, wodurch sich eine geschlossene Fläche ergibt. Diese Variante wird vermutlich von allen als falsch angsehen.
Veraltet: (Bild) Der äussere Rand der Äcker wird so erfasst als wäre die gesamte Fläche Acker. Hinzu kommt eine Relation mit type=multipolygon als einzigem Tag, die den äusseren Way als "outer" und die Inneren als "inner" enthält. Nachteile hierbei sind u.a., dass der äussere Way keine Tags haben kann, die für die gesamte Fläche gelten und dass Anwendungen die Fläche Tags für die gesamte Fläche nutzen, wenn die Relation auf irgendeine Art "verloren" geht, weshalb diese Erfassungsart als veraltet gilt.
"Normal": (Bild) Die Tags, die bei der Variante "Veraltet" an dem äusseren Way waren sind nun in der Relation. Hierdurch können an dem Way Tags sein, die für den Way bzw. die (gesamte) Fläche gelten und es kann mehrere äussere Ways geben.

Bei den beiden Varianten mit Relationen gibt es verschiedene Möglichkeiten mit "Touching Inners" umzugehen:

Die touching Inners ignorieren (Bild) und so verfahren wie sonst auch. Hiermit erzeugt man allerdings genaugenommen einen 0 Meter breiten Streifen Acker zwischen Wald und Wingert. Ausserdem kann man damit nicht mehr die Länge der Grenze der Fläche ermitteln (z.B. Wenn die Bauern gemeinsam einen Zaun um die Äcker bauen wollen).
Eine zusätzliche Linie ziehen: (Bild) Hierbei zieht man die Linie um Wald und Wingert nochmal und nutzt diese wie sonst auch als "Inner". Nachteil ist, dass eine Linie mehr in der Datenbank ist (was aber tatsächlich nicht stören sollte, sonst sollten wir besser aufhören z.B. Gebäude einzuzeichnen) und übereinanderliegende Linien in ein paar Editoren schlecht bearbeitbar sind (diese kommen allerdings so schon recht oft vor (z.B. hier zwischen Wald und Wingert), weshalb das eindeutig ein Problem der betroffenen Editoren ist).
Multipolygonitis: (Bild 1, Bild 2) Hierbei wandelt man auch die inneren Flächen in Multipolygone um, wodurch auch die überlappende Linie zwischen Wald und Weinberg entfällt. Nachteile sind, dass eine zusätzliche Linie und mehrere zusätzlich Relationen notwendig sind (was nicht wirklich stören sollte, siehe "zusätzliche Linie"), diese Konstrukte deutlich fehleranfälliger sind und die Verständlichkeit für unerfahreneren Benutzer sehr schnell verloren geht. Bei strikter Anwendung müsste man einen sehr grossen Teil der Polygone umwandeln, was dann auch für erfahrene Benutzer schnell unübersichtlich wird.

Alternativ kann man noch überlegen, ob sich das äussere Gebiet einigermassen sinnvoll so aufteilen lässt, dass die Grenze an der man aufteilt die innere(n) Fläche(n) enthält. Hierdurch bildet in einfachen Fällen die äussere Fläche ein doppeltes C. (Bild). In etwas komplexeren Fällen kann das natürlich auch anders aussehen (Bild). Nachteil dabei ist, dass es in vielen Fällen keine sinnvolle Aufteilmöglichkeit gibt und hierbei relativ viele überlappenden Linien entstehen, die nicht mit allen Editoren gut bearbeitet können (wobei dies wie schon unter "zusätzliche Linie" erläutert eher bei den Editoren behoben werden sollte (siehe auch ''[[Tagging für den Renderer]]'')).

/edit: Dateiendungen ergänzt...
/edit2: Doppeltes C ergänzt, typo in "ignorieren", Ergänzungsangebot beendet

Last edited by rayquaza (2013-06-02 21:28:19)

streckenkundler · 2013-06-02 16:29:13

Hei,

Bei den Bildlinks im Beitrag fehlen bis auf https://wiki.openstreetmap.org/wiki/Fil … lation.png die Dateiendungen...

stellt Sven fest

reneman · 2013-06-02 16:54:25

@rayquaza: siehe bitte PN auf osm.org. Danke

morjak · 2013-06-02 17:13:56

rayquaza wrote:

Eine zusätzliche Linie ziehen: (Bild) Hierbei zieht man die Linie um Wald und Wingert nochmal und nutzt diese wie sonst auch als "Inner". Nachteil ist, dass eine Linie mehr in der Datenbank ist (was aber tatsächlich nicht stören sollte, sonst sollten wir besser aufhören z.B. Gebäude einzuzeichnen) und übereinanderliegende Linien in ein paar Editoren schlecht bearbeitbar sind (diese kommen allerdings so schon recht oft vor (z.B. hier zwischen Wald und Wingert), weshalb das eindeutig ein Problem der betroffenen Editoren ist).
Multipolygonitis: (Bild 1, Bild 2) Hierbei wandelt man auch die inneren Flächen in Multipolygone um, wodurch auch die überlappende Linie zwischen Wald und Weinberg entfällt. Nachteile sind, dass eine zusätzliche Linie und mehrere zusätzlich Relationen notwendig sind (was nicht wirklich stören sollte, siehe "zusätzliche Linie"), diese Konstrukte deutlich fehleranfälliger sind und die Verständlichkeit für unerfahreneren Benutzer sehr schnell verloren geht. Bei strikter Anwendung müsste man einen sehr grossen Teil der Polygone umwandeln, was dann auch für erfahrene Benutzer schnell unübersichtlich wird.

Die Fehleranfälligkeit ist erfahrungsgemäß bei der oberen Variante größer, weil man die zusätzliche Linie nicht sieht bzw. nicht sofort zuordnen kann. Die meisten Fehler, die ich ausbessere entstehen durch überlappende Wege. Mir sind in meiner Gegend schon genug Fälle untergekommen, wo scheinbar der Ersteller selbst den Überblick über seine Wegestapel verloren hat.

Bei der letztgenannten Variante ist sofort ersichtlich, wohin die Kanten gehören.

rayquaza · 2013-06-02 18:01:37

@streckenkundler: Flüchtigkeitsfehler, danke für den Hinweis, ist erledigt.

@morjak: Ich bin davon ausgegangen, wo ich Fehler gemacht und/oder entdeckt habe. Bei der Multipolygonitis-Variante ist da die Fehleranzahl bei weniger betrachteten Objekten höher als bei "zusätzliche Linie".

streckenkundler · 2013-06-02 18:24:03

Hallo,

rayquaza wrote:

Eine zusätzliche Linie ziehen: (Bild) Hierbei zieht man die Linie um Wald und Wingert nochmal und nutzt diese wie sonst auch als "Inner". Nachteil ist, dass eine Linie mehr in der Datenbank ist (was aber tatsächlich nicht stören sollte, sonst sollten wir besser aufhören z.B. Gebäude einzuzeichnen) und übereinanderliegende Linien in ein paar Editoren schlecht bearbeitbar sind (diese kommen allerdings so schon recht oft vor (z.B. hier zwischen Wald und Wingert), weshalb das eindeutig ein Problem der betroffenen Editoren ist).
Multipolygonitis: (Bild 1, Bild 2) Hierbei wandelt man auch die inneren Flächen in Multipolygone um, wodurch auch die überlappende Linie zwischen Wald und Weinberg entfällt. Nachteile sind, dass eine zusätzliche Linie und mehrere zusätzlich Relationen notwendig sind (was nicht wirklich stören sollte, siehe "zusätzliche Linie"), diese Konstrukte deutlich fehleranfälliger sind und die Verständlichkeit für unerfahreneren Benutzer sehr schnell verloren geht. Bei strikter Anwendung müsste man einen sehr grossen Teil der Polygone umwandeln, was dann auch für erfahrene Benutzer schnell unübersichtlich wird.

gibt es eigentlich eine Möglichkeit zu bestimmen, wie groß das Verhältnis der Anzahl der Relationen zwischen Multipolygonen aus geschlossenen Linienzügen und Multipolygon-Relationen aus zusammengesetzten Linien ist, also diese beiden gelisteten Varianten ist? Eine Verteilung wäre auch interessant.

fragt Sven

rayquaza · 2013-06-02 18:28:22

Eine wirklich zuverlässige nicht, z.B. da es auch gemischte geben kann und MP-Inners, die selbst aus anderem Grund MPs sind nicht mitzählen dürften.

seichter · 2013-06-02 18:39:54

morjak wrote:

rayquaza wrote:
Eine zusätzliche Linie ziehen: (Bild) Hierbei zieht man die Linie um Wald und Wingert nochmal und nutzt diese wie sonst auch als "Inner". Nachteil ist, dass eine Linie mehr in der Datenbank ist (was aber tatsächlich nicht stören sollte, sonst sollten wir besser aufhören z.B. Gebäude einzuzeichnen) und übereinanderliegende Linien in ein paar Editoren schlecht bearbeitbar sind (diese kommen allerdings so schon recht oft vor (z.B. hier zwischen Wald und Wingert), weshalb das eindeutig ein Problem der betroffenen Editoren ist).
Multipolygonitis: (Bild 1, Bild 2) Hierbei wandelt man auch die inneren Flächen in Multipolygone um, wodurch auch die überlappende Linie zwischen Wald und Weinberg entfällt. Nachteile sind, dass eine zusätzliche Linie und mehrere zusätzlich Relationen notwendig sind (was nicht wirklich stören sollte, siehe "zusätzliche Linie"), diese Konstrukte deutlich fehleranfälliger sind und die Verständlichkeit für unerfahreneren Benutzer sehr schnell verloren geht. Bei strikter Anwendung müsste man einen sehr grossen Teil der Polygone umwandeln, was dann auch für erfahrene Benutzer schnell unübersichtlich wird.
Die Fehleranfälligkeit ist erfahrungsgemäß bei der oberen Variante größer, weil man die zusätzliche Linie nicht sieht bzw. nicht sofort zuordnen kann. Die meisten Fehler, die ich ausbessere entstehen durch überlappende Wege. Mir sind in meiner Gegend schon genug Fälle untergekommen, wo scheinbar der Ersteller selbst den Überblick über seine Wegestapel verloren hat.
Bei der letztgenannten Variante ist sofort ersichtlich, wohin die Kanten gehören.

+1: Die letzte Variante ist die aufwendigste, aber auch die sauberste. Bei Verwaltungsgrenzen hat man da gar keine andere Wahl: Da gibt es Enklaven/Exklaven mitten in einem Gebiet, die möglicherweise auch noch zu mehr als einer anderen Gemeinden gehöre. Zur allgemeinen Freude das Ganze dann auch noch in Kreisen, Ländern und Staaten (siehe Grenze zur Schweiz bei Schaffhausen). Man tut sich aber da leichter, weil boundary im Gegensatz zu landuse kein area-key ist und man daher kein geschlossenen Linienzüge machen muss. Wenn man das bei landuse z.B. per boundary=landuse aufgeben würde, hätte man im aufgeführten Beispiel vier Segmente: Eines (geschlossen) außen herum, zwei "Halbkreise" und ein Segment dazwischen. Die Topologie und die Eigenschaften, was wo ist, steckt dann ausschließlich in den Relationen und nicht in den ways.
Ob das realistisch ist, kann ich nicht beurteilen - die Renderer müssten nicht nur die simplen area-Objekte, sondern ggf. auch die Relationen auswerten, um ein Gebiet zuordnen zu können. Bei boundary=* funktioniert es, ich behaupte aber nicht, dass das trivial ist.

Abgesehen davon neige ich zur KISS-Philosophie: MPs nur, wo es sein muss, also Gebäude mit Innenhof, Waldstück mit ein paar Lichtungen, aber trennen, wo immer möglich und intuitiv einsichtig (Straßen, Wege oder notfalls Bezirksgrenzen), damit beherrschbare Einheiten entstehen.

MasiMaster · 2013-06-02 21:02:24

rayquaza wrote:

[...]
Falls jemand eine Variante vermisst[...]

Ja, man kann aus dem Acker 2 'C'-förmige Flächen machen, die die beiden inneren umschließen. So spart man sich das MP ganz.

Sehr seltene Ausnahme wäre dann nur, wenn das "Außenrum" einen Namen hat, oder wie bei einem Haus mit Innenhof zusammengehört (oder See mit halb Wald/Wiesen-insel).

rayquaza · 2013-06-02 21:38:42

Ach deshalb brauche ich so wenige Multipolygone (zwei Stück sind 's inzwischen) oO
Danke für die Ergänzung, ich habe es als Alternative hinzugefügt.

Ich habe das Ergänzungsangebot oben rausgenommen, da ich jetzt das ganze Zeug zum schöne Bilder machen geschlossen habe (Du warst gerade noch rechtzeitig, MasiMaster). Wenn noch jemandem was einfällt kann das natürlich trotzdem als Plaintext oder mit inkonsistenten Bildern dazu.

aighes · 2013-06-02 21:43:45

Ich halte die "C-Flächenvariante" für unsinnig. Auf den ersten Blick scheint es einfacher, jedoch spiegelt es nicht die Fläche wieder. Wenn man sich einen See mit einer Insel anschaut, hat der See eben keine Grenze, sondern ist komplett geschlossen.

rayquaza · 2013-06-02 21:53:12

Es gibt auch Polygone, bei denen sowas sinnvoll möglich ist, meist kleinere, bei denen das (zumindest da, wo ich bisher gemappt habe) auch fast immer so erfasst ist. Ein Beispiel fällt mir jetzt gerade nicht ein, aber sowas hatte ich schonmal. Meist ist sowas relativ offensichtlich und wird vermutlich von den meisten automatisch gemacht (z.B. ein Kirchplatz mit unterschiedlichem Untergrund auf einer Seite der Kirche). Man sollte imo auf jeden Fall nochmal nachdenken, ob es eine sinnvolle Alternative gibt, bevor man zum Multipolygon greift.

seichter · 2013-06-02 21:58:24

MasiMaster wrote:

rayquaza wrote:
[...]
Falls jemand eine Variante vermisst[...]
Ja, man kann aus dem Acker 2 'C'-förmige Flächen machen, die die beiden inneren umschließen. So spart man sich das MP ganz.
Sehr seltene Ausnahme wäre dann nur, wenn das "Außenrum" einen Namen hat, oder wie bei einem Haus mit Innenhof zusammengehört (oder See mit halb Wald/Wiesen-insel).

Doppeltes C fände ich dann in Ordnung, wenn die Trennlinie einsichtig gezogen werden kann - ich nehme mal an, dass zum Weinberg und Wald ein, zwei Wege hochführen. Streng genommen ist der Weg sowieso keine Ackerfläche, denn der Bauer wird wohl kaum quer über den Weg pflügen. So betrachtet braucht man für farmland, meadow o.ä. nur selten zwingend MPs, nur bei größeren Wäldern und Wasserflächen können MPs sinnvoll sein.

Nebenbei: Gibt es eigentlich einen tieferen Grund, nebeneinander liegende, aber getrennte Ackerflächen (dto. Wiesen, Wäldchen) in MPs zusammenzufassen?

rayquaza · 2013-06-02 22:08:11

seichter wrote:

Doppeltes C fände ich dann in Ordnung, wenn die Trennlinie einsichtig gezogen werden kann - ich nehme mal an, dass zum Weinberg und Wald ein, zwei Wege hochführen. Streng genommen ist der Weg sowieso keine Ackerfläche, denn der Bauer wird wohl kaum quer über den Weg pflügen. So betrachtet braucht man für farmland, meadow o.ä. nur selten zwingend MPs, nur bei größeren Wäldern und Wasserflächen können MPs sinnvoll sein.

Ja, genau so sehe ich das auch.

seichter wrote:

Nebenbei: Gibt es eigentlich einen tieferen Grund, nebeneinander liegende, aber getrennte Ackerflächen (dto. Wiesen, Wäldchen) in MPs zusammenzufassen?

Man könnte argumentieren, dass wir mit landuse=residential auch nicht einzelne Wohnblöcke oder gar Grundstücke erfassen, sondern das ganze zusammenhängende Gebiet (innerhalb eine Ortes zumindest meistens). Ich mappe auch nur aufgrund des relativ hohen Aufwandes Ackerflächen in grösseren Stücken (also: kleinere Feldwege werden ignoriert, grössere Feldwege reichen aber oft für eine Trennung).

seichter · 2013-06-02 22:28:15

rayquaza wrote:

seichter wrote:
Nebenbei: Gibt es eigentlich einen tieferen Grund, nebeneinander liegende, aber getrennte Ackerflächen (dto. Wiesen, Wäldchen) in MPs zusammenzufassen?
Man könnte argumentieren, dass wir mit landuse=residential auch nicht einzelne Wohnblöcke oder gar Grundstücke erfassen, sondern das ganze zusammenhängende Gebiet (innerhalb eine Ortes zumindest meistens). Ich mappe auch nur aufgrund des relativ hohen Aufwandes Ackerflächen in grösseren Stücken (also: kleinere Feldwege werden ignoriert, grössere Feldwege reichen aber oft für eine Trennung).

Mappen ist immer ein Kompromiss zwischen Aufwand und Nutzen, von daher finde ich Ackerflächen über Wege hinweg vertretbar. Ich meine ja nicht, dass man teilen muss, sondern kann, um die Größe zu begrenzen.

Ich hatte aber etwas anderes gemeint: Flächen, die getrennt vorhanden und vielleicht Dutzende Meter voneinander entfernt sind, aber in eine Relation zusammengefasst wurden.

wambacher · 2013-06-02 23:18:28

seichter wrote:

Ich hatte aber etwas anderes gemeint: Flächen, die getrennt vorhanden und vielleicht Dutzende Meter voneinander entfernt sind, aber in eine Relation zusammengefasst wurden.

nee, ich sehe keinen Grund dafür, die z.B. als mehrere outer in einer Relation "zusammenzufassen", nur weil sie alle den gleichen Landuse haben.

Es gibt da aber eine Grauzone, wenn alle so zusammengefassten Flächen eine weiter gemeinsame Eigenschaft wie den Namen haben. Sowas kommt schon mal bei Wäldern von - ist aber wirklich hart an der Grenze.

Gruss
walter

Last edited by wambacher (2013-06-02 23:19:28)

MasiMaster · 2013-06-03 00:36:34

aighes wrote:

Ich halte die "C-Flächenvariante" für unsinnig. Auf den ersten Blick scheint es einfacher, jedoch spiegelt es nicht die Fläche wieder. Wenn man sich einen See mit einer Insel anschaut, hat der See eben keine Grenze, sondern ist komplett geschlossen.

Zu See (und auch Gebäuden) hatte ich oben geschrieben, dass diese "ein" Objekt sind, da macht es natürlich keinen Sinn zwei Objekte raus zu machen. (Die 2 C's könnte man zwar dann tag-los in einer collection oder MP zusammenfassen, aber gewonnen hat man dadurch rein gar nichts.)

Allerdings bietet es sich bei landuse schon an. Landnutzungsart ist ja an kein Objekt gebunden.

PS: Da fällt mir ein, bei riverbank wird auch zerstückelt, obwohl keine Grenze da ist. Ich finde so ist es weitaus besser zu Handhaben (für Editor und Auswerter gleichermaßen), als alle nichtgeschlossenen outer in eine fette Relation zu packen.

Weide · 2013-06-03 06:32:29

MasiMaster wrote:

PS: Da fällt mir ein, bei riverbank wird auch zerstückelt, obwohl keine Grenze da ist. Ich finde so ist es weitaus besser zu Handhaben (für Editor und Auswerter gleichermaßen), als alle nichtgeschlossenen outer in eine fette Relation zu packen.

Man könnte sie auch garnicht so einfach in eine Relation packen, selbst wenn man es für sinnvoll halten würde.
Das Berührungsverbot der Linien einer Relation ist in OSM für inner-an-inner eingeschränkt -- nicht für outer-an-outer (oder inner-an-outer oder Linie-mit-sich-selbst).

Weide

Weide · 2013-06-03 06:48:38

aighes wrote:

Ich halte die "C-Flächenvariante" für unsinnig. Auf den ersten Blick scheint es einfacher, jedoch spiegelt es nicht die Fläche wieder. Wenn man sich einen See mit einer Insel anschaut, hat der See eben keine Grenze, sondern ist komplett geschlossen.

Im Prinzip stimme ich Dir zu. Aber mir sind in letzter Zeit einige MPs über den Weg gelaufen, die mich in dieser Hinsicht nachdenklich gemacht haben. Wir haben in Südschweden im Prinzip erstmal Wald; darin liegen -- sehr oft in berührenden Grüppchen verschiedener landuse-typen andere Sachen. Die Wald-Multipolygone haben fast ausschließlich willkürliche Grenzen, die mitten im Wald liegen. Schon bei der jetzigen Größe sind sie -- auch mit MP-Erfahrung -- kaum noch zu überblicken; insbesondere dann, wenn die Inner-Grüppchen auch noch Ringe bilden. Hier sieht es im Moment -- ich bin mir noch nicht sicher -- danach aus, als ob das Mapping des Waldes tatsächlich am Besten mit eigenen Linien entlang der Außenseite dieser Grüppchen und geraden Stücken zwischen den Grüppchen erfolgen sollte. Und das ist im Grunde auch eine solche C-Technik.

Weide

chris66 · 2013-06-03 07:57:05

Ich habe die C-Technik auch schon genutzt. Z.B. für eine meadow welche ein farmyard umschliesst und durch den Zufahrtsweg
unterbrochen ist.

seichter · 2013-06-03 10:55:58

MasiMaster wrote:

aighes wrote:
Ich halte die "C-Flächenvariante" für unsinnig. Auf den ersten Blick scheint es einfacher, jedoch spiegelt es nicht die Fläche wieder. Wenn man sich einen See mit einer Insel anschaut, hat der See eben keine Grenze, sondern ist komplett geschlossen.
Zu See (und auch Gebäuden) hatte ich oben geschrieben, dass diese "ein" Objekt sind, da macht es natürlich keinen Sinn zwei Objekte raus zu machen. (Die 2 C's könnte man zwar dann tag-los in einer collection oder MP zusammenfassen, aber gewonnen hat man dadurch rein gar nichts.)
Allerdings bietet es sich bei landuse schon an. Landnutzungsart ist ja an kein Objekt gebunden.
PS: Da fällt mir ein, bei riverbank wird auch zerstückelt, obwohl keine Grenze da ist. Ich finde so ist es weitaus besser zu Handhaben (für Editor und Auswerter gleichermaßen), als alle nichtgeschlossenen outer in eine fette Relation zu packen.

Dazu gibt es aktuell einen neueren thread: http://forum.openstreetmap.org/viewtopic.php?id=21389
Dort wie auch hier mit C-Technik mein Anliegen, die Trennlinien möglichst nur an nachvollziehbaren Stellen wie Stauwehr oder Zufahrtsweg zu machen.

Das Grundübel ist meiner Ansicht nach, dass man den ursprünglichen Ansatz mit landuse-Objekten als geschlossene area-ways unbesehen in die landuse(-etc)-Relationen übernommen hat. Bei Gebäude mit Innenhof und See mit Insel macht das keine Probleme und ist wohl auch akzeptiert, bei komplizierteren Topologien (Schweden, Finnland) kommt man aber schnell an die Grenze der Handhabbarkeit. Die C-Technik und das Aneinanderstückeln von Wasserflächen zu einem Flusslauf sind da eigentlich nur Krücken, um das Ganze noch beherrschbar zu halten.

Bei Verwaltungsgrenzen werden nicht geschlossene ways als Elemente zugelassen, nur die Relationen müssen geschlossen sein, anders wären Grenzrelationen bis zur EU hoch gar nicht machbar. Bei landuse u.ä. ist dieser Zug möglicherweise aber schon längst abgefahren.

Announcement

#326 2013-06-02 09:59:36

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#327 2013-06-02 11:25:13

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#328 2013-06-02 11:35:36

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#329 2013-06-02 13:05:10

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#330 2013-06-02 16:19:50

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#331 2013-06-02 16:29:13

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#332 2013-06-02 16:54:25

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#333 2013-06-02 17:13:56

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#334 2013-06-02 18:01:37

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#335 2013-06-02 18:24:03

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#336 2013-06-02 18:28:22

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#337 2013-06-02 18:39:54

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#338 2013-06-02 21:02:24

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#339 2013-06-02 21:38:42

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#340 2013-06-02 21:43:45

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#341 2013-06-02 21:53:12

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#342 2013-06-02 21:58:24

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#343 2013-06-02 22:08:11

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#344 2013-06-02 22:28:15

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#345 2013-06-02 23:18:28

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#346 2013-06-03 00:36:34

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#347 2013-06-03 06:32:29

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#348 2013-06-03 06:48:38

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#349 2013-06-03 07:57:05

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

#350 2013-06-03 10:55:58

Re: Multipolygonwahnsinn - oder: Durchblick war gestern!

Board footer