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

[Christian Müller]

Hi,


Am 15.09.2011 15:30, schrieb Martin Koppenhoefer:
> Am 15. September 2011 12:01 schrieb Martin Koppenhoefer
> <dieterdreist at gmail.com>:
>> b) gab es mal (convert to multipolygon), ist aber irgendwie wieder aus
>> meinem JOSM verschwunden. (Vielleicht ein plugin, das ich
>> deinstalliert habe? Weiss jemand näheres?). Was es gibt ist SHIFT+A ->
>> create multipolygon, dabei werden allerdings ausser type=multipolygon
>> keine Tags gesetzt.
>
> Das b) gibt es: ist ein Plugin für JOSM und heisst multipoly-convert.

Hm, mir war es nicht gegenwärtig, Du musstest danach suchen und 
nachprüfen.  Außerdem ist es nur ein Plugin und es bezieht sich nur auf 
JOSM - wie sieht es z.B. in Potlatch aus?
Das multipoly-convert als DAS Flächentool wahrgenommen wird, dürfte 
damit fast ausgeschlossen sein..

Da ist das Verständnis von "overlapping ways" als Kernfunktionalität bei 
der Flächenerfassung wesentlich ausgeprägter - leider..  Es ist doch 
viel einfacher (und vordergründig intuitiver), wenn man Flächen/Gebiete 
auf bestehenden Daten erfassen will, einfach einen overlapping way zu zu 
zeichen und den zu taggen, anstatt sich mit der aufwendigen Erstellung 
eines multipolygons zu beschäftigen:  Dazu muss ich erstmal wissen, dass 
ich multipolys allgemein für die Erfassung jeder Fläche verwenden kann.  
Dann brauche ich ein grobes Verständnis von Relationen und, weiter, ich 
muss wissen, welche Werkzeuge des Editors, bzw. noch schlimmer, Plugins, 
benötigt werden, um komfortabel mit ihnen umzugehen.

Multipolygon Features müssten Kernfunktionalität werden.  Bis zu einem 
Punkt, wo es Joemapper (fast) gar nicht mehr auffällt, dass er es mit 
multipolys zu tun hat - denn erst dann werden sie nicht mehr von den 
meisten/vielen MapperInnen links liegen gelassen oder als 
Nerd-Spezial-Spielzeug abgetan..  Das Konvertieren zw. Multipolys und 
Flächen sollte im Endeffekt gar nicht notwenig sein, weil jede Fläche 
ein Multipoly /ist/.  Um da hinzukommen, müssen Editoren 
"multipoly-aware" arbeiten, d.h. dem Mapper viele Schritte, die er jetzt 
manuell macht, abnehmen.  Es muss "inuitiv" sein, multipolys zu 
verwenden.  So "intuitiv", wie einen closed way zu zeichnen.

=================================
An welchen Flächen eine Flächengrenze teilnimmt, ist mit overlapping 
ways, wie oben erwähnt, durch Rotieren möglich:

     Nacheinander selektiert der Editor alle Flächen, die an der 
Flächengrenze beteiligt sind.

Vgl. dazu multipoly:

     Ich selektiere die Flächengrenze und schaue in die Liste /aller/ 
Relationen, ob es Flächenrelationen gibt, und wenn ja welche.
     Um eine Fläche auszuwählen, selektiere ich die entsprechende 
multipoly-relation.

Usability-technisch dürfte zwischen beiden eigentlich gar kein 
Unterschied bestehen, denn in beiden Fällen wird der gleiche Sachverhalt 
modelliert, auch wenn die Daten/haltung/ leicht anders ist.

Overlapping ways sind keine echte Alternative zu Multipolys.  Es ist 
zwar der gleiche Flächenbezug modellierbar (obwohl er bei overlapping 
ways schwieriger zu ermitteln ist), aber beim Schnitt von Daten mit 
einer bbox sind "overlapping ways" "pure evil".  Das Problem ist, dass 
alle overlapping ways geladen werden, sobald ein Wegknoten innerhalb der 
bbox liegt.  Beispiel dt. Grenzen:

     - die Nation, die Bundesländer, die Kreise, die Gemeinden sind ohne 
weiteres durch  "overlapping ways" abbildbar
     - nun werden die Daten einer -sehr kleinen- bbox geladen, durch 
welche die Bundesgrenze verläuft  (z.B. bei Görlitz)

     - Resultat:
         - es wird der "closed way" der kompletten Bundesfläche geladen 
(der "closed way" ohne Flächeninhalt ist die Grenze)
         - es wird der "closed way" der kompletten Fläche des 
Bundeslandes geladen
         - es wird der "closed way" der kompletten Fläche des Kreises 
geladen
         - es wird der "closed way" der kompletten Fläche der Gemeinde 
geladen
         - im Editor sehe ich dann alle Flächen, deren Flächengrenze 
sich bei Görlitz "überlappt"

     -> mich interessierte doch aber eigentlich nur das Segment der 
Flächengrenze, welches innerhalb der BBOX lag, nicht die Flächen

     - weil die Bundesfläche sehr groß ist - so groß, dass bereits der 
/way/ ihrer Flächengrenze zu umfangreich ist, als das er bei jeder 
BBOX-Anfrage im Grenzgebiet geladen werden könnte, erfasst man also 
nicht die Fläche, sondern die Flächengrenze
     - lädt man nun die gleiche BBOX, passiert folgendes

     - Resultat:
         - es wird ein "way" geladen, ein Flächengrenzsegment, auf dem 
Bundes-, Kreis- und Gemeindegrenze überlappen
         - zusätzlich werden die Relationen Bundes-, Kreis- und 
Gemeindegrenze geladen
         - letztere sind alle "unvollständig" - für jede der Relationen 
sind nur die /ways/ (Flächengrenzsegmente) geladen, die innerhalb der 
BBOX liegen


     Analoges gilt eigentlich für das restliche Flächennetzwerk.  Man 
stelle sich eine Siedlungsflächengrenze als "closed way" von Berlin vor 
und einen kleinen landuse=residential am Rande Berlins.  Beide haben ein 
gemeinsames Grenzsegment.  Wenn ich die BBOX des kleinen 
landuse=residential lade, interessiert mich die riesige Siedlungsfläche 
Berlins herzlich wenig - deren Grenze würde aber mit über die Leitung 
geschwappt kommen  (wenn sie eben nicht als multipoly erfasst wird).   
The thing is.., dass ich das außenliegende Grenzsegment des 
landuse=residential nur dann ins Flächennetzwerk einbinden kann, wenn 
auch dieser als multipoly erfasst wird.    Diesen Sachverhalt hatte ich 
in der Datenhaltungsmail als "virale" Eigenschaft von multipolygons 
bezeichnet.

=================================


Es nützt 'uns' auch nichts, wenn multipolygons nur in einem Editor gut 
als Flächentool umgesetzt sind und dann allen anderen, die andere 
Editoren nutzen, ausgeschlossen werden.  Das führt dazu, was Garry schon 
ansprach:  Angst vor Fehlern, Angst vor versehentlichem Zerstören, etc. 
im Zusammenhang mit Multipolys - in letzter Instanz wird dann, selbst 
wenn ein Editor das gut umsetzt, die community davon Abstand nehmen, 
weil die Zusammenarbeit mit Nutzern anderer Editoren scheitert, bzw. 
problematisch ist..

Da bin ich mir deshalb so sicher, weil das mit "overlapping ways" schon 
so ist:  Die werden von Potlatch2 UND JOSM (siehe Doku der Editoren) 
unterstützt.  Allein, dass in JSOM das Handling ein Stück weit einfacher 
ist (Mittelklick oder Rotation durch overlapping ways durch wiederholte 
Klicks), als in Potlatch2  (Rotation durch Tastenkombination, die nicht 
jeder kennt, und die auf manchen Keyboards/in manchen Browsern nicht 
verfügbar ist)  teilt die Gemeinde in zwei Lager..


Gruß
Christian