API Archive • Benedict Witzenberger

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

2. März 2017

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:

library(RCurl)
myQuery <- paste0("[out:csv(::id,::type,\"name\",::lat,::lon)];area[\"name\"=\"München\"];node[\"railway\"=\"station\"](area);(._;>;);out%20body;")
url <- paste0("http://overpass-api.de/api/interpreter?data=", myQuery)
response <- getURL(url, .encoding = "UTF-8")
response_csv <- read.csv(text = response, head = TRUE, sep="\t", stringsAsFactors = FALSE)

library(RCurl)

myQuery <- paste0("[out:csv(::id,::type,\"name\",::lat,::lon)];area[\"name\"=\"München\"];node[\"railway\"=\"station\"](area);(._;>;);out%20body;")

url <- paste0("http://overpass-api.de/api/interpreter?data=", myQuery)

response <- getURL(url, .encoding = "UTF-8")

response_csv <- read.csv(text = response, head = TRUE, sep="\t", stringsAsFactors = FALSE)

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.