Editor usage stats

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)

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

hübsch,

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

Gruss
walter

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.

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

oder so:

kann eigentlich jede Software.

Gruss
walter

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.

das alles noch etwas enger zusammenschieben.

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

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.

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             

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.