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?
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.
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.
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.
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.
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:
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).
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).
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.
Zu diesen Daten auch eine kumulative Darstellung, die vermutlich etwas leichter zu verstehen (und nicht so zappelig) ist:
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.
Warum fehlen eigentlich bei der Tabelle “Distinct Users” im Gegensatz zu den beiden Nachbarn die Prozentangaben?
Generell finde ich es schade, daß die Plots praktisch alle logarithmisch sind und viele normalisiert. Als Ingenieur muß ich einen Moment grübeln wie sie zu interpretieren sind - aber für den Laien sind sie komplett unverständlich bzw. er wird völlig falsche Schlüsse daraus ziehen.
Könnte man nicht allgemeinverständliche lineare Skalen wählen? (Falls man dann die “kleinen” Editoren nicht mehr sieht würde ein zweites Diagramm des niedrigen %-Bereichs helfen).
Falsche Zeitform, die Arbeit daran liegt hinter mir mittlerweile ist es nur noch ein gelegentliches make -B changesets-latest.osm.bz2 && make (plus Einpflegen in die Wikiseite)
Ist im Text erläutert - in dieser Tabelle ist die Definition des “Marktanteils” problematisch. Ein Änderungssatz oder ein bearbeitetes Objekt läßt sich eindeutig einem Editor zuordnen, aber was ist mit einem Mapper, der mehrere Editoren benutzt? Entweder muß ich ihn aufteilen (verfälscht das Gewicht) oder nur bei seinem Haupteditor zählen (verfälscht ebenfalls das Gewicht, und macht Probleme bei 50/50-Situationen) oder ich zähle ihn doppelt (ruiniert die Normierung). Ich habe mich für die letzte Variante entschieden. Die so erhaltene Zahl der Mapper, die einen bestimmten Editor im betreffenden Zeitraum benutzt haben, kann ich entweder durch die Gesamtzahl aller Mapper teilen, dann ist die Summe der Marktanteile größer als Eins; oder durch die Summe der Tabellenzeilen. Egal wie, die Bedeutung beider Quotienten ist fragwürdig. Deshalb habe ich sie bewußt nicht angegeben, um Fehlinterpretationen zuvorzukommen. Sonst müßte ich jedes Mal, wenn jemand z.B. sagt, Potlatch 2 werde von 83 % aller Mapper benutzt, erklären, daß in der Tat diese 83 % aller Mapper nur mindestens einmal einen Änderungssatz mit P2 erstellt haben, auch wenn sie womöglich viel mehr mit einem anderen Editor (lies: JOSM) gemacht haben. In jedem Fall muß man sich bewußt sein, daß gerade die Zahlen nach “distinct users” mit Vorsicht zu genießen sind.
Ich habe mir gerade mal den Spaß gemacht, die Skala umzustellen. Die kleinen Editoren sieht man dann in der Tat nicht mehr. Merkaartor liegt noch knapp oberhalb des bunten Bündels von Nulllinien, aber selbst P1 verschwindet mittlerweile darin (und im uid-Diagramm sogar Merkaartor). Selbst die kleinen Editoren (wobei ich die Auswahl für die Graphen schon auf Mehr-oder-weniger-Mainstream-Programme beschränkt habe) decken noch mehrere Größenordnungen ab, da stünde man bei dem zweiten Diagramm ganz schnell vor dem gleichen Problem - und der Übersicht wäre durch mehr Diagramme auch nicht geholfen.
Klar, die Problematik ist mir klar. Aber wenn eine Zahl mit Vorsicht zu genießen ist und das auch ausführlich erklärt wird, ist das ja kein Grund sie komplett wegzulassen.
Ich denke diese Aussage ließe sich signifikant schärfen, wenn man den Eindeutigen User nur jeweils bei dem Editor zählt, mit dem er in dem Jahr am meisten Changesets produziert hat? (Das Diagramm “multiplicity” klingt so als ob es eine Zählung in der Art schon gäbe) Dann würde man den Haupteditor zählen und Ausnahmen, Urlaubsedits, Tests usw. ignorieren. 50/50 Situationen dürften in der Praxis kaum vorkommen - falls doch könnte man ja ab 40% Anteil an Edits beide Editoren zählen - das wäre dann auch berechtigt.
Ich hab mir selber aus Neugierde jetzt auch mal ein lineares Diagramm aus Deinen Zahlen gebastelt. (P1 verschwindet nicht im Gewühl sondern taucht in den unkorrigierten Userzahlen noch mit 11% auf - auch wenn ich mir vorstellen kann, daß das evtl. nur undeletes waren.) Wenn man sich an der Politik orientiert und nur Editoren einzeln zählt, die zu irgendeinem Zeitpunkt die 5% Hürde geschafft haben, kommt man eigentlich zu einer recht übersichtlichen Darstellung. Ich denke ich werde sie mal zusätzlich ins Wiki packen, weil sie einen Textabsatz dort eigenltich recht schön illustriert.
Tja, aber ist das wirklich der Haupteditor? Oder der mit den meisten Bearbeitungen (Objekten)? Oder sollte man beide zu einer Funktion verwursten? Angesichts der Willkür, die auf diese Weise eingeführt würde, habe ich davon abgesehen.
Die “editor multiplicity” beschreibt übrigens die mittlere Anzahl Editoren, die ein User benutzt hat. Darüber wie aussagekräftig diese Größe ist, bin ich mir selbst noch nicht im Klaren. Durch immer mehr Einmal-und-nie-wieder-Mapper sinkt diese Zahl natürlich unabhängig von Trends innerhalb der tatsächlichen OSM-Community (etwa daß einige ab und an P1 als Zweiteditor benutzt haben, was jetzt weitgehend entfällt). Vielleicht würde eine Beschränkung auf Mapper mit mindestens N Änderungssätzen diesem Diagramm insgesamt gut tun.
Das stimmt, aber wenn sich der Trend fortsetzt, verschwindet P1 dank der nicht mehr vorhandenen Website-Einbindung in dieser Rangliste bald hinter Merkaartor, Vespucci, OsmAnd und Pushpin. Die Zahlen von gerade mal vier Tagen sind natürlich noch ein wenig dünn für eine belastbare Vorhersage, aber bei Changesets und Edits ging es bereits seit der Abschaltung steil bergab. Bei den Nutzern dagegen bleibt abzuwarten, wie es in einigen Wochen (mit mehr Statistik) aussieht.
Unschön ist, daß auch ein anerkannter Tilescraper wie OpenMaps offenbar nicht totzukriegen ist.
So, ich habe jetzt mal eine alternative Auswertung gefahren um die Mehrdeutigkeit bei mehreren Editoren beim selben User etwas aufzulösen. Die Vorgehensweise ist wie folgt:
es werden nur JOSM und Potlatch verglichen, alle anderen Editoren sind unter “Other” zusammengefaßt.
die Statistik erfolgt Monatsweise anstatt in Jahresscheiben, um die zeitliche Überschneidung bei ausnahmsweiser Nutzung von mehreren Editoren zu verringern und sich veränderndes Nutzerverhalten innerhalb eines Jahres besser weiderzugeben
die Auswertung unterscheidet zwischen “Exklusiver Nutzung” von einem Editor oder “Haupsächlicher Nutzung” gemeinsam mit anderen Editoren
eine Hauptsächliche Nutzung wird angenommen, wenn 40% oder mehr der Changesets in einem Monat mit einem Editor erzeugt wurden. Es ist also möglich daß bei nahezu Gleichverteilung beide Editoren gezählt werden
eine Nutzung von weniger als 40% wird als Ausnahme gewertet und nicht gezählt
Damit ergibt sich folgendes, wenig überraschende Bild: Es gibt bei OSM zwei große Lager. Die einen benutzen nur JOSM (ca. 25%), die anderen benutzten nur Potlatch (ca. 55%).
Erstaundlich finde ich daß sich trotz aller hitzigen Diskussionen in den letzten Jahren eigentlich nichts wirklich bewegt hat. Die Anteile von P1 sind auf P2 übergegangen aber die Schwankungen zwischen den beiden Lagern sind gering. Der Anteil von Nutzern die im selben Monat unterschiedliche Editoren nutzt ist recht niedrig. Andere Editoren spielen nur eine unwesentliche Rolle.
Testweise habe ich dieselbe Auswertung auch nochmal mit 30% als Mindestanteil für die Zählung als Hauptsächliche Nutzung durchlaufen lassen, die Änderungen sind aber unwesentlich.
Ich möchte noch einmal auf die Wiki-Seite Editor usage stats aufmerksam machen, da passieren im Moment einige bemerkenswerte Umwälzungen.
Seit einigen Monaten wird Potlatch 1 nicht mehr direkt auf der OSM-Website angeboten und ist in der Folge in allen drei Tabellen bereits 2012 deutlich abgerutscht, was sich in den ersten Monaten 2013 noch einmal verstärkt hat. Der neue Stern am Himmel der OSM-Editoren heißt iD. Bisher nur als Betaversion verfügbar, wird er offenbar bereits eifrig genutzt. Bei der Zahl der Nutzer liegt iD bereits auf Platz drei; Potlatch 1 hat er in allen drei Tabellen überholt. Der langsame Abstieg von Merkaartor, häufig als einer der wichtigsten Editoren angesehen, setzt sich ebenfalls fort. Zugleich gewinnen mobile Editoren - Pushpin, Go Map!!, Vespucci usw. - immer mehr an Bedeutung, vor allem bei der Zahl der Nutzer. Naturgemäß fallen deren Änderungssätze in der Regel eher klein aus, sodaß ihr Anteil an den Bearbeitungen quantitativ vernachlässigbar ist. Per Zufall bin ich kürzlich auf einen Editor namens MapStalt Mini aus dem Hause Mikroweich gestoßen. Der fehlte bisher in den Tabelle, weil er seine Änderungssätze mit create_by statt created_by signiert. Ulkigerweise ist mir damit der mobile Editor mit den meisten Nutzern durchgerutscht.
mittlerweile ist es nur noch ein gelegentliches 
