Editor usage stats

Genau genommen sind es Rot und teilweise transparentes Rot in der Fläche… Ursprünglich war es mal einfach flächiges Rot, dann habe ich die Transparenzoption entdeckt :stuck_out_tongue:

Zusammengestellt sind (1) die aktuelle JOSM-Version (das ist im Moment die blaue Linie), (2) die in Gebrauch befindlichen Versionen (als Verteilung von Kreisen bzw. Punkten), (3) deren Mittelwert und Standardabweichung (Fehlerbalken).
Ich möchte auch alle diese Daten in dem Plot behalten, damit die Zusammenhänge erkennbar bleiben: Nehme ich (1) heraus, sieht man zwar, welche Versionen genutzt werden, aber nicht, wie weit diese hinter der aktuellen hinterherhängen. Ohne (2) sieht man nur, daß “im Mittel” die genutzte Version nahe an der aktuellen Version liegt, aber wie weit die Streuung hinunterreicht, erkennt man nicht. (Auch die Fehlerbalken kann nicht jeder richtig einordnen.) Ohne (3) habe ich zwar die Streuung der Versionen, aber (auch wegen der begrenzten Skalierbarkeit der Punkte) kann man den Mittelwert nur schwer abschätzen.
Ich kann natürlich einen Plot aus (1) und (3) und einen aus (2) und (3) erstellen. Damit wäre die Information auf übersichtlichere Plots verteilt, aber alle Zusammenhänge noch erkennbar. Andererseits ist es gerade ein Nutzen solcher Plots, unterschiedliche Daten zusammenführen zu können. Und wenn noch mehrere andere Plots dazukommen, wirkt die Seite schnell abstoßend überfrachtet.

Also wie können die drei Datensätze sinnvoller dargestellt werden? Für (1) bietet sich eigentlich nur eine Linie an, da es sich um quasikontinuierliche Daten bzw. eine skalare Funktion der Zeit handelt. Da sind Farbe und (bedingt) Linienstärke variabel. Für die Streuverteilung (2) könnte ich wieder ausgefüllte Kreise verwenden, oder andere Formen wie z.B. Quadrate oder Dreiecke, die vielleicht etwas günstiger skaliert werden. Mit welcher Farbkombination würden die sich von (1) deutlich abheben? Für (3) könnte man statt der Fehlerbalken auch breite farbige Balken in den Hintergrund stellen und den Mittelwert eigens kennzeichnen.
Ein Problem ist allerdings auch immer, daß die Objekte übereinander gezeichnet werden und sich dann teilweise verdecken (wie beim Kartenrendern…). Daher kam auch die Idee mit der Transparenz.

Ansonsten bliebe noch eine Möglichkeit, die Daten doch nur quartalsweise aufzulösen und somit zu reduzieren. Das wäre aber aus meiner Sicht ein Informationsverlust.

Ein Möglichkeit wäre die Grafik etwas größer zu machen. Zur Zeit ist das 640x480. Bei z.B. 800x600 als Vorschau und nochmal deutlich größer als Ausgangsbild könnte man einiges besser erkennen.

Im Grunde hast du mit den drei Varianten Linie (für aktuelle Version), Kreise/Punkte (für die einzelnen Versionen) und senkrechter Balken (für den Schwerpunkt der Versionen) die Information schon sehr übersichtlich gestaltet. Wegen der Farben kann man ja noch einiges ausprobieren.

Was die Übersichtlichkeit deutlich erhöhen würde, wäre eine Grafik nur für die letzten zwölf Monate, da dann die Informationsmenge geringer ist.
Der komplette Überblick kann dann zusätzlich oder nur auf Anfrage per Link zugänglich sein. Im letzteren Fall gleich als großes Bild.

Edbert (EvanE)

Ich würde ähnlich wie Edbert eine Aufteilung des JOSM-Plots in Zeitscheiben favorisieren. Dann dürfte Alles größer und damit hoffentlich auch übersichtlicher werden, ohne dass du Informationen herausnehmen musst.

Ich habe den Vorschlag “letzte zwölf Monate” einmal ausprobiert: http://wiki.openstreetmap.org/wiki/File:Josm_versions_recent.png.
Die Größe habe ich noch nicht geändert, aber allein die geringere Datenmenge schafft schon einiges an Übersicht. Außerdem habe ich die Mittelwerte deutlicher mit kleinen Rechtecken markiert und die Farbe der Punkte geändert. Hauptkriterium für die Auswahl der Farbe war, daß die Punkte einerseits deutlich genug erkennbar sein sollten, anderseits nicht (wie bei kräftigem Rot) die Fehlerbalken überstrahlen. Wie das für Leute mit Farbschwäche aussieht, weiß ich natürlich nicht, aber allein die geänderten Formen sollten eine bessere Differenzierung erlauben als vorher.
Eine Möglichkeit wäre, auf der Wikiseite nur den 12-Monate-Plot anzuzeigen und die volle Zeitreihe (dann auch deutlich größer) nur zu verlinken, um die Seite nicht zu sehr vollzukleistern.

Gefällt mir sehr gut.
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 wäre für die Variante 12-Monate auf der Wiki-Seite und ‘komplette’ Übersicht per Link und größer.

PS: Setze mal eine Leerzeile oder einen Zeilenumbruch vor die Grafik. Dann wird der Text nicht vor die Grafik geschoben.

Edbert (EvanE)

Ich überlege mir mal, wie ich das mit variablen Farben hinbekomme. Die großen Blobs in der Nähe der Mittelwerte und Fehlerbalken möchte ich nicht zu kräftig haben - siehe oben.

Der Fehler war, daß ich die Datei per File: statt Media: verlinkt habe. Eigentlich wollte ich sie hier gar nicht angezeigt haben. Ist jetzt geändert.

JOSM sagte heute mal wieder zu mir: Sie sollten aktualisieren! :smiley:

Also wenn dieser Farbfilter halbwegs realistisch arbeitet, sollten die Farbwahl an sich auch okay sein. Für die kleinen Punkte überlege ich mir aber noch etwas.

Und daß der Plot zu Editor-Marktanteilen nicht das Gelbe (Grüne?) vom Ei war, verstehe ich jetzt auch.
Erste Verbesserung: Marker an jeder Linie. Linienstärken/Strichelung und vorteilhaftere Farben kommen später.

Also das ist jetzt Alles jedenfalls schon mal viel besser! :stuck_out_tongue:

Die Tabellen ließen sich besser erfassen, wenn die Einträge nach dem aktuellsten Wert (2012) fallend sortiert wären.

Du kannst die Tabelle durch Klick auf das Symbol hinter dem Namen nach deinen Wünschen sortieren.
Unabhängig davon wäre eine Default-Sortierung nach “, hohe Werte zuerst” zu überlegen. Ich stelle mir das auch meist so ein.

Edbert (EvanE)

Wenn ich wüßte, wie ich in einer Wiki-Tabelle eine Default-Sortierung erzwinge, bräuchte ich gar nicht zu überlegen - dann wäre das längst eingestellt.
Ansonsten müßte ich eine Sortierung direkt im Skript vornehmen. Kein Ding der Unmöglichkeit, aber lästig und gerade wegen “wikitable sortable” im Moment für mich keine Priorität. Früher oder später wird aber auch das noch kommen.

Das geht vermutlich nicht:
https://en.wikipedia.org/wiki/Help:Sorting#Initial_sort_order_of_rows

Gruß,
Mondschein

Je nachdem wieviel du noch händisch machen willst, könnte ein kleiner Umweg über die Tabellenkalkulation deiner Wahl das Problem relativ leicht lösen. Inwieweit sich das dann (noch leicht) automatisieren lässt, ist eine andere Frage.

Wenn du die Tabelle(n) allerdings automatisch erstellen willst, bist du durch die Fähigkeiten des MediaWiki und deiner Erstellungsmethode begrenzt.

Wie auch immer, eine Vorsortierung wäre zwar noch schöner, ist aber wegen “wikitable sortable” nicht dringend nötig.

Edbert (EvanE)

Ja, kann bestätigen, dass das (zumindest als ich das letzte Mal recherchiert habe) nicht ging. Daher sortiert mein Bot für die Softwaretabellen die Zeilen jetzt selber und schreibt sie gleich in der richtigen Reihenfolge auf die Wikiseite.

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.

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)

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)

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)