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

Christian Müller cmue81 at gmx.de
Do Sep 29 14:15:27 UTC 2011


Am 29.09.2011 02:02, schrieb Garry:
> So einfach ist das leider nicht. Mein Standpunkt ist das die 
> highway-ways in erster Linie Routingdaten sind die nichts direkt mit 
> Flächendaten zu tun haben -

Also wenn ich eine Fläche als MP erfasse und eine Flächengrenze ein 
highway ist, hat der highway doch nur /in/direkt etwas mit der Fläche zu 
tun.  Das siehst Du doch schon daran, dass die Flächentags an das MP 
vergeben werden und nicht an den highway.


> mit der wesentlichen Aussage dass (landuse-)Flächen nicht mit 
> highways, sondern nur mit den Flächendaten der Strasse
> (also dann highway= road)verknüpft werden dürfen.

Meines Wissens gibt es dazu keinen Konsens.  Und wie wir stets 
feststellen, ist es mit einem "nicht [...] dürfen", also einem Verbot 
aus dem Wunschdenken eines einzelnen heraus, nicht getan.  Wenn Du es 
umformulierst und schreibst, Flächendaten sollten wiederum mit 
Flächendaten verknüpft werden, klingt das, so als Empfehlung, schon besser..

Außerdem hoffe ich, Du meintest hier:  landuse=road ..   highway=road 
als area gibt es schon und meint etwas anderes (und zwar die 
/Verkehrs/fläche eines unbestimmten Straßentyps)

Evtl. könnte man wieder versuchen, das Argument ins Feld zu führen, dass 
Routing-Layer und Landuse-Layer getrennt voneinander bearbeitbar sein 
sollten, damit die einen nicht die Arbeit der anderen kaputt machen - 
ich empfände eine solche strikte Trennung dann aber auch etwas 
künstlich, weil dann die einen von der Arbeit der anderen auch weniger 
profitieren können (wenn ich als Flächenerfasser, keinen highway als 
Flächengrenze benutzen darf, muss ich sie neu erfassen).

Wohlgemerkt hat der Wunsch nach getrenntem Editing nichts damit zu tun, 
dass Routing- und Landuse-Layer sonst nicht zu trennen wären.  Ließe man 
die Daten weiterhin verknüpft, benutzt also highways als Flächengrenzen, 
ist es überhaupt kein Problem, Routing- und Landuse-Layer 
auseinanderzuhalten, ja sogar sie getrennt zu erzeugen, z.B. mit Osmosis 
(indem einfach nach Tag landuse=* inkludiert oder exkludiert wird).

Noch eine Bemerkung zu den vielen Beschwerden über Flächenedits, welche 
den "Routing-Layer" verunglimpfen.  Oft ist das auch wieder ein Editing 
Problem - z.B. habe ich "in the wild" erlebt, wie durch 
Editing-Features, die eigentlich der Bequemlichkeit dienen, Wege mit 
Flächenstil weitergezeichnet wurden, die vorher schon längst geschlossen 
waren - oder umgekehrt:  Flächen erzeugt wurden, indem ein bestehender 
/highway/ zu einem closed way verlängert, dann aber nicht getrennt und 
extra getaggt wurde - da gibt es dann Wege auf Flächengrenzen, die gar 
nicht existieren.  All das ist aber kein Grund, die Flinte ins Korn zu 
werfen und zu meinen:  "kill the convenient editing-features".  Es wird 
immer Leute geben, die sich im Lernprozess befinden oder etwas besonders 
schnell erledigen, und auf diese Weise editing-features so benutzen, 
dass etwas Unerwartetes dabei herauskommt.  Damit muss man leben, ich 
würde da keinem Mapper Absicht unterstellen.

Gleichfalls bin ich nicht der Meinung, dass wir aufgrund dessen, das 
andere "Fehler" in die eigenen Daten bringen können, versuchen sollten, 
wo es nur geht, Abhängigkeiten zu reduzieren, bis wir zum Schluss bei 
der Regel angelangt sind:  "jeder darf einen Node setzen, aber nicht 
dort, wo schon einer ist."

Das OSM-Technotop macht doch schon vor, wie es richtig geht:  Analyzers 
und Tools schreiben, welche die Daten validieren, und Fehledits 
"entdecken" - das dann fixen.  Für letzteres braucht man eine 
Vorstellung davon, /wie/ ein optimales Abbild aussieht und auch nur 
damit kann eigentlich ein Validator geschrieben werden.  Die Probleme 
bei der Verwendung von closed/overlapping ways bei der Flächenerfassung 
wurden in den letzten beiden Monaten auf dieser Liste zur Genüge 
dargestellt.  Nun kann man sich fragen, ob es sinnvoll ist, einen 
highway in einer bestimmten Rolle eines MP zu verwenden, oder nicht.  
IMHO spricht nichts dagegen.

Wobei ich mit Dir einer Meinung bin, dass /wenn/ ein landuse=road 
vorhanden ist, oder eingezeichnet wird, die Flächengrenze dieses 
landuses wiederverwendet werden sollte, um die nächste Fläche 
anzudocken, und nicht die highway-Linie.  Falls zu diesem Zeitpunkt im 
MapView schon ein landuse=* an den highway grenzt, legt man das eben um 
- das ist mit MPs wesentlich einfacher, als wenn die Flächen über closed 
ways erfasst sind, weil nur Mitgliedschaften geändert werden müssen, und 
keine basisgeometrischen Wege gelöscht/geändert werden müssen (was 
fehleranfälliger wäre).


> Wenn ich etwas ergänzen/die Genauigkeit verbessern möchte dann sollte 
> das dadurch möglich sein dass ich vorhandenes idealerweise einfach
> nur etwas zurechtrücken muss ohne in eine Struktur einzugreifen mit 
> der ich mich erst intensiv auseinandersetzen muss, einen komplexen 
> Editor benötige
> und einen grösseren Schaden durch kleine Fehler anrichten kann.
> D.h. eine Detailverbesserung an Flächen und Linien muss mit 
> Basisoperationen möglich sein ohne dass im Hintergrund ein komplexes 
> Programm arbeitet
> das tausende von Überprüfungen vornehmen muss um sicherzustellen dass 
> ich nicht irgendwelche Daten zerstöre die ich übehaupt nicht 
> bearbeiten möchte.

Deine Vorstellungen sind sehr vage und unkonkret - sie sprechen IMHO von 
den "Mythen" und "Legenden", die ich beschrieben habe.  Ich erkläre es 
mal so, let me rephrase it ..  :

         Du machst mit dem Verschieben einer Flächengrenze, die an MPs 
teilnimmt, nicht mehr oder weniger kaputt, als wenn Du einen closed way 
verschiebst - im Gegenteil, du musst Dir um Überlappungen und korrekte 
Geometrie viel weniger Gedanken machen, etwas zu zerstören, weil es die 
Flächengrenze nur _einmal_ und nicht zigtausend mal gibt.

         Das "komplexe Programm" im Hintergrund ist wesentlich 
einfacher, als Du es Dir vorstellst - weil die Fehler, die mit MPs 
entstehen können, verwaltbarer sind, als die, die durch obskure und 
verrückte Geometrieüberlappungen entstehen.  Letztere lassen sich 
teilweise programmatisch nicht einmal entdecken, weil viel schlechter zu 
errechnen ist, /was/ ein Fehler ist, und was nicht.  Das ist mit MPs 
eindeutiger und einfacher zu errechnen - siehe Relation Analyzer.

         Du musst von einer größeren Struktur nicht einmal wissen, um 
Detail zu bearbeiten - mit MPs ist es so, dass die Arbeitsschritte

             - Detail erfassen  und
             - Detail verbinden  (in Beziehung zueinander setzen)

         durchaus von völlig verschiedenen Mappern übernommen werden 
können.  Vergleiche nochmal die Analogie  "Rad-Route":

             Es kümmert den Mapper des Radweges (des highways) in der 
Regel herzlich wenig, ob eine neu erfasste Geometrie eine 
Rad-Routen-Relation zerstört.  Wenn er umsichtig ist, fixed er diese 
_nachdem_ er mit den basisgeometrischen Sachen fertig ist.  Falls nicht, 
ist die Relation broken, bis einem Mapper das auffällt, der das dann 
wieder in Ordnung bringt.  /Das/ ist die OSM-Mapping-Realität.

         Und so kann es auch mit Flächenstrukturen laufen.  Da muss man 
keinen Mythen hinterherlaufen, dass das komplexer und komplizierter 
wäre, als jede Fläche mittels "closed way" zu erfassen.  Die 
Unstrukturiertheit von "closed ways" ist ein viel größeres Problem, 
sobald man mehrere davon hat.


> Z.B. wenn ich eine Waldgebiet bearbeite möchte ich nicht einen 
> Jakobsweg zerstören, mich aber auch nicht damit befassen nur weil 
> dessen Verlauf nach einer groben Annäherung mit der Kante einer 
> Waldgrenze gekoppelt wurde. Hier entsteht also ein Konflikt durch 
> Kopplung der Daten wenn ich nur genaue Walddaten
> oder nur genaue Jakobswegdaten habe. Wenn ich nur eins von beidem habe 
> kann ich nichs an den Daten verbessern weil ich nicht garantieren kann
> dass ich den anderen Teil der Daten dadurch nicht verschlechtere.

Nehmen wir einmal an, das ist mit Relationen gemappt, die Daten sehen 
also so aus, _bevor_ Du zu mappen beginnst:

         - basisgeometrischer way #124 (highway=path,  foot=yes,  ...)
         - Relation Jakobsweg  (type=route route=rwn    members, #124, 
more_members)
         - Relation MP (type=multipolygon natural=wood     members als 
outer, #124 als outer, more_members als outer)

Nun stellst Du fest, dass die Waldgrenze nicht auf der kompletten Länge 
von #124 mit dem Jakobsweg identisch ist:

         - teile #124 so, dass meinetwegen #124, #245 entstehen
                 (auf dem node, an welchem sich Waldgrenze und Jakobsweg 
trennen)
         - #245 ist nicht identisch mit der Waldgrenze, also wird #245 
aus MP entfernt
                 (eine Lücke in der Relationsliste entsteht)
         - zeichne die Waldgrenze, die bis jetzt nicht existierte  (#250)
                 (verbindet  #124 mit #246)
         - füge #250 in MP ein

Es ist andere Arbeit, als einen node zu verrücken - aber Du drückst mit 
deinen Daten auch wesentlich besser den Sachverhalt, der vor Ort 
existiert, aus.  Wenn Du das ein paar Mal machst, wird es zur Routine 
und Du stellst nach einer Weile fest, dass das Mappen wesentlich flotter 
von der Hand geht, als wenn Du jedes Mal Streckenzüge im MapView 
komplett neu zeichnest.

Mapper müssen sich IMHO daran gewöhnen, dass je "voller" die DB wird, 
desto "entfernter" ist das Arbeiten mit den Daten gegenüber einer 
"weißen Fläche" - es rückt mehr das /Verwalten/, /Umlegen/ und /in 
Beziehung setzen/ bestehender Daten in den Vordergrund, als das "neu 
zeichnen" von Daten.  Es nützt nichts, auf Gedeih und Verderb zu 
fragmentieren und künstlich die Erfassung von Grenzen zu verhindern, wo 
tatsächlich welche sind:  "Jede Grenze ist _exakt einer_ Fläche 
zuzuordnen" ist kein Modell der Realität - "Jede Grenze trennt/verbindet 
mindestens zwei Flächen" aber schon.

Brainstorming:  Evtl. kann hier ein Editor auch einiges leisten, indem 
wir uns z.B. vorstellen, dass wir MPs mit dem was da ist /zeichnen/.  
Das also, indem über bestehende Wege "gemalt" wird, ein MP 
erzeugt/geändert wird, anstatt neue Knoten zu setzen.  Wir "malen" dann 
sozusagen keinen "closed way" neu und auch keinen "overlapping way" über 
bestehende nodes, sondern eine MP-Relation über bestehende ways.

Letzteres kann ein Kombitool sein, dass dort, wo tatsächlich nichts ist, 
einen way erzeugt, der dann gleich mit in die MP-Relation aufgenommen wird.

In JOSM hatte jemand vor nicht allzu langer Zeit ein Tool entwickelt, 
mit dem das Zeichnen von overlapping ways einfacher wurde - die Idee 
war, Folgeknoten per Tastendruck an den neuen Weg anzufügen, indem der 
alte, unterliegende Weg, durchlaufen wird und die gefunden Knoten-IDs an 
den zu zeichnenden Weg angefügt werden.  Das hat die Erfassung von 
Flächen wesentlich vereinfacht, wenn man darauf aus war, sie als 
overlapping way zu erfassen - es mussten nicht mehr alle Knoten eines 
Weges repetitiv angeklickt werden, sondern es reichte wiederholt die 
Taste zu drücken, um den alten Weg zu "tracken".

Wäre es nicht viel besser, Flächen (oder von mir aus auch allg. 
Relationen) so "bauen" zu können, dass man die gewünschten 
Flächengrenzen eines MP nacheinander anwählt (oder auch abwählt), um es 
zu modifizieren?  Das geht mit JOSM dato über einen kleinen Umweg - die 
Selektionsmenge - dazu muss ich:

         - alle ways der Relation selektieren
             - kann dann mit Strg an- und abwählen, was Grenze der 
Fläche sein soll
         - .. und beende das ganze, indem die Selektionsmenge neue 
way-Menge der Relation wird

Allein das sieht nicht jeder.  Ein direkterer Weg wäre, die Relation 
auszuwählen (in JOSM werden dann im MapView all ihre Mitglieder magenta 
gefärbt), um dann im MapView mit Strg die Mitgliedsmenge beeinflußen zu 
können.

Das ist, wenn ich Garry richtig verstanden habe, das ganze Problem.  MPs 
und Relationen werden auf andere Art und Weise (über den 
Relationen-Dialog) beeinflusst, als die Basisgeometrie, die sich direkt 
im MapView ändern lässt.  Ein visuelles Feedback der Änderung einer 
Relation erhält man momentan nur, indem die Relation nach Bearbeitung 
ausgewählt, und damit ihr neues Mitgliederset im MapView wieder magenta 
gefärbt wird.  Dieser editing-cycle ist, verglichen zum 
basisgeometrischen, sehr lang.  Aber nur deswegen erscheint MP als 
Flächentool kompliziert.


Gruß
Christian




Mehr Informationen über die Mailingliste Talk-de