Im deutschen OSM-Forum hat Benutzer Jochen Kern neulich beschrieben, warum er Multipolygone für die bessere Art der Flächenerfassung hält. Da es die Diskussion dort zu arg auseinanderführen würde, lagere ich meine Erwiderung mal hierher in meinen Benutzer-Blog aus.

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 abbilden.

Dass zwei Flächen aneinander grenzen, lässt sich auch ermitteln, wenn die beiden als geschlossene Ways gemappt sind und sich die Nodes teilen. ST_Intersection der beiden ist dann ein LineString oder MultiLineString. Das OSM-Datenmodell ist für Analysen nur sehr eingeschränkt geeignet, weil es sehr viele JOINs erfordert. Um die Geometrie (Koordinatenliste) eines Ways zu erhalten, muss man in einer zweiten Tabelle die Koordinaten der Nodes nachschlagen. Um die Geometrie einer Multipolygonrelation zu erhalten, muss man zuerst die Ways in der Tabelle der Ways nachschlagen, dann deren Nodes in der Tabelle der Node nachschlagen. Das kostet Performance und aus diesem Grund hat sich für fast alle Anwendungen von OSM-Daten der Simple-Features-Ansatz durchgesetzt, bei dem Linien und Flächen keine Liste an Punkt-IDs, sondern direkt eine Liste der Koordinatenpaare haben.

Der Grund, warum unser Datenmodell praktisch nicht zur Analyse genutzt wird, ist eigentlich nicht, dass es schon in den OSM-Anfangstagen Open-Source-GIS-Software gab, die nach dem Simple-Features-Modell gearbeitet hat, sondern dass der Wechsel von einem Knoten-Kanten-Modell zu einem Simple-Feature-artigen Modell in der GIS-Welt schon vor 20 Jahren (oder etwas länger) erfolgt ist, weil es schlicht und einfach praktische Gründe gibt, eine Abstraktionsebene weniger zu haben.

Es gibt Diskussionen und mehr als nur absolut vage [1] Pläne, mittelfristig den Datentyp Node teilweise abzuschaffen, damit Ways nur noch eine Liste an Koordinatenpaaren enthalten. Im Zuge dieser Diskussion sind auch Entwickler von Software für verschiedene OSM-Anwendungsfälle gefragt worden, ob sie Nodes überhaupt brauchen. Mir ist keine Antwort bekannt, in der die teilweise Abschaffung der Nodes eine Anwendung verunmöglichen oder sehr erschweren würde. Das zeigt doch, dass unser eigenes Datenmodell nur für die OSM-API-seitige Datenhaltung taugt und praktisch alle anderen Anwendungsfälle aus guten Gründen auf die OSM-Komplexität verzichten können, oder?

Die Nichtnutzung des OSM-Datenmodells für Analysen zeigt, dass dein Argument, man könne mit Multipolygonen die Beziehungen zwischen Flächen ermitteln, keine Bedeutung hat. In den gebräuchlichen Datenhaltungen von OSM-Anwendungen, für die nachbarschaftliche Beziehungen relevant sind, hat eine Fläche keine Liste an Mitglieder-Ways. Außerdem ist eine rein koordinatenbasierte Nachbarschaftsanalyse robuster, wenn ein Mapper für zwei aneinander grenzenden Flächen keine gemeinsamen Nodes verwendet oder absichtlich für einen Verkehrsweg zwischen den beiden eine Lücke lässt.

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ächengrenzobjekte mehrfach modelliert, wodurch eine Verletzung des zweiten Gebots stattfindet - und zwar _regel_mäßig.

Ich lege die On-the-Ground-Regel anders aus. Es geht bei dieser Regel nicht darum, ob man einen Node oder einen Way, Tags oder eine Relation verwendest, sondern darum, ob das, was in OSM erfasst ist, vor Ort so beobachtet werden kann. Sowohl wenn ein Gebüsch als geschlossener Way als auch wenn es als Multipolygon-Relation mit vier Outer-Ways und keinem Inner-Way gemappt ist, ist es vor Ort existent. Es entspricht dann innerhalb der Genauigkeit, mit der sein Rand in OSM abgebildet ist, der Realität.

Die One-Feature-one-Object-Regel verstehe ich völlig anders. Sie wäre verletzt, wenn wir Landnutzung nicht mit Flächen, sondern mit Kanten erfassen würden und nicht Tags an den Flächen, sondern an den Kanten anbringen würden (also landuse:left=meadow + landuse:right=forest statt landuse=meadow am Wiesenpolygon und landuse=forest am Waldpolygon). Die Regel ist meiner Meinung nach dafür gedacht, dass ein Objekt nicht mehrfach erfasst wird. Da wir die Landnutzung als Flächen erfassen und nicht dieselbe Wiese mehrfach erfassen, wird sie nicht verletzt.

Ein Objekt im Sinne der One-Feature-one-Object-Regel ist das Objekt, das die Tags trägt. Ein Haus in OSM, da es aus einem Way und mindestens drei Nodes besteht (also drei OSM-Objekte „zu viel“), verletzt diese Regel nach meiner Auslegung nicht. Genauso wenig verstößt man gegen sie, wenn man eine Multipolygon-Relation nimmt. Der Einsatz einer Multipolygon-Relation steht hingegen mit dem ungeschriebenen Grundsatz [2], Sachen so einfach wie angemessen zu mappen, in Konflikt. Dieser Grundsatz soll sicherzustellen, dass Neulinge die Möglichkeit haben, die Daten bearbeiten zu können, ohne umfangreiche Dokumentation lesen zu müssen.

Um es noch einmal klarzustellen: Ich will Multipolygon-Relationen nicht an sich abschaffen, ich will nur ihren Einsatz auf die Fälle beschränken, bei denen es erforderlich oder angemessen ist. Das sind Flächen mit inneren Ringen [3] sowie Flächen, mit einem sehr langen äußeren Ring und Flächen, die aus mehreren äußeren Ringen bestehen und bei denen das Mappen als zwei separate Polygone gegen die One-Feature-one-Object-Regel verstoßen würde [4].

[1] d.h. etwas konkreter als Träumereien auf einer Mailingliste oder im Forum, wie ich sie seit ich bei OSM bin, von Zeit zu Zeit sehe. https://2018.stateofthemap.org/2018/T107-Modding_the_OSM_Data_Model

[2] Bei OSM gibt es viele ungeschriebene Regeln. Wer gegen sie verstößt, wird gebeten, sie einzuhalten.

[3] Die Begriffe “innere Ringe” und “äußere Ringe” erkläre ich das gerne, wenn das gewünscht wird.

[4] z.B. ein Universitätscampus mit einer großen Straße dazwischen oder ein benannter Wald, der von einer Autobahn zerteilt wird. Diese zwei Beispiele sind aber recht kontrovers.