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