Fast hätte ich das wichtigste Werkzeug vergessen:
http://matt.dev.openstreetmap.org/owl_viewer/
Gruß,
Mondschein
Eigentlich eine gute Idee wäre die Einführung eines “geschützt”-Bits. Die Datenbank (und über eine API der Editor) fragt beim Bearbeiten von Objekten, bei denen das Bit gesetzt ist, nach, ob die Änderung wirklich gewollt ist. Von mir aus mit erneuter Passworteingabe, die nicht gespeichert werden kann. Nur wenn der Editor diese API-Änderung implementiert hat, kann der Nutzer die Änderung bestätigen. Dieses Bit kann allerdings jeder setzen oder löschen. Eventuell machts Sinn, dieses Bit nutzerseitig auf einen Tag zu mappen (z.B. locked=yes).
Damit ließen sich Autobahnen, Grenzen, Relationen und weitere kritische Objekte vor versehentlichem Verändern schützen. Wenn man weiter gehen möchte, knüpft man daran bestimmte Nutzergruppen, ähnlich wie in der Wikipedia beim Sichten. Wichtig ist jedoch, dass nicht alle Objekte geschützt werden, sondern nur die besonders kritischen.
Das war mein Brainstorming. Ich hoffe, dass das Thema Qualitätssicherung an der SotM ein Thema sein wird, am besten mit Beschlüssen.
Stimmt…an Blockwarten mangelt es in OSM noch…
Glaubst du ernsthaft, dass das locked=yes sich auf gewisse Daten begrenzen lässt? Die Folge wird sein, dass Mapper auf die Idee kommen, alle ihre Daten zu schützen, weil die sind ja so richtig. Ist ja an sich auch nicht verwerflich, weil genau dafür ist ja das Tagg gedacht. Nun kommt aber so ein naiver Mapper daher und möchte durch den geschützten Ort nur eine Radweg-Relation legen. Er splittet die entsprechenden Wege auf, verlegt die Relation und beim Hochladen kommt dann das böse erwachen. dutzende Male muss er das Passwort eingeben und bestätigen, dass er wirklich den Weg teilen wollte.
Was glaubst du wie lange der Mapper das mitmacht?
Es gibt bei OSM keine Instanz (und wird es wird nie eine allgemein etablierte Instanz geben), die entscheidet, wann ein Objekt so richtig und vollständig ist, dass er nicht mehr einfach verändert werden sollte.
Halte ich für eine problematische Idee.
Ich habe gerade eben eine Bundesstraße teilen müssen, weil ich sie an die reale Situation der Rad-/Fußwege an einer Einmündung anpassen wollte. Wenn die Bundesstraßen-Relation oder gar die Straße als solche gesperrt gewesen wäre, hätte ich ziemlich alt ausgesehen. Beliebige andere Beispiele wo das enorm stören würde, lassen sich sicher leicht finden.
Im Grunde widerspricht es der OSM Idee, dass jeder Änderungen/Verbesserungen an jedem beliebigen Objekt durchführen kann und darf. So eine generelle Einstellung sollte man nicht leichtfertig über Bord werfen.
Die Idee Nutzergruppen mit Sonderrechten auszustatten ist auch etwas, was man nicht mal so nebenbei einführen sollte. Das will gut überlegt sein, ob man so etwas bei OSM überhaupt haben will.
Edbert (EvanE)
Stimme ich zu. Laut dem Buch “Alles über Wikipedia” werden die Moderatoren dort sehr sehr kritisch gesehen, wir sollten probieren diese Klippe bei OSM zu umschiffen. Ein Ansatz dafür wäre für ebend diese zerbrechliche Sachen einen stable Epxort einzuführen, bei dem nur die letzte funktionierende Objektinstanz ausgeliefert wird.
Danke für die schnellen Antworten! Ich sehe ein, dass das keine allzu gute Idee war. Das einzige was mir aktuell als Möglichkeit einfällt, sind Editoren, die mögliche Fehler erkennen und nachfragen. Im Prinzip läuft das ja schon so mit JOSM.
Vermutlich haben wir weniger mit Trollen zu tun, sondern mit Neulingen, die unabsichtlich Sachen beschädigen. Am kritischsten sind in meinen Augen Relationen und Fernstraßen.
Werden unsere Daten nun z.B. für Navis verwendet, lädt sich der Hersteller das Planet-File runter, wurschtelt bisschen drauf rum und haut es aufs Gerät. Dort wird es ohne Update vielleicht zwei Jahre drauf sein. Wenn genau in dem Moment des Downloads die Autobahn an irgendeiner Stelle in Deutschland kaputt ist (und wenns nur 10 Minuten waren), wird der Nutzer immer falsch navigiert werden.
Das wäre, mit Verlaub, ein ziemlich schwachsinniges Vorgehen auf Herstellerseite.
Jede vernünftige Firma verfügt über eine “Wareneingangskontrolle” um sich vor Mängeln der gelieferten Rohprodukte zu schützen.
Dies sollte auch für Softwarehersteller sinnvoll sein.
Z.B. könnte man als Hersteller von Navi-Software einige Hundert Testpunkte für Testrouten erstellen und damit automatisch die Datenqualität an den relevanten Ecken überprüfen.
Ansonsten gilt: “garbage in - garbage out”. http://de.wikipedia.org/wiki/GIGO
Gruss
Walter
Naja es würde ja schon reichen, wenn die Hersteller eine zuverlässige Feedback Funktion hätten und sich auch von unserer Community was sagen ließen 