Verschachtelte MP-Relationen

Wolfgang_B · 2011-11-03T13:39:09.000Z

Auch wenn ich mich mit meiner Wortmeldung möglicherweise unbeliebt mache:
Das Relationenwirrwarr in Kufstein ist der helle Wahnsinn. Wozu tut sich Erwin so etwas an? Das ist doch alles unnötig. Eine Fläche landuse=residential für das Wohngebiet. Dann die Gebäude, Parkplätze, den Friedhof einfach drüberzeichnen. Dazu braucht man keine einzige Relation. Die Hauptrenderer Mapnik und Osmarender stellen es richtig dar, was will man mehr. Schade um den Aufwand.

wambacher · 2011-11-03T13:39:39.000Z

Weide:

Nehmen wir eine Wasserfläche:

Wir machen eine Liste aller Ränder dieser Wasserfläche, d.h. aller Linien, bei denen auf der einen Seite diese Wasserfläche ist und auf der anderen Seite etwas anderes – andere Linien gehören da nicht rein. Wenn die Liste mehr als eine Linie hat, dann brauchen wir ein Multipolygon (type=multipolygon und natural=water) in dem genau diese Liste von Linien drin ist. Dann kommen noch “inner” und “outer” an die Linien und fertig.

1+

Das generelle Problem bei dem Umgang mit Multipolygonen liegt darin, dass man “outer” und “inner” mit Sachen verbindet, die überhaupt nicht relevant sind.
Weder “outer” noch “inner” sagen etwas darüber aus, was sich ausserhalb oder innerhalb der jeweiligen Line befindet.
“Outer” und “inner” sind einfach nur die Ränder der Fläche, die durch das MP beschrieben werden soll - mehr nicht.
Wenn man diese Tatsache endlich verstanden und akzeptiert hat (zwei Schritte!!!), wird es auf einmal ganz einfach.

z.b. “Touching inner rings”:

nehme EINE Fläche und stanze EIN Loch rein → 1 outer / 1 inner OK
stanze ein weiteres Loch rein → 1 outer / 2 inner OK
stanze ein weiteres Loch rein,
das eines der bestehenden Löcher berührt:

was ist richtig? → (1a) 1 outer / 3 inner
oder → (1b) 1 outer / 2 inner

Oder “Loch am Rand”

nehme EINE Fläche ohne Loch → 1 outer OK
mache ein “Loch am Rand”

was ist richtig? → (2a) 1 outer / 1 inner
→ (2b) zwei MP mit jeweils 1 outer
→ (2c) zwei outer mit einem inner
→ (2d) euch fällt eventuell noch was ein

Könnten ja ne Poll machen, wenn das Forum sowas hätte.

Gruss
Walter

p.s. wenn es immer noch nicht klar ist, werd ich wohl Gimp bemühen müssen

hurdygurdyman · 2011-11-03T14:10:50.000Z

wambacher:

…
Das generelle Problem bei dem Umgang mit Multipolygonen liegt darin, dass man “outer” und “inner” mit Sachen verbindet, die überhaupt nicht relevant sind.
Weder “outer” noch “inner” sagen etwas darüber aus, was sich ausserhalb oder innerhalb der jeweiligen Line befindet.
“Outer” und “inner” sind einfach nur die Ränder der Fläche, die durch das MP beschrieben werden soll - mehr nicht.
Wenn man diese Tatsache endlich verstanden und akzeptiert hat (zwei Schritte!!!), wird es auf einmal ganz einfach.
…
p.s. wenn es immer noch nicht klar ist, werd ich wohl Gimp bemühen müssen

Kompliment für die Erklärung.
Aber Gimp brauchst du nicht bemühen. es reicht das ganz normale Büroequipment:

Blatt Papier
Locher
Filzstift
Kamerahandy
Anspruchsvoll ist nur das Hochladen des/der Fotos

viw · 2011-11-03T14:21:50.000Z

wambacher:

Weide:

Nehmen wir eine Wasserfläche:

Wir machen eine Liste aller Ränder dieser Wasserfläche, d.h. aller Linien, bei denen auf der einen Seite diese Wasserfläche ist und auf der anderen Seite etwas anderes – andere Linien gehören da nicht rein. Wenn die Liste mehr als eine Linie hat, dann brauchen wir ein Multipolygon (type=multipolygon und natural=water) in dem genau diese Liste von Linien drin ist. Dann kommen noch “inner” und “outer” an die Linien und fertig.

1+

Mhhh ich weiß nicht ob wir uns falsch verstehen. Aber wir haben eine Insel in der Mitte eines Sees. Diese Insel besteht aus mehreren Wegen.
Also haben wir für den See ein MP mit min einem outer und den Wegen welche die Insel repräsentieren als inner. Jetzt ist die Insel mit Wald bewachsen und deshalb wird dort ein MP (mehrere Wege für eine Fläche) angelegt wo die Grenzwege der Insel dann wieder als outer drin sind. Genau darum ging es Erwin in seinem Beispiel. Jedenfalls wenn ich ihn richtig verstanden habe.
Es ist unstrittig, dass der gleiche Weg nicht zwei Rollen im selben MP haben kann!

wambacher:

z.b. “Touching inner rings”:

nehme EINE Fläche und stanze EIN Loch rein → 1 outer / 1 inner OK

stanze ein weiteres Loch rein → 1 outer / 2 inner OK

stanze ein weiteres Loch rein,
das eines der bestehenden Löcher berührt:

was ist richtig? → (1a) 1 outer / 3 inner
oder → (1b) 1 outer / 2 inner

Oder “Loch am Rand”

nehme EINE Fläche ohne Loch → 1 outer OK

mache ein “Loch am Rand”

was ist richtig? → (2a) 1 outer / 1 inner
→ (2b) zwei MP mit jeweils 1 outer
→ (2c) zwei outer mit einem inner
→ (2d) euch fällt eventuell noch was ein

Könnten ja ne Poll machen, wenn das Forum sowas hätte.

Gruss
Walter

p.s. wenn es immer noch nicht klar ist, werd ich wohl Gimp bemühen müssen

ich plädiere für (1b) Kann aber auch zu weiteren MPs führen, da die Löcher welche sich berühren ja ebenfalls eine gemeinsame Grenze haben, welche aber nicht mehr inner des ursprünglichen MPs sind und damit auch getrennt werden muss.
Das loch am outer ist schon schwieriger. Denn für ein outer wird kein MP angelegt.
Nach Auffassung der GISwelt würde hier zweimal outer die richtige Verwendung sein, da die Fläche ja eine Außenlinie hat und keine vollständig
eingeschlossene "Innen-"Fläche. Wie allerdings die Sache von den Programmen interpretiert würde wäre schon spannend. Insbesondere wenn diese beiden Flächen sich nur an einem Punkt berühren.

hurdygurdyman · 2011-11-03T14:31:35.000Z

viw:

…
ich plädiere für (1b) Kann aber auch zu weiteren MPs führen, da die Löcher welche sich berühren ja ebenfalls eine gemeinsame Grenze haben, welche aber nicht mehr inner des ursprünglichen MPs sind und damit auch getrennt werden muss.

Nö, denn das Loch ist ja noch keine Fläche. Zwei sich berührende Löcher sind ein Loch

viw:

Das loch am outer ist schon schwieriger. Denn für ein outer wird kein MP angelegt.
Nach Auffassung der GISwelt würde hier zweimal outer die richtige Verwendung sein, da die Fläche ja eine Außenlinie hat und keine vollständig
eingeschlossene "Innen-"Fläche. Wie allerdings die Sache von den Programmen interpretiert würde wäre schon spannend. Insbesondere wenn diese beiden Flächen sich nur an einem Punkt berühren.

Nö, ein Loch am Rand verändert die Kontur der Fläche. Am Rand wird nur was “rausgerissen”
Es bleibt eine Fläche.
Immer dran denken; Loch ist noch keine Fläche.

Radeln · 2011-11-03T15:05:15.000Z

Wolfgang B:

Auch wenn ich mich mit meiner Wortmeldung möglicherweise unbeliebt mache:
Das Relationenwirrwarr in Kufstein ist der helle Wahnsinn. Wozu tut sich Erwin so etwas an? Das ist doch alles unnötig. Eine Fläche landuse=residential für das Wohngebiet. Dann die Gebäude, Parkplätze, den Friedhof einfach drüberzeichnen. Dazu braucht man keine einzige Relation. Die Hauptrenderer Mapnik und Osmarender stellen es richtig dar, was will man mehr. Schade um den Aufwand.

Friedhof (landuse=cemetery) gehört IMHO ausgestanzt.

Radeln · 2011-11-03T15:15:40.000Z

hurdygurdyman:

Radeln:

hurdygurdyman:

Das sehe ich hier aber nicht http://wiki.openstreetmap.org/wiki/DE:Tag:barrier%3Dwall
Deshalb wäre dann area=yes zwingend.

Was ist damit: http://wiki.openstreetmap.org/wiki/DE:Key:barrier
Da ist doch das Symbol für Fläche. Wenn ich das richtig sehe, stellt JOSM bei geschlossener Linie auch ohne das area=yes eine Fläche dar.

Für mich gilt im Zweifel nicht die Zusammenfassung, sondern die explizite Seite der Wiki. Und da ist die Fläche nicht dabei. Außerdem steht auch auf der englischen barrier-Wiki “linear barriers”. http://wiki.openstreetmap.org/wiki/Key:barrier

Einspruch, da steht: Note that there are two main types of barriers: Linear and Node. Ist also nicht auf die zwei begrenzt.

weiter unten steht auch das Flächensymbol
was ist mit der Darstellung in JOSM

hurdygurdyman:

Das Thema “Redundanzen in der Wiki” gehört hier aber nicht hin…

Wenn es Deiner Meinung nach offensichtlich nicht richtig ist, kann und muß die Redundance hier sehr wohl angesprochen werden.

Radeln · 2011-11-03T15:33:50.000Z

Und immer noch kein Lösungsansatz für das Problem.

mdk · 2011-11-03T15:38:58.000Z

viw:

Mhhh ich weiß nicht ob wir uns falsch verstehen. Aber wir haben eine Insel in der Mitte eines Sees. Diese Insel besteht aus mehreren Wegen.
Also haben wir für den See ein MP mit min einem outer und den Wegen welche die Insel repräsentieren als inner. Jetzt ist die Insel mit Wald bewachsen und deshalb wird dort ein MP (mehrere Wege für eine Fläche) angelegt wo die Grenzwege der Insel dann wieder als outer drin sind. Genau darum ging es Erwin in seinem Beispiel. Jedenfalls wenn ich ihn richtig verstanden habe.
Es ist unstrittig, dass der gleiche Weg nicht zwei Rollen im selben MP haben kann!

Warum sind einige Leute so masochistisch?

KISS.

Also:
See: Ein MP mit äusserem way als outer und EIN inneren way als “Loch im See” (was man auch als Insel bezeichnen könnte).
Insel: Das " Loch" im See kann nun ohne Hirnkrebs zu bekommen mit Wegen, Flächen, uns all den schönen Dingen zugepfastert werden, auch ohne Doktor in Multipoligonie. Und ja, einige der Wege und Flächen der Insel können tatsäch deckungsgleich mit Teilen des der inner ways des Sees sein - so what?

Wieso den (nachgewiesenermassen!) umständlichen Weg nehmen und die Insel aus x Teilen zusammenzufriemeln?

Kopf schüttel

mdk

erwin6330 · 2011-11-03T18:06:46.000Z

Wolfgang B:

Auch wenn ich mich mit meiner Wortmeldung möglicherweise unbeliebt mache:
Das Relationenwirrwarr in Kufstein ist der helle Wahnsinn. Wozu tut sich Erwin so etwas an? Das ist doch alles unnötig. Eine Fläche landuse=residential für das Wohngebiet. Dann die Gebäude, Parkplätze, den Friedhof einfach drüberzeichnen. Dazu braucht man keine einzige Relation. Die Hauptrenderer Mapnik und Osmarender stellen es richtig dar, was will man mehr. Schade um den Aufwand.

Nein, Du machst Dich nicht unbeliegt, ein Forum ist dazu da, um zu diskutieren. Und das machen wir.

Ganz so groß wie Du das Wirrwarr sieht, ist es nun nicht. Ich zeichne nur nicht drei oder vier Linien übereinander, sondern ich mache es mit MPs. Ist aufwendiger, das mag sein, aber von einem “Relationenwirrwarr” zu sprechen halte ich doch für übertrieben.

Das mit den inner und outer habe ich nach der Erklärung von den anderen Forumsteilnehmern immer besser geschnallt und werde auch versuchen es umzusetzen. Ich möchte aber keine aneinandergrenzenden Flächen übereinander malen.

Ich gebe jetzt ja zu, dass die Art nicht ganz richtig war, aber auf diese Weise habe ich bei OSMI bei den MPs keine “touching inner rings” mehr. Gut, das mit den MPs als inner werde ich in den nächsten Tagen auch beseitigen, man lernt nie aus und gegen konstruktive Kritik habe ich nichts

Aber Wirrwarr ist übertrieben.

hurdygurdyman · 2011-11-03T18:37:39.000Z

Radeln:

…
Einspruch, da steht: Note that there are two main types of barriers: Linear and Node. Ist also nicht auf die zwei begrenzt.

weiter unten steht auch das Flächensymbol

was ist mit der Darstellung in JOSM

hurdygurdyman:

Das Thema “Redundanzen in der Wiki” gehört hier aber nicht hin…

Wenn es Deiner Meinung nach offensichtlich nicht richtig ist, kann und muß die Redundance hier sehr wohl angesprochen werden.

Ich streite nicht um Kaisers Bart. Alle mir bekannten Renderer interpretieren barrier als closed ways nicht als Fläche ohne Zusatztag area=yes, wenn überhaupt.
Da wir mit barrier hier OT sind, schlage ich vor, dass du einen neuen thread dazu eröffnest, wenn du das diskutieren willst. Meine Meinung steht fest. Und Wiki-Redundanzen sind hier auch OT.

hurdygurdyman · 2011-11-03T18:45:29.000Z

mdk:

…
Warum sind einige Leute so masochistisch?

KISS.

Also:
See: Ein MP mit äusserem way als outer und EIN inneren way als “Loch im See” (was man auch als Insel bezeichnen könnte).
Insel: Das " Loch" im See kann nun ohne Hirnkrebs zu bekommen mit Wegen, Flächen, uns all den schönen Dingen zugepfastert werden, auch ohne Doktor in Multipoligonie. Und ja, einige der Wege und Flächen der Insel können tatsäch deckungsgleich mit Teilen des der inner ways des Sees sein - so what?

Wieso den (nachgewiesenermassen!) umständlichen Weg nehmen und die Insel aus x Teilen zusammenzufriemeln?

Kopf schüttel

mdk

Man muss sich im Klaren sein, dass “inner” lediglich eine innere Begrenzung in der Fläche bedeutet, und noch nichts über die Flächeneigenschaft innerhalb des “inner” aussagt. Da ist erst mal nichts.
Dass wir aus Bequemlichkeit dann diesen closed way nehmen und ihm noch eine Flächeneigenschaft zuordnen, steht in keinem Zusammenhang zu der Funktion diese ways als inner. Das ist genauso, wenn wir einer Fläche meadow auf den umschließenden way noch ein barrier=fence setzen. Der Zaun ist dann auch nicht Teil der Wiese.

Radeln · 2011-11-03T19:16:21.000Z

hurdygurdyman:

Radeln:

…
Einspruch, da steht: Note that there are two main types of barriers: Linear and Node. Ist also nicht auf die zwei begrenzt.

weiter unten steht auch das Flächensymbol

was ist mit der Darstellung in JOSM

hurdygurdyman:

Das Thema “Redundanzen in der Wiki” gehört hier aber nicht hin…

Wenn es Deiner Meinung nach offensichtlich nicht richtig ist, kann und muß die Redundance hier sehr wohl angesprochen werden.

Ich streite nicht um Kaisers Bart. Alle mir bekannten Renderer interpretieren barrier als closed ways nicht als Fläche ohne Zusatztag area=yes, wenn überhaupt.
Da wir mit barrier hier OT sind, schlage ich vor, dass du einen neuen thread dazu eröffnest, wenn du das diskutieren willst. Meine Meinung steht fest. Und Wiki-Redundanzen sind hier auch OT.

Neuer Thread, nicht notwendig. Wäre das Wicki genauer … wäre dies nicht hochgekocht. Mist, schon wieder OT.

erwin6330 · 2011-11-04T05:35:58.000Z

Ich bin so dumm, bitte helft mir!

Was bedeutet “OT” ?

ajoessen · 2011-11-04T06:21:15.000Z

erwin6330:

Ich bin so dumm, bitte helft mir!

Was bedeutet “OT” ?

Off-Topic = Am hier diskutierten Thema vorbei.

HTH (Hope that helps),
ajoessen

hurdygurdyman · 2011-11-04T07:07:16.000Z

Ich möchte noch mal kurz auf das Ausgangsthema zurückkommen:
Meiner Meinung nach sollte die Verwendung eines MP als inner vermieden oder sogar verhindert werden, denn spätestens, wenn dieses verwendete MP eigene inner hat oder bekommt, läuft jede Auswertungslogik ins Leere.

wambacher · 2011-11-04T08:00:10.000Z

hurdygurdyman:

Ich möchte noch mal kurz auf das Ausgangsthema zurückkommen:
Meiner Meinung nach sollte die Verwendung eines MP als inner vermieden oder sogar verhindert werden, denn spätestens, wenn dieses verwendete MP eigene inner hat oder bekommt, läuft jede Auswertungslogik ins Leere.

da müssen wir noch etwas mehr Klarheit reinbringen:

was meinst du mit “MP als inner”?

ein aus mehreren ways zusammengesetztes Polygon (inner Circle)?
die Verwendung des inner eines MP als outer eines anderen MP?
ohne die ways doppelt zu zeichnen
ein “echtes” MP - also eine selbständige MP-Relation- als Member? (Master/Child)

Die beiden ersten Punkte halte ich für sinnvoll und verwende sie demnach auch.
Punkt 3 erscheint mir zulässig aber zu komplex - sowohl für den Mapper als auch die vielen nicht darauf “vorbereiteten” Programme. (*)

Gruss
Walter

*) mit diesen Argumenten wurde ja auch “meine” 1111111 gekillt

EvanE · 2011-11-04T08:09:36.000Z

wambacher:

*) mit diesen Argumenten wurde ja auch “meine” 1111111 gekillt

Hallo Walter

Das ist sehr schade.
Aber spätestens beim Lizenzwechsel wird die Relation wieder hervorgeholt, da die weit weniger als die ‘normale’ Relation vom Lizenzwechsel betroffen ist.

Edbert (EvanE)

mdk · 2011-11-04T08:20:07.000Z

@wambacher:
Ich denke es geht um MPs als Mitglieder von MPs (also 3. Punkt). Nach meinem Verständnis ist das grundsätzlich zulässig.

In dem Konkreten Beispiel geht es jedoch um eine type=multiplygon und dort ist laut Wiki eben nur ways (mit inner und outer) zulässig. Keine nodes (z.B. wie label und andmin_centre bei Boundary Relationen) und auch keine Relationen.

Für dein 1111111 (type=boundary) sind Relationen zulässig, allerdings nur mit der Rolle subarea, da ist also nach Handlungsbedarf

mdk

[Edit]
Ich habe gesehen, dass hier die deutsche Wiki Seite etwas nachhinkt (Relationen als Members sind dort noch nicht erwähnt). Und es fehlt auch node mit Rolle label.

Kann mir jemand die Notiz zu Relationen als subarea erklären:

Note that this role is optional and its use in a number of cases may complicate editing boundaries.

[Edit 2]
In 1111111 verwendest du ja die Relationen gar nicht als subarea, sondern als boundary_segment. Da existiert aber erst ein Proposal.

wambacher · 2011-11-04T08:25:27.000Z

EvanE:

Das ist sehr schade.
Aber spätestens beim Lizenzwechsel wird die Relation wieder hervorgeholt, da die weit weniger als die ‘normale’ Relation vom Lizenzwechsel betroffen ist.

Danke Edbert,
gekillt war wohl etwas zu stark formuliert - sie ist noch da (wird quasi mitgeschleppt) - sie erfüllt halt nur nicht ihren Zweck (Ersatz für 51477)

Gruss
Walter