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
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.
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.
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
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.
@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:
[Edit 2]
In 1111111 verwendest du ja die Relationen gar nicht als subarea, sondern als boundary_segment. Da existiert aber erst ein Proposal.
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)
Dazu müssen wir erst mal definieren:
Wenn ich hier die Abkürzung MP verwende, sind damit Relationen type=multipolygon gemäß OSM gemeint. Leider beinhaltet dies auch Polygone gemäß simple features
Dein erster Fall geht, wenn sichergestellt ist, dass dieser ausschließlich ways als member mit outer-tag hat.
Fall 2 ist m.E. auch unkritisch
Wenn du mit echtem MP ein Multipolygon nach Simple Features meinst, teile ich deine Meinung ebenfalls.
Ich grübele gerade darüber, wie ich ergänzend zu den Wiki-Erläuterungen für Multipolygone eine Empfehlung bastele, die “best practice” darstellt, wie MP-Konstrukte robust sowie auch für nachfolgende Mapper nachvollziehbar und ergänzbar bleiben.
Leider haben sie hier für’s Wochenende schönstes Wetter angesagt
