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 [email protected] ## N49°00'09" E008°23'33"
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
