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

[Torsten Breda]

Am 10. März 2010 13:06 schrieb Frederik Ramm <frederik at remote.org>:
> Hallo,
>
> Torsten Breda wrote:
>> Das Grundgerüst wären die Nodes. Sie halten die einzelnen Module
>> zusammen. Node 1234567 bleibt node 1234567, egal in welchem Modul.
>
> Machst Du es Dir da nicht zu einfach - es koennte doch sein, dass der
> Node 1234567 im Modul "Deutschland vor 100 Jahren" gar nicht auftaucht ;-)
Dann taucht er halt nicht auf. Ist das schlimm?

>
>> 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 hat schon ein (per default abgeschaltetes) Filter-Feature, mit dem
> man genau das machen kann, bestimmte Sachen ausblenden oder
> un-editierbar machen.
Wie komme ich da ran? Das Ghost-plugin funktioniert (zumindest bei
mir) mit der latest nicht mehr.

>
> Es gibt aber eine Menge Usability-Probleme, egal ob man das auf
> Editorseite oder, wie von Dir vorgeschlagen, auf Datenbankseite macht.
> Was zum Beispiel passiert, wenn ich in einem Modus arbeite, in dem nur
> Strommasten sichtbar sind und ich einen Strommasten versehentlich auf
> amenity=restaurant umtagge - wie kriege ich den dann jemals wieder? -
> und aehnliche Dinge.
So wie bisher.
Falls ich aber gerade in einem Spezialeditor arbeite, kommt eine
Warnung "Bist du sicher, dass in diesem Strommast ein McDonalds ist?"
Scherz beiseite. Wenn ich Restaurants einzeichnen will, dann lade ich
nur das POI-Modul mit den Straßen als view-only. Dann komme ich gar
nicht an den Strommast ran.
Das Datenzerstören, geht momentan noch viel einfacher, nur dass man es
nicht so schnell merkt.

> Ich glaube, dass man das einigermassen gut auf Editorseite hinbekommen
> kann.
Ist natürlich auch eine Möglichkeit, jedoch was nützt ein Editor, der
alles Prima macht, wenn ein anderer Editor alles wieder kaputt macht.
(Es müsste also in jeden Editor eingebaut werden) Oder es müssten
Regeln gemacht werden, wie zB "Wenn ein Editor Funktion X nicht hat
(zB Relationen sortieren), dann darf er Y nicht tun (Relationen
ändern).

> Allerdings zwingt uns irgendwann eventuell die immer wachsende
> Datenmenge, auch partielle Downloads zum Editieren zu erlauben, mit all
> den potentiellen Fehlerquellen - schon heute kann man ja theoretisch auf
> Basis eines XAPI-Files im JOSM editieren, aber dabei koennte man ja
> einen Node verschieben, ohne zu sehen, dass der noch von anderen Ways
> genutzt wird, und dadurch Chaos erzeugen usw.

Genau das war der Ursprung meiner Überlegung.
Ich hatte mich gefragt, ob ich mir Boundarys über XAPI ziehen soll, um
die schneller reparieren zu können, oder ob ich mit Josm nur die
Relationen lade. Beides war mir zu kritisch.
Daher habe ich mir überlegt, wie man das modularisieren kann.
Dabei Fehler zu vermeiden und Regeln aufzustellen, wann ein
node/way/relation verändert werden darf und wann er sich dagegen
streubt, wird noch eine große Aufgabe (Vielleicht ja mit API 0.999)

Netter Gruß
Torsten