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ß
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
