Hilfe bei Multipolygen nötig!

[kellerma]

@erwin6330

@kellerma

Hi Erwin,

beim obereren Teil des forest ist eine Wiese.
Auf dem Luftbild schaut es so aus, als ob dort gebaut wird.

Den Bereich den Du meinst, dass ist glaube ich der Bereich mit dem abgebaggerten Kies aus dem Inn. Der wurde per Bagger aus dem Inn geholt und jetzt gesiebt, gereinigt und anschließend per LKW verfrachtet.

Tagging - wie? Es ist keine Baustelle!

Also eine Wiese ist es jedenfalls nicht

Auch wenn es nicht 100% passt, wuerd’ ich hier
landuse=quarry
nehmen. (siehe wiki)

Ciao,
Frank

[mdk]

@kellerma

Genau so habe ich bisher “gearbeitet”, was jedoch zu diesen “touching inner rings” führen kann und auch geführt hat. Aussdem braucht diese Arbeitsweise mehr Speicherplatz auf den Festplatten, da mehr Punkte, mehr Linien usw.

Die touching inner rings behebe ich in dem ich einen eigenschaftslosen Weg um alle inneren Flächen als inner lege (natürlich mit den bestehenden nodes). Dann die bisherigen inner Flächen aus dem MP entfernen. Ich mache also erst mal das passende Loch in die Fläche (ein outer, ein inner) und dann zeichne ich beliebiges Zeug in das entstandene Loch ohne mich um irgentwelche MPs kümmern zu müssen.

Zum Thema Platzverschwendung: Da bin ich ganz anderer Meinung. Nehmen wir das Beispiel aus dem Wiki:

Zuerst einmal ist die Anzahl der Nodes bei beiden Verfahren gleich. Wenn zwei Wege einen node doppelt verwenden, ist die node trotzdem nur einmal in der DB (aber es gibt zwei Wege, die diese node referenzieren).

Die Anzahl der Wege sieht wie folgt aus:
Mit MPs “überall”:
20: Im Beispiel schön von 1 bis 20 durchnummeriert (wenn wir 19 und 20 als touching inner und outer akzeptieren, ansonsten sind es 4 mehr, wenn das Problem mit MPs gellst wird)
Die referenzieten nodes sind für die Wege 1 bis 20): 2 + 2 + 4 + 5 + 2 + 3 + 4 + 2 + 2 + 5 + 2 + 2 + 3 + 2 + 2 + 2 + 2 + 2 + 5 + 6 = 59
Wenn man das touching Problem mit MPs löst gibt es sogar zusätzliche Refferenzen: Weg 7: 6 statt 4, Weg 19: 6 statt 5, Weg 20: bleibt bei 5 (da jeweils die überlappenden Wege nur einmal definiert werden)

KISS (also möglichst wenige MPs):
7: Pro Fläche einen Weg (also für A , B, C, D, E, F und G). Referentzierte nodes: 9 + 5 + 4 + 5 + 7 + 6 + 5 = 41
1: boundary=administrative (statt der Teilwege 5, 6, 7 und 8). Referentzierte nodes: 8
1: highway=unclassified (statt Teilwege 9, 10 und 11). Referentzierte nodes: 7
2: highway=track (entweder 12-13-14 & 15 oder 12-13 & 14-15). Referentzierte nodes: 5 + 2 = 7
1: barrier=fence (Teilwege 16 + 17). Referentzierte nodes: 3
Total=11 also nur knapp die Hälfte!! Bei einer nur leicht auf 66 erhöhten Anzahl von node refferenzen.

Bei den Relationen sieht es ähnlich schlechter aus:
Mit MPs “überall”:
A (mit 4 outer, 2 inner)
B (mit 2 outer, 1 inner)
E (mit 4 outter, 2 inner) (+2 outer wenn touching problem behoben)
Total=3 ([Edit] +2 für F und G wenn touching problem behoben)

KISS:
A (mit 1 outer, 2 inner)
B (mit 1 outer, 1 inner)
Total=2

Wo ist da die Einsparung?

Ganz zu schweigen von dem Mehraufwand, den JEDE Applikation teiben muss, um beim Verarbeiten der Daten alle Teile zusammenzusuchen (CPU-Zeit und Speicher).

Ferner Fehleranfälligkeit und Frust bei (vor allem neuen) Mappern.

Nehmen wir nur die Boundary Relation, die es normalerweise gibt. Normal reichen 4 bis 6 Wegstücke aus um ein admin_level=8 zu beschreiben. In diesem Beispiel wird aber der way schon in 4 Teile geteilt und wenn man das auf eine komplette Grenze hochrechnet, kommt man leicht auf eine 3-stellige Anzahl von Ways dank der MP unterteilungen. Das selbe gilt für Relationen für Wanderwege, Radrouten, Strassen, etc.

Noch mal: das Agument der Ressourcenschonung kann ich - auch und gerade im weitesten Sinne (Frustation von Mappern) - nicht akzeptieren!

Grüsse

mdk

[erwin6330 (Erwin Pleyer)]

@GeorgFausB

Moin Erwin,

vielleicht wäre es sinnvoll, dass Du z. B. nochmal die Relation 1675986 (Wohngebiet Stadt Kufstein) überprüfst, ob die 95 Elemente wirklich sinnvoll sind.

Ich würde

• die inner 121163581 und 134884930 unbedingt zum outer machen, denn sonst ist der outer nicht geschlossen und die residential-Fläche kann eigentlich gar nicht gerendert werden.

Ansonsten ist die “vorwiegend mit Wohngebäuden bebaute Fläche” Daten-technisch sehr schön modelliert - aber ist die Relation auch Mapper-technisch einfach gehalten?

Ehrlich gesagt, ich würde

• es auf 13 outer landuse-Segmente und 11 inner landuse-Ringe beschränken.
• die restlichen 71 Parkplätze, Spielplätze, Sportplätze usw. rausschmeißen.

Gruß
Georg

Hallo GeorgFausB

bei uns in Bayern, und da arbeite ich, sagt man immer, “Wo Du recht hast, hast Du Recht! Und wer Recht hat, der zahlt a Mass”

Habe die beiden Wege als outer geändert und das Wohngebiet müsste jetzt geschlossen sein. Danke für den Hinweis.

[kellerma]

Jetzt werden mir schon Dinge in den Mund gelegt,
die ich nie gesagt habe!

Verkehrte Welt

[chris66]

@mdk
Sehr schöne Untersuchung.
Ich persönlich würde das mit genau 2 MPs taggen.

[kellerma]

mdk zahlt a Mass fuers falsche Zitieren!

[erwin6330 (Erwin Pleyer)]

@mdk

Zuerst einmal ist die Anzahl der Nodes bei beiden Verfahren gleich. Wenn zwei Wege einen node doppelt verwenden, ist die node trotzdem nur einmal in der DB (aber es gibt zwei Wege, die diese node referenzieren).

Frage: Wenn ich 2 Punkte per “j” im Potlatch bzw. “m” im JOSM verschmelze, dann werden aus 2 Punkten einer?

Wie habt Ihr das Datenbanktechnisch gemacht? Und was passiert, wenn ich einen Weg, bzw. 2 Punkte splitte? Dann werden aus dem einen wieder 2 Punkte? Klingt interessant, aber unverständlich!

[erwin6330 (Erwin Pleyer)]

@kellerma

mdk zahlt a Mass fuers falsche Zitieren!

Da bin ich dabei, das klingt prima!

Prost!

[mdk]

@kellerma

mdk zahlt a Mass fuers falsche Zitieren!

Oooops

Die Aussage stammt ja von erwin6330.

@kellerma OK. komm doch am 11.11. zum Züricher Stammtisch, dann geb ich dir gerne einen aus

Grüsse

mdk

[mdk]

@erwin6330

Frage: Wenn ich 2 Punkte per “j” im Potlatch bzw. “m” im JOSM verschmelze, dann werden aus 2 Punkten einer?

Ja. JOSM nimmt als “Überlebenden” immer den älteren (auch wenn dieser von einem Ablehner ist )

Wie habt Ihr das Datenbanktechnisch gemacht? Und was passiert, wenn ich einen Weg, bzw. 2 Punkte splitte? Dann werden aus dem einen wieder 2 Punkte? Klingt interessant, aber unverständlich!

Zuerst wird in allen Wegen und Relationen, die den zu löschenden Node enthalten, dieser durch den neuen ersetzt und danach der überflüssige Node gelsöscht.

Punkte Splitten?

Wenn man einen Weg an einem Punkt splittet, bleibt es ein Punkt, aber beide Wege refferenzieren den selben Punkt.

Wenn du “Linien Trennen” meinst (JOSM mit G), ja dann wird ein neuen Knoten erzeugt mit einer Kopie aller Eigenschaften (bei JOSM incl. Relationszugehörigkeit)

Grüsse

mdk

[chris66]

@mdk

Ja. JOSM nimmt als “Überlebenden” immer den älteren (auch wenn dieser von einem Ablehner ist )

Oh, das ist sub-optimal…

[mdk]

@chris66

@mdk

Ja. JOSM nimmt als “Überlebenden” immer den älteren (auch wenn dieser von einem Ablehner ist )

Oh, das ist sub-optimal…

Ja, vor allem weil es (noch vor der Ärger mit der Lizenzumstellung) extra einen Bugfix gab, der dieses Verhalten erzwungen hat. Damas war das Problem, dass teilweise neue Nodes verwendet wurden und daher unnötige Löschungen erfolgten.

Grüsse

mdk

[hurdygurdyman]

@mdk

…
Die touching inner rings behebe ich in dem ich einen eigenschaftslosen Weg um alle inneren Flächen als inner lege (natürlich mit den bestehenden nodes). Dann die bisherigen inner Flächen aus dem MP entfernen. Ich mache also erst mal das passende Loch in die Fläche (ein outer, ein inner) und dann zeichne ich beliebiges Zeug in das entstandene Loch ohne mich um irgendwelche MPs kümmern zu müssen.

Grüsse

mdk

1+
Genau das ist m.E. der beste Weg. man muss sich immer daruber im klaren sein, dass ein Loch in einer Fläche erst mal keinen Flächeneigenschaft hat (Loch mit nix). Und bei der beschriebenen Vorgehensweise füllt man dieses Loch. Man kann sich das auch wie ein Mosaik oder eine Intarsie vorstellen.

Und wie gehen wir jetzt mit den Wiki-Examples um, in die Willy2006 soviel Arbeit gesteckt hat? http://wiki.openstreetmap.org/wiki/DE:Multipolygon_Examples
Und wie mit der Beschreibung: http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon
Und das gibt’s auch noch: http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon/Examples

[hurdygurdyman]

Mist gebaut und gelöscht

[kellerma]

Bei dem vorgelegten Beispiel gibt es IMHO gar kein “MPs “überall”” oder “KISS”, denn

A) ist die Geometrie so wie im Beispiel, also G reicht an die boundary 7 heran, dann ist E kein MP, sondern “nur” ein Weg mit 11 (!) Knoten, F und G sind einfache ways.

oder
B) G ist echt in E enthalten => E wird ein MP mit
B1) G disjunkt F: 1 outer (E) mit 2 inner (G, F)
oder
B2) G liegt an F: dann so wie mdk vorschlägt: E outer mit 1 inner (um G+F) herum und G, F einfache ways, die sich berühren.

[mdk]

@kellerama

Bei dem vorgelegten Beispiel gibt es IMHO gar kein "MPs “überall” oder “KISS”, denn

A) ist die Geometrie so wie im Beispiel, also G reicht an die boundary 7 heran, dann es E kein MP, sondern “nur” ein Weg mit 10 (!) Knoten,
F und G einfache ways.

Richtig.

Dieser Beispiel wurde jedoch am Anfang des Thread genannt mit dem Hinweis, das touching outer kein Problem sind, da es im [Wiki](http://wiki.openstreetmap.org/wiki/DE:M … n_Examples) so beschrieben ist:

Farmland E wird durch ein neues Multipolygon E beschrieben:

Relation E:
   type=multipolygon
   landuse=farmland
   outer 7
   outer 16
   outer 17
   outer 18
   inner 19
   inner 20

Und das mit den 10 Punkten statt meiner 7 stimmt auch (fast). Ich habe tatsächlich vergessen, den Weg um F+G herumzuführen. Aber als Informatiker kann ich es mir nicht verkneifen: Es sind mindestens 11 refferenzierte nodes, da ein geschlossener Weg in OSM dadurch entsteht, dass Anfangs- und Endpunkt der gleiche ist.

Grüsse

mdk

[kellerma]

Es sind tatsächlich (disjunkte) 11 Punkte, hab’s im Post schon korrigiert,
aber nicht weil man Anfang und Endpunt hat und so 2x zählen muss,
sondern zwischen den Strecken “19” und “20” man noch einen zusätzlichen Punkt zur Trennung von G und F braucht.

Hab’s eben im JOSM nachgestellt

[mdk]

Mist…

Ich hab mir extra verkniffen darauf hinzuweisen, dass ich den rechten Punkt zwischen 19 und 20 auch noch hinzufügen würde, damit es keinen Ärger gibt, wenn die 3 Punkte nicht genau auf einer Geraden liegen.

[Radeln]

@erwin6330

@Radeln

@Hobby Navigator

Ich fürchte du hast es richtig beschrieben Erwin. Aber man kann es auch übertreiben mit den MP`s.
Wenn ich mir diesen Thread richtig auschaue und die vielen Erklärungen und Beispiele dazu, frag ich mich wirklich ob das einen neuen Mapper nicht eher abschreckt als motiviert. Das Thema MP ist ja selbst für “altgediente” mittlerweile eine Wissenschaft für sich.

Nur die MPs?
Wenn ich mir das Hin und Her mancher Diskussionen hier anschaue …

Konsistente Regeln für das Mapping würde da weiterhelfen. Dazu gehört auch ein klar strukturiertes Wiki.

Gute Regeln würde sicherlich allen helfen, das ist ganz klar.

@Radeln: Wie ich gesehen habe, bist Du derzeit auch im Bereich Kufstein am mappen, kommst Du aus dieser Ecke?

Was mich schon stört, ist das Beispiel an der westlichen Grenze des Schwimmbades. Dort sind mittlerweilen 3 Linien übereinander. Einmal der Zaun, einmal der Wald und dann noch das MP.

Ist das wirklich noch gut?

Nee aus der Ecke komm ich nicht. Ich beseitige nur ab und an ‘Intersections’, wenn nicht zu kompliziert.

Aus den 3 Linien am Schwimmbad könnte man zwei machen, wenn man den outer des Waldpolygons an dieser Stelle teilt.

BTW, weshalb hast Du das Gebäude geteilt? Nimm es aus dem MP, und rücke es sicherheitshalber etwas vom outer ab. Ob letzteres notwendig ist, Frage an die Spezialisten.

Gruß
Josef