[Mod-Edit: Beleidigende Inhalte entfernt]
Nochmal: Die Welt ist kein /Siedler von Catan/ - Spielbrett, wo man die einzelnen
Flächen greifen und nach Belieben neu rekombinieren und aneinanderlegen kann (und wo
auch immer eine noch so kleine Lücke tatsächlich zwischen den Hexagon-Plättchen
verbleibt).
Flächen und Flächengrenzen der Realität sind hingegen kontinuierlich, sie fließen
ineinander über, selbst dort wo der Mensch Anlagen installiert, um sie sichtbar bzw.
unüberwindbar werden zu lassen. Multipolygone werden diesen Aspekt in besonderem
Maße gerecht, weil sie diese Beziehungen von Flächen der Realität unmittelbar ab-
bilden.
Es ist Unsinn Flächen der Realität ohne ihre Nachbarn denken zu wollen,
genau das passiert aber bei der Nutzung von “closed ways” als Flächenersatz: Sie
verletzen in der überwiegenden Zahl der Fälle zwei Gebote aus den “best practices”
die das Projekt sich selbst gegeben hat:
-
Bilde die Realität vor Ort ab (“ground truth”).
-
Benutze ein OSM-Objekt für ein Objekt der Realität (“one object, one feature”).
Zu “ground truth” ist der Fakt zu beachten, dass fast alle Flächen keine homogene
Flächengrenze besitzen (“closed ways” aber genau das modellieren). Werden mehrere
angrenzende Flächen durch “closed ways” modelliert, werden i.d.R. mehrere Flächen-
grenzobjekte mehrfach modelliert, wodurch eine Verletzung des zweiten Gebots
stattfindet - und zwar _regel_mäßig.
Außerdem bieten “closed ways” bis heute keine klare semantische Separation der Tags,
die entweder das lineare Feature oder die umgebene Fläche bezeichnen können. Ein
beliebtes und anschauliches Beispiel hierfür ist das Tag barrier=hedge, welches auf
einem “closed way” sowohl den Flächenumriss, als auch den Flächeninhalt auszeichnen
kann. Diese semantische Uneindeutigkeit besteht mit Multipolygonen nicht, und es
ist bei konsequentem Einsatz von MP klar, dass Tags auf den Flächengrenzen bzw.
Flächengrenzsegmenten stets das lineare Feature und nicht die umgebene Fläche aus-
zeichnen.
“closed ways” sind eine Krücke aus den Anfangstagen von OSM, in denen man glaubte,
man käme ohne eine klare Separation von Flächen- und Wegtypen aus. Allein die frühe
Ergänzung von Multipolygonen als Relationstyp zeigt deutlich, dass man da falsch
lag und diese Separation wichtig ist, gerade wenn man Daten in einem sich evolutionär
weiterentwickelnden Datenmodell richtig interpretieren will: Da der Katalog an Tags
nicht abgeschlossen bzw. abschließbar ist, lässt sich auch nicht definieren,
welche Untermenge davon auf “closed ways” nun zur Interpretation als Flächentag bzw.
Umrisstag führen solle.
Die bisherigen Diskussionen sind zum großen Teil dem Entwicklungsstopp der OSM-API
geschuldet, die noch nie einen dedizierten Flächentyp unterstützt hat und eben diese
Interpretation Nutzern und Anwendern (mit häufig mangelhaften theoretischen und
praktischen Kenntnissen) seit Jahren bzw. Jahrzehnten überlässt. Warum die deutsche
Community das nicht erkennt und stets mit Regeln und Verboten versucht irgendwas im
“nationalen Alleingang” (das dann natürlich als internationales Vorbild zum Selbstläufer
werden soll) zu richten, ist mir unbegreiflich. Evtl. kann sie mit der entstandenen Viel-
falt nicht umgehen, oder sie versteht sie eben nicht. Diejenigen die “closed ways”
als Krücke sehen, versuchen schließlich auch nicht -weder mit mechanischen edits
noch mit pseudo-legitimierten Regelungen- alles in ein MP-Korsett zu zwängen.
Eine wirklich nachhaltige Lösung kann m.E. erst stattfinden, nachdem man sich dazu
entschieden hat, einen bestimmten Flächendatentyp durch die API serverseitig anzu-
erkennen und zu unterstützen. Solange aber serverseitig alles erlaubt ist, wird die
Vielfalt in der Datenrepräsentation mitsamt Konflikten und Diskussionen weiterhin
Bestand haben.
PS Die Verwendung des Terminus “Overpass Turbo” im Changeset Kommentar war
in der Tat ein Schreibfehler, man möge es verzeihen.