[Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel

[Christian Müller]

Hi Martin,


um zu sehen, was ich mir so als Ziel vorstelle, kannst Du in JOSM mal 
den Bereich

	12.3168755,51.2102240,12.3196864,51.2111313

laden..


Aber bitte genau diesen, ansonsten ist es schwer zu verstehen, was genau 
die Vorteile von multipolygons beim Mappen der Bodennutzung sind.

Es ist mit JOSM gar nicht sooo schwer, ein bestehendes Gebiet zu 
"konvertieren", mir sind aber auch viele usability Aspekte aufgefallen, 
die den Weg hin zu multipolygonen erschweren bzw. versperren..

Wie auch immer, das Gebiet soll erstmal nur praktisch illustrieren, 
wovon ich überhaupt rede..  Was sollte an dem Beispiel zu sehen sein:


   - Vorteil der Datenhaltung: Beim Laden des Gebietes, erhalte ich nur 
die Flächengrenzen und nicht mehr gleich _alle_ Flächen, die das Gebiet 
schneiden.

   - keine Overlapping Ways: es gibt eine Flächengrenze, klickt man 
diese an, sieht man, wieviele und welche Flächen sie begrenzt

   - ist eine Fläche noch nicht komplett geladen, braucht man, für JOSM, 
nur Rechtsklick aufs Multipolygon > unvollständige Elemente laden

   - auch einfache Fälle als multipolygon  (die landuse=meadows links)

   - Für jede Flächengrenze (way) ist sofort ersichtlich /welche/ 
Flächen geändert werden, wenn die nodes der Flächengrenze verschoben werden
     -> das ist für overlapping ways oft nicht der Fall, gerade wenn 
diese auf Wegen außerhalb der bbox entstehen, oder wenn in JOSM Objekte 
auf der Basis von IDs geladen werden - ich erhalte dann eine komplette 
Fläche (closed way), ohne evtl. zu sehen, welche Flächen beeinflusst 
werden, wenn ich einen Knoten verrücke.

   - Verschachtelung:  Die Multipolygon meadows auf der linken Seite 
nehmen am "Imnitzer Park" in der Rolle "inner" Teil, sind aber selbst 
völlig autark lad- und bearbeitbar.  Über die Elternrelation kann aber 
eine Lagebeziehung zu "gröberen Gebieten" ermittelt werden.

   - Genauso umgekehrt: Der Imnitzer Park ist als Fläche ohne Kinder 
interpretier- und ladbar  (es ist denkbar, dass man die inner-Elemente 
z.B. beim Rendering oder anderweitigen Verarbeiten einfach ignoriert 
werden, und nur "outer" in Betracht gezogen wird).  Falls man sich für 
"extreme Nutzungsänderungen" innerhalb einer gemappten Fläche, die 
"überwiegend" als Park genutzt wird, interessiert, betrachtet man 
einfach die inner-Elemente der Parkfläche..  fertig  (ein Datennutzer 
kann also entscheiden, wie weit er granulieren möchte, bzw. ab welchen 
Flächengrößen er nicht mehr im Multipolygon-Netz hinabsteigen möchte).


Diese Beispieldaten sind für die Geschichte mit den 2/3 Häusern im Wald 
übertragbar und auch auf die Geschichte mit dem Bäcker im Wohngebiet:

(Beispiel -> Situation Haus im Wald):

	(Imnitzer Park multipoly  ->  landuse=forest)
	(landuse meadow children ->  mini-residentials im forest)

(Beispiel -> Situation Bäcker im Wohngebiet):

	(Imnitzer Park -> landuse=residential)
	(landuse meadow children -> tiny-commercials im residential)


Nochmal, mir ist klar, dass das flächendeckend momentan nicht umsetzbar 
ist, dazu müssten Editoren multipolygons mehr in den Kern ihrer 
Editierfunktionalität rücken und nicht als Extra am Rand liegen lassen.

Dennoch ist es gar nicht so schwer, etwa eine Fläche einzufügen, wenn 
man diese Daten hat.

	- neue Grenze zeichenen
	- neues Multipolygon erstellen und taggen
	- alte Flächenbeziehungen umdefinieren (häufig nur eine Fläche)


Für mich liegen die Vorteile auf der Hand, und wenn man die Beziehung 
Flächen - Flächengrenze einmal verstanden hat, ist es auch wesentlich 
einfacher, so zu editieren, als mit zig tausend ways, overlapping oder 
nicht, parallel oder nicht..  .. und das betrifft auch Änderungen - oft 
wird argumentiert, es sei schwerer Gebiete mit viel Beziehungen 
untereinander zu ändern - dabei ist es wirklich nur anders.

Wenn jemand z.B. einen neuen closed way in ein Multipolygon einfügt und 
mal vergisst, dieses als "inner" in ein bereits gröberes Gebiet (outer) 
einzutragen, ist das ja kein Beinbruch.  Irgendeinem anderen Mapper wird 
das schon auffallen, der das dann fixed.  Dieser verbindet dann 
MICROgemappte Daten mit MACROgemappten..


Übrigens:  Auch immens große Flächen lassen sich damit im Detail und 
ohne großen Fehler editieren, indem man sich einfach nur auf das 
relevante Grenzsegment fokussiert.  Genauso, wie derzeit Radrouten 
editiert werden - da befasst man sich i.d.R. auch nur mit 
Streckenabschnitten.

Routen sind tatsächlich eine gute Analogie:  auch hier wird von 
Basismappern oft durch Editieren der Basisgeometrie eine Relation 
kurzzeitig unbrauchbar..  ..die dann jemand, der sich mit der Route 
beschäftigt, wieder fix'd.  Gleiches funktioniert für Flächen, die über 
Multipolygone abgebildet werden.  Validatoren zeigen dabei Fehlerflächen 
schnell und unkompliziert auf..


Der Schlüssel für die multipolygon-Akzeptanz ist m.M.n. eine höhere 
Editorintegration.  Das fängt schon damit an, dass multipolygone neben 
anderen Relationen in einer Liste stehen.  Und das hört dort auf, dass 
ich zwar einen "closed way" als Fläche im Mapview selektieren kann, aber 
kein multipolygon (obwohl das auch nur eine Fläche ist).  Da ließe sich 
noch so einiges verbessern..


Einem Mapper der mit Flächennetzwerken anfangen möchte, würde ich 
Folgendes raten:  Fokus weg von der Fläche, Fokus hin zur Flächengrenze.

Im Endeffekt wird dadurch die Erfassung der Daten einfacher, besonders 
auf lange Sicht.


Gruß