Markus,
Am 27. Januar 2016 um 22:33 schrieb Markus <liste12a4...@gmx.de>:
> In OSM werden Daten ja von tausenden Benutzern geprüft und ggf.
> verbessert. So entsteht iterativ eine hohe Genauigkeit und
> Detailliertheit unserer Daten.
>
> Gibt es zum "1000-Augen-Prnizip" als Methode der Qualitätsicherung in
> Opensource-Projekten schon Untersuchungen?
Ja; es gibt wissenschaftliche Papers (Haklay/Uni London) oder Zipf/Uni
Heidelberg?) über den Einfluss auf die Qualität in Bezug auf Anzahl
Changes und verglichen mit amtlichen Daten. Da wurde OSM eine gute
Qualität attestiert.
Aktuelle Forschungen von Zipf/Uni Heidelberg werten andererseits die
Tatsache, dass eine grosse Menge an "Aktiven Mapper" (d.h. die
Ungleichverteilung/"the long tail") auch als Qualitätsmerkmal.
Wie die Diskussion eben - und Fred's "I Like OSM" Idee - zeigt, gibt
können alternativ auch Leute wieder durch "Crowdsourcing" zu aktiven
Qualitätsaussagen angeregt werden.
Ich schätze aber, dass man breiter abgestützte Aussagen machen kann
nach dem Prinzip der "intrinsischen" Qualitätsuntersuchung verwendet.
Lukas (28. Januar 2016 um 13:26) verwies denn auch als weitere
Möglichkeit auf meinen Blog (mit Karte!) über die Visualisierung der
Anzahl Zugriffe auf die Startseite/Slippy Map von osm.org (siehe auch
dieses Poster [2]). Diese Untersuchung zielt darauf ab, was "Hot
Spots" sind. Die Analyse liesse sich natürlich auch umkehren, indem
man visualisiert, was NIE angeschaut wurde.
Mapbox hat schon früher versucht herauszufinden, wo potentiell
OSM-Daten fehlen und darüber berichtet ("Predicting data curation in
OpenStreetMap" [1]).
Noch früher waren wohl OSM Admins wie Grant, die eine "Tile disk
usage" berechnet haben [2]. Letztere Untersuchung besagt, dass im
Jahre 2011 auf zweitunterster Zoom-Stufe 18 nur 0.9%(!) der
Kacheln/Tiles verwendet wurden.
Mir scheint, dass man mit Statistiken von (nicht-)gebrauchten und
(nicht-)besuchten Kacheln vielversprechende Analysen machen könnte. Es
kommt aber drauf an, ob das genügt und auf das Ziel der Analysen sein
soll.
:Stefan
[1] https://www.mapbox.com/blog/osm-tracing-candidates/
[2] https://twitter.com/sfkeller/status/619954847031410688
[3] http://wiki.openstreetmap.org/wiki/Tile_disk_usage
Am 28. Januar 2016 um 14:26 schrieb Hartmut Holzgraefe
<hartmut.holzgra...@gmail.com>:
> On 27.01.2016 22:33, Markus wrote:
>
>> In OSM werden Daten ja von tausenden Benutzern geprüft und ggf.
>> verbessert. So entsteht iterativ eine hohe Genauigkeit und
>> Detailliertheit unserer Daten.
>
> Das wesentliche Zitat zu dem Thema war ja
>
> "Given enough eyeballs all bugs are shallow"
>
> So viele "eyeballs" haben wir aber, verglichen mit der Datenmenge,
> garnicht. Dazu kommt noch dass, anders als bei Source Code, es deutlich
> schwieriger ist sich das entsprechende Domänenwissen zu beschaffen um
> konkrete Daten überhaupt bewerten zu können.
>
> Ich denke nicht dass die Daten hier in der Gegend von tausenden
> Benutzern geprüft werden, wirklich aktive OSM-Accounts gibt es
> nur paar handvoll, und auch die Anzahl der Notes hält sich
> in Grenzen (vermutlich stammt der Großteil der anonymen davon
> sogar nur von einem einzelnen ex-User)
>
> Und ein wirklich systematisches Review findet auch nicht wirklich
> statt ... auch wenn wir immerhin ca. 1 1/2 User haben die über
> alle in der Gegend auflaufenden Changesets drüberschauen (der 1/2
> bin ich ...)
>
>> Gibt es zum "1000-Augen-Prnizip" als Methode der Qualitätsicherung in
>> Opensource-Projekten schon Untersuchungen?
>
> Die generelle Aussage war nicht dass Open Source Software dadurch
> automatisch besser wird, nur dass sie gegenüber Closed Source den
> Vorteil hat dass sie unter anderem auch auf diesem Weg besser werden
> *kann*.
>
> Allein schon das Wissen das andere hinter die Kulissen der eigenen
> Arbeit schauen können führt (bei mir zumindest) dazu dass man sich
> gewisse "passt scho'" Schludereien nicht mehr leistet.
>
> Aber auch hier gibt es unterschiedlich gelebte Vorgehensweisen,
> siehe zB. den klassischen Text "The Cathedral and the Bazaar" von
> Eric S. Raimond. Nicht alle Open Source Projekte sind da gleich
> offen, auch wenn der Quellcode bei allen öffentlich sichtbar ist.
>
> Mein früherer und auch mein aktueller Arbeitgeber (MySQL AB, MariaDB Corp.)
> sind zB. deutlich eher auf der Cathedral-Seite zu verorten.
> Mein nicht-mehr-Arbeitgeber (MySQL-Abteilung innerhalb von Oracle)
> treibt den Cathedral-Ansatz sogar auf die Spitze.
>
> OpenStreetMap dagegen empfinde ich zZ. als ein extremes Beispiel
> des Bazaar-Modells.
>
> Aber zurück zum eigentlichen Thema:
>
> Ich weiß nur von Untersuchungen zum konkreten Thema Pair Programming
> bei dem das Vier-Augen-Prinzip auf die Spitze getrieben wird. Das ist
> dann aber eigentlich schon wieder kein Open Source Thema mehr. Eher
> sogar im Gegenteil da tatsächliches Pairing mit zwei Entwicklern,
> die physisch vor demeselben Bildschirm sitzen, bei Open Source
> Projekten eher die totale Ausnahme sein werden solage keine
> Firma hinter dem Projekt steht. Und selbst dann ...
>
> Ansonsten gibt es Untersuchung zur generellen Fehlerhäufigkeit in
> offenem und nicht-offenem Code. Die Flagschiff-Projete im Open
> Source Bereich schneiden da relativ gut ab gegenüber der proprietären
> Konkurenz, aber in wieweit das über das ganze Spektrum hinweg
> aussagekräftig ist bleibt eine ganz andere Geschichte ...
>
>
> _______________________________________________
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
