You are not logged in.

#26 2012-07-22 21:44:15

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

Schade - ich hatte gehofft, es gäbe doch einen Trick, den ich bisher nicht gefunden habe. Aber die Wiki-Doku (den betreffenden Abschnitt hatte ich bisher übersehen) sagt ja sogar das Gegenteil. Eigentlich komisch, die Nachfrage nach einem solchen Feature dürfte gegeben sein.

EvanE wrote:

Je nachdem wieviel du noch händisch machen willst, ...

Klare Antwort: make -B
Einzig das Einfügen des geänderten Wiki-Quellcodes und das Hochladen neuer Plots möchte ich noch manuell machen, alles andere soll automatisiert werden. Im Moment habe ich ein einziges Skript, das (bzcat) changesets-latest.osm.bz2 liest, verarbeitet und sowohl die Tabellen in fertigem Wiki-Markup als auch Daten zur Erstellung von Plots ausspuckt, welche dann noch durch gnuplot weiterverarbeitet werden. Lediglich die Analyse der JOSM-Versionen ist da noch außen vor, aber diese wird auch noch in das erste Skript integriert.


No animals were harmed in the writing of this posting.

Offline

#27 2012-07-23 13:45:53

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: Editor usage stats

Oli-Wan wrote:
EvanE wrote:

Je nachdem wieviel du noch händisch machen willst, ...

Klare Antwort: make -B
Einzig das Einfügen des geänderten Wiki-Quellcodes und das Hochladen neuer Plots möchte ich noch manuell machen, alles andere soll automatisiert werden. Im Moment habe ich ein einziges Skript, das (bzcat) changesets-latest.osm.bz2 liest, verarbeitet und sowohl die Tabellen in fertigem Wiki-Markup als auch Daten zur Erstellung von Plots ausspuckt, welche dann noch durch gnuplot weiterverarbeitet werden. Lediglich die Analyse der JOSM-Versionen ist da noch außen vor, aber diese wird auch noch in das erste Skript integriert.

Ich hatte kurz an das Unix-Sort gedacht.
Allerdings kann das nicht nach (logischen) Spalten sortieren, jedoch nach Bereichen (PosN - PosN+m) innerhalb einer Zeile. Da ich jedoch befürchten muss, dass deine Zeilen nicht gleich lang sind, sprich die Infos, nach der du sortieren wolltest, nicht immer an der gleichen Stelle stehen, hilft dir das wahrscheinlich auch nicht weiter.

Edbert (EvanE)

Offline

#28 2012-07-23 14:12:37

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

EvanE wrote:

Ich hatte kurz an das Unix-Sort gedacht.
Allerdings kann das nicht nach (logischen) Spalten sortieren, jedoch nach Bereichen (PosN - PosN+m) innerhalb einer Zeile. Da ich jedoch befürchten muss, dass deine Zeilen nicht gleich lang sind, sprich die Infos, nach der du sortieren wolltest, nicht immer an der gleichen Stelle stehen, hilft dir das wahrscheinlich auch nicht weiter.

sort -k ging mir auch schon durch den Kopf. Die Zeilenlänge wäre das kleinste Problem, die Ausgabe erfolgt ohnehin schon formatiert (vgl. Quellcode der Tabellen im Wiki - kommt genau so aus dem Skript). Aber in der Zeit, in der ich die Ausgabe so ändere, daß sie sort-ierbar (und sehr unübersichtlich) wird, kann ich auch gleich eine richtige Sortierung einbauen. Idee ist vorhanden, Umsetzung folgt.


No animals were harmed in the writing of this posting.

Offline

#29 2012-07-23 14:26:54

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: Editor usage stats

Oli-Wan wrote:

sort -k ging mir auch schon durch den Kopf. Die Zeilenlänge wäre das kleinste Problem, die Ausgabe erfolgt ohnehin schon formatiert (vgl. Quellcode der Tabellen im Wiki - kommt genau so aus dem Skript). Aber in der Zeit, in der ich die Ausgabe so ändere, daß sie sort-ierbar (und sehr unübersichtlich) wird, kann ich auch gleich eine richtige Sortierung einbauen. Idee ist vorhanden, Umsetzung folgt.

Wie bereits mehrfach gesagt ist die vorsortierte Tabelle eine "nice-to-have" Eigenschaft aber nicht dringend. Also lass dir soviel Zeit, wie du dafür benötigst.

Edbert (EvanE)

Offline

#30 2012-07-24 12:07:39

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

EvanE wrote:

Nur die kleinen Beiträge von sehr alten Versionen sind noch sehr unauffällig. Die könnten eine wesentlich kräftigere Farbe (vielleicht nur der Rand) vertragen.

Ich habe jetzt mal allen Versionen zusätzlich einen schwarzen Punkt verpaßt (nur 12M). Bei häufigen Versionen skaliert immer noch die Fläche mit der Anzahl der Änderungssätze, bei seltenen sieht man eben nur den schwarzen Fliegenschiß. Mir schwebte eigentlich eine hübschere Lösung vor, aber die habe ich noch nicht hingekriegt.

Die Tabellen sind nun ebenfalls vorsortiert.


No animals were harmed in the writing of this posting.

Offline

#31 2012-07-24 12:52:21

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: Editor usage stats

Oli-Wan wrote:

Ich habe jetzt mal allen Versionen zusätzlich einen schwarzen Punkt verpaßt (nur 12M). Bei häufigen Versionen skaliert immer noch die Fläche mit der Anzahl der Änderungssätze, bei seltenen sieht man eben nur den schwarzen Fliegenschiß. Mir schwebte eigentlich eine hübschere Lösung vor, aber die habe ich noch nicht hingekriegt.

Die Tabellen sind nun ebenfalls vorsortiert.

So langsam wird es richtig rund.
Die kleinen Punkte sind jetzt besser zu erkennen.

Edbert (EvanE)

Offline

#32 2012-08-02 12:25:01

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

Neueste Errungenschaft: Histogramme zur Größe von Änderungssätzen.
http://wiki.openstreetmap.org/wiki/Edit … .282012.29


No animals were harmed in the writing of this posting.

Offline

#33 2012-08-02 12:35:52

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,736
Website

Re: Editor usage stats

Oli-Wan wrote:

Neueste Errungenschaft: Histogramme zur Größe von Änderungssätzen.
http://wiki.openstreetmap.org/wiki/Edit … .282012.29

hübsch,

nur ne kleine Frage: sind die Werte gestapelt oder fangen all drei jeweils bei null an?

Gruss
walter

Offline

#34 2012-08-02 12:41:38

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

wambacher wrote:

nur ne kleine Frage: sind die Werte gestapelt oder fangen all drei jeweils bei null an?

Nee, die fangen bei Null an. (Stapeln ist bei logarithmischer Achse auch nicht ohne). Aber das ist aus der Grafik selbst nicht ersichtlich, deswegen bin ich auch noch nicht ganz zufrieden damit. Wenn Dir (oder jemand anderem) etwas besseres einfällt, werfe ich die aktuelle Darstellung gerne über den Haufen. Das Original "plot with histograms" ist in der Doku leider ein bißchen umständlich.

Erstaunlich finde ich dabei, daß es tatsächlich Potlatch 2-Änderungssätze mit >=10 000 Änderungen gibt. Eventuell ein einfacher Trigger für Vandalenalarm, muß ich mir bei Gelegenheit mal näher ansehen.

Last edited by Oli-Wan (2012-08-02 12:44:59)


No animals were harmed in the writing of this posting.

Offline

#35 2012-08-02 13:01:21

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,736
Website

Re: Editor usage stats

Oli-Wan wrote:

Wenn Dir (oder jemand anderem) etwas besseres einfällt, werfe ich die aktuelle Darstellung gerne über den Haufen.

da macht man drei kleine Balken nebeneinander und dann die nächsten drei. etwas so:
histogramm.png
oder so:
histo.gif

kann eigentlich jede Software.

Gruss
walter

Last edited by wambacher (2012-08-02 13:04:11)

Offline

#36 2012-08-02 13:04:31

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

wambacher wrote:

da macht man drei kleine Balken nebeneinander und dann die nächsten drei. etwas so:
kann eigentlich jede Software.

Richtig, kann natürlich auch Gnuplot. Aber genau bei diesem Stil steige ich (noch) nicht durch die Dokumentation durch. Nachteil ist, daß es damit horizontal ganz schön eng wird im Plot.


No animals were harmed in the writing of this posting.

Offline

#37 2012-08-02 13:27:05

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,736
Website

Re: Editor usage stats

Oli-Wan wrote:
wambacher wrote:

da macht man drei kleine Balken nebeneinander und dann die nächsten drei. etwas so:
kann eigentlich jede Software.

Richtig, kann natürlich auch Gnuplot. Aber genau bei diesem Stil steige ich (noch) nicht durch die Dokumentation durch. Nachteil ist, daß es damit horizontal ganz schön eng wird im Plot.

dann leg die hintereinander: vorne pl1 pl2 und hinten josm. das ganze etwas gedreht mit 3d-effekt.
excel2010-graphique2.gif
das alles noch etwas enger zusammenschieben.

ideen sind ja was herrliches, wenn man sie nicht selber realisieren muß wink

Offline

#38 2012-08-02 22:06:27

Fabi2
Member
Registered: 2010-03-21
Posts: 1,073

Re: Editor usage stats

Oli-Wan wrote:
wambacher wrote:

da macht man drei kleine Balken nebeneinander und dann die nächsten drei. etwas so:
kann eigentlich jede Software.

Richtig, kann natürlich auch Gnuplot. Aber genau bei diesem Stil steige ich (noch) nicht durch die Dokumentation durch. Nachteil ist, daß es damit horizontal ganz schön eng wird im Plot.

Naja, sicher kann gnuplot alles, besonders wenn man gerne leidet, aber um mal schnell ein paar 2D-Daten darzustellen, kann ich xmgrace empfehlen, das kann unter der Haube mehr, als es auf im ersten Moment scheint und ist meist ausreichend, wenn man mehr will als simple Tabellenkalkulationsgrafiken und nicht gleich die großen Geschützen wie R oder Gnuplot auffahren will.


Healthcare 2.0
Wir geben Faschisten ein Zuhause. BMI.

Offline

#39 2012-08-03 07:32:28

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,767
Website

Re: Editor usage stats

Mal noch ein Einwurf: Gnuplot kann doch dem Hörensagen nach SVG. Könnte man die Diagramme dann nicht als Vektorgrafik erstellen und hochladen?


OSM in 3D: OSM2World

Offline

#40 2012-08-03 10:34:15

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

Tordanik wrote:

Mal noch ein Einwurf: Gnuplot kann doch dem Hörensagen nach SVG. Könnte man die Diagramme dann nicht als Vektorgrafik erstellen und hochladen?

Klar geht das. Über das Format habe ich mir keine tieferen Gedanken gemacht; png schien mir fürs Wiki (für nichts anderes waren die Plots gedacht) naheliegend. Wie geht das Wiki mit SVG um?

Subtopics available for terminal:
    canvas            gnugraph          nec_cp6           svg               
    cgm               gpic              okidata           tandy_60dpi       
    corel             hp2623a           pbm               tek40xx           
    dpu414            hp2648            pcl5              tek410x           
    dumb              hp500c            pdfcairo          texdraw           
    dxf               hpdj              png               tgif              
    dxy800a           hpgl              pngcairo          tikz              
    eepic             hpljii            pop               tkcanvas          
    emf               hppj              postscript        tpic              
    emtex             imagen            prescribe         vttek             
    epslatex          jpeg              pslatex           vx384             
    epson_180dpi      kyo               pstex             wxt               
    epson_60dpi       latex             pstricks          x11               
    epson_lx800       lua               push              xlib              
    excl              mf                qms               xterm             
    fig               mif               regis             
    gif               mp                starc             

No animals were harmed in the writing of this posting.

Offline

#41 2012-08-03 12:41:49

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,767
Website

Re: Editor usage stats

Oli-Wan wrote:

Wie geht das Wiki mit SVG um?

SVG ist eines der Dateiformate, mit denen MediaWiki problemlos umgehen kann, es lässt sich ganz normal hochladen.

Für die Einbindung in die Seite wird es aus Kompatibilitätsgründen automatisch in ein PNG konvertiert. Das kann in einer beliebigen Auflösung geschehen - je nachdem, wie es für die Einbindung eben benötigt wird -, und man kann sich auf der Bildbeschreibungsseite unterschiedlich große Bitmaps oder aber die Original-Vektorgrafik anschauen und herunterladen.

Als zufällig herausgegriffene Beispiele: Die Zeichnungen auf Relation:multipolygon und das OSM-Logo in der Infobox dort sind z.B. SVG.


OSM in 3D: OSM2World

Offline

#42 2012-08-03 12:52:30

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

Okay, Umstellung auf SVG steht hiermit auf der To-Do-Liste. Mir war nicht klar, ob man bei der PNG-Konversion irgendwie nachhelfen muß, aber wenn das automatisch geht... Sucht sich das Wiki auch automatisch eine passende Vorschaugröße abhängig vom Browserfenster aus?
Erstmal kümmere ich mich aber weiter um die Aufbereitung und Darstellung der Daten (sowie Debugging); die vorhandenen PNGs werde ich erst später austauschen.


No animals were harmed in the writing of this posting.

Offline

#43 2012-08-04 12:52:38

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,767
Website

Re: Editor usage stats

Oli-Wan wrote:

Sucht sich das Wiki auch automatisch eine passende Vorschaugröße abhängig vom Browserfenster aus?

Die Wahl der Größe automatisiert das Wiki nicht - eine gewünschte Auflösung kann der Benutzer derzeit nur von Hand in seinen Einstellungen setzen. Das geht separat für Bildbeschreibungs- und Artikelseite:

Auf der Bildbeschreibungsseite ist die gewählte Auflösung das Minimum aus Benutzereinstellung und im SVG gespeicherter bevorzugter Auflösung (hier schreiben die meisten Programme, die SVG erzeugen, automatisch sinnvolle Werte).

In der Artikelseite wird - wenn im Artikelquelltext keine Größe ausdrücklich angegeben ist - bei Einbindung mit dem "thumb"-Parameter die entsprechende Benutzereinstellung gewählt, ohne diesen Parameter die im SVG gespeicherte bevorzugte Auflösung.


OSM in 3D: OSM2World

Offline

#44 2012-08-10 09:57:49

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

Neues: Die Marktanteile nach Changesets, Edits und Uids sind jetzt alle graphisch dargestellt (und ein Fehler bei der Erzeugung des ursprünglichen Plots ist auch beseitigt).

Das Änderungssatzgrößen-Histogramm ist immer noch das alte - wird aber irgendwann auch noch ausgetauscht. Außerdem will ich noch die Änderungssatzgrößen als Quantile darstellen, evtl. in Kombination mit einem der Profilplots (wo bisher nur mäßig aussagekräftige Mittelwerte stehen).

Wie gesagt, wenn noch jemand Ideen für weitere aussagekräftige Darstellungen hat (die mit changesets-yymmdd.osm.bz2 zu realisieren sind), würden mich diese interessieren - bestimmte Größen als Funktion der Zeit, verschiedene Größen gegeneinander. Für eine übersichtlichere Gestaltung der Seite findet sich vermutlich kein wiki-erfahrener Freiwilliger...?

@Tordanik: Danke für die Erklärungen. Der Wechsel zu SVG steht noch aus, aber wenn es soweit ist, werden sie sicher hilfreich sein.


No animals were harmed in the writing of this posting.

Offline

#45 2012-08-14 15:17:49

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

Änderungssatzgrößen-Histogramme sind ausgetauscht.
http://wiki.openstreetmap.org/wiki/Editor_usage_stats


No animals were harmed in the writing of this posting.

Offline

#46 2012-08-24 14:55:55

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

Bis auf ein paar png's, die noch svg's werden wollen, sehe ich die Baustelle "Editor usage stats" als weitgehend abgeschlossen an.
Höchstens noch eine Frage @Tordanik: Gibt es eine einfache Möglichkeit, hochgeladene Dateien automatisiert (per API) zu ersetzen? Die Tabellen sind schnell aktualisiert (vielleicht bringe ich auch noch Emacs bei, das automatisch zu machen), aber das Hochladen mehrerer neuer Plots ist doch immer etwas lästig.
Und @miraculixOSM: Wie sieht es mit der Lesbarkeit aus?

Dafür was anderes. Es ist ja immer die Rede davon, daß OSM Anfänger nicht bindet: Leute probieren OSM aus, dann sind sie wieder weg. Fundierte Erkenntnisse dazu sind aber rar (auch der Artikel von P. Neis und A. Zipf beleuchtet nur wenige Teilaspekte).
Ich habe mir daher einmal angesehen, wie viele Neumapper am Tag x nach ihrem ersten Änderungssatz einen weiteren aufmachen. Ein erstes Ergebnis ist, normiert auf Eins, hier zu sehen:
beginners_edits.svg
Zunächst ist wichtig zu verstehen, was dort dargestellt ist und was nicht. Tag Null ist nicht der Tag der Anmeldung, sondern der Tag des ersten Änderungssatzes (dazwischen liegen bisweilen Jahre). Die Aussage ist "am Tag x nehmen %% der neu angemeldeten User Bearbeitungen vor" - am Tag Null ist der Anteil definitionsgemäß eins. Eine Aussage, welcher Anteil der User insgesamt zu einem bestimmten Zeitpunkt noch aktiv ist, läßt sich daraus nicht unmittelbar ableiten, u.a. weil hierfür zunächst eine Aktivitätsdefinition gegeben werden muß. (Man könnte z.B. alle User, die innerhalb eines Monats/Quartals/Jahres mindestens N=1,10,100, ... Edits gemacht haben, als aktiv bezeichnen.) Auch die Anzahl der Änderungssätze pro Tag oder pro Tag und Nutzer geht aus dem Plot nicht hervor, es wird nur gezählt, ob jemand am entsprechenden Tag mindestens einen Edit gemacht hat.
Aus dem obigen Plot geht z.B. auch nicht hervor, ob einige wenige Mapper übrig bleiben, die jeden Tag mindestens einen Änderungssatz aufmachen, oder ob es viele sind, die dafür nur in größeren Abständen editieren. Das will ich noch herausarbeiten.
Die Tendenz ist jedoch klar: nur ein Bruchteil der Anfänger wird richtig "angefixt" - nach günstigster Lesart würde etwa ein Prozent der Anfänger zu täglichen Mappern.
Ulkig ist jedoch das 7-Tage-Muster, das man im Plot erkennen kann. Auch Anfänger editieren bevorzugt an immer denselben Wochentagen (mutmaßlich Wochenende).

Datenquelle: changesets-120801.osm.bz2
Basis: User mit erstem Edit in den ersten 6 Monaten des Jahres 2012 (so gewählt, daß die im Plot gezeigten 30 Tage noch in das Zeitintervall der changesets-Datei fallen).

Last edited by Oli-Wan (2012-08-24 15:00:02)


No animals were harmed in the writing of this posting.

Offline

#47 2012-08-24 16:04:34

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

Oli-Wan wrote:

Aus dem obigen Plot geht z.B. auch nicht hervor, ob einige wenige Mapper übrig bleiben, die jeden Tag mindestens einen Änderungssatz aufmachen, oder ob es viele sind, die dafür nur in größeren Abständen editieren. Das will ich noch herausarbeiten.

Dazu:
beginners_editing_frequency.svg
Aufgetragen ist der Anteil der Anfänger, die innerhalb der ersten 30 Tage nach ihrem ersten Änderungssatz an 0, 1, 2, ... 30 Tagen erneut editieren. Man sieht: 71 % kommen (innerhalb der ersten 30 Tage) gar nicht wieder, 13 % nur an einem weiteren Tag, 5 % an zwei Tagen, 3 % an drei Tagen. Ein Anteil 10^-4 (0,01 % - im betrachteten Zeitraum ganze fünf neue User) werden zu süchtigen Mappern (Bearbeitungen an 30/30 Tagen).


No animals were harmed in the writing of this posting.

Offline

#48 2012-08-24 20:50:48

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,767
Website

Re: Editor usage stats

Oli-Wan wrote:

Höchstens noch eine Frage @Tordanik: Gibt es eine einfache Möglichkeit, hochgeladene Dateien automatisiert (per API) zu ersetzen?

Die Mediawiki-API bietet ein action=upload für Bilder. Mehr weiß ich aber nicht, Bilder automatisch hochladen habe ich auch noch nicht gemacht.

Danke übrigens für deine Arbeit und die schönen Statistiken!


OSM in 3D: OSM2World

Offline

#49 2012-08-27 12:35:43

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

Tordanik wrote:

Die Mediawiki-API bietet ein action=upload für Bilder. Mehr weiß ich aber nicht, Bilder automatisch hochladen habe ich auch noch nicht gemacht.

Schade, ich hatte auf ein mehr oder weniger fertiges Kommando für solche einfachen Fälle gehofft... naja, dann quäle ich mich halt irgendwann durch die Doku und löse das mit curl.

Und noch etwas zu den Anfänger-Bearbeitungen: Eine Variante des zweiten Plots von oben, jetzt mit allen 2011er Erstbearbeitern und nicht nur dem ersten, sondern auch weiteren 30-Tage-Intervallen. D.h. es werden jeweils für jeden Anfänger die Intervalle Tag 1 bis Tag 30, Tag 31 bis Tag 60, ... nach seiner ersten Bearbeitung betrachtet und gezählt, an wie vielen Tagen in jedem dieser Intervalle ein Anfänger Bearbeitungen vorgenommen hat - dieser Wert landet auf der x-Achse. Auf der y-Achse werden die User gezählt, die in dieser Kategorie landen (normiert auf alle Anfänger). Wenig überraschend sinken die Kurven immer weiter ab, aber es deutet sich Konvergenz an - d.h. man kann anhand der untersten Kurve schon grob abschätzen, welcher Anteil dauerhaft erhalten bleibt und wie regelmäßig diese Mapper aktiv sind.
beginners_editing_frequency_2011.svg

Zu diesen Daten auch eine kumulative Darstellung, die vermutlich etwas leichter zu verstehen (und nicht so zappelig) ist:
beginners_editing_frequency_cumulative_2011.svg
Beispiel: innerhalb der ersten 30 Tage nach erster Bearbeitung editieren etwa 94% der Anfänger nicht häufiger als an fünf Tagen, bzw. 6 % editieren an mehr als fünf Tagen. Von Tag 151 bis Tag 180 editieren 95 % der ursprünglichen Anfänger gar nicht; 4 % an einem bis ca. 6 Tagen, und nur das verbleibende eine Prozent nimmt an mindestens 7 Tagen Bearbeitungen vor. Angesichts der großen Statistik (65 000 Erstmapper 2011) sind die Zahlen auch halbwegs belastbar und zugleich noch hinreichend aktuell.

Mittelfristig werden auch die Analysen zu diesem Themenbereich auf einer eigenen Seite im Wiki landen, obiges nur als Vorgeschmack.


No animals were harmed in the writing of this posting.

Offline

#50 2013-01-08 11:45:45

Oli-Wan
Member
From: NRW
Registered: 2010-09-14
Posts: 2,814

Re: Editor usage stats

Ich habe gerade mal die Seite auf den Stand Gesamtjahr 2012 gebracht (Tabellen und Plots).

http://wiki.openstreetmap.org/wiki/Editor_usage_stats


No animals were harmed in the writing of this posting.

Offline

Board footer

Powered by FluxBB