You are not logged in.

#1 2012-07-19 11:23:47

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

Editor usage stats

Wie kürzlich in einem anderen Faden (OT) angekündigt, habe ich begonnen, die Wikiseite Editor usage stats zu überarbeiten. Wer sich nicht erinnert, wie sie vorher aussah, mag einen Blick auf die Archivseite werfen.

Neben der bloßen Aktualisierung (zuvor stammten die letzten Daten vom September 2011) gibt es folgende wesentliche Neuerungen:

  • Statt rein kumulativer Daten (jeweils von prähistorischer Zeit bis zum Stichtag der Auswertung) wird nun nach Jahren differenziert. Wie viele Änderungssätze wurden 2010 mit JOSM erstellt, wie viele Mapper arbeiteten 2011 mit Merkaartor usw. Man kann also zeitliche Entwicklungen nachvollziehen.

  • Die Zeitreihen werden nicht nur in Tabellen, sondern auch graphisch dargestellt (bisher nur für die Anzahl der Änderungssätze je Editor; Anzahl der User und Anzahl der Bearbeitungen werden folgen); dies sogar mit halbjährlichen Daten.

  • Ein Plot zur Update-Disziplin von JOSM-Nutzern.

  • "Editorprofile" (für 2012): bisher die Editoren mit der Anzahl ihrer Nutzer und der mittleren Anzahl von Bearbeitungen pro Changeset. Dies illustriert z.B., wie breit die Nutzerbasis eines Editors ist und wie/wofür er bevorzugt eingesetzt wird.

Was noch fehlt (aber noch kommt)

  • Erklärungen zur Gewinnung der Daten und ihrer Darstellung sowie zur Interpretation (im Moment stehen die Daten da weitgehend unkommentiert)

  • Weitere Editorprofile, speziell für die großen Editoren

  • Kosmetische Verbesserungen der Plots

  • Übersichtlichere Gestaltung der Wikiseite (hier wäre etwas Hilfe von jemandem mit einschlägiger Erfahrung willkommen).

Weitere Ideen?


No animals were harmed in the writing of this posting.

Offline

#2 2012-07-19 11:40:10

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

Re: Editor usage stats

Oli-Wan wrote:

Weitere Ideen?

wirklich hübsch geworden, Danke

an Ideen: Verknüpfung mit Quality-Tools: "Welche Fehler wurden mit welchem Editor gemacht?".
Sagt dann eventuell was über die Anwendungsfreundlichkeit aus. Mist kann man in allen Editoren machen, aber möglicherweise gibt es da doch Unterschiede.

Gruss
walter

Offline

#3 2012-07-19 12:52:55

Mondschein
Member
Registered: 2011-01-29
Posts: 1,831

Re: Editor usage stats

Danke, sehr schön und informativ!

Gruß,
Mondschein

Offline

#4 2012-07-19 12:57:01

Hobby Navigator
Member
From: Aßlar, Germany
Registered: 2007-11-11
Posts: 1,616

Re: Editor usage stats

Sehr schön gemacht. Das sollte in der Wochennotiz auftauchen!
Georg


"Ich denke, dass es einen Weltmarkt für vielleicht fünf Computer gibt."
Thomas Watson, Vorsitzender von IBM, 1943

Offline

#5 2012-07-19 14:34:30

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

Re: Editor usage stats

Sehr schön geworden.

Einzige Verbesserung, die ich vorschlagen möchte, wäre die großen Zahlen durch Trennung bei den Tausender-Stellen etwas besser lesbar zu machen. Also statt 257615240 so etwas wie 257.615.240

Edbert (EvanE)

Offline

#6 2012-07-19 15:38:57

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

Re: Editor usage stats

Danke für die wohlwollenden Rückmeldungen!

EvanE wrote:

Einzige Verbesserung, die ich vorschlagen möchte, wäre die großen Zahlen durch Trennung bei den Tausender-Stellen etwas besser lesbar zu machen. Also statt 257615240 so etwas wie 257.615.240

Gute Idee. Ich habe jetzt erst einmal Leerzeichen zur Trennung verwendet - und dabei ganz unauffällig einen Fehler in den Zahlen korrigiert cool (ging aber nur um Promille). Punkte verwirren die Englisch-, Kommata die Deutschsprachigen roll

Ach ja, die Null-Einträge in den Tabellen sind verschwunden. Der Fehler ist identifiziert; bei der nächsten Bearbeitung der Tabellen kommen auch die Nullen wieder.

wambacher wrote:

an Ideen: Verknüpfung mit Quality-Tools: "Welche Fehler wurden mit welchem Editor gemacht?".
Sagt dann eventuell was über die Anwendungsfreundlichkeit aus. Mist kann man in allen Editoren machen, aber möglicherweise gibt es da doch Unterschiede.

In der Tat eine interessante Idee, die jedoch weit über meine Ambitionen und Möglichkeiten hinausgeht. Für die Statistiken schlachte ich nur changesets-yymmdd.osm.bz2 aus (woraus sich schon erstaunlich viel Information gewinnen läßt). Einmalig (bzw. in größeren Abständen) ein Planetfile durch ein Skript zu schnullern, wäre auch noch denkbar - aber eine komplexe Analyse der Genese von Fehlern ist leider mit meinen Mitteln nicht drin.

Bei bestimmten sehr häufigen Fehlern sind die Auslöser ja bekannt, etwa aus einem Knoten bestehende Wege (Potlatch), nicht angebundene Wege (häufiger Potlatch-Anfängerfehler), leergeräumte Relationen (JOSM-Konfliktlösung) usw. Es wäre sicher interessant, dies mal auf breitere Füße zu stellen und systematisch zu untersuchen, woher bestimmte Fehler kommen, um dann ganz gezielt Gegenmaßnahmen ergreifen zu können - aber ich denke, daß da eine völlig andere Herangehensweise nötig wäre als bei meiner kleinen statistischen Auswertung. Schließlich müßte die Analyse speziell an jeden einzelnen Fehlertyp angepaßt werden. Nur ein Beispiel: Lücke in einem Multipolygon-Ring. Der Fehler kann daher kommen, daß die Relation bearbeitet wurde (z.B. Weg entfernt, oder unsinniger neuer Weg hinzugefügt), oder aus der Bearbeitung eines der Wege, wovon die Relation gar nichts mitbekommen hat. Man bräuchte also einen Algorithmus, der 1. den Fehler im Ist-Zustand erkennt und 2. unter allen Bearbeitungen a) der Relation und b) der Elemente diejenige findet, bei der der Fehler entstanden ist. Eine ganz schön komplexe Aufgabe, und das für jeden Fehlertyp, den man untersuchen will.


No animals were harmed in the writing of this posting.

Offline

#7 2012-07-19 15:51:26

miraculixOSM
Member
From: Cottbus
Registered: 2010-07-13
Posts: 314

Re: Editor usage stats

Danke, Oli-Wan, dass du dir diese Mühe machst!

Sensibilisieren möchte ich aber doch einmal für ein Thema, das, wie ich finde, auch bei den meisten Editoren etwas kurz kommt, nämlich das der Barrierefreiheit. So verwendet die überarbeitete Seite z.B. in Schaubildern unterschiedliche Farben, um die Nutzung der verschiedenen Editoren graphisch darzustellen. Für jemanden, der an einer ausgeprägten Farbschwäche leidet, sind diese unterschiedlichen Farben nur schwer bis gar nicht auseinander zu halten. Viel besser sind da unterschiedliche Stricharten bzw., wenn schon Farben, dann solche, die deutlichst auseinander liegen. Auch eine Kombination aus diesen beiden Möglichkeiten wäre besser.


Die Grundlage für eine gute Ordnung ist ein großer Papierkorb (nach Tucholsky)

Offline

#8 2012-07-19 15:55:10

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

Re: Editor usage stats

Oli-Wan wrote:

- aber eine komplexe Analyse der Genese von Fehlern ist leider mit meinen Mitteln nicht drin.

Du hattest nach Ideen gefragt und eine bekommen - Ideen sind ja auch zum Träumen da .

Gruss
walter

p.s. einer hat mal jemanden gefragt, ob er den Begriff "Idee" definieren könne.
     Als demjenigen das nach längerem Nachdenken gelungen war, meinte sein Kumpel nur:
     "dann rück bitte mal ne Idee weiter"

Last edited by wambacher (2012-07-19 15:59:46)

Offline

#9 2012-07-19 15:58:35

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

Re: Editor usage stats

-doppelt-

Last edited by wambacher (2012-07-19 15:59:28)

Offline

#10 2012-07-19 16:02:27

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

Re: Editor usage stats

miraculixOSM wrote:

So verwendet die überarbeitete Seite z.B. in Schaubildern unterschiedliche Farben, um die Nutzung der verschiedenen Editoren graphisch darzustellen. Für jemanden, der an einer ausgeprägten Farbschwäche leidet, sind diese unterschiedlichen Farben nur schwer bis gar nicht auseinander zu halten.

Oh ja, das hatte ich überhaupt nicht auf der Rechnung. Ich wollte die Plots ohnehin demnächst noch überarbeiten (die derzeitige Farbauswahl ist einfach gnuplot-Standard), ich versuche mal Deinen Hinweis dabei im Hinterkopf zu behalten. Was ist mit dem letzten Plot zu JOSM-Versionen? Blaue Linie, rosa Kreise mit rotem Rand, schwarze Fehlerbalken - reichen die Formen zur klaren Unterscheidung oder sollten da auch andere Farben her?


No animals were harmed in the writing of this posting.

Offline

#11 2012-07-19 16:11:51

miraculixOSM
Member
From: Cottbus
Registered: 2010-07-13
Posts: 314

Re: Editor usage stats

Oli-Wan wrote:

Oh ja, das hatte ich überhaupt nicht auf der Rechnung. Ich wollte die Plots ohnehin demnächst noch überarbeiten (die derzeitige Farbauswahl ist einfach gnuplot-Standard), ich versuche mal Deinen Hinweis dabei im Hinterkopf zu behalten. Was ist mit dem letzten Plot zu JOSM-Versionen? Blaue Linie, rosa Kreise mit rotem Rand, schwarze Fehlerbalken - reichen die Formen zur klaren Unterscheidung oder sollten da auch andere Farben her?

Dass du rosa und rot verwendest, ist mir gar nicht aufgefallen! Wenn ich mal davon ausgehe, dass ich nicht zu den ganz heftig Farbenblinden gehöre, dürfte an dieser Stelle eine andere Lösung angebracht sein. Ehrlich gesagt finde ich diese ganze Grafik zu den JOSM-Versionen nicht so ganz gelungen. Mir fällt jetzt auf die Schnelle aber auch nicht ein, wie man's besser machen könnte. Sind halt viele Daten auf engstem Raum zusammengepackt. Vielleicht liegt in der Aufteilung auf mehrere Plots die Lösung?!


Die Grundlage für eine gute Ordnung ist ein großer Papierkorb (nach Tucholsky)

Offline

#12 2012-07-19 16:40:57

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

Re: Editor usage stats

miraculixOSM wrote:

Dass du rosa und rot verwendest, ist mir gar nicht aufgefallen!

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 tongue

miraculixOSM wrote:

Sind halt viele Daten auf engstem Raum zusammengepackt. Vielleicht liegt in der Aufteilung auf mehrere Plots die Lösung?!

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.


No animals were harmed in the writing of this posting.

Offline

#13 2012-07-19 17:03:54

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

Re: Editor usage stats

Oli-Wan wrote:

... Also wie können die drei Datensätze sinnvoller dargestellt werden? ...

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)

Offline

#14 2012-07-19 21:38:17

miraculixOSM
Member
From: Cottbus
Registered: 2010-07-13
Posts: 314

Re: Editor usage stats

Oli-Wan wrote:

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.

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.


Die Grundlage für eine gute Ordnung ist ein großer Papierkorb (nach Tucholsky)

Offline

#15 2012-07-20 11:04:49

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

Re: Editor usage stats

Ich habe den Vorschlag "letzte zwölf Monate" einmal ausprobiert: http://wiki.openstreetmap.org/wiki/File … 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.


No animals were harmed in the writing of this posting.

Offline

#16 2012-07-20 13:13:06

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

Re: Editor usage stats

Oli-Wan wrote:

Ich habe den Vorschlag "letzte zwölf Monate" einmal ausprobiert: http://wiki.openstreetmap.org/wiki/File … recent.png.
... 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. ... 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)

Offline

#17 2012-07-20 13:27:10

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 ü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.

EvanE wrote:

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

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! big_smile


No animals were harmed in the writing of this posting.

Offline

#18 2012-07-20 14:20:30

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

Re: Editor usage stats

Oli-Wan wrote:

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.

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.

Last edited by Oli-Wan (2012-07-20 16:12:28)


No animals were harmed in the writing of this posting.

Offline

#19 2012-07-20 21:51:26

miraculixOSM
Member
From: Cottbus
Registered: 2010-07-13
Posts: 314

Re: Editor usage stats

Also das ist jetzt Alles jedenfalls schon mal viel besser! tongue

Last edited by miraculixOSM (2012-07-20 21:52:21)


Die Grundlage für eine gute Ordnung ist ein großer Papierkorb (nach Tucholsky)

Offline

#20 2012-07-21 06:47:45

cgu66
Member
Registered: 2009-08-19
Posts: 3

Re: Editor usage stats

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

Offline

#21 2012-07-21 08:48:45

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

Re: Editor usage stats

cgu66 wrote:

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 "<aktuelles Jahr>, hohe Werte zuerst" zu überlegen. Ich stelle mir das auch meist so ein.

Edbert (EvanE)

Offline

#22 2012-07-21 09:31:12

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

Re: Editor usage stats

EvanE wrote:

Unabhängig davon wäre eine Default-Sortierung nach "<aktuelles Jahr>, hohe Werte zuerst" zu überlegen. Ich stelle mir das auch meist so ein.

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.

Last edited by Oli-Wan (2012-07-21 09:31:51)


No animals were harmed in the writing of this posting.

Offline

#23 2012-07-21 11:59:17

Mondschein
Member
Registered: 2011-01-29
Posts: 1,831

Re: Editor usage stats

Oli-Wan wrote:

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.

Das geht vermutlich nicht:
https://en.wikipedia.org/wiki/Help:Sort … er_of_rows

Gruß,
Mondschein

Offline

#24 2012-07-21 15:14:49

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

Re: Editor usage stats

Oli-Wan wrote:
EvanE wrote:

Unabhängig davon wäre eine Default-Sortierung nach "<aktuelles Jahr>, hohe Werte zuerst" zu überlegen. Ich stelle mir das auch meist so ein.

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.

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)

Offline

#25 2012-07-21 18:18:51

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

Re: Editor usage stats

Mondschein wrote:
Oli-Wan wrote:

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.

Das geht vermutlich nicht:
https://en.wikipedia.org/wiki/Help:Sort … er_of_rows

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.


OSM in 3D: OSM2World

Offline

Board footer

Powered by FluxBB