Hallo Liste Als ich vor einigen Jahren bei OSM angefangen habe, war die Welt noch einfach. Man erfasste Straßen und ihre Namen, dazu noch ein paar POIs - fertig! Viel Diskussionsbedarf bestand nicht, wenn man sich auf die einzelnen Keys geeinigt hatte.
So einfach ist es heute aber nicht mehr. Die Komplexität der OSM-Welt nimmt ständig zu. Wer sich heute mal eine Innenstadt in JOSM anschaut, weiß was ich meine. Da gibt es neben den Straßen und POIs viele andere Dinge, die in der Karte zu sehen sind. Landflächen, Plätze, Buslinien, Grenzen, Brücken, Stromleitungen, Tunnel und und und... Wer in so einem Gebiet wirklich nur eine Kleinigkeit ändern möchte, muss höllich aufpassen, das er keine Relationen beschädigt, Straßen mit Flächen verbindet, Maxspeed löscht oder auf eine falsche Straße ausweitet, "Löcher" in Wanderrouten erzeugt und so weiter. Man muss sich immer mit der sonstigen Verwendung der Elemente vertraut machen, um nicht die Arbeit der Anderen zu stören oder zu beschädigen. Oder man aggiert nach dem Motto "Augen zu und durch", "Wird schon schiefgehen" oder "Die Fehler die ich mache wird schon jemand richten". Wer sich mal mit der Pflege von Boundarys, ÖPNV-Relationen oder sonstigen komplexeren Dingen beschäftigt hat, weiß ein Lied davon zu singen. Durch dieses Dilemma entstehen verschiedene Probleme: 1. Der Einstieg in das Thema OSM wird immer komplizierter. "Mal eben eine fehlende Straße einzeichnen" - so wie es früher war - funktioniert nur noch im Niemandsland. 2. Immer mehr Energie wird in die Pflege/Reparatur der Daten aufgewendet. 3. Ein sinnvolles Bearbeiten ist nur noch durch wenige Experten möglich. 4. Importe werden sehr kompliziert. - Gespendete Daten müssen mit größter Vorsicht oder händich eingefügt werden. Wie kann man das Lösen? Einfach zu lösen ist dieses Problem mit Sicherheit nicht. Momentan versuchen wir Fehler passiv zu vermeiden. Damit meine ich, dass die Editoren, wie JOSM, vor möglichen Fehlern warnen, bspw wenn eine Relation geteilt, eine Straße verschoben oder Straßen mit verschiedenen Eigenschaften verbunden werden. Eigentlich müssten JOSM und Co noch viel mehr Fehler abfangen, damit diese gar nicht erst in die Datenbank kommen. Dadurch wird das Editieren zwar sicherer, jedoch nicht einfacher. Es kann also nur eine Teillösung sein, beseitigt jedoch nicht das Grundproblem. Was ist das Grundproblem? OSM ist monolithisch! - Alles ist miteinander verknüpft und verwoben. Eine kleine Änderung kann große Wirkung haben und Bereiche oder Sachverhalte ändern, die man gar nicht verändern wollte. Was fehlt, ist die Modularität! Modularität? Wäre OSM (bzw. die OSM-Datenbank) modularer aufgebaut, beziehungsweise wären Elemente modular zu bearbeiten, so könnten andere "Baustellen" komplett ausgeblendet werden. Man hätte ein festes Grundgerüst und darauf die einzelnen Module, die man je nach Absicht voneinander unabhängig benutzen könnte. "So einfach, wie es sich anhört, ist es nicht zu realisieren!" - Stimmt, einfach ist es wirklich nicht, aber wie könnte es aussehen? Das Grundgerüst wären die Nodes. Sie halten die einzelnen Module zusammen. Node 1234567 bleibt node 1234567, egal in welchem Modul. "Aber was ist mit Ways?" - Ways sind in der Datenbank momentan ein Sonderfall. Sie beschreiben zum Beispiel einen Weg, indem sie die verwendeten Nodes auflisten. Damit unterscheiden sie sich eigentlich nicht viel von Relationen. Eine Relation ist eine Sammlung verschiedener, zu einander in Verhältnis gebrachter, Elemente. Genau das macht auch der Way mit den Nodes. Also - weg mit dem Datenelement "way", ist ja doch nur ne verkappte Relation. "Da blickt doch dann keiner mehr durch?" Diese Angst habe ich nicht. Es ist nur eine Frage der Visualisierung. Da sich beim Thema "way" fast nur der Name ändert, dürften die Unterschiede gering sein. Wenn ich an die Abschaffung der "segments" im Oktober 2007 zurückdenke, erinnere ich mich, dass das für den Anwender eine sehr leichte Umstellung war. Warum sollte es in diesem Fall anders sein? Dieses war der erste Streich! Wie könnte es aussehen, dass mit den Modulen? Momentan ist JOSM ein Rohdaten-Editor. Es lässt sich alles ändern und das meiste wird visualisiert. Nicht alles, da viele Relationen nur als Tabellenansicht zu sehen sind und nicht oder nur nach dem Markieren auf der Karte gezeichnet werden. Könnte man jedoch vor dem Editieren auswählen, welches Themengebiet man bearbeiten möchte, so wäre JOSM ein Spezialeditor für alle Module, die es unterstützt und würde trotzdem nichts an Funktionalität verlieren. JOSM würde fragen: "Was möchten sie Bearbeiten und sehen?" Man bekäme eine Auswahl geliefert, in der man wählen könnte, welche Module editierbar sind und welche nur optisch erscheinen. --------------------------------------------- | Modul | editierbar | sichtbar | --------------------------------------------- | Straßen | o | x | --------------------------------------------- | Landnutzung | o | x | --------------------------------------------- | Gebäude | o | o | --------------------------------------------- | Routen | o | o | --------------------------------------------- | Grenzen | x | x | --------------------------------------------- | ÖPNV | o | o | --------------------------------------------- So könnte es zB aussehen, wenn man plant, Grenzen zu bearbeiten. Natürlich sind viele weitere Module aber auch eine weitere Unterteilung oder Untermodule denkbar. Es muss natürlich feste Regeln geben, wie mit gemeinsam genutzten Elementen zu verfahren ist, welche Module auf anderen Modulen aufbauen und so weiter. So darf natürlich ein node, der in einer Relation verwendet wird, nicht gelöscht werden. Diese Regeln auszuarbeiten ist keine zu unterschätzende Aufgabe, da dadurch die Stabilität gewährleistet wird. Momentan fehlen diese Regeln fast komplett, was u.a. zu den Eingangs beschriebenen defekten Relationen führt. Nur JOSM oder was? Dieses Konzept ist auf alle Editoren anwendbar. Dabei ist auch vorstellbar, das es Editoren gibt, die nur eine festgelegte Modulauswahl unterstützen, zB Seezeicheneditor oder nur eine Teilauswahl zB Potlatch, der Routenrelationen komplett ignoriert. Ich denke, diese Idee ist zumindest wert, dass man mal darüber nachdenkt. Nun eure Meinung zu dem Thema: Seht ihr die Eingangs beschriebenen Probleme genau so? Glaubt ihr, dass man die Probleme mittelfristig lösen muss? Was haltet ihr von der (Pseudo-)Modularisierung? Habt ihr eine andere Lösung? Hoffe, verständlich gewesen zu sein Torsten - ein Theoretiker _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
