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

So sieht das Applet in IFTTT aus.

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:

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:

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:

Das Ergebnis sieht in R so aus:

Die Wochenarbeitszeiten in R

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

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:

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

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:

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

Das Ergebnis sieht dann auf dem Handy so aus:

Screenshot aus der Arbeitszeiten-Mail auf dem Handy

Webscraping in Python 3: Wie ich es mache

Eine alte Datenjournalistenregel besagt: Wenn Du es einem Praktikanten geben willst, schreib einen Scraper. Stimmt nicht immer, aber oft. Denn grundsätzlich geht das sehr einfach. Ein Tutorial.

Mehr lesen

Von einem Ort zum anderen

Distanzmatrix der U6 in München.

Danke, Google Maps. Wer hätte vor zwanzig Jahren gedacht, dass man heute keinen Landkarten mehr lesen können muss, um an sein Ziel zu kommen? Aus journalistischer Sicht lassen sich mit Kartendaten zudem richtig coole Geschichten erzählen. Und damit meine ich nicht, irgendwelche Punkte auf eine Karte zu setzen, hinter denen sich Popups öffnen. Ich meine Geschichten, die mit geografischen Einheiten spielen.

Mehr lesen

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.

Mehr lesen

Freie Karte für freie Bürger

Wie oft denkt man über folgende Fragen nach:

  • Wo ist der nächste Briefkasten?
  • Wo ist die nächste U-Bahnstation?
  • Wo ist der nächste Spielplatz?

 

Ganz alltägliche Fragen, für die es zahlreiche Apps gibt, um sie zu beantworten. Aber: Es gibt auch ein Tool, dass alle diese Fragen beantworten kann – und darüber hinaus noch viele mehr. Und das beste: Es bietet die Antworten maschinenlesbar an, unter einer freien Lizenz. Es geht um die Open Street Map.

Das Projekt exisitert seit 2006 und hat sich zum Ziel genommen frei verfügbare Geodaten anzubieten, damit die Nutzer daraus Landkarten bauen, oder per GPS navigieren können. Während die normalen Kartenabieter, wie Google oder Apple, ihre Karten unter Lizenz stellen, können wir die OSM-Daten frei benutzen, nur eine kleine Quellenangabe ist fällig.

Die OSM abfragen

Wie wohl die meisten Geodaten besteht die OSM aus drei Hauptbestandteilen: Punkten (Nodes), Kanten (Ways) und Verbindungen (Relations). Die haben nicht nur Koordinaten, sondern können auch Key-Value-Paare besitzen, die beschreiben, was die einzelnen Bestandteile sind. Telefonzellen heißen zum Beispiel: amenity = telephone, Bahnhöfe railway = station. Diese Kombinationen heißen: Tags. (Zehn nützliche und/oder lustige Tags habe ich hier zusammengeschrieben)
Besagte Telefonzellen können dann aber noch mehr Infos haben: Den Betreiber (operator = Deutsche Telekom AG), eine Angabe, ob sie überdacht sind (covered = yes/no) oder sogar die Telefonnummer. Einen guten Überblick darüber, was ein Punkt für Informationen haben kann, liefert Nominatim (einfach mal nen Ort eingeben).

Mit der API lässt sich alles finden

Über die OSM-Karte kann man sich das anzeigen lassen, zur automatisierten Abfrage gibt es eine API – die Overpass API. Inzwischen hat die so viele Instanzen, dass man damit ordentlich arbeiten kann. (Mein Haupt-Nachschlagewerk dafür ist das Wiki hier, mit vielen Beispielen.) Sehr cool finde ich, dass man mit Query-Forms sogar ohne ein Skript zu schreiben, abfragen kann. Und auch die zahlreichen Exportoptionen (JSON, XML, CSV) reichen voll aus. Wie so eine Beispielquery in R aussehen kann:

 

Der API-Einstieg mit Overpass Turbo

Wer sich nicht so gut mit APIs auskennt, oder ersteinmal experimentieren will: Es gibt einen super Einstieg. Overpass Turbo. Damit kann man sehr schnell ausprobieren, was möglich ist mit der OSM, und wie eine Suchabfrage aussehen kann. Im Idealfall kann man sie über die Overpass Turbo auch gleich ausführen. Ein Beispiel: Wir wollen wissen, wo in München Bahnhöfe sind. Ich weiß nichtmal, in welcher Bounding Box (also von welchen Koordinaten umgeben) München liegt. Die OSM hat aber auch einen Geocoder, der aus Orten Koordinaten macht.

In der Overpass Turbo gibt es einen Wizard, bei dem ich meine Suchanfrage ganz easy eingeben kann:

Es baut daraus die Abfrage – ich muss gar nichts machen.

Natürlich könnte ich hier noch manuell was verändern. In der Overpass API würde ich zum Beispiel ganz oben ein [out:csv(::id,::type,"name")]; einfügen, um eine CSV-Ausgabe zu erzeugen (und ich kann genau festlegen, welche Felder ich gerne hätte. Auch kann ich mit dem Befehl area[name="München"] den Ort händisch festlegen. Es kann sich auch anbieten, für die Bahnhöfe nur nach Nodes zu suchen, oder in anderen Fällen nur nach Straßen.

Overpass Turbo schickt seine Anfrage an die Overpass API und gibt das Ergebnis als Karte zurück.

Das Ergebnis lässt sich jetzt direkt als GeoJSON, GPX oder KML exportieren. Für CSV oder XML kann man die Abfrage für die Overpass API konvertieren lassen. Overpass Turbo hilft auf jeden Fall zu checken, ob die Suchbegriffe die richtigen sind. Für größere Abfragen muss man dann aber die Overpass API nutzen, Turbo hängt sehr schnell.

Die Daten kann ich dann super visualisieren, zum Beispiel mit QGIS. Ich kann sie aber auch als Ausgangspunkt für eine weitere Analyse nutzen. Es gibt auch Anwendungsfälle, in denen mit OSM-Höhendaten 3D-Modelle gebaut wurden. Der Fantasie sind da sehr wenige Grenzen gesetzt.

10 coole OpenStreetMap-Tags

Eine kleine Zusammenstellung von verrückten und hilfreichen Tags der Punkte, Wege und Relationen der OpenStreetMap.

building=yes ist der am meisten verwendete Tag in der OpenStreetMap. Er zeigt an: Das hier ist ein Gebäude.

emergency=fire_hydrant zeigt die Position von Hydranten.

highway = ... Der Klassiker für die Suche nach Straßen. Es gibt zahlreiche Einschränkungen, zu Beispiel residential (Wohngebiet), motorway (Autobahn), pedestrian (Fußgängerzone)

highway=bus_stop zeigt Bushaltestellen.

maxspeed = 50 sucht nach Straßen, bei denen die Höchstgeschwindigkeit (in km/h) hinterlegt wurde.

religion=christian zeigt christliche Gebetsstätten – klappt auch mit anderen Konfessionen.

ice_cream = yes/no gibt an, ob es in einem amenity = restaurant/cafe oder shop = ice_cream Eis gibt.

wheelchair=yes zeigt behindertengerechte Toiletten an.

boundary=administrative + admin_level=2 gibt Verwaltungsgrenzen zurück. In diesem Fall die Staatsgrenze. Geht aber teilweise runter bis auf Stadtbezirksteile. Ein Überblick hier.

name:de:1953-1990=Ernst-Thälmann-Straße Das „de“ und die Jahreszahlen schränken ein, wie die Straße früher hieß. Bietet sich natürlich in Deutschland an, bei den Umbenennungen nach der DDR.

So lassen sich die richtigen Tags finden

Die OpenStreetMap lebt ja von den Tags – deswegen sind sie auch sehr gut dokumentiert. Ich schaue am liebsten hier im OSM-Wiki und hier bei Taginfo. Sehr anschaulich ist auch der Eintrag „How to map a“.