[Talk-de] Einige Gedanken zu OSM - Datenbanken nicht croudsource-fähig?

Mi Mär 10 10:31:51 UTC 2010

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