Hilfe bei Multipolygen nötig!

kellerma · 2011-10-27T09:46:07.000Z

Hi Erwin,

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

hurdygurdyman · 2011-10-27T09:51:39.000Z

erwin6330:

…
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?

Nö, ist es nicht.
Nimm doch einfach den Zaun als outer-Teil. Entspricht doch der Realität und spart eine Linie

erwin6330 · 2011-10-27T10:02:30.000Z

hurdygurdyman:

erwin6330:

…
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?

Nö, ist es nicht.
Nimm doch einfach den Zaun als outer-Teil. Entspricht doch der Realität und spart eine Linie

Habe ich gerade gemacht, ich hoffe es passt so

erwin6330 · 2011-10-27T10:10:33.000Z

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!

hurdygurdyman · 2011-10-27T10:10:37.000Z

erwin6330:

hurdygurdyman:

erwin6330:

…
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?

Nö, ist es nicht.
Nimm doch einfach den Zaun als outer-Teil. Entspricht doch der Realität und spart eine Linie

Habe ich gerade gemacht, ich hoffe es passt so

Man könnte sogar noch beim Wald-outer den gemeinsamen Bereich, an dem der Zaun steht, rausschneiden und löschen, aber dafür dann den Zaun als outer in das Wald-MP dazunehmen, um noch eine Linie zu sparen…
…aber das erscheint mir nicht sinnvoll, denn wenn der Zaun dann mal abgerissen wird, fehlt ein Stück des großen Wald-outer, welches dann zu finden wäre.
Ich denke, die jetzige Lösung ist logisch und robust genug gegen ungewollte Änderungen.

erwin6330 · 2011-10-27T10:16:26.000Z

hurdygurdyman:

Man könnte sogar noch beim Wald-outer den gemeinsamen Bereich, an dem der Zaun steht, rausschneiden und löschen, aber dafür dann den Zaun als outer in das Wald-MP dazunehmen, um noch eine Linie zu sparen…
…aber das erscheint mir nicht sinnvoll, denn wenn der Zaun dann mal abgerissen wird, fehlt ein Stück des großen Wald-outer, welches dann zu finden wäre.
Ich denke, die jetzige Lösung ist logisch und robust genug gegen ungewollte Änderungen.

Ich weiß jetzt nicht, was Du Dir angesehen hast, aber an der NW-Seite des Schwimmbades ist nur mehr der Zaun, die anderen Linien wurden gelöscht.

Wenn der Zaun abgerissen wird, dann bedarf das der Aktualisierung, im Moment stimmt es so. Dann dürfte man nie zwei Grenzen in einer Linie zusammenfassen, denn Änderungen können sich immer ergeben.

hurdygurdyman · 2011-10-27T10:30:09.000Z

erwin6330:

…
Ich weiß jetzt nicht, was Du Dir angesehen hast, aber an der NW-Seite des Schwimmbades ist nur mehr der Zaun, die anderen Linien wurden gelöscht.

Wenn der Zaun abgerissen wird, dann bedarf das der Aktualisierung, im Moment stimmt es so. Dann dürfte man nie zwei Grenzen in einer Linie zusammenfassen, denn Änderungen können sich immer ergeben.

Hatte es mir nicht nochmal angesehen.
Da der Zaun ja jetzt auch outer vom Wald ist, kann man das lassen. Du hast mich teilweise überzeugt
Es bleibt aber die Gefahr, dass der Zaun als Wald-outer irgendwann an einem falschen MP hängt, falls jemand das Wald-MP in zwei MP’s aufteilt und dabei dieser Waldbereich beim Schwimmbad eine neue Nr. bekommt
Doch dafür gibt’s ja OSMI

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…