[Talk-de] Schutz vor Manipulation/Vandalismus in OSM

[Guenther Meyer]

Am Dienstag 01 April 2008 schrieb Frederik Ramm:
> Es war noch nie moeglich, unregistriert Aenderungen vorzunehmen. Man
> konnte, und kann derzeit noch, verhindern, dass andere erfahren, wer man
> ist, aber in der Datenbank war das schon immer drin.
>
dann hatte ich die diskussion damals (u.a. wegen potlatch) wohl falsch 
verstanden. worum's mir geht, ist eine registrierung mit gueltiger 
email-adresse, so dass derjenige kontaktierbar ist. die identitaet muss ja 
deswegen nicht oeffentlich bekannt sein.
wenn das bereits so ist, umso besser.

> > hmm, die gaengigen versionsverwaltungssysteme machen das selber. und es
> > laesst sich normalerweise auch  so einstellen, das das nur an die leute,
> > die sich dafuer explizit subscriben rausgeht, nicht an alle user.
> > drum sollte das nicht so wild sein. ich finde es ausserdem wesentlich
> > besser, benachrichtigt zu werden, als staendig selbst nachschauen zu
> > muessen...
>
> Unterschaetz das mal nicht, wenn auch nur 100 Leute einfach mal so
> "London" auf ihre Watchlist tun, und bei jeder London-Aenderung dann 100
> Mails raus muessen... und bei denen versauern diese Mails dann in
> irgendeinem Folder, weil sie zu faul sind, sie abzubestellen ;-)
>
100 emails sind jetzt nicht sooo viel. da ja nicht jedes element einzeln, 
sondern immer nur ganze commits beruecksichtigt werden muessen, duerfte das 
die anzahl wesentlich reduzieren. wenns wirklich zuviele sein sollten, kann 
man ja immer noch die taeglichen nachrichten zu einer zusammenfassen...
zusammen mit der pflicht einer regelmaessigen bestaetigung der anmeldung 
muesste das funktionieren...

> > naja, so wie ich mir das vorstelle, hat die versionsnummer nur der
> > commit. und im log steht drin, welche elemente veraendert wurden.
>
> Das wuerde eine groessere Aenderung an der Datenbankstruktur bedeuten;
> Du willst SVN-artig eine "globale" Versionsnummer, die bei jeder
> Aenderung irgendwo auf der Welt hochgezaehlt wird (genauer, bei jedem
> Commit). Wir haben im Moment fuer jedes Objekt eine Versionsnummer.
>
ich glaube nicht, dass man dazu die datenbankstruktur aendern muss. ich wuerde 
das eher als eine art zwischenschicht zwischen api und datenbank sehen.

> Dein Vorschlag hat Vor- und Nachteile. Ein Nachteil ist, dass bei jedem
> Upload ein ziemlich aufwendiger Vergleich mit den betroffenen
> Aenderungsbereichen aller inzwischen hochgeladenen anderen Aenderungen
> erfolgen muss,
>
der aufwand fuer den vergleich duerfte sich in grenzen halten, schliesslich 
wird ja immer nur ein relativ kleiner bereich betrachtet; wobei ich 
natuerlich die genaue datenbankstruktur nicht kenne...

> > um bei meinem beispiel zu bleiben:
> > ich lade mir daten in josm, um die zu bearbeiten. der satz hat den stand
> > rev1234.
> > wenn ich fertig bin, will ich wieder hochladen. die api weiss aber, dass
> > der aktuelle stand jetzt rev1236 ist, also zwischendurch zwei aenderungen
> > erfolgt sind.
> > nun kann ein vergleich der logs erfolgen. wenn sich die bearbeiteten
> > bereiche bzw. objekte mit meinen ueberschneiden, gibts einen konflikt,
> > der mir (inklusive eventuellem kommentar) angezeigt wird und aufgeloest
> > werden muss.
>
> Und bis Du ihn aufgeloest hast, ist der globale Versionszaehler bei
> 1291, und es gibt schon wieder einen Konflikt... ich hoere schon die
> User heulen ;-)
>
das problem kann bei jedem projekt mit vielen entwicklern auftreten...
einen konflikt hast du sowieso nur, wenn sich die aenderungen in der selben 
gegend befinden. ausserdem gibts immer noch die moeglichkeit der 
kontaktaufnahme, falls mehrere user laenger im selben bereich arbeiten.

> Unklar ist mir im Moment noch, wie man unsere bestehenden Daten
> nachtraeglich in eine mit diesem Modell kompatible Datenstruktur packen
> koennte. Wird sicher irgendwie gehen, muesste man mal nachdenken.
>
auch so ein thema (aehnlich wie die highway- oder hausnummern-geschichte), wo 
man sich mal mit ein paar leuten zusammensetzen sollte, um was vernuenftiges 
auszuarbeiten.

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20080404/e39c9fbb/attachment.sig>