[Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)

[Stefan Keller]

Christian,

Am 22. September 2011 16:58 schrieb Christian Müller <cmue81 at gmx.de>:
>>>            - Bedingung: Datenhaltung von Flächen als multipolygons
>>
>> wie es Sinn macht, bei kleinen landuse-Flächen aus meiner Sicht
>> unnötig und schädlich, da es unnötig das Mappen verkompliziert.
>
> +/- 1.  Jein.  Das ist ja momentan nur deshalb komplizierter, weil die Tools
> dafür zu schlecht sind.  Ich schrieb in einer meiner mails:  multipolygons
> müssen so einfach werden, wie einen "closed way" zu zeichen.  Das erachte
> ich als Vorraussetzung und letztlich /sind/ multipolygons DAS Flächentool in
> OSM schlechthin.  Nur werden sie noch nicht so eingesetzt, stattdessen
> beschränkt man sich auf ihre Verwendung für Spezialfälle.

Das mit den Flächen ist bei OSM so eine Sache. Es gibt in der
Nicht-OSM-Welt eine einzige allgemein(!) akzeptierte Norm (von OGC)
und die kennt den Geometrietyp Polygon und Multipolygon.
OSM-Multipolygone sind vergleichbar mit OGC-Polygon *und*
OGC-Multipolygon. Mir wäre noch so recht, würde OSM auf diese
Definition umstellen.

Was du nun mit OSM-Multipolygonen in der Folge erläuterst, ist sehr
mit Vorsicht zu geniessen:

> Die Vergangenheit zeigt aber, dass öfter als weniger, einfache Fälle zu
> Spezialfällen mutieren.  Clevere Leute mappen ihre Flächen dann mit
> multipolygons neu (obwohl das umständlich ist, Du schreibst es selbst),
> andere behelfen sich damit, "overlapping ways" zu bilden (was ich selbst
> lange Zeit gemacht habe, da ich noch nicht wußte, wie die eigentliche Lösung
> aussieht), oder damit, überhaupt keinen Flächenbezug herzustellen
> (geschachtelte "closed ways") - was keine vernünftige Abbildung der Realität
> ist.

Du verwendest hier das Wort "Flächenbezug" in verwirrender Weist
(s.u.). Wenn es Flächen gibt, die innerhalb Flächen sind, dann ist das
Ok, ob die innerste Fläche nun als "closed way plus tags" oder
Multipolygon erfasst ist.

> In der Realität gibt es ohne Ende Bezüge zwischen den Flächen (das
> Wohngebiet liegt __innerhalb__ der Gemeindefläche, der Bäcker liegt
> __innerhalb__ des Wohngebiets, das Feld _grenzt_ an Weg- oder Wald- -fläche
> -- und das sind nur Beispiele für eine Lagebeziehung).

Einverstanden. Bezüge (Relationen) ohne Ende.

> Natürlich kann ich mir die Lagebeziehungen auch erst ausrechnen, anstatt sie
> ordentlich mitzumodellieren, für viele Lagebeziehungen wird aber diese
> Rechnung sehr komplex - betrachte z.B. die Lagebziehung "Gemeindefläche
> __innerhalb__ Bundesgebietsfläche":

Ist komplex - aber in allen Geodatenbanken und Geoinformationssystemen gelöst.

> Wenn diese Beziehung nicht durch Datenstrukturen zu ermitteln ist (wie
> das jetzt der Fall ist), müsste ich für die gesamte bundesdeutsche Grenze (a
> lot of nodes) algorithmisch prüfen, ob die Gemeindefläche (less nodes but
> still a lot) komplett inkludiert ist.  Wenn ich diese Lagebeziehung dann für
> _alle_ Gemeindeflächen brauche, wird meine CPU schwitzen.  OSM sei Dank muss
> ich aber nur wissen, /wie/ ich die entsprechende Datenstruktur auslesen
> muss.
>
> Dieses Problem lässt sich für jedwede Lagebeziehung von Flächen aufzeigen.
>  Das ist, weshalb ich schon die ganze Zeit nicht müde werde, zu erzählen,
> dass Beziehungen zwischen Flächen "nicht _einfach so_ da sind".  Es ist
> besser, wenn insbes. die Lagebeziehungen innerhalb OSMs Datenstrukturen
> vorhanden sind:

Das ist ein wichtiger Punkt: Die meisten geometrische(!) Beziehungen
zwischen Punkten, Linien, Flächen und zwischen Flächen und Flächen
kann man mit geometrischen Werkzeugen jederzeit berechnen! Es ist nur
das Nötigste zu erfassen! Wenn eine Fläche keine Enklave hat, genügt
ein "closed way plus tags" (du nennst es glaube ich anders) ansonsten
als Multipolygon.

>        Das geht nicht mit "closed ways", das geht auch nicht mit
> "overlapping ways" sondern nur mit zueinander in Beziehung stehenden
> Multipolygons (ich habe das als 'Flächennetzwerk' bezeichnet).

Flächennetzwerk ist ein Begriff, der die Topologie (Konzept der
Nachbarschaft auf einer Menge von Punkten ...). Konkret wird die
gemeinsame Grenze zweier Flächen je einmal in der
Multipolygon-Relation erfasst.

Du scheinst dieses Konzept nun erweitern zu wollen, so dass
Beziehungen zu umschliessenden Flächen ("Inkludiertheit") erfasst
werden. Zu dem rate ich dingend ab! Es ist so schon schwierig genug,
sich auf eine einheitliche Handhabung von OSM-Multipolygonen zu
"einigen". Würde man diese Forderung umsetzen, dann müsste man die
Bezüge (Relationen) ohne Ende (wie oben erwähnt) und Relationen ohne
Ende umsetzen, also möglichst für jede mögliche Abfrage.

Dein Anliegen zur schnellen Abfrage (= genannt Analyse) ist aber
legitim. Die Lösung sieht so aus, dass man Erfassung und Verwaltung
trennt von der Analyse (s.u.).

> Es nützt auch nichts zu argumentieren, dass manche Polygone ja "viel
> kleiner" seien und nicht so viele nodes hätten, wie andere und damit die
> Rechnung in der Tat einfacher sei..  Eine Lagebeziehung kann ich nur
> zwischen mindestens zwei Polygonen bilden, d.h. ich beschränke mich mit
> dieser Argumentation dann schon auf Lagebeziehungen zwischen zwei _viel
> kleineren_ Polygonen.
>
> Natürlich sind Algorithmen denkbar, die den Rechenaufwand für viele solcher
> Berechnungen wieder reduzieren, indem z.B. entsprechend bounding boxes
> gebildet werden und dann erstmal nur gegen diese gerechnet wird, anstatt
> gegen den kompletten Streckenzug.

Richtig. Die sind wie gesagt nicht nur denkbar, sondern seit
Jahrzehnten Realität. Mittlerweile sind die auch genügend effizient,
dass auch verrücktere Abfragen innert nützlicher Zeit berechnet werden
können.

Das kann jeder ausprobieren z.B. auf dem PostGIS Terminal, z.B. so
http://labs.geometa.info/postgisterminal/?xapi=polygon[tourism=zoo]

Da wird eine XAPI-artige Anfrage übergeben, die in eine SQL-Anfrage
umgeformt wird. Die SQL-Anfrage wird auf eine Tabelle (osm_polygon)
losgelassen, deren Daten periodisch importiert und optimiert (sprich
z.B. indexiert) abgelegt werden. Die SQL-Anfrage kann man dann im
Query-Feld anpassen.

> Warum sollte aber jemand diesen Aufwand betreiben, wenn er durch bessere
> Datenlage nicht bestünde?  Mehr noch, warum sollte ihn _jeder_ _separat_
> betreiben, der an Lagebeziehungen zwischen Flächen interessiert ist?

Anders rum: Warum sollte jeder, Relationen ohne Ende erfassen, nur um
mögliche künftige Abfragen zu erleichtern? Dies zumal es schon genug
schwierig ist, Flächen (jeder Art) konsistent zu erfassen?

Stefan