[Talk-de] Datenhaltung: Flächen und Flächen_grenzen_

Di Sep 13 22:28:44 UTC 2011

Am 12.09.2011 19:47, schrieb Martin Koppenhoefer:
> place-polygon heisst nicht, dass dieses Polygon unbedingt durch einen
> doppelten Way gemappt werden muss, Multipolygone rechne ich da
> natürlich auch dazu.

Dann hätten wir theoretisch einen Konsens.  Theoretisch deshalb, weil 
der "way" eines landuse=* geschlossen sein muss.  Man korrigiere mich, 
wenn das nicht zwingend notwendig ist.  Bisher ist es in Validatoren 
zumindest eine Warnung, wenn ein nicht geschlossener way mit 
Flächen-Tags (landuse) versehen ist.  Wenn diese Warnung ignoriert 
werden kann, haben wir auch praktisch einen Konsens.  Dann dienen die 
außen liegenden Streckenzüge der Einzelflächen als Mitglieder des 
multipolygons, das die Siedlungsflächengrenze erfasst.

--------------------------------
Im Prinzip erleben wir hier auf einer weiteren Ebene das, was vor Jahren 
mit ways passiert ist - desto detailierter die Daten wurden, umso mehr 
wurden ways fragmentiert - Gründe:  da eine Verkehrsbeschränkung, 
anderswo die Relationen-Mitgliedschaft eines Wegabschnitts, etc.

Das gleiche passiert mit Flächen.  Reichte bisher die basisgeometrische 
Erfassung aus, wird durch Grenzdebatten sichtbar, dass, egal welche 
Flächengrenze man betrachtet,  ein Grenzsegment immer mehrere Flächen 
begrenzt und damit Kandidat für ein "outer"-Mitglied ist.

--------------------------------
Für den relativ einfachen Fall zweier benachbarter Landuses heißt das, 
dass ein /gemeinsames/ Segment der Flächengrenze durch

     - overlapping ways  (1)
     - einen way, der an zwei landuse-multipolygonen in der Rolle outer 
teilnimmt,  (2)

repräsentiert werden kann.  Letzteres ist die elegantere Lösung, da sie 
den direkten Datenbezug herstellt, also z.B. bei verschachtelten Flächen 
die Definition über die Verschachtelung in OSMs Datenstruktur enthalten ist.

--------------------------------
Vom Standpunkt des ways ist der Verschachtelungsbezug in der Datenstruktur

         im Fall (1) dadurch gegeben, dass man sich (einen beliebigen 
node nebst Nachbarn) irgendeines ways herausgreift
                 - für beide nodes separat alle durchlaufenden ways 
ermittelt (Wege die entweder node oder Nachbar nutzen)
                 - und jeden ermittelten way wegwirft,
                     - der nur einen der beiden nodes nutzt
                     - in welchem node und 'Nachbar' nicht benachbart sind
                     - der kein Flächen-, bzw. Grenz-Tag hat (+ nicht an 
einer Relation mit solchen Tags teilnimmt)

                 - für jeden way, der übrig bleibt,
                     - Fläche direkt ermitteln, falls way getaggt
                     - Fläche indirekt (boundary, multipolygon, etc.)  
ermitteln, falls way Mitglied mind. einer Relation

                 - Ergebnis:  alle Flächen, die dieses Segment (zw. node 
und Nachbar) als Grenze nutzen,
                                     egal ob Fläche durch Grenzsegmente 
definiert ist, oder basisgeometrisch vorhanden ist

         im Fall (2) dadurch gegeben, dass man sich diesen _einen_ way 
hernimmt und
                 - alle Flächen indirekt (boundary, multipolygon, etc.)  
ermittelt, da way Mitglied mind. einer Relation

                 - Ergebnis: alle Flächen, die dieses Segment als Grenze 
nutzen

Man sieht, dass der Bezug in beiden Fällen ermittelbar, aber im Falle 
von (2) wesentlicher einfacher ist und, das ist fast noch wichtiger, 
_ohne_ overlapping ways auskommt.  Übrigens lässt sich die Wichtigkeit 
des Grenzsegments (way segments) feststellen, indem man zählt an wie 
vielen Flächengrenzen es teilnimmt.

--------------------------------
Das Problem der Definition von Flächen über ihre Grenzen mittels 
multipolygon ist, dass _jede_ Fläche als multipolygon definiert werden 
muss.  multipolygon verhält sich an der Stelle viral.

Multipolygone vertragen sich mit basisgeometrischen Flächen nicht, weil 
letztere in OSM einen "closed way" erfodern.  Eine basisgeometrisch 
erfasste Fläche (beF) kann also in einem multipolygon nur dann verwendet 
werden, wenn die gesamte Grenze der beF in das multipolygon aufgenommen 
wird.  Beispiel:

     - zwei Flächen, welche vorrangig wohnbebaut sind, sind als bef 
erfasst und grenzen direkt aneinander
     - Möglichkeiten, die Gesamtfläche explizit, aber redundanzfrei zu 
erfassen:

             - overlapping way auf den nodes der außenliegenden 
Flächengrenzen ("hässliche" Repräsentation, siehe oben)

             - multipolygon mit den außenliegenden Flächengrenzen als 
"outer" member
                 -> nur, wenn "closed way" der beF gesplittet wird
                 -> bzw. beF in ein multipolygon gewandelt wird

--------------------------------
Soviel zur Datenhaltungsfrage.  Insbesondere administrative Flächen 
werden momentan in OSM bis zur Gemeindegrenze, teilweise noch etwas 
tiefer, über multipolygon-Relationen erfasst, indem Methode (2) 
verwendet wird (ein way, eine Grenze, die aber mehrere Flächen 
begrenzt).  Siehe

http://wiki.openstreetmap.org/wiki/Relation:boundary#Relation_Tags

Weiterhin wird in D nicht, wie noch in manchen anderen Ländern üblich 
type=boundary in der boundary-Relation gesetzt, sondern 
type=multipolygon, weil man erkannt hat, dass type=boundary nichts 
anderes ist, als (type=multipolygon  boundary=administrative)

http://wiki.openstreetmap.org/wiki/Talk:Relation:boundary#Use_type.3Dmultipolygon_instead

--------------------------------
Hätte man die nationale Fläche basisgeometrisch erfasst, hätten wir in 
jedem Grenzsegment 'zig overlapping ways.  Dennoch ist es falsch zu 
glauben, dass auf diese Weise mehr Daten geladen würden, als nötig, wenn 
ich nur die dt. Grenze vom Server ziehe.  Ich ziehe ja nur einen way, 
nicht alle overlapping ways.  Selbst Software, die beim Laden eines 
Bereichs alle overlapping ways zieht, würde damit nicht alle Flächen in 
D laden, sondern nur alle jene, die das Grenzsegment verwenden.  Ganz 
offenbar sind es nicht nur technische Gründe, die hier bei der Wahl der 
verwendeten Struktur eine Rolle gespielt haben, sondern hauptsächlich, 
dass Multipolygone die Realität der Flächenbezüge besser abbilden, als 
overlapping ways.

--------------------------------
Die Erfassung admin. Flächen wurde also über die Erfassung der Grenzen 
gelöst und technisch mit multipolygonen umgesetzt.

Sollten wir also für landuse, statt den Fokus auf die Erfassung der 
Fläche an sich zu richten, nicht auch lieber deren Grenzen erfassen?

     Schließlich ist eine Flächennetzwerk (sprich Bezüge) auch in der 
Flächennutzung erkennbar,
         (die Flächenhierachie bei admin. Flächen ist ein Spezialfall 
eines Flächennetzwerks):

         ** landuse=residential, landuse=commercial, landuse=road, 
landuse=industrial
             *** landuse=<subtag> <subtag>=manufacturing, mining, 
agriculture, etc.

         ** landuse=settlement
             *** landuse=residential, landuse=commercial, landuse=road, 
landuse=industrial
             *** but NOT  landuse=<industrial> <industrial>=mining, 
quarrying, etc.

     Ein Flächennutzungsnetzwerk abzubilden, bringt ähnliche Probleme, 
wie die Flächenhierachie der Administration abzubilden.  D.h. aber, dass 
die bestehende Lösung dort wiederverwendet werden kann.

--------------------------------
Die kleinsten Elemente dieses Netzwerks werden nach wie vor durch die 
allg. Definition gebildet:

         landuse  erfasst  die vorrangige, reale Nutzung einer Fläche

Nur die technische Umsetzung wäre dann die von admin. Flächen:

         * Grenzsegmente (border=landuse) einer durch den Menschen 
genutzten Fläche bilden eine Multipolygon
         * tagge das Multipolygon

--------------------------------
Damit könnte man sehr viele Datennutzer zufriedenstellen, umgekehrt 
würde OSM sehr viele Leute einladen, die bisher nicht gesehen haben, wie 
sie ihre Art von Daten mit OSM erfassen können.

Aber es ist auch ein großes Wagnis:  viele fürchten sich vor 
Multipolygonen, sprich Relationen - leider..
Viele lehnen Relationen aus den gleichen Gründen ab, wie aneinander 
geklebte, "overlapping" ways:  zu kompliziert, heißt es dann.
Evtl. lässt sich hier durch gute Dokumentation und noch besseren / 
einfacheren Editorsupport für multipolygons (Sammlung von 
Vieleckgrenzen) viel tun.

Gruß
Christian