Hilfe bei Multipolygen nötig!

wambacher · 2011-10-27T10:42:27.000Z

erwin6330:

Denke so wäre es dann richtig, aber wahnsinnig kompliziert und umständlich, oder etwas nicht?

nö, find ich ok.

wenn es der ~~Wahrheitsfindung~~ Darstellung der Realität dient, warum nicht?

Gruss
walter

GeorgFausB · 2011-10-27T10:52:28.000Z

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

kellerma · 2011-10-27T11:05:39.000Z

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 · 2011-10-27T12:08:44.000Z

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 · 2011-10-27T12:14:08.000Z

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 · 2011-10-27T12:15:51.000Z

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

Verkehrte Welt

chris66 · 2011-10-27T12:16:56.000Z

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

kellerma · 2011-10-27T12:22:00.000Z

mdk zahlt a Mass fuers falsche Zitieren!

erwin6330 · 2011-10-27T12:27:18.000Z

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 · 2011-10-27T12:27:50.000Z

kellerma:

mdk zahlt a Mass fuers falsche Zitieren!

Da bin ich dabei, das klingt prima!

Prost!

mdk · 2011-10-27T12:29:41.000Z

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 · 2011-10-27T12:41:39.000Z

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 · 2011-10-27T12:53:05.000Z

mdk:

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

Oh, das ist sub-optimal…

mdk · 2011-10-27T13:09:46.000Z

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 · 2011-10-27T13:11:50.000Z

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 · 2011-10-27T13:19:49.000Z

Mist gebaut und gelöscht

kellerma · 2011-10-27T13:29:22.000Z

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 · 2011-10-27T14:00:27.000Z

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 · 2011-10-27T14:09:35.000Z

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 · 2011-10-27T14:17:52.000Z

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.