Neueste Artikel

Kategorien

Suchen

Facebook

Sonstiges

RSS-Feed-Icon RSS-Feed

Visualisierung der Vorratsdaten als neu markieren

Wow, nach nur 5 Monaten komme ich auf die geniale Idee, ein kleines „Making of Vorratsdaten-Visualisierung” zu posten!

Die Visualisierung der Vorratsdaten von Malte Spitz war eigentlich nur ein kleines hübsches Projekt. Welche Resonanz diese Visualisierung zur Folge hatte, hat mich wirklich überrascht. Nicht nur die New York Times hatte darüber berichtet, auch US-Abgeordnete wurden aktiv. Z.B. stand im WIRED Magazine:

Never before had a mobile phone company been shown to have such a detailed log on a single customer. Already, Spitz's story has created ripples reaching the United States, where congressmen Edward Markey and Joe Bartain have sent letters to AT&T, Verizon, Sprint and T-Mobile demanding disclosure on their data collection and storage practices. "Location, location, location may be the favored currency of the real estate industry but it is sensitive information for mobile phone users that must be safeguarded," said Rep. Markey. "Collecting, storing and disclosing a consumer's exact whereabouts for commercial purposes without their express permission is unacceptable and violates current law."

Und zu guter Letzt wurde das Ding auch noch mit einem Lead Award und einem Grimme Online Award ausgezeichnet! Ich glaube ab jetzt ist ein kleines „Making of” gerechtfertigt.

Um das Ding hier geht es:

Etwa im Februar 2011 suchte Lorenz Matzat von OpenDataCity Unterstützung für eine Web-Visualisierung von Vorratsdaten. Sofort war mir die Qualität der Herausforderung klar! Ich musste das einfach machen! Ohne Frage! :)

Ich bekam dann ein dickes Excel-Monstrum in die Hand. So ein Ding mit 20 Spalten und 35.831 Zeilen. Das Monstrum sah ungefähr so aus:


(In der unteren Bildhälfte sind die restlichen Spalten zu sehen.)

Die Felder mit XXXXXXXX sind von der Deutschen Telekom geschwärzt worden, um den jeweils anderen Gesprächsteilnehmer zu anonymisieren. Das war Teil des juristischen Deals, damit Malte noch vor der Löschung der Vorratsdaten an die eigenen Daten kommen konnte.

Nach dem Säubern musste man sich irgendwie einen Überblick über die Daten verschaffen. Das ist aber gar nicht so einfach! Die Geokoordinaten sind ja nur Punkte von Mobilfunkstationen. Um sich einen Überblick zu verschaffen, musste man auch irgendwie die Senderichtung der Antennen, als auch die Zeitkomponente darstellen. Dafür gibt es aber gar keine Tools! Die einzige Variante überhaupt war es, extra ein Tool für diese Art von Daten zu entwickeln. Schon nach einem Wochenende war der erste Prototyp geboren:

Die Leute sind immer wieder überrascht, dass bereits nach 2 Tagen das Ding im Groben schon so weit war. Das war aber gar nicht unser Ziel. Eigentlich wollten wir in einer Visualisierung nur einen einzigen Tag darstellen. Wir benötigten aber ein Recherche-Tool, um überhaupt uns einen Überblick zu verschaffen. Erst schrittweise haben wir erkannt, dass wir nicht einen einzelnen Tag visualisieren sollten, sondern unser Recherche-Tool als journalistisches Werkzeug für die Öffentlichkeit aufbereiten sollten. In zahlreichen Schritten haben Lorenz und ich das Werkzeug deshalb weiter entwickelt:

Eines der Features war es, die ungefähre Position von Malte darzustellen. Dazu musste man seine Position über einen Zeitraum von 6 Monaten schätzen. Bei 181 Tagen mit je 1.440 Minuten macht das 260.640 Geopositionen. Diese habe ich mit einem Optimierungsverfahren aus den Mobilfunkdaten errechnet. Interessanterweise konnte man nun nicht nur Bewegungsprofile, sondern auch Geschwindigkeitsprofile erstellen. Unten links ist z.B. zu sehen, wie Malte von München zum Münchner Flughafen fährt und dann nach Berlin fliegt:

260.640 Geopositionen sind eine ganze Menge Daten. Deswegen waren die ersten Prototypen auch über 6MB groß. Bei DSL 1000 würde es also fast eine Minute dauern, bis die App geladen ist. Deswegen musste die Datenmenge unbedingt reduziert werden. Dafür boten sich zwei Maßnahmen an:

Den ersten Schritt nenne ich mal „algorithmische Kompression”, also die Daten je nach ihren Eigentschaften so verlustbehaftet zu komprimieren, dass keine Artefakte bemerkbar sind. Z.B. bei den 260.640 Geopositionen erreicht man das, in dem man nur bestimmte Stützstellen speichert und die Zwischenschritte linear interpoliert. Lässt sich also relativ einfach implementieren. Für die Berechnung der Stützstellen hatte ich (so glaube ich mich zu erinnern) den Douglas-Peucker-Algorithmus verwendet. Durch diese und andere Tricks waren die Daten nur noch 7% so groß.

Für den zweiten Schritt brauchte ich die Unterstützung der IT-Abteilung von zeit-online. Die hatten extra für diese App eine gzip-Kompression serverseitig konfiguriert. Dadurch konnte die Datenmenge nochmals auf 27% reduziert werden. Zum Schluss war das Ding nur noch 1/50 seiner Größe. Hier noch mal zur Veranschaulichung die Dateigrößen:

Ich weiß, dass hört sich nach technischem Kleinkram an, aber für interaktive Visualisierungen ist es absolut notwendig, dass die Dinger klein und snappy sind. Man muss irgendwie das Zeug so klein pressen wie möglich. Für statistische Wirtschafts-Visualisierungen mit multidimensionalen Datenbanken gelingen mir sogar Kompressionsverhältnisse von bis zu 1:500!
Hat ein bisschen was von 64K-Projekten ...

So, und zum Schluss haue ich noch mal ein paar Charts raus!

Die „Datenbank” ist als JSON gespeichert. Hier mal ein kleiner Ausschnitt:

Die größte Datenmenge steckt aber wie gesagt in den ganzen Geo-Daten. Deshalb ein Überblick über die komplette Daten:

Während des Projektes ist die Größe des Codes fast kontinuierlich linear gestiegen. Hat mich selbst überrascht!

Anhand der Datei-Versionierung kann man den täglichen Arbeitsaufwand abschätzen. Wie man sieht, gab es drei Phasen.
Phase 1 war das Sichten und Säubern der Daten, so wie die Entwicklung des 1. Prototypen.
Phase 2 war dann die Weiterentwicklung unseres „Recherche-Werkzeuges” zu einer publizierbaren Web-Applikation.
Phase 3 ... vier Wochen später ... war dann das Übersetzen der App ins Englische.

Ich hab vom dem einen oder anderen Feedback bzgl. meines JavaScript-Codes bekommen. Dazu kann ich nur sagen: „Selber Schuld!” Das Ding musste auf Biegen und Brechen fertig werden. Der Code ist weder hübsch noch kommentiert. Ich hab das Ding irgendwie geschafft hin zukleistern. Es gibt eigentlich nur eine valide Kommentarzeile im Code ... und zwar die letzte Zeile:

Update: Ach so ... in der Medienradio-Folge 45 gibt es auch ein laaaanges Interview mit mir. Unter anderem geht es um die Vorratsdaten-Visualisierung. Zuvor erzählte Lorenz Matzat in Folge 43 auch kurz davon.