Hallo, Markus wrote: >> Grundsätzlich halte ich es für gar nicht wünschenswert, >> dass wir in naher Zukunft irgendeine echte Schutz-/Sperrmöglichkeit >> in die Datenbank einbauen. > > Warum?
Weil dies eine Macht bei jenen konzentrieren wuerde, die entscheiden, was gesperrt wird und was nicht und wer etwas bearbeiten darf. Solche Machtkonzentration fuehrt fast immer zu einem oder mehreren der folgenden negativen Effekte: * einige Leute fuehlen sich besonders wichtig, es bilden sich Machtstrukturen, Entscheidergremien, Abstimmungen, Anfechtungen von Abstimmungen, Rauswuerfe von Gremienmitgliedern, Anfechtugen von Rauswuerfen und all das * einige Leute sind Flaschenhaelse, an denen immer alles haengenbleibt, und wenn sie mal in Urlaub oder im "Real Life" ueberarbeitet sind, geht nix mehr * es entstehen komplizierte Authentifikations-/Legitimationsverfahren und ein Ruf nach Sicherheit (wenn Du mit Deinem Account ploetzlich spezielle Bearbeitungsrechte hast, wird Dein Account auch ploetzlich besonders schuetzenswert - man darf dann nur noch Authentifizierung ueber HTTPS machen und solche Scherze); all das bindet Zeit und Arbeitskraft Wenn man hingegen am Ausgang kontrolliert, dann kann jeder Empfaenger selbst definieren, welche Art von Qualitaet er will, wem er trauen will und wem nicht und so weiter; an den zentralen Bottlenecks der Datenbank faellt dadurch keine zusaetzliche Last an, es muessen keine Listen privilegierter Benutzer gefuehrt werden, Editoren muessen nicht angepasst werden... >> Ich könnte mir aber gut vorstellen, dass man Objekte dadurch "schützt", >> dass man beim Auslesen der Daten gewisse automatisierte Prüfungen macht. > > Im Qualitätsmanagement ist man seit vielen Jahren zur Erkenntnis > gelangt, dass es effizienter ist, *Qualität zu generieren*, sie also > bereits am Eingang zu erzeugen. (Im Gegensatz zu "Qualität am Ausgang zu > überprüfen" und Ausschuss ggf. wegzuschmeissen). Diese Lektionen lassen sich m.E. auf OSM keinesfalls uebertragen, zumindest nicht pauschal. Bei OSM gibt es keine zentrale, allen gemeinsame Definition von Qualitaet; was der eine wegwirft, ist fuer den andren wertvoll (bsp. ein 1000m daneben liegender Leuchtturm - wenn ich nur analysieren will, wie die Leuchtturmdichte pro Quadratkilometer in verschiedenen Kuestengebieten ist, dann ist mir das wurscht). > Das entspricht der von mir vorgeschlagenen "sorgfältigen > Eingangsprüfung", und deckt möglichst alle Qualitätsforderungen ab, > natürlich auch böswillige Datenänderungen. Eine Eingangspruefung wird es auf absehbare Zeit nicht geben. Dazu fehlen sowohl die technischen Mechanismen als auch der Wille. > Jede/r kann Änderungen einbringen. > Aber vor der Speicherung in die DB wird diese geprüft. Das wuerde eine Warteschlange von "noch nicht genehmigten Aenderungen" erfordern, zusammen mit einem Interface und einer privilegierten Personengruppe, die diese Aenderungen bestaetigt, samt Regeln, nach denen sich diese privilegierte Personengruppe konstituiert. Sowas sehen wir fruehestens 2011 und auch dann nur gegen meinen Widerstand ;-) >> "Seezeichen-Qualitätskontrollgruppe" mit gemeinsamem OSM-Account >> alle Seezeichen prüfen und mit unserem Accountnamen "abstempeln". >> und wenn jemand genau unsere abgesegnete Seezeichenkarte >> will, wird er beim Download halt alles rauswerfen, was nicht von unserem >> Account kommt. > > Ja, das wäre eine Alternative zu "read-only". > Allerdings erreicht man damit nicht, dass immer alle Daten zur Verfügung > stehen (nicht gestempelte können nicht in der gestempelten Vorversion > geladen werden). Sag das nicht, sowas waere recht leicht ueber ein modifiziertes OSMXAPI machbar (es uebernimmt einfach nur gestempelte). > In der Eingangskontrolle wären solche Instrumente sehr effizient. Es wird keine Eingangskontrolle geben. Das widerspricht den Grundprinzipien von OSM. - Eine Eingangskontrolle gibt es bei Google Map Maker, soviel ich weiss. > Das klingt interessant! > Und vielleicht sind "gefilterter mirror" ja dasselbe wie "read-only" für > einen keinen Bereich von sicherheitsrelevanten Daten.... In die Richtung koennte es gehen. Der Vorteil ist das "basisdemokratische Element" - jeder oder jede Gruppe entscheidet selbst, welche Art von Filterung sie wuenscht/wuenschen; sobald jemand sich bevormundet fuehlt, kann er eine eigene, abweichende Filterung vornehmen. Sind hingegen in der zentralen Datenbank nur gefilterte Daten, steht diese Option nicht mehr offen. 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
