[Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel

[Martin Koppenhoefer]

Am 29. September 2011 17:02 schrieb Christian Müller <cmue81 at gmx.de>:
> Wir drehen uns hier im Kreis


+1, und die Mails werden nicht kürzer. Wer soll das alles lesen?


> , ich erinnere an eine mail, die wir dazu
> hatten, indem ich Dich fragte, ob Du auch noch zwischen Bord und
> Pflasterstein Platz lassen möchtest, weil es geographisch nicht korrekt ist
> - schließlich ist da noch Sand dazwischen.


wenn wir einzelne Pflastersteine mappen würden, dann klar ja. Wenn man
"die Pflasterung" mappt gehört Sand und Stein zusammen. Aber die
wenigsten würden auf die Idee kommen, den Grasstreifen daneben
absichtlich auch noch miteinzuschließen.


> Die Frage muss sein, welchen Sachverhalt der Realität man abbilden möchte.
>  Will ich den Sachverhalt, dass ein Wald an die Straße grenzt (was nur eine
> grobe Aussage zur Lagebeziehung ist, und immer sein wird, aber das kann ich
> eben modellieren)


wie schon erläutert ist das durch die Lage bereits klar (Stichwort
Geodatenbank). Wenn Du den Wald an seiner Grenze erfasst hast und
feststellen willst, ob eine Straße innerhalb der nächsten 50 m ist,
dann musst Du nur die Ausdehnung des Walds um 50 m erweitern (in
Deiner Abfrage, nicht in der OSM-Datenbank) und sehen, ob sich Straßen
darin befinden. Wenn Dich auch Straßen interessieren, die innerhalb
von 30 oder 100 m liegen, dann kannst Du auch das abfragen: Du
entscheidest selbst, bis zu welchem Abstand die Straße noch "am Wald"
läuft.

Im übrigen dürfte das nicht gerade eine häufig nachgefragte
Eigenschaft sein, ob sich in der Nähe einer Straße ein Wald befindet.
Wo uns das mehr interessiert (z.B. Wohngebiete) haben wir schon längst
einen workaround (highway=residential) geschaffen.


> oder möchte ich den Sachverhalt ausdrücken, dass zwischen
> etwas und etwas anderem immer noch ein drittes etwas ist  (das ist Leibniz -
> "egal wie klein der Raum wird, ich kann ihn immer nochmal in zwei Teile
> teilen").  Letzteres können wir mit OSM nicht modellieren, da wir dazu
> unbegrenzte Genauigkeit bräuchten, eine Grenze zu erfassen - die haben wir
> nicht.


das stimmt so nicht: wenn klar ist, was alles zu einem bestimmten
Flächentyp gehört, (s. oben Pflasterung vs einzelne Pflastersteine),
dann kann man nicht immer noch etwas erfinden, was dazwischen passt,
sondern dann gehört es zum Modell, dass die Bordsteinkante mit der
Kante der "gepflasterten Fläche" verbunden ist.



> Wir kommen in OSM nicht umher, eine Struktur zu benutzen, um sowohl die
> etwas gröberen Abbilder, als auch die sehr detailierten (aber immer noch
> begrenzt genauen) Abbilder der Realität, welcher MapperInnen zusammentragen,
> zu verwalten.  Diese Struktur ist, wenn es um Flächen geht, schon vorhanden,
> sie heißt Multipolygon.


nein, ein Multipolygon hat nichts damit zu tun, wie detailliert oder
grob die Daten sind. Sie ist in diesem Kontext nur eine etwas
elegantere Methode, überlappende Ways zu vermeiden und dafür einen
einzelnen Way mehrfach zu verwenden (weiterhin ermöglichen sie,
mehrere Flächen als eine zu definieren und Flächen abzuziehen).


> Sie wird bereits mal dort und mal da in begrenztem
> Kontext eingesetzt, sie aber als /das/ verbindende Element zwischen MICRO-
> und MACROmapping Welten zu begreifen, fehlt.


weil das damit auch nichts zu tun hat. M.E. sollten wir uns auf das
Micro konzentrieren, da das Macro sich aus dem Micro errechnen lässt.


> Eine konsequente MP-Verwendung
> ist z.B. bei den politischen Grenzen, sprich polit. Flächen zu erkennen - da
> werden Teile von Teilen von Teilen gemappt und ihre Beziehungen
> untereinander eben auch.


die Beziehungen ergeben sich aus den tags (admin_level) in Kombination
mit der räumlichen Konfiguration.

Gruß Martin