[Talk-de] Objekte gegen Änderungen schützen

Frederik Ramm frederik at remote.org
Di Jan 20 23:13:23 UTC 2009


Hallo,

    es gibt immer mal wieder die Anforderung, dass Objekte gegen 
Änderungen "geschützt" werden sollen.

Die Forderung, oder der Wunsch, kommt aus verschiedensten Richtungen; 
manche hätten gern am liebsten ihre ganze Stadt "geschützt", damit man 
nur noch mit Zustimmung von drei alteingesessenen Mappern etwas ändern 
darf. Andere möchten einzelne Objekte "schützen", zum Beispiel einen 
importierten Datenpunkt, an dessen Koordinaten eben einfach nichts zu 
ändern ist, weil er per definitionem 100% richtig ist (ein Stützpunkt 
eines in internationalen Übereinkünften festgelegten Grenzverlaufs z.B.).

Grundsätzlich halte ich es für sehr unwahrscheinlich und auch gar nicht 
wünschenswert, dass wir in naher Zukunft irgendeine echte 
Schutz-/Sperrmöglichkeit in die Datenbank einbauen (ausser vielleicht 
für Admins, um bei Edit Wars einzugreifen o.ä.).

Ich könnte mir aber gut vorstellen, dass man Objekte dadurch "schützt", 
dass man beim Auslesen der Daten gewisse automatisierte Prüfungen macht.

Beispielsweise könnte man einen Checksummen-Algorithmus definieren: 
"Nimm lat und lon, schreibe sie hintereinander, nimm die ersten 4 Bytes 
der MD5-Summe". Dann würde man dem Node ein "checksum=0xdeadbeef" geben, 
passend zu seinen Koordinaten. Programme, die Daten auslesen, könnten 
bei solchen Nodes die Checksumme prüfen, und wenn sie nicht zu den 
Koordinaten passt, den Node ignorieren (oder den Benutzer irgendwie 
warnen). Das wäre ein effektiver Schutz gegen des *versehentliche* 
Verschieben eines Nodes.

(Jemand könnte argumentieren, dass man genauso einfach "protected=yes" 
schreiben könnte und der Editor den Benutzer dann warnen soll. Aber das 
erforder, dass alle Editoren mitziehen, während es der o.g. Lösung 
völlig egal ist, ob ein Editor mit dem checksum-Tag etwas anfangen kann 
oder nicht!)

Der Checksum-Algorithmus könnte auch komplizierter werden, indem man 
zwei Tags nimmt ("checksum:tags=highway,name,ref" und 
"checksum:value=0xdeadbeef") und so auch den Wert verschiedener Tags mit 
in die Pruefsumme einbeziehen kann. Eventuell noch "checksum:reason" 
dazu, um zu erklaeren, warum diese Daten speziell geschuetzt sind.

Wenn man weiter geht und sich auch gegen *absichtliche* Datenänderungen 
schützen will, gäbe es einmal den "trust"-Weg, dazu hat grad jemand was 
auf talk geschrieben: Man hat eine Liste von Benutzern, denen man 
vertraut, und bei bestimmten Objekten - z.B. der genauen Lage von 
Lufträumen oder Seezeichen - verlässt man sich ausschliesslich auf diese 
Leute, d.h. sobald ein Objekt von jemand anderem zuletzt verändert 
wurde, fällt es raus. Die Gefahr hierbei ist, dass nicht jeder, der 
einen kleine Änderung am Seezeichen vornimmt und daher als letzter 
Bearbeiter verzeichnet ist, eine Gewähr für die Richtigkeit er anderen, 
von ihm nicht veränderten, Angaben übernehmen will.

Eine ähnliche Alternative dazu wäre eine Art "Qualitäts-Gremium", das 
jede Änderung abnicken muss. Man kann in OSM ja auch eine unveränderte 
Version eines Objekts neu hochladen. Wenn ich also mit 10 Leuten eine 
"Seezeichen-Qualitätskontrollgruppe" gründe, könnten wir zusammen einen 
OSM-Account anmelden und den alle benutzen, um alle Seezeichen zu prüfen 
und mit unserem Accountnamen "abzustempeln". Alle könnten weiterarbeiten 
wie immer, und wenn jemand genau unsere abgesegnete Seezeichenkarte 
will, wird er beim Download halt alles rauswerfen, was nicht von unserem 
Account kommt. Wir würden zugleich ein Tool a la OSM-Inspector oder OSM 
Mapper einsetzen, um schnell zu sehen, wenn irgendjemand eines von 
"unseren" Objekten ändert, um diese Änderung dann auch prüfen und 
"abstempeln" zu können.

Statt des Vertrauens in Accountnamen könnte man auch Vertrauen in 
irgendwelche Krypto-Tokens setzen, also sowas ähnliches wie mein 
Checksummen-Beispiel, nur halt basierend auf public key-Kryptographie. 
Ich sehe allerdings nicht wirklich einen Anwendungsfall dafür, ausser 
man würde der Benutzerverwaltung auf dem zentralen Server misstrauen.

Die OSMXapi hat übrigens ein interessantes Feature, das in diese 
Richtung geht (siehe 
http://wiki.openstreetmap.org/index.php/Osmxapi#RSS_Feed). Hier wird ein 
bestimmtes Tag ausgewertet, mit dem Benutzer ein Objekt auf ihre 
"Watchlist" setzen können, und selbst wenn andere Benutzer dieses Tag 
entfernen, wird OSMXapi diese Änderung ignorieren. Es gibt also die 
Möglichkeit, bei völliger Freiheit in der zentralen OSM-Datenbank, 
trotzdem einen "gefilterten" Mirror zu betreiben, der Änderungen nur 
dann übernimmt, wenn sie nach irgendwelchen programmierten Regeln 
zulässig sind.


Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"




Mehr Informationen über die Mailingliste Talk-de