Hallo Martin,
Ein Fehler in der engl. Diskussion ist m.E.,
dass dort nach einem "Tagging für den Renderer" gesucht wird
(genauer: für die Beschriftung von unscharfen Gebilden in der Karte).
Und dabei die geografischen Fragen ausser acht gelassen werden.
Stattdessen wird dann gestritten darüber, ob etwas "einfach" oder
"kompliziert" sei - jeweils aus unterschiedlichen Sichtweisen ;-)
Ein Missverständnis in der engl. Diskussion scheint mir,
dass Punkt und Fläche als geometrische Elemente
verwechselt werden mit "Punkt" und "Fläche" als Repräsentanz für
unscharfe geografische Gebilde oder gar als Repräsentanz zur
kartografischen Lokalisierung eines Namenszuges eines unscharfen
geografischen Gebildes.
Dass weder geometrischer Punkt noch geometrische Fläche ein unscharfes
Gebilde geometrisch beschreiben können, dürfte aber doch klar sein?
M.E. darf die Klasse der scharfen Objekte (die geometrisch eindeutig
beschrieben werden können, und deren Grenzen in der Wirklichkeit
deutlich sichtbar sind) - nicht vermischt werden mir der Klasse der
unscharfen Gebilde (die geometrisch nicht eindeutig beschrieben werden
können, und deren Grenzen in der Wirklichkeit nicht sichtbar sind).
Ich glaube, dass der durchschnittliche Mapper nicht unterscheiden kann,
ob eine Linie ein geometrisches Element darstellt oder nur Repräsentanz
ist für ein "unscharfes Gebilde".
Deshalb die Idee, unscharfe Gebilde in einer neuen zusätzlichen Ebene
der DB zu erfassen, getrennt von den geometrischen Objekten, aber denoch
in einem räumlichen Bezug zu ihnen.
Du hattest mal vorgeschlagen, dafür eine Extra-DB einzurichten.
Da wir in der DB bisher nur geometrische Elemente kennen (Punkt, Linie,
Fläche) plus Relationen dieser Elemente, und ich keine Idee habe, wie
man "nichtgeometrische Elemente" beschreiben könnte,
schlage ich vor "Flächen" zu missbrauchen als Repräsentanz für unscharfe
Gebilde, und diese in eine zweiten DB-Ebene dergestalt zu "isolieren",
dass die nicht geometrisch verbunden werden können mit den geometrischen
Punkten, Linien und Flächen aus der jetzigen DB-Ebene.
Eine *Bucht* als unscharfes Gebilde ist dann nicht verbunden mit einer
Küstenlinie (die übrigens auch nur zu einem bestimmten Zeitpunkt scharf
ist, und sich vorher und nachher mit Welle, Tide und Erosion permanent
ändert).
Eine Bucht endet nicht an der landseitigen Wasserlinie.
Nur die Wasserfläche der Bucht endet an der landseitigen Wasserlinie.
Aber die landseitige Wasserlinie ist nicht identisch mit der Bucht.
Die "Bucht" endet je nach Sicht des Betrachters: an der Küstenstrasse,
an der inneren (oder äusseren) Grenze der Bebauungszone, am Hang der
umgebenden Hügel/Berge, auf der Tiefenlinie die dem Tiefgang des eigenen
Schiffes entspricht, etc.
Eine Bucht ist auch landseitig unscharf.
Seeseitig ist eine "Bucht" ebenfalls unscharf.
Sie endet irgendwo zwischen zwei (oder mehreren) "markanten Punkten".
Wo diese Punkte liegen, und wie sie miteinander verbunden werden, ist
immer abhängig von der Sicht des Betrachters.
Manchmal hingegen werden seeseitige Grenzen festgelegt.
Dann handelt es sich aber um eine definierte und festgeschriebene
Grenze, wie beispielsweise die Basislinie zur Bestimmung der seeseitigen
Staatsgrenze.
Ich meine, es wäre sinnvoll, die Frage der Repräsentanz unscharfer
Gebilde hier einmal grundsätzlich anzugehen und zu lösen :-)
Ein *Berg* als unscharfes Gebilde besteht aus einem Gipfel als Punkt,
und "irgendetwas drumherum" das irgendwie eher einer "Fläche"
entspricht, aber halt nicht genau begrenzt ist.
Ein "Berg" ist auch nicht durch Flüsse begrenzt (denn Flüsse fliessen in
einem Tal, und ein Tal gehört nicht zum "Berg").
Ein "Berg" geht soweit, bis ein anderer "Berg" mit dessen Ausdehnung zur
eigenen Ausdehnung in Konflikt kommt. Oder bis sein "Fuss" in ein "Tal"
übergeht. Das hat etwas zu tun mit "Mächtigkeit": Gipfelhöhe,
Gipfelform, Dominanz, Reliefenergie, Schartenhöhe, Flankensteilheit,
ist-Teil-von, Entfernung-von, etc.
Was ein "Berg" ist, kann m.E. nur durch (meist relative) Parameter
beschrieben werden - aber nicht geometrisch.
Einige der Parameter könnte man an eine "angenäherte Fläche" koppeln,
und andere Parameter könnte man vermutlich relativ zu den Flächen
untereinander berechnen (so wie Christoph das vorschlägt).
_DB-Ebene für unscharfe Gebilde_
Ob so eine "DB-Ebene für unscharfe Gebilde" eine methodisch sinnvolle
Lösung ist - ober ob es noch etwas viel Sinnvolleres gibt - weiss ich
nicht. Technisch machbar scheint es aber zu sein...
Scharfe Objekte und unscharfe Gebilde sind verschiedene Klassen.
Sie sollten nie vermischt werden.
kannst Du das erklären?
Hoffe es ist jetzt etwas klarer?
Wäre die Schlussfolgerung, alle Buchten wieder rauszulöschen aus OSM?
Nein, sondern sie zu überführen in eine DB-Ebene für unscharfe Gebilde.
sowas hatte ich vor 3 Jahren auch mal vorgeschlagen, gemeinsam z.B. von
einem Shapefile von NaturalEarth ausgehend einen grobmaßstäblichen
Shapefilelayer mit Namen in allen zugänglichen Sprachen (oder z.B.
Wikidata-Referenzen) zu entwickeln, einen Paralleldatensatz der bei Bedarf
dazugemischt werden kann.
https://lists.openstreetmap.org/pipermail/talk-de/2011-August/088514.html
Find' ich gut!
- - - -
_Küstenzonenmanagement_
diese Küstenzonen sind m.E. administrative Gebiete
Ja.
Erwähnt habe ich das, weil es eine weitere, zusätzliche Dimension ist,
die uns bei OSM beschäftigen wird:
*virtuelle Grenzen* - die in der Wirklichkeit nicht sichtbar sind.
Anders als Staatsgrenzen und deren hierarchischen Sub-Formen
(die vielfach auch virtuell sind und nicht durch Grenzsteine markiert,
und die wir in OSM trotzdem eintragen)
sind Grenzen aus dem Küstenzonenmanagement nur ein Teil vieler und
exponentiell zunehmender virtueller Grenzen.
Ich gehe davon aus, dass diese zunehmend in OSM abgebildet werden.
Vermutlich "irgendwie" nach persönlichen "Vorlieben"
a) als eigenständige Objekte,
b) an bestehende Objekte drangeklebt, oder
c) gemischt mal eigenständig mal drangekebt werden
(wie bei den Buchten)
Dann werden die Linien/Relationen in JOSM nicht mehr händelbar.
Sie sind es jetzt schon teilweise nur noch mit hohem Aufwand.
Auch dafür brauchen wir bald eine Lösung.
- - - -
Bei einem so komplexen Projekt wie OSM und bei der inzwischen riesigen
gemeinsam zusammengetragenen Datenmenge besteht die Gefahr, dass wir
zunehmend die Mapper verlieren, weil die Lernkurve immer steiler wird.
Ich glaube es ist notwendig, Entwicklungen rechtzeitig zu erkennen und
künftige vorherzusehen - um rechtzeitig Lösngen zu finden, die den
Crowdsourcing-Prozess wieder simpel und umsetzbar machen :-)
Gruss, Markus
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
