R Archive • Benedict Witzenberger

Benedict Witzenberger

7. Februar 2020

Automatisierung im Journalismus: Wenn das Skript Texte schreibt

Schneller, tiefgehender und persönlicher sollen die Inhalte werden: Automatisierung im Journalismus ist ein ziemlich neues Feld. Und ein ziemlich spannendes.

Es ist eine Horrorvorstellung für viele Arbeitnehmer: Entlassen, weil der eigene Job jetzt von einem Computer gemacht werden kann. Besser und billiger. Zwischen 75 und 375 Millionen Jobs könnte das bis 2030 treffen, hat eine Studie von McKinsey mal geschätzt. Was man dabei aber nicht vergessen darf: Neue Jobs entstehen.

Im Journalismus sind das beispielsweise Berufsbilder im Automation-Bereich (im Deutschen oft unter dem Begriff „Roboterjournalismus“ – als ob da eine Maschine säße und in die Tastatur eintippt…). In den USA gibt es schon einige Newsrooms mit Automation-Editors, auch der BR startet gerade ein Automation und AI-Lab:

Der Inhalt ist nicht verfügbar.
Bitte erlaube Cookies, indem du auf Übernehmen im Banner klickst.

Und tatsächlich steckt sehr viel Potenzial im Bereich Automatisierung und Journalismus. Der US-amerikanische Journalistikforscher Nick Diakopoulos hat 2019 dazu das Buch „Automating the News“ veröffentlicht. Darin beschreibt er anhand vieler Beispiele im Groben vier Bereiche, in denen Automatisierung Journalisten und Medienhäusern helfen kann:

Geschwindigkeit: Automatisierung kann Daten in wenigen Sekunden in vordefinierte Text-Templates füllen und veröffentlichen,
Qualität: gerade Zahlen können ohne menschliches Zutun mit weniger Fehlern weiterverarbeitet werden – wenn die Input-Daten fehlerfrei sind,
Breite: Automatisierung kann mehr Bereiche abdecken, als das menschliche Journalisten leisten können,
und Personalisierung: mit Automatisierung können wir die Daten hervorheben, die die Nutzer persönlich betreffen.

(Ich habe mit Diakopolous ein Interview für die SZ geführt / Für das Nieman Lab hat er außerdem einen spannenden Post über das Thema geschrieben)

Die Überschneidung von Automatisierung und Journalismus hat ziemlich viele Facetten: Welche Datenquellen nehmen wir für die Automatisierung? Wie bringen wir den Computerprogrammen journalistische Grundsätze bei? Wie kontrollieren wir die Programme? Und wie machen wir kenntlich, dass nicht ein Mensch, sondern ein Skript einen Text verfasst hat?

Ich konzentriere mich in diesem Blogpost aber vor allem auf meine Erfahrungen aus der Praxis.

Automatisierung bei der SZ

Auch bei der SZ haben bisher vor allem Katharina Brunner und Martina Schories mit dem Thema Automatisierung experimentiert. Vom Datenjournalismus zur Automatisierung ist es auch kein sehr weiter Weg: Beide nutzen Daten, und bei beiden wird programmiert.

Im Projekt „Better Polls“ [hier auf Github] wurden Umfragen auf eine neue Art dargestellt – ohne absolute Werte, mit ihrem Fehlerbereich. So wie es inzwischen Medien auf der ganzen Welt machen: New York Times, FiveThirtyEight oder die BBC.

Screenshot SZ.de: Projekt Better Polls, Liniendiagramm mit aggregierten Umfragen zur Bundestagswahl 2017 — Quelle: Screenshot SZ.de

Bei den Bundestagswahlen 2017 und den Landtagswahlen in Bayern 2018 hat die SZ zum ersten Mal auf mit automatisch erstellten Texten gearbeitet. Wobei „automatisch“ nicht heißt, dass davor nicht ziemlich viel Arbeitsaufwand in Entwicklung, Berechnung und Testen gesteckt worden wäre. Für jeden Wahlkreis haben die Datenjournalistinnen damals das Wahlergebnis einzeln, als eigener Artikel über ein Skript ausgespielt und mit vielen Vergleichsgrafiken angereichert.
[Ein Beispiel gibt es hier]

Automatisierung für die US-Wahlen 2020

Und auch jetzt, im Beginn des US-Wahlkampfes 2020 haben wir uns wieder gefragt, wie wir unseren Nutzerinnen und Nutzern aktuelle Grafiken bieten können – ohne die ständig händisch aktualisieren zu müssen.

Für die US-Vorwahlen nutzen amerikanische Medien Umfrage-Aggregatoren. Sie berechnen also aus allen einzelnen Umfragen einen Mittelwert. Der Gedanke dabei: Umfragen sind immer mit Ungenauigkeiten behaftet. Bildet man aus Umfragen aber den Durchschnitt, so gleichen sich die verschiedenen Abweichung nach Oben und Unten im Idealfall wieder aus. Auch wir haben uns daher für eine solche Aggregation entschieden. Wir nutzen dabei die Daten von FiveThirtyEight, das alle Umfrageergebnisse verfügbar macht, und alle amerikanischen Umfrageinstitute nach ihrer Leistung einstuft. Wir können daher nur die besten Instituten auswählen.

Die Berechnung für unseren Mittelwert machen wir (wie so oft) in der Programmiersprache R. Am Ende entstehen zwei Grafiken. Ein Scatterplot mit Liniendiagramm für die nationalen Umfragen über die Zeit hinweg…

… und eine Tabelle in Datawrapper, die die Umfragen in den Einzelstaaten der kommenden Vorwahlen aggregiert:

Screenshot SZ.de Datawrapper-Tabelle mit Umfragen in US-Einzelstaaten

Die Tabelle befülle ich über das DatawRappr-Package, das ich neulich veröffentlicht habe.

Jeden Morgen um 5.30 Uhr läuft ein Skript auf unserem Server und aktualisiert die Umfragen. So haben wir einen immer aktuellen Überblick über das demokratische Rennen in den USA. [Hier der Link auf den Überblicksartikel zu den Vorwahlen auf SZ.de]

Weiterführende Links zu Automatisierung im Journalismus:

Der Deutschlandfunk und Netzpolitik.org haben Überblickstexte zum Thema „Roboterjournalismus“
Ziemlich spannend ist eine Studie der LMU München, die untersucht hat, wie automatisierte Text auf die Nutzer wirken.

Anmerkung: Ich habe bei den SZ-Beispielen nochmal präzisiert, wer die Projekte umgesetzt hat. War da ein bisschen zu pauschal.

Benedict Witzenberger

2. Dezember 2019

Introducing DatawRappr

Datawrapper ist eines der erfolgreichsten Visualisierungstools für Journalisten. Mit einer neuen Erweiterung können die Daten aus R jetzt auch ohne Umwege in Datawrapper-Grafiken geladen werden.

Nein, dieser Blogpost soll keine Werbung für Datawrapper werden. Und der „Tippfehler“ im Titel ist gar keiner (na, wer hat sich gewundert?). Ich will in diesem Post kurz beschreiben, warum ich eine Bibliothek für die Statistiksoftware R geschrieben habe, die auf die Datawrapper-API zugreift. Und weil viele dieser R-Erweiterungen gerne mit dem Namen der Software spielen (ihr Vorgänger hieß übrigens S), wollte ich dem in nichts nachstehen: DatawRappr.

In vielen meiner Arbeitsstellen wurde Datawrapper eingesetzt. In meinem aktuellen Job visualisieren wir damit alle möglichen Grafiken auf der Homepage, oder erstellen damit schnelle Karten in Breaking-News-Situationen.

Inzwischen tauchen die Grafiken sogar schon in der gedruckten Zeitung auf:

https://twitter.com/Datawrapper/status/1175365864406822912

[/cookie]

In der Regel nutzen wir Datenjournalisten für unsere Auswertungen die Software R. Sie ist frei verfügbar und hat eine riesige Community, die für jeden Anwendungsfall eigene Erweiterungen geschrieben hat. (Vor allem aus der Informatik-Richtung kommt Python, die Sprache kann quasi dasselbe. Manche Leute mögen die eine, andere die andere mehr.)

[Mehr zu R habe ich in einem eigenen Blogpost aufgeschrieben.]

Um die Daten von R in Datawrapper zu bekommen, ist momentan noch ein Umweg nötig:

Entweder wir speichern die Ergebnisse für die Grafik als CSV und copy&pasten sie in Datawrapper (oder laden die CSV dort hoch)
Oder wir nutzen die Bibliothek clipr, die die Ergebnisse der Berechnungen in die Zwischenablage kopiert:

df = data.frame(a = c(1, 2, 3), b = c(4, 5, 6))
write_clip(df)

1 2	df = data.frame(a = c(1, 2, 3), b = c(4, 5, 6)) write_clip(df)

In einem aktuellen Projekt wollen wir aber automatisiert und regelmäßig Berechnungen durchführen (die Daten verändern sich ständig), und daraus Datawrapper-Grafiken generieren. Wir wollen aber ungern dauernd selbst daran denken müssen, die Grafiken zu aktualisieren. Außerdem müssen wir manchmal nicht nur die Daten, sondern auch die Beschreibungstexte ändern.

Die Datawrapper-API

Zum Glück hat Datawrapper dafür eine Lösung: Die API.

Über diese Schnittstelle können wir auf alle Funktionen zugreifen, die Datawrapper auch über sein Web-Interface anbietet. Gerade wurde die API von Version 1 auf Version 3 geupgradet. (Mehr dazu hat Datawrapper hier gebloggt)

Damit man direkt aus R darauf zugreifen kann, habe ich also die R-Erweiterung geschrieben. Mit ihr kann man zum Beispiel:

Daten direkt aus R hochladen (dw_data_to_chart())
eine neue Grafik erstellen (dw_create_chart())
eine vorhandene Grafik bearbeiten (dw_edit_chart())
eine Grafik veröffentlichen (dw_publish_chart())
oder eine Grafik löschen (dw_delete_chart()).

Was genau DatawRappr kann – und wie es genau funktioniert, steht in der Dokumentation. Zwar ist die Erweiterung schon in Version 1.0, aber vermutlich wäre 0.9 – also eher eine Beta-Version – angebrachter. Noch ist sie einfach zu wenig getestet, vor allem auf Windowssystemen. Aber: Sie geht! 😉

Infos zu DatawRappr

Der Code von DatawRappr steht auf Github. Es gibt eine eigene Dokumentation dazu.

Installiert wird es ganz einfach in R mit dem Package devtools:

devtools::install_github("munichrocker/DatawRappr")

1	devtools::install_github("munichrocker/DatawRappr")

Benedict Witzenberger

20. Mai 2019

Überstunden-Tracking mit R und IFTTT

Previewbild eines Balken-Diagrams mit meinen Überstunden

Der Europäische Gerichtshof will, dass Arbeitgeber die Arbeitszeit ihrer Mitarbeiter erfassen. Bis das eingeführt wird, behelfe ich mir selbst.

Ein Urteil aus Luxemburg hat die Arbeitgeber ziemlich durchgeschüttelt. Der Europäische Gerichtshof hat entschieden, dass Arbeitgeber die Arbeitszeiten von ihren Angestellten systematisch erfassen müssen. Für die Arbeitgeber das Ende der flexiblen Arbeitszeiten und der Vertrauensarbeitszeit. Für die Angestellten aber wohl die Chance auf mehr Gesundheit. Denn Überstunden machen krank, hat zumindest eine Studie der Unis Halle-Wittenberg und Erlangen-Nürnberg für Angestellte im öffentlichen Dienst herausgefunden.

Nicht nur deshalb, sondern vor allem, weil ich einen Überblick über meine Arbeitszeiten haben wollte, habe ich im Januar begonnen, zu tracken, wann ich meine Arbeit betrete, und wann ich sie verlasse. Das klappt gut, wenn man einen festen Ort hat, den man morgens betritt.

Mein Handy erkennt, wann ich die Arbeit betrete und verlasse

Ich nutze für mein Tracking IFTTT. Das steht für „If This Then That“ – eine Webseite, auf der die Nutzer verschiedene Webanwendungen zusammenbinden können. In meinem Fall benutze ich deren App auf meinem Handy mit einem sogenannten „Geo-Fencing“. Wie der Name andeutet, lege ich einen „umzäunten“ Bereich fest, durch den eine Aktion ausgelöst wird, wenn ich ihn betrete oder verlasse. In meinem Fall schreibt die App dann die Uhrzeit und entered oder exited in ein Google Spreadsheet.

So sieht das Google Spreadsheet mit den Rohdaten aus.

Diese Apps könnte man selbst entwickeln. Bei IFTTT ist die Infrastruktur aber schon vorhanden. Und andere Entwickler haben diese Schnittstellen schon gebaut. Ich konnte sie also ganz einfach wiederverwenden.

Von den Daten zur Auswertung

Die Daten laufen also seit Januar in das Spreadsheet ein. Doch ich wollte ja auch irgendwie davon profitieren, dass ich diese Daten erhebe. Meine Idee: Jeden Freitag bekomme ich eine Übersicht meiner Überstunden für die vergangene Woche per Mail geschickt.

Zunächst habe ich ein Auswertungsskript geschrieben. Dafür nutze ich diese Bibliotheken in R:

library("stringr")
library("lubridate")
library("dplyr")
library("ggplot2")
library("mailR")

library("stringr")

library("lubridate")

library("dplyr")

library("ggplot2")

library("mailR")

In meinem Workflow downloade ich die Daten aus dem Spreadsheet und arbeite dann mit ihnen weiter. Das geht ganz einfach mit einem Spreadsheet, das öffentlich gestellt wurde. Das kann man als CSV herunterladen: https://docs.google.com/spreadsheets/d/[ID zum Spreadsheet]/export?format=csv

In R wandle ich die computer-ungeeignete Datumsangabe in ein Format um, mit dem ich weiterrechnen kann. Außerdem berechne ich Wochentag und Kalenderwoche:

d %>% 
  mutate(date = as.POSIXct(date, format = "%B %d, %Y at %I:%M%p"),
         week_number = isoweek(date),
        weekday_number = factor(weekdays(date, FALSE), levels = c("Monday", "Tuesday", 
"Wednesday", "Thursday",                                                                   "Friday", "Saturday", "Sunday"))) -> d

d %>%

mutate(date = as.POSIXct(date, format = "%B %d, %Y at %I:%M%p"),

week_number = isoweek(date),

weekday_number = factor(weekdays(date, FALSE), levels = c("Monday", "Tuesday",

"Wednesday", "Thursday", "Friday", "Saturday", "Sunday"))) -> d

Und dann gibt’s’s auch schon erste Ergebnisse. Ich berechne für jeden Arbeitstag die Differenz zwischen den Soll- und Ist-Stunden. Weil ich 36,5 Stunden in der Woche arbeiten muss, komme ich auf 7,3 Stunden pro Tag (ohne Pausen). Das fasse ich dann nach KWs zusammen:

d_distinct %>% 
  arrange(date) %>% 
  group_by(date(date)) %>% 
  tidyr::spread(status, date) %>% 
  mutate(working_hours = as.duration(interval(entered, exited))) %>% 
  ungroup() %>% 
  group_by(week_number) %>% 
  summarize(no_workingdays = n(),
            sum_workinghours = sum(as.numeric(working_hours), na.rm = TRUE) / 3600,
            workingtime_todo = no_workingdays * 7.3,
            overtime = round(sum_workinghours - workingtime_todo, 2)) %>% 
  arrange(week_number)

d_distinct %>%

arrange(date) %>%

group_by(date(date)) %>%

tidyr::spread(status, date) %>%

mutate(working_hours = as.duration(interval(entered, exited))) %>%

ungroup() %>%

group_by(week_number) %>%

summarize(no_workingdays = n(),

sum_workinghours = sum(as.numeric(working_hours), na.rm = TRUE) / 3600,

workingtime_todo = no_workingdays * 7.3,

overtime = round(sum_workinghours - workingtime_todo, 2)) %>%

arrange(week_number)

Das Ergebnis sieht in R so aus:

Mit zwei Filterbefehlen kann ich aus diesen Daten schon ein bisschen Text für meine Mail generieren:

filter(week_number == max(d_results$week_number)) %>% 
   select(overtime) %>% 
   .[[1]] -> this_week_overtime

filter(week_number == max(d_results$week_number)) %>%

select(overtime) %>%

.[[1]] -> this_week_overtime

berechnet mir, wie viele Überstunden ich in der vergangenen Woche gemacht habe. Mit einem if_else bekomme ich dann eine Aussage, welches Vorzeichen dieser Wert hat – und kann daraus Worte generieren:

over_under_time = if_else(this_week_overtime >= 0, "zu viel", "zu wenig")

1	over_under_time = if_else(this_week_overtime >= 0, "zu viel", "zu wenig")

Das Ergebnis wird dann zu text_result zusammengebunden und ergibt den veränderbaren Text für meine Mail:

text_result = paste0("Du hast in der vergangenen Arbeitswoche  insgesamt ", round(abs(this_week_overtime), 2), " Stunden ", over_under_time, " gearbeitet.")

1	text_result = paste0("Du hast in der vergangenen Arbeitswoche insgesamt ", round(abs(this_week_overtime), 2), " Stunden ", over_under_time, " gearbeitet.")

Damit das ganze anschaulicher wird, gebe ich außerdem noch zwei Grafiken aus.

Der E-Mailtext body_text selber ist eigentlich nur ein Zusammenfügen von Bruchstücken in HTML:

body_text = paste0('<html>','<p>Hallo Benedict, <br>hier kommt dein freitägliches Arbeitszeitupdate.</p>', 
                    '<p>', text_result, '</p>', '<h3>So verteilen sich die Arbeitsstunden in dieser Woche:</h3><br>',
                    '<img src="', here::here(), '/this_week.png", style = "width: 100%; height: auto"><br>', 
                    '<h3>So viele Überstunden gab es in den vergangenen Wochen</h3><br>',
                    '<img src="', here::here(), '/last_weeks.png", style = "width: 100%; height: auto"><br>',
                    '</html>')

body_text = paste0('<html>','<p>Hallo Benedict, <br>hier kommt dein freitägliches Arbeitszeitupdate.</p>',

'<p>', text_result, '</p>', '<h3>So verteilen sich die Arbeitsstunden in dieser Woche:</h3><br>',

'<img src="', here::here(), '/this_week.png", style = "width: 100%; height: auto"><br>',

'<h3>So viele Überstunden gab es in den vergangenen Wochen</h3><br>',

'<img src="', here::here(), '/last_weeks.png", style = "width: 100%; height: auto"><br>',

'</html>')

Mit der Bibliothek MailR verbinde ich mich dann mit meinem Mailaccount und schicke die Mail ab:

send.mail(from = XXX,
          to = XXX,
          subject = "Arbeitszeiten",
          body = body_text,
          html = TRUE,
          inline = TRUE,
          smtp = list(host.name = "X",
                      port = X,
                      user.name = "X",
                      passwd = "X",
                      ssl = TRUE),
          authenticate = TRUE,
          send = TRUE)

send.mail(from = XXX,

to = XXX,

subject = "Arbeitszeiten",

body = body_text,

html = TRUE,

inline = TRUE,

smtp = list(host.name = "X",

port = X,

user.name = "X",

passwd = "X",

ssl = TRUE),

authenticate = TRUE,

send = TRUE)

Das Ergebnis sieht dann auf dem Handy so aus:

Screenshot aus der Arbeitszeiten-Mail auf dem Handy

Benedict Witzenberger

8. Mai 2019

Wie sich das Grundgesetz in 70 Jahren verändert hat

Unsere Verfassung feiert runden Geburtstag – wie stark der Text seit 1949 umgeschrieben wurde, habe ich in einem Projekt recherchiert.

Rund 70 000 Zeichen hatte das Grundgesetz im Jahr 1949. Heute sind es deutlich mehr, denn in insgesamt 63 Änderungen wurde viel gestrichen und vor allem hinzugefügt.

In der SZ haben wir zum Verfassungsjubiläum eine Sonderbeilage gemacht. Darin war auch eine Seite voller Grafiken. Unsere Idee dafür: Können wir zeigen, wie sehr sich das Gesetz von heute und das Gesetz von damals unterscheiden?

Ein CCC-Projekt will das Grundgesetz versionieren

Ein bisschen Glück hatten wir in diesem Fall, denn die Daten waren schon zum großen Teil da. Ein Projekt des chaospott in Essen hat vor einigen Jahren versucht, das Grundgesetz versionierbar zu machen – also jede Änderung im Text nachvollziehbar zu speichern. Ähnlich wie Computercode (aus der Richtung kommen die chaospott-Leute auch).

Für das Projekt haben sie extra die Software DocPatch geschrieben (hier auf Github). Die sorgt dafür, dass aus den einzelnen Dateien, die jede Änderung im Text beschreiben (sogenannte Patches) am Ende wieder ein kompletter Text wird – und sogar in verschiedenen Ausgabeformaten ausgegeben werden kann (zum Beispiel in PDF, Word, Markdown, Plaintext).

Mit dem Versionskontrolltool quilt tracken die Leute vom chaospott jede Änderung, die eine neue Version des Grundgesetzes enthält. Und das kann auf einmal gleich mehrere Artikel betreffen. Sie spielen quasi jede Version einmal durch, damit quilt weiß, was es für eine bestimmte Version verändern muss.

Auf einem Githubrepository werden dann alle Versionen Patches gespeichert, die geben an, was vom ursprünglichen Text verändert werden muss, damit der jeweilige Text rauskommt. Der Vorteil: DocPatch kann ganz einfach auch andere Versionen als die aktuelle ausgeben.

So sieht ein solcher Patch aus:

--- a/013.md
+++ b/013.md
@@ -2,5 +2,9 @@
 
 (1) Die Wohnung ist unverletzlich.
 (2) Durchsuchungen dürfen nur durch den Richter, bei Gefahr im Verzuge auch durch die in den Gesetzen vorgesehenen anderen Organe angeordnet und nur in der dort vorgeschriebenen Form durchgeführt werden.
-(3) Eingriffe und Beschränkungen dürfen im übrigen nur zur Abwehr einer gemeinen Gefahr oder einer Lebensgefahr für einzelne Personen, auf Grund eines Gesetzes auch zur Verhütung dringender Gefahren für die öffentliche Sicherheit und Ordnung, insbesondere zur Behebung der Raumnot, zur Bekämpfung von Seuchengefahr oder zum Schutze gefährdeter Jugendlicher vorgenommen werden.
+(3) Begründen bestimmte Tatsachen den Verdacht, daß jemand eine durch Gesetz einzeln bestimmte besonders schwere Straftat begangen hat, so dürfen zur Verfolgung der Tat auf Grund richterlicher Anordnung technische Mittel zur akustischen Überwachung von Wohnungen, in denen der Beschuldigte sich vermutlich aufhält, eingesetzt werden, wenn die Erforschung des Sachverhalts auf andere Weise unverhältnismäßig erschwert oder aussichtslos wäre. Die Maßnahme ist zu befristen. Die Anordnung erfolgt durch einen mit drei Richtern besetzten Spruchkörper. Bei Gefahr im Verzuge kann sie auch durch einen einzelnen Richter getroffen werden.
+(4) Zur Abwehr dringender Gefahren für die öffentliche Sicherheit, insbesondere einer gemeinen Gefahr oder einer Lebensgefahr, dürfen technische Mittel zur Überwachung von Wohnungen nur auf Grund richterlicher Anordnung eingesetzt werden. Bei Gefahr im Verzuge kann die Maßnahme auch durch eine andere gesetzlich bestimmte Stelle angeordnet werden; eine richterliche Entscheidung ist unverzüglich nachzuholen.
+(5) Sind technische Mittel ausschließlich zum Schutze der bei einem Einsatz in Wohnungen tätigen Personen vorgesehen, kann die Maßnahme durch eine gesetzlich bestimmte Stelle angeordnet werden. Eine anderweitige Verwertung der hierbei erlangten Erkenntnisse ist nur zum Zwecke der Strafverfolgung oder der Gefahrenabwehr und nur zulässig, wenn zuvor die Rechtmäßigkeit der Maßnahme richterlich festgestellt ist; bei Gefahr im Verzuge ist die richterliche Entscheidung unverzüglich nachzuholen.
+(6) Die Bundesregierung unterrichtet den Bundestag jährlich über den nach Absatz 3 sowie über den im Zuständigkeitsbereich des Bundes nach Absatz 4 und, soweit richterlich überprüfungsbedürftig, nach Absatz 5 erfolgten Einsatz technischer Mittel. Ein vom Bundestag gewähltes Gremium übt auf der Grundlage dieses Berichts die parlamentarische Kontrolle aus. Die Länder gewährleisten eine gleichwertige parlamentarische Kontrolle.
+(7) Eingriffe und Beschränkungen dürfen im übrigen nur zur Abwehr einer gemeinen Gefahr oder einer Lebensgefahr für einzelne Personen, auf Grund eines Gesetzes auch zur Verhütung dringender Gefahren für die öffentliche Sicherheit und Ordnung, insbesondere zur Behebung der Raumnot, zur Bekämpfung von Seuchengefahr oder zum Schutze gefährdeter Jugendlicher vorgenommen werden.

--- a/013.md

+++ b/013.md

@@ -2,5 +2,9 @@

(1) Die Wohnung ist unverletzlich.

(2) Durchsuchungen dürfen nur durch den Richter, bei Gefahr im Verzuge auch durch die in den Gesetzen vorgesehenen anderen Organe angeordnet und nur in der dort vorgeschriebenen Form durchgeführt werden.

-(3) Eingriffe und Beschränkungen dürfen im übrigen nur zur Abwehr einer gemeinen Gefahr oder einer Lebensgefahr für einzelne Personen, auf Grund eines Gesetzes auch zur Verhütung dringender Gefahren für die öffentliche Sicherheit und Ordnung, insbesondere zur Behebung der Raumnot, zur Bekämpfung von Seuchengefahr oder zum Schutze gefährdeter Jugendlicher vorgenommen werden.

+(3) Begründen bestimmte Tatsachen den Verdacht, daß jemand eine durch Gesetz einzeln bestimmte besonders schwere Straftat begangen hat, so dürfen zur Verfolgung der Tat auf Grund richterlicher Anordnung technische Mittel zur akustischen Überwachung von Wohnungen, in denen der Beschuldigte sich vermutlich aufhält, eingesetzt werden, wenn die Erforschung des Sachverhalts auf andere Weise unverhältnismäßig erschwert oder aussichtslos wäre. Die Maßnahme ist zu befristen. Die Anordnung erfolgt durch einen mit drei Richtern besetzten Spruchkörper. Bei Gefahr im Verzuge kann sie auch durch einen einzelnen Richter getroffen werden.

+(4) Zur Abwehr dringender Gefahren für die öffentliche Sicherheit, insbesondere einer gemeinen Gefahr oder einer Lebensgefahr, dürfen technische Mittel zur Überwachung von Wohnungen nur auf Grund richterlicher Anordnung eingesetzt werden. Bei Gefahr im Verzuge kann die Maßnahme auch durch eine andere gesetzlich bestimmte Stelle angeordnet werden; eine richterliche Entscheidung ist unverzüglich nachzuholen.

+(5) Sind technische Mittel ausschließlich zum Schutze der bei einem Einsatz in Wohnungen tätigen Personen vorgesehen, kann die Maßnahme durch eine gesetzlich bestimmte Stelle angeordnet werden. Eine anderweitige Verwertung der hierbei erlangten Erkenntnisse ist nur zum Zwecke der Strafverfolgung oder der Gefahrenabwehr und nur zulässig, wenn zuvor die Rechtmäßigkeit der Maßnahme richterlich festgestellt ist; bei Gefahr im Verzuge ist die richterliche Entscheidung unverzüglich nachzuholen.

+(6) Die Bundesregierung unterrichtet den Bundestag jährlich über den nach Absatz 3 sowie über den im Zuständigkeitsbereich des Bundes nach Absatz 4 und, soweit richterlich überprüfungsbedürftig, nach Absatz 5 erfolgten Einsatz technischer Mittel. Ein vom Bundestag gewähltes Gremium übt auf der Grundlage dieses Berichts die parlamentarische Kontrolle aus. Die Länder gewährleisten eine gleichwertige parlamentarische Kontrolle.

+(7) Eingriffe und Beschränkungen dürfen im übrigen nur zur Abwehr einer gemeinen Gefahr oder einer Lebensgefahr für einzelne Personen, auf Grund eines Gesetzes auch zur Verhütung dringender Gefahren für die öffentliche Sicherheit und Ordnung, insbesondere zur Behebung der Raumnot, zur Bekämpfung von Seuchengefahr oder zum Schutze gefährdeter Jugendlicher vorgenommen werden.

Die Zeilen mit + und - geben jeweils an, welcher Text hinzugefügt oder entfernt werden soll. Der Ausschnitt bezieht sich auf 013.md – also Artikel 13. md ist der Dateiname für Markdown-Dateien. Die lassen sich sehr einfach in andere Dateiformate umwandeln.

Die Daten waren da – und dann?

Wir hatten also eine gute Datengrundlage für die jeweiligen Versionen des Grundgesetzes – aber wie konnten wir zwei Versionen vergleichen? Dafür habe ich die Software wdiff genutzt.

Anders als die Patches, die versuchen, möglichst große Bereiche zu finden, die sich unterscheiden, vergleicht wdiff auf einer Wort-zu-Wort-Basis. Ist ein Wort, oder nur ein Buchstabe anders, wird die Änderung ausgegeben. Der Vorteil: wdiff gibt den kompletten Text aus, markiert aber, was eingefügt und was gelöscht wurde. Hier am Beispiel einer kleinen Änderung in Artikel 1 Abs. 3:

Artikel 1
---------

(1) Die Würde des Menschen ist unantastbar. Sie zu achten und zu
    schützen ist Verpflichtung aller staatlichen Gewalt.
(2) Das Deutsche Volk bekennt sich darum zu unverletzlichen und
    unveräußerlichen Menschenrechten als Grundlage jeder menschlichen
    Gemeinschaft, des Friedens und der Gerechtigkeit in der Welt.
(3) Die nachfolgenden Grundrechte binden Gesetzgebung, [-Verwaltung-] {+vollziehende
    Gewalt+} und Rechtsprechung als unmittelbar geltendes Recht.

Artikel 1

---------

(1) Die Würde des Menschen ist unantastbar. Sie zu achten und zu

schützen ist Verpflichtung aller staatlichen Gewalt.

(2) Das Deutsche Volk bekennt sich darum zu unverletzlichen und

unveräußerlichen Menschenrechten als Grundlage jeder menschlichen

Gemeinschaft, des Friedens und der Gerechtigkeit in der Welt.

(3) Die nachfolgenden Grundrechte binden Gesetzgebung, [-Verwaltung-] {+vollziehende

Gewalt+} und Rechtsprechung als unmittelbar geltendes Recht.

In R mussten wir also nur noch für jeden Artikel die Zeichen zwischen [--] und {++} zählen – und kamen so auf die Gesetzesteile, die verändert wurden.

Der R-Code für diese Zählung sieht kompliziert aus. Aber hauptsächlich, weil man mit sogenanntem RegEx (Regular Expressions) die Texte zwischen den Klammern extrahieren muss. nchar() berechnet die Zahl der einzelnen Zeichen. Und aus denen kann man hinterher ganz einfach einen Anteil berechnen.

d %>% 
  rowwise() %>% 
  mutate(char_removed = nchar(paste0(unlist(str_extract_all(Text, "(?<=\\[-)[\\s\\S]+?(?=-\\])")), collapse = " ")),
         char_added = nchar(paste0(unlist(str_extract_all(Text, "(?<=\\{\\+)[\\s\\S]+?(?=\\+\\})")), collapse = " ")),
         Text = trimws(str_remove_all(Text, "\\s?\\[[\\s\\S]+?\\]|\\{[\\s\\S]+?\\}\\s?")),
         char_unchanged = nchar(Text)

d %>%

rowwise() %>%

mutate(char_removed = nchar(paste0(unlist(str_extract_all(Text, "(?<=\\[-)[\\s\\S]+?(?=-\\])")), collapse = " ")),

char_added = nchar(paste0(unlist(str_extract_all(Text, "(?<=\\{\\+)[\\s\\S]+?(?=\\+\\})")), collapse = " ")),

Text = trimws(str_remove_all(Text, "\\s?\\[[\\s\\S]+?\\]|\\{[\\s\\S]+?\\}\\s?")),

char_unchanged = nchar(Text)

Das klingt eigentlich ganz einfach. Trotzdem hat das Projekt mehrere Wochen gedauert. Denn zuerst wollte ich jeweils den kompletten Grundgesetztext vergleichen. Das hat überhaupt nicht funktioniert, weil wdiff immer ein Problem damit hatte, wenn neue Artikel eingefügt wurden (also alles mit Kleinbuchstaben: 16a, etc.). Die Lösung war relativ einfach: Immer nur einzelne Artikel vergleichen. In quilt lassen sich diese neuen Artikel auch anlegen, sie werden aber bei der Ausgabe von früheren Versionen des Grundgesetzes nicht mit angezeigt, wenn sie damals noch nicht drinstanden. Ziemlich cooles Tool.

Das Ergebnis fand in der Zeitung auf einer Grafikseite statt – und kann sich sehen lassen, finde ich:

Benedict Witzenberger

3. Mai 2019

Durchs Internet surfen – mit einem Skript in R

Im Internet stehen so viele Informationen. Ein Paradies für Datenjournalisten, die große Mengen an Informationen automatisiert abfragen wollen. Manchmal ist es einfach, an sie heranzukommen, manchmal etwas schwieriger. Denn manche Webseiten laden ihre Daten nicht in den Quellcode – dort, wo die einfachen Lösungen zum sogenannten Webscraping (über Scraping mit Python habe ich schon mal gebloggt) ansetzen. Doch mit ein bisschen Aufwand, können Datenjournalisten auch Seiten abfragen, die ihre Inhalte nachladen oder über Skripte generieren. Der einfachste Anwendungsfall ist aber: Der Weiter-Button.

Neulich hatte ich einen Fall, in dem ich knapp 1500 Daten von Abgeordneten abrufen wollte. Sie waren über eine Suche zugänglich, wurden allerdings nur in Hunderterschritten angezeigt. Ich habe ein Skript geschrieben, dass die Suche startet, jede Seite aufruft, die Informationen speichert und nach allen Abgeordneten auf einer Seite den Weiter-Button drückt. Später kann ich dann jede einzelne Abgeordnetenseite herunterladen.

Zum Glück gibt es „Selenium“. Das ist ein Framework, das ursprünglich dafür entwickelte wurde, um Tests in Browsern zu automatisieren. Um also schnell testen zu können, ob Softwareupdates irgendein Problem für die Nutzer erzeugen. Selenium ahmt dafür das Verhalten eines Nutzers im Webbrowser nach. Es kann Felder ausfüllen, Buttons anwählen oder einen Mausklick simulieren.

Eigentlich basiert Selenium auf HTML und Javascript, für R gibt es aber (wie so oft, zum Glück) ein Package, das die Funktionen anbietet: RSelenium. Für die Extraktion der Informationen benutze ich rvest, eine weitere R-Bibliothek, die HTML-Code in R durchsuchbar macht.

RSelenium im Einsatz

RSelenium hat zwar eine gute Dokumentation, ich musste trotzdem viel rumprobieren, weswegen ich hier mal meine Vorgehensweise dokumentiere. Um rechtlich nicht angreifbar zu sein, habe ich den Namen der URL gelöscht.

Zunächst laden wir die beteiligten Bibliotheken. rvest und RSelenium erwähnte ich bereits, tidyverse ist eine Sammlung von mehreren R-Packages, die für die Arbeit mit Dataframes (also einer Tabelle) in R benutzt werden.

library(rvest)
library(tidyverse)
library(RSelenium)

library(rvest)

library(tidyverse)

library(RSelenium)

# Start RSelenium
link <- "" # hier steht der Link, den ich gelöscht habe - dort startet RSelenium
rD <- rsDriver()
remDr <- rD[["client"]]

# Start RSelenium

link <- "" # hier steht der Link, den ich gelöscht habe - dort startet RSelenium

rD <- rsDriver()

remDr <- rD[["client"]]

RSelenium startet auf einem lokalen Server und lädt dann ein neues Fenster in R. Darin wird ein Browser geöffnet, über den ich nachvollziehen kann was meine Befehle in R bewirken. remDr ist quasi der Browser, den ich steuere. Zum Beispiel lasse ich ihn einen Link öffnen – auf die erste Seite mit den Ergebnissen:

remDr$navigate(link)

1	remDr$navigate(link)

Insgesamt habe ich 14 Ergebnisseiten. Die habe ich händisch abgezählt für den Loop. Alternativ hätte ich auch eine Funktion schreiben können, die erkennt, wenn es keinen Weiter-Button mehr gibt.

14 Mal wiederholt R also den folgenden Vorgang: Es ruft eine Ergebnisseite auf, speichert dann den Link zur Detailseite jedes Abgeordneten, und klickt am Ende der Seite auf den Weiter-Button, den ich hier über seinen sogenannten X-Path finde. Dafür suche ich das Element auf der Seite, das den Text „nächste Treffer“ enthält. Und das ist nur der Weiter-Button.

for (i in seq_along(1:14)) {
  print(i)
  try(next_button <- remDr$findElement(using = 'xpath', "//*[contains(text(), 'nächste Treffer')]"))
  try(next_button$clickElement())
  Sys.sleep(5)
  remDr$setImplicitWaitTimeout(5000)
  html_current <- read_html(remDr$getPageSource()[[1]])

for (i in seq_along(1:14)) {

print(i)

try(next_button <- remDr$findElement(using = 'xpath', "//*[contains(text(), 'nächste Treffer')]"))

try(next_button$clickElement())

Sys.sleep(5)

remDr$setImplicitWaitTimeout(5000)

html_current <- read_html(remDr$getPageSource()[[1]])

Wir sind immer noch im Loop. Ich schreibe auf jeder Seite die Datenin Vektoren. Die Standardherangehensweise beim Webscraping ist allerdings: Detailseite öffnen und dann downloaden. Die Details kann ich dann auf meinem lokalen Rechner extrahieren, ohne unnötigen zusätzlichen Webtraffic bei der Seite zu erzeugen. Das werde ich auch hier tun. Ich sammle ja gerade die Links zu jeder Detailseite. Allerdings auch Namen und eine Information zu den Legislaturperioden der einzelnen Abgeordneten.

  html_current %>% 
    html_nodes(".t_text:nth-child(1) a") %>% 
    html_attr("href") -> urls_current
  urls <- c(urls, urls_current)
  
  html_current %>% 
    html_nodes(".t_text:nth-child(1)") %>% 
    html_text() %>% 
    trimws() -> last_name_curr
  last_name <- c(last_name, last_name_curr)
  
  html_current %>% 
    html_nodes(".t_text:nth-child(2)") %>% 
    html_text() %>% 
    trimws() -> first_name_curr
  first_name <- c(first_name, first_name_curr)
  
  html_current %>% 
    html_nodes(".t_text:nth-child(4)") %>% 
    html_text() %>% 
    trimws() -> length_lt_curr
  length_lt <- c(length_lt, length_lt_curr)
  
  Sys.sleep(5)
}

html_current %>%

html_nodes(".t_text:nth-child(1) a") %>%

html_attr("href") -> urls_current

urls <- c(urls, urls_current)

html_current %>%

html_nodes(".t_text:nth-child(1)") %>%

html_text() %>%

trimws() -> last_name_curr

last_name <- c(last_name, last_name_curr)

html_current %>%

html_nodes(".t_text:nth-child(2)") %>%

html_text() %>%

trimws() -> first_name_curr

first_name <- c(first_name, first_name_curr)

html_current %>%

html_nodes(".t_text:nth-child(4)") %>%

html_text() %>%

trimws() -> length_lt_curr

length_lt <- c(length_lt, length_lt_curr)

Sys.sleep(5)

}

5 Sekunden lasse ich das Skript hier am Ende ruhen, damit ich nicht zu viel Last auf dem Server erzeuge. Das ist allerdings schon eine sehr lange Zeitspanne.

Während das Skript läuft, kann ich weiterarbeiten. Die R-Bibliothek BeepR spielt einen Sound ab, wenn alle Dateien heruntergeladen wurden. Dann verbinde ich die einzelnen Vektoren zu einem Dataframe in R, mit dem ich dann fortfahren kann. In meinem Fall loope ich jetzt über die einzelnen Links und lade die Dateien herunter. Das hätte ich aber natürlich auch schon im Schritt oben machen können. Ich habe mich aber dagegen entschieden, weil ich erstmal alle Links bekommen wollte, und mit denen dann weiterarbeiten kann.

beepr::beep()

df_abgeordnete <- cbind(first_name,last_name,urls,length_lt)

beepr::beep()

df_abgeordnete <- cbind(first_name,last_name,urls,length_lt)

Am Ende stoppe ich den Seleniumbrowser, der lokal auf meinem Rechner lief.

remDr$close()
# stop the selenium server
rD[["server"]]$stop()

remDr$close()

# stop the selenium server

rD[["server"]]$stop()

Fertig.

Benedict Witzenberger

27. Mai 2018

Shiny statt Javascript

Mit Javascript wird das Internet interaktiv. Das kann auch bei Datenanalysen wichtig sein. Mit „Shiny“ klappt sowas auch in R – ganz ohne Javascriptkenntnisse.

Benedict Witzenberger

3. Mai 2017

Werkstatt: Zu Fuß durch den Münchner Innenraum

Mit Kartendaten lassen sich tolle Analysen und Anwendungen bauen. Ich bin ein großer Verfechter der Open Street Map (merkt man kaum in diesem Blog). Mit deren Hilfe habe ich auch eine etwas andere Innenraumkarte für die Münchner öffentlichen Verkehrsmittel gebaut.

Benedict Witzenberger

14. April 2017

Wie ich R gelernt habe

Inzwischen professionalisiert sich der Datenjournalismus. Es gibt immer noch Kollegen, die es schaffen, mit Excel Auswertungen zu machen. Das geht. Aber es geht auch anders. Mit R zum Beispiel.

Benedict Witzenberger

24. Februar 2017

Werkstatt: Wie voll sind die Münchner Bibliotheken?

Studenten in München haben es nicht leicht. Die Mietpreise sind der Wahnsinn, es gab großen Stress um das relativ teuere Semesterticket – und dann sind die Bibliotheken noch so voll. Das war zumindest der Anlass, weshalb die Universitätsbibliothek der LMU Ende 2016 ein neues Tool gestartet hat: Den Platzfinder. Zusammen mit einer Parkscheibe, die Studierende bekommen, wenn sie die Bibliothek betreten, ermitteln die Bibliotheksmitarbeiter, wie voll ihre Bibliothek gerade ist – und tragen das in ein Onlineformular ein (Was natürlich auch sehr fehlerbehaftet ist – aber die Daten sind das Beste, was wir haben).

Auf der Webseite der Uni-Bibliothek können Studierende dann checken, wie voll ihre „Lieblingsbib“ ist.

Für M94.5 wollte ich herausfinden, welche Bib am vollsten ist – und wie sich das im Tagesverlauf verändert.

Die Seite der LMU gibt SVGs mit Prozentwerten für die Füllung aus, die in den Balkendiagrammen angezeigt werden. Mit Python und der Bibliothek BeautifulSoup konnte ich also easy die Daten auslesen und in ein CSV speichern:

#!/usr/bin/python
# -*- coding: utf-8 -*-
from bs4 import BeautifulSoup
import urllib
import re
import csv
from datetime import datetime

r = urllib.urlopen('http://www.ub.uni-muenchen.de/arbeiten/platzfinder/index.html').read()

soup = BeautifulSoup(r, "lxml")

iframes = soup.find_all("iframe")
csvdata = []

print "Sammle Daten"
for i in iframes:
    r1 = urllib.urlopen(i["src"]).read()
    iframe = BeautifulSoup(r1, "lxml")
    name = iframe.find("div", {"id": "chart_text1"}).get_text().encode('utf-8')
    data = iframe.find_all("script")[1].string
    data = data.replace("'", '"')
    p = re.compile('var data = google.visualization.arrayToDataTable\(\[\[(.*?)\],\[.+"\,(.*?)\]\]\)')
    m = p.search(data)
    try:
        lst = str(m.group(2).encode('utf-8')).split(",")
    except:
        lst = str(m.group(0).encode('utf-8')).split(",")

    if lst[0] == "1":
        name = name.strip()
        fill = "Geschlossen"
        empty = 0
    else:
        name = name.strip()
        fill = lst[0]
        empty = lst[1]

    csvdata.append((name, fill, empty))
    print "Schreibe: ", i["src"]

# open a csv file with append, so old data will not be erased
with open('data.csv', 'a') as csv_file:
    writer = csv.writer(csv_file, delimiter=';', lineterminator='\n')
    # The for loop
    print "Schreibe CSV"
    for name, fill, empty in csvdata:
        writer.writerow([name, fill, empty, datetime.now()])
print "Fertig"

#!/usr/bin/python

# -*- coding: utf-8 -*-

from bs4 import BeautifulSoup

import urllib

import re

import csv

from datetime import datetime

r = urllib.urlopen('http://www.ub.uni-muenchen.de/arbeiten/platzfinder/index.html').read()

soup = BeautifulSoup(r, "lxml")

iframes = soup.find_all("iframe")

csvdata = []

print "Sammle Daten"

for i in iframes:

r1 = urllib.urlopen(i["src"]).read()

iframe = BeautifulSoup(r1, "lxml")

name = iframe.find("div", {"id": "chart_text1"}).get_text().encode('utf-8')

data = iframe.find_all("script")[1].string

data = data.replace("'", '"')

p = re.compile('var data = google.visualization.arrayToDataTable$\[\[(.*?)\],\[.+"\,(.*?)\]\]$')

m = p.search(data)

try:

lst = str(m.group(2).encode('utf-8')).split(",")

except:

lst = str(m.group(0).encode('utf-8')).split(",")

if lst[0] == "1":

name = name.strip()

fill = "Geschlossen"

empty = 0

else:

name = name.strip()

fill = lst[0]

empty = lst[1]

csvdata.append((name, fill, empty))

print "Schreibe: ", i["src"]

# open a csv file with append, so old data will not be erased

with open('data.csv', 'a') as csv_file:

writer = csv.writer(csv_file, delimiter=';', lineterminator='\n')

# The for loop

print "Schreibe CSV"

for name, fill, empty in csvdata:

writer.writerow([name, fill, empty, datetime.now()])

print "Fertig"

Damit das Ganze alle 15 Minuten laufen kann – in den Zeiten, in denen die Bibliotheken geöffnet haben – habe ich zu einem Trick gegriffen. Das Pythonskript lag auf meinem Webspace, der Python vorinstalliert hat. Daneben lag ein einfaches Shell-Startskript für das Python. Dieses Skript rufe ich über über einen Cronjob auf. In meinem Fall habe ich Cronjob.de benutzt (ein Skript ist kostenlos, weitere kosten ab 99 Cent pro Monat) – es gibt Alternativen.

Dann hieß es: Warten. 1,5 Monate lang etwa. Das CSV füllte sich immer weiter, ohne, dass ich irgendwas tun musste.

Dann hieß es: Auswerten. Dafür habe ich das CSV gedownloaded und in R eingelesen.

library(dplyr)
library(ggplot2)
library(lubridate)
library(extrafont)
library(grid)

colN <- c("Bibliothek", "Belegt", "Leer", "Datum")
d <- read.csv2("data.csv", stringsAsFactors = TRUE, col.names = colN, colClasses = c("factor", "numeric", "numeric", "POSIXct"), header = FALSE, encoding = "UTF-8", na.strings = "Geschlossen")

library(dplyr)

library(ggplot2)

library(lubridate)

library(extrafont)

library(grid)

colN <- c("Bibliothek", "Belegt", "Leer", "Datum")

d <- read.csv2("data.csv", stringsAsFactors = TRUE, col.names = colN, colClasses = c("factor", "numeric", "numeric", "POSIXct"), header = FALSE, encoding = "UTF-8", na.strings = "Geschlossen")

Schon beim ersten Rumspielen hat sich gezeigt: Weihnachten ist ne blöde Zeit für den Datensatz. Im Vergleich zu den anderen Zeiten lag die Belegungsquote ziemlich weit unten. Das hieß für mich: Weihnachten raus.

#Remove Test-Data and create new columns, filter out Christmas-Time
d %>% 
  filter(Datum > "2016-12-17 23:45:29") %>% 
  filter(Datum <= "2016-12-23 23:59:59" | Datum >= "2017-01-02 00:00:00") %>% 
  mutate(weekday = weekdays.POSIXt(Datum), hour = hour(Datum)) -> w

w$weekday <- factor(w$weekday, levels = c("Montag", "Dienstag", "Mittwoch", "Donnerstag", "Freitag", "Samstag", "Sonntag"))

#Remove Test-Data and create new columns, filter out Christmas-Time

d %>%

filter(Datum > "2016-12-17 23:45:29") %>%

filter(Datum <= "2016-12-23 23:59:59" | Datum >= "2017-01-02 00:00:00") %>%

mutate(weekday = weekdays.POSIXt(Datum), hour = hour(Datum)) -> w

w$weekday <- factor(w$weekday, levels = c("Montag", "Dienstag", "Mittwoch", "Donnerstag", "Freitag", "Samstag", "Sonntag"))

Dann folgten die einzelnen Analysen. Zunächst wollte ich wissen (und natürlich auch plotten), wie groß der Unterschied zwischen Wochentag und Wochenende in den Bibliotheken ist.

# create tbl_df for weekend and weekday with mean per hour
w %>% 
  select(Bibliothek, Belegt, weekday, hour, Datum) %>% 
  filter(complete.cases(.)) %>% 
  filter(weekday != "Samstag" & weekday != "Sonntag") %>% 
  group_by(hour) %>% 
  summarise(mean(Belegt)) -> week

w %>% 
  select(Bibliothek, Belegt, weekday, hour, Datum) %>%
  filter(complete.cases(.)) %>% 
  filter(weekday == "Samstag" | weekday == "Sonntag") %>% 
  group_by(hour) %>% 
  summarise(mean(Belegt)) -> weekend

## Plotting Weekday vs Weekend
svg("week_vs_weekend.svg", pointsize = 28, width = 11.78, height = 8.39)
ggplot() +
  geom_line(data = weekend, aes(hour, `mean(Belegt)`), color = "#590086", size = 1.3) +
  geom_area(data = weekend, aes(hour, `mean(Belegt)`), color = "#dd9aff", alpha = 0.2) +
  geom_line(data = week, aes(hour, `mean(Belegt)`), color = "#865900", size = 1.3) +
  geom_area(data = week, aes(hour, `mean(Belegt)`), fill = "#ffd686", alpha = 0.6) +
  labs(title = "Durchschnitts-Belegung im Tagesverlauf", subtitle = "Braun: Werktag, Blau: Wochenende") +
  ylab("Belegung in Prozent") + 
  xlab("Uhrzeit") +
  theme_bw() +
  theme(text = element_text(size = 12),
        plot.margin = unit(c(1, 1, 4, 1), "lines"),
        panel.grid.major.x = element_blank(),
        panel.grid.minor.x = element_blank(),
        panel.border = element_blank())
dev.off()

# create tbl_df for weekend and weekday with mean per hour

w %>%

select(Bibliothek, Belegt, weekday, hour, Datum) %>%

filter(complete.cases(.)) %>%

filter(weekday != "Samstag" & weekday != "Sonntag") %>%

group_by(hour) %>%

summarise(mean(Belegt)) -> week

w %>%

select(Bibliothek, Belegt, weekday, hour, Datum) %>%

filter(complete.cases(.)) %>%

filter(weekday == "Samstag" | weekday == "Sonntag") %>%

group_by(hour) %>%

summarise(mean(Belegt)) -> weekend

## Plotting Weekday vs Weekend

svg("week_vs_weekend.svg", pointsize = 28, width = 11.78, height = 8.39)

ggplot() +

geom_line(data = weekend, aes(hour, `mean(Belegt)`), color = "#590086", size = 1.3) +

geom_area(data = weekend, aes(hour, `mean(Belegt)`), color = "#dd9aff", alpha = 0.2) +

geom_line(data = week, aes(hour, `mean(Belegt)`), color = "#865900", size = 1.3) +

geom_area(data = week, aes(hour, `mean(Belegt)`), fill = "#ffd686", alpha = 0.6) +

labs(title = "Durchschnitts-Belegung im Tagesverlauf", subtitle = "Braun: Werktag, Blau: Wochenende") +

ylab("Belegung in Prozent") +

xlab("Uhrzeit") +

theme_bw() +

theme(text = element_text(size = 12),

plot.margin = unit(c(1, 1, 4, 1), "lines"),

panel.grid.major.x = element_blank(),

panel.grid.minor.x = element_blank(),

panel.border = element_blank())

dev.off()

Dann wollte ich wissen, wie die unterschiedlichen Wochentage sich einzeln unterscheiden. Das könnte man in ggplot mit Facets lösen. Ich wollte das ganze aber in einem Plot. Das hieß: Rumspielen.

# Plotting Every day by hour
w %>% 
  select(Bibliothek, Belegt, weekday, hour, Datum) %>%
  filter(Datum <= "2016-12-23 23:59:59" | Datum >= "2017-01-02 00:00:00") %>% 
  filter(complete.cases(.)) %>% 
  group_by(weekday, hour) %>% 
summarise(mean = mean(Belegt)) -> weekday_by_hour

svg("weekday_per_hour.svg", pointsize = 28, width = 11.78, height = 8.39)
#png("weekday_per_hour.png", pointsize = 28, width = 500)
g1 <- ggplot(weekday_by_hour, aes(x = interaction(weekday, hour, lex.order = TRUE), y = mean, group = 1)) +
  geom_line(colour = "#008659", size = 1.3) +
  geom_area(fill = "#86ffd6", alpha = 0.5) +
  coord_cartesian(ylim = c(0, 65), expand = FALSE) +
  annotate(geom = "text", x = seq_len(nrow(weekday_by_hour)), y = -1, label = weekday_by_hour$hour, size = 2) +
  annotate(geom = "text", x = 9 + 16 * (0:6), y = -4, label = unique(weekday_by_hour$weekday), size = 5) +
  theme_bw() +
  theme(text = element_text(size = 12),
        plot.margin = unit(c(1, 1, 4, 1), "lines"),
        axis.title.x = element_blank(),
        axis.text.x = element_blank(),
        panel.grid.major.x = element_blank(),
        panel.grid.minor.x = element_blank(),
        panel.border = element_blank()) +
  geom_hline(yintercept = mean(weekday_by_hour$mean), linetype = 3) +
  ylab("Durchschnittsbelegung in Prozent")

g2 <- ggplot_gtable(ggplot_build(g1))
g2$layout$clip[g2$layout$name == "panel"] <- "off"
grid::grid.draw(g2)
dev.off()

# Plotting Every day by hour

w %>%

select(Bibliothek, Belegt, weekday, hour, Datum) %>%

filter(Datum <= "2016-12-23 23:59:59" | Datum >= "2017-01-02 00:00:00") %>%

filter(complete.cases(.)) %>%

group_by(weekday, hour) %>%

summarise(mean = mean(Belegt)) -> weekday_by_hour

svg("weekday_per_hour.svg", pointsize = 28, width = 11.78, height = 8.39)

#png("weekday_per_hour.png", pointsize = 28, width = 500)

g1 <- ggplot(weekday_by_hour, aes(x = interaction(weekday, hour, lex.order = TRUE), y = mean, group = 1)) +

geom_line(colour = "#008659", size = 1.3) +

geom_area(fill = "#86ffd6", alpha = 0.5) +

coord_cartesian(ylim = c(0, 65), expand = FALSE) +

annotate(geom = "text", x = seq_len(nrow(weekday_by_hour)), y = -1, label = weekday_by_hour$hour, size = 2) +

annotate(geom = "text", x = 9 + 16 * (0:6), y = -4, label = unique(weekday_by_hour$weekday), size = 5) +

theme_bw() +

theme(text = element_text(size = 12),

plot.margin = unit(c(1, 1, 4, 1), "lines"),

axis.title.x = element_blank(),

axis.text.x = element_blank(),

panel.grid.major.x = element_blank(),

panel.grid.minor.x = element_blank(),

panel.border = element_blank()) +

geom_hline(yintercept = mean(weekday_by_hour$mean), linetype = 3) +

ylab("Durchschnittsbelegung in Prozent")

g2 <- ggplot_gtable(ggplot_build(g1))

g2$layout$clip[g2$layout$name == "panel"] <- "off"

grid::grid.draw(g2)

dev.off()

Und dann das Highlight. Ich dachte mir, ein bisschen Bewegung schadet nicht. Deswegen wollte ich ein GIF erstellen, dass für jede Stunde des Tages für jede Bibliothek die Durchschnittsbelegung angibt. Das Skript sollte mir die einzelnen Stunden automatisch ausgeben, damit ich daraus nur noch ein GIF bauen muss. (Das würde auch direkt in R gehen, mit diesem Package)

Ich habe meinen w-Dataframe nochmal kopiert, weil ich die Rohdaten-NAs durch 0 ersetzt habe. Das wollte ich mir im Original-Datensatz nicht zerschießen.

##
# Create PNG for each Hour of the Day
###

#Make copy of w-df
w_nas <- w

#replace NAs with 0
w_nas[is.na(w_nas$Belegt),]$Belegt <- 0

#Debugging needed for the hjust of plot.title
for (i in 8:23){
  w_help = NULL

  w_nas %>% 
    filter(hour==i) %>% 
    group_by(Bibliothek) %>% 
    summarise(mean = mean(Belegt)) -> w_help
  print(head(w_help))
  
  png(paste0(i,".png"), width = 500, units = "px")
  p <- ggplot(w_help, aes(Bibliothek, mean)) +
    geom_bar(stat="identity", fill = "#008659") +
    coord_flip() +
    theme(text = element_text(family = "Arial"), axis.title = element_blank(), plot.title = element_text(face = "bold", size = 18)) +
    labs(title = paste("Besetzte UB-Plätze um", i, "Uhr")) +
    scale_y_continuous(limits = c(0, 100))
  print(p)
  dev.off()
}

# Create PNG for each Hour of the Day

###

#Make copy of w-df

w_nas <- w

#replace NAs with 0

w_nas[is.na(w_nas$Belegt),]$Belegt <- 0

#Debugging needed for the hjust of plot.title

for (i in 8:23){

w_help = NULL

w_nas %>%

filter(hour==i) %>%

group_by(Bibliothek) %>%

summarise(mean = mean(Belegt)) -> w_help

print(head(w_help))

png(paste0(i,".png"), width = 500, units = "px")

p <- ggplot(w_help, aes(Bibliothek, mean)) +

geom_bar(stat="identity", fill = "#008659") +

coord_flip() +

theme(text = element_text(family = "Arial"), axis.title = element_blank(), plot.title = element_text(face = "bold", size = 18)) +

labs(title = paste("Besetzte UB-Plätze um", i, "Uhr")) +

scale_y_continuous(limits = c(0, 100))

print(p)

dev.off()

}

Fertig.

Das Ergebnis gibt es hier.