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