Original-URL des Artikels: https://www.golem.de/news/mitmachprojekt-frostbeulen-zieht-nach-oesterreich-1703-126288.html    Veröffentlicht: 08.03.2017 12:02    Kurz-URL: https://glm.io/126288

Mitmachprojekt

Frostbeulen, zieht nach Österreich!

Unsere Leser haben an ihren Arbeitsstellen Temperaturen gemessen, wir haben die Daten ausgewertet. Dabei haben wir nicht nur einiges über die Bürotemperaturen unserer Leser gelernt, sondern auch über aktuelle Statistik- und Geografiewerkzeuge. Eine interessante Erkenntnis kam vollkommen unerwartet.

Als wir Anfang des Jahres 2016 unser Projekt zur Messung der Bürotemperatur konzipierten, verfolgten wir damit als Redaktion mehrere Ziele: Wir wollten unsere Leser zur Beschäftigung mit Elektronik animieren und uns dabei ganz praktisch mit Datenjournalismus auseinandersetzen. Das Thema Bürotemperatur schien uns dafür ideal, denn es betrifft viele unserer Leser, und ein wenig Statistik kann wohl in mancher Bürodebatte äußerst nützlich sein. Wir glauben, alle Ziele erreicht zu haben. In unserer Auswertung wollen wir nicht nur auf die reinen Temperaturwerte und Statistiken eingehen, sondern auch auf die vielen, zum Teil unerwarteten Herausforderungen, die dabei auftraten.

Ein erster Überblick

Für unsere Auswertung haben wir die Werte vom 19. April bis zum 31. August 2016 zugrunde gelegt. In dieser Zeit erhielten wir fast 4,4 Millionen Messwerte.

Wir ließen unseren Lesern die Wahl, inwieweit sie Informationen zu ihrem Messstandort preisgaben. So wissen wir, dass in neun verschiedenen Ländern gemessen wurde, für uns vollkommen überraschend nicht nur in Europa, sondern auch in Kanada und Indien. Bereitwillig wurde auch die Stadt angegeben, so finden sich 215 verschiedene Städtenamen in der Datenbank. Noch mehr Vielfalt gibt es bei den Postleitzahlen, wir finden 309 verschiedene Werte. 245 Leser gaben Breiten- und Längengrad an. Diese Werte sind aber mit Vorsicht zu betrachten, wie wir später herausfanden. Über einen zufallsgenerierten Token konnten Leser ihre Messstation anonym, zu Statistikzwecken aber eindeutig identifizieren lassen. 406 Tokens wurden verwendet. Praktisch alle Leser, die eine Ortsinformation übermittelten, nutzten auch einen Token.

Sieben Nutzer oder mehr?

Die Frage, wie viele Nutzer überhaupt teilnahmen, ist auf den ersten wie auch den zweiten Blick schwer zu beantworten. Hinter den Messwerten ohne Token können 10 wie auch 1.000 Messstationen stecken. Wir greifen zu einem ersten Trick, um uns der Zahl zu nähern. Wir ermitteln, wie oft Nutzer mit Token Messwerte ablieferten und bestimmen den Median-Wert. Ein typischer Token-Nutzer übermittelte 2.166 Messwerte. Wir haben knapp 15.000 Messwerte ohne Token. Nach dieser Logik verstecken sich hinter den vollständig anonymen Messwerten also gerade einmal um die sieben Nutzer. Insgesamt bleibt es also bei schätzungsweise rund 400 Teilnehmern. Wie halten aber die Zahl von 2.166 Messwerten bei Nicht-Token-Nutzern für deutlich zu hoch. Wir haben noch eine andere Idee, der wir uns später zuwenden.

Zur Einordnung: Als wir mit dem Projekt begannen, wünschten uns Kollegen mit mehr Erfahrung im Datenjournalismus und bei Nutzerbefragungen viel Glück - sie nannten schon 100 ernsthafte Teilnehmer ein optimistisches Ziel. Unsere Anforderungen an die Elektronik- und Programmierkenntnisse sowie unsere vermeintlich kleine Zielgruppe schienen ihnen eine zu große Hürde.

Raspberry Pi als Elektronikplattform weit vorn

Werfen wir zunächst noch einen Blick auf leichter zu ermittelnde Statistikdaten. Wir baten auch um die Angabe der verwendeten Elektronikplattform. Dabei liegen die Bastelcomputer wie der Raspberry Pi weit vorn, mit ihnen wurde die Hälfte der Messwerte ermittelt. Mikro-Controller-Boards wie Arduinos und Funkmodule wie der ESP8266 kommen zusammen nicht einmal auf ein Viertel. Interessanterweise spiegelt diese Verteilung auch das Leserinteresse an den zugehörigen Anleitungsartikeln wider.



Für die Analyse haben wir dann aber keinen Raspberry Pi eingesetzt, auch wenn die genutzten Programme auch darauf laufen. Auf einem Laptop mit einem Intel i7 ist es doch angenehmer, mit größeren Datenmengen zu arbeiten.

Die Programmiersprache für Statistikfans

Zunächst haben wir die Daten direkt aus der MySQL-Datenbank ermittelt. Aber schon beim Median nahmen wir R zu Hilfe. Die Programmiersprache R ist speziell für die Datenanalyse entwickelt worden, insbesondere auch für statistische Analysen. Deshalb sind solche Operationen zuweilen sehr trivial und enorm schnell. Für die Bestimmung des obengenannten Median der Anzahl von Messwerten benötigen wir lediglich vier Codezeilen auf der interaktiven Shell von R, nachdem wir aus der Datenbank die nach Token gruppierten, aber unsortierten Daten herausgezogen haben:

# Lade CSV-Datei daten <- read.csv("daten.csv"); # Benenne Spalten colnames(daten)<-c("token", "werte_anzahl"); # Beachte nur die Zeilen mit einem Token daten <- daten[daten$token != 'Null',] # Median ermitteln median(daten$werte_anzahl); [1] 2166

Der Aufruf der median()-Funktion benötigt nur Millisekunden. Wie im Beispiel aber schon deutlich wird, bringt R als fachspezifische Sprache ihre eigene Syntax und andere Eigenheiten mit. Klassische Sprachelemente wie Schleifen und if-Bedingungen sind zwar möglich, führen aber oft zu kompliziertem und langsamem Code. Wer sich aber auf R einlässt und aus eingefahrenen Denkmustern aus C, PHP & Co. ausbricht, kann mit wenigen Zeilen Code zuweilen wahre Wunder zustande bringen.

QGIS und Python setzten wir auch ein

Zwangsläufig geht damit eine steile Lernkurve einher, die uns mehr Zeit gekostet hat, als wir ursprünglich dachten. Das gilt auch für QGIS. Es ist ein Programm für geografische Analysen, Anfänger dürften an ihm aber erst einmal schnell als Malprogramm für Karten Gefallen finden. Trotzdem verlangt es einen gehörigen Aufwand, um sich in die Fachbegriffe und Workflows einzuarbeiten. Schließlich verwenden wir auch Python. Wir benutzen es hauptsächlich, um Daten aus MySQL in CSV-Daten zu arrangieren. Einiges davon können wir auch MySQL erledigen lassen, in Python fällt es uns aber zuweilen leichter und der Code ist übersichtlicher. Allerdings sind CSV-Dateien im Zusammenspiel mit R sehr leicht zu benutzen. Und wir merken früh, dass es sinnvoll ist, auch vermeintliche Zwischenergebnisse besser stets auf Festplatte zu speichern, um jederzeit unsere Arbeit unterbrechen zu können.

Es gibt auch eine ganze Reihe kommerzielle Programme für die folgenden Aufgaben, mit denen wir uns das Leben wohl einfacher machen würden. Doch zum einen wollen wir offene Programme einzusetzen, zum anderen wollen wir so viel wie möglich durch Skripte automatisieren können. Idealerweise können wir diese Skripte für spätere Aufgaben auch wiederverwenden.

Heiteres Städteraten

Zurück zu den Daten. Bevor wir tatsächlich Aussagen extrahieren können, validieren wir die Daten. Am Anfang stehen die Städtenamen. Spaßeinträge halten sich sehr in Grenzen, auch wenn wir einige Einträge anfangs dafür halten. Aber die Orte "Au ZH", "Ban Pong" und "Wetter" heißen wirklich so. Mancher Lokalpatriot hat auch noch den Stadtteil angegeben. Mit Zeichensatz-Problemen haben wir ebenfalls gerechnet. Auch auffällig viele Benutzer kannten wohl das Problem, weshalb wir zum Beispiel auf "Koeln" und "Luebeck" stoßen, aber auch "Munich". Mehrdeutigkeiten lösen wir üblicherweise aufgrund einer ebenfalls angegebenen Postleitzahl eindeutig auf.

Um die Breitengrad- und Längengrad-Angabe erst einmal grob zu prüfen, nutzen wir einen simplen Trick: Wir nutzen QGIS im Zusammenspiel mit Vektorkarten, um die Angaben darzustellen. Eine hilfreiche Übersicht, wo solche Karten heruntergeladen werden können, gibt es auf einer Webseite.

Mit Längen- und Breitengraden hantieren

So erhalten wir einen ersten Überblick, und wir entdecken tatsächlich einige Merkwürdigkeiten. Einige Punkte liegen in Ländern, die nicht in unserer Datenbank vermerkt sind. Wir schauen uns die Datensätze genauer an und stellen fest, dass offensichtlich einige Nutzer den Breitengrad (Latitude) und Längengrad (Longitude) vertauscht haben. Einige Punkthaufen erinnern uns an ein gitterartiges Muster und liegen weitab jeglicher Besiedlung. Hier fehlt es den geografischen Angaben offensichtlich an Genauigkeit. Das ist leider unsere eigene Schuld: Wir empfahlen in unserer Dokumentation ursprünglich, Breiten- und Längengrad auf zwei Stellen nach dem Komma zu kürzen. Das haben wir zwar korrigiert, aber das war zu spät. Da wir aber sowieso fehlende geografische Angaben nachträglich ermitteln wollen, entscheiden wir uns, dieses auch bei bereits bestehenden Daten zu tun.

Geoencoding hilft uns weiter

Dazu schreiben wir ein Python-Skript. Es ermittelt alle Datensätze in der Datenbank, in denen entweder eine Stadt oder eine Postleitzahl oder beides angegeben ist. Mit diesen Daten rufen wir das Python-Package geocoder auf. Es liefert uns die zugehörigen geografischen Angaben, zumindest meistens. Leider ist auch nicht jede Angabe eindeutig. Deshalb müssen wir zwangsläufig jeden Eintrag manuell gegenprüfen, wobei wir noch einige Zahlendreher und Vertipper in Postleitzahlen entdecken. Schließlich gelingt es uns. Alle Datensätze mit Ortsangaben haben nun auch eine Breiten- und Längengradangabe, insgesamt sind es 326 verschiedene Ortsangaben.

Eine große Überraschung

Mit den so korrigierten Datensätzen erzeugen wir in QGIS erneut eine Übersichtskarte der Messstationen - und sind verblüfft: Das Verteilungsmuster kommt uns bekannt vor. Tatsächlich gleicht es der vom Institut für deutsche Wirtschaft herausgegebenen Karte der IT-Arbeitsplätze in Deutschland.



Zumindest für die IT-Büros scheint die Teilnehmerverteilung des Temperaturmessprojekts repräsentativ zu sein.

Wenn zu viel getestet wird

Bevor wir mit den Temperaturwerten beginnen, werfen wir einen Blick auf die Menge der Testwerte. Nutzer konnten ihren übermittelten Datensatz mit einem Debug-Flag versehen. Der Wert sollte dann nicht in die Auswertung eingehen. Doch unsere Datenbank liefert uns eine überraschende Aussage: Ein Viertel der Werte ist mit einem Debug-Flag versehen. Darunter befinden sich auch viele Datensätze von Token-Nutzern - deren übrige Angaben aber korrekt aussehen. Wir schauen uns deren Werte an, sie sehen trotz des Debug-Flags valide aus. Deshalb entscheiden wir uns, auch Datensätze mit dem Debug-Flag in die Auswertung mitaufzunehmen. Wir können schließlich auch bei den vermeintlich regulären Sendungen nicht von fehlerfreien Messungen ausgehen.

Hoffentlich valide Temperaturdaten

Eine Häufigkeitsanalyse liefert uns einen ersten Eindruck von den Temperaturwerten. Insgesamt gibt es 5.493 unterschiedliche Messwerte. Die Anzahl mag verblüffen, aber da wir keine konkrete Vorgabe zur Genauigkeit der übermittelten Werte gemacht haben, ist das erklärlich. Wir erzeugen eine Grafik mit den Häufigkeiten pro Wert. Dabei betrachten wir die Werte mit Debug-Flag und ohne getrennt. Im Graphen zeigt sich, dass sich die Verteilung ähnelt.

Die Werte 0 und 99 treten vergleichsweise häufig auf. Auch wir hatten zu Beginn unseres Projekts häufig solche Werte, während wir mit den verschiedenen Elektronikplattformen experimentierten. Sie entstanden durch fehlerhaft ausgelesene Sensoren oder Fehler bei der Aufbereitung der Daten für die Übermittlung per URL.

Auffällig ist auch die Häufung im Bereich um die 40 °C. Ein Blick in die Datenbank zeigt, dass es sich anscheinend tatsächlich um die korrekten Werte eines einzelnen Teilnehmers handelt, auch wenn sie als Debug-Werte gekennzeichnet sind.

Aufgrund der Häufigkeitsverteilung wird deutlich, dass wir uns für eine sinnvolle Betrachtung auf einen Wertebereich von 10 bis 45 °C Grad beschränken können. Das sind immer noch gut 4,1 Millionen Messwerte.

Am wärmsten ist es nicht mittags

Aus dieser Menge errechnen wir einen Mittelwert über den ganzen Tag von 24,8 °C. Unterscheiden wir nach der Tageszeit: Tagsüber, von 7 bis 19 Uhr, beträgt der Median 24,9 °C, der Durchschnitt 25 °C. Nachts liegt der Temperatur-Mittelwert bei 24,7 °C. Gliedern wir die Werte nach den Stunden des Tages auf, ist das Minimum gegen 7 und 8 Uhr früh erkennbar. Das Maximum wird gegen 17 Uhr erreicht. Dabei beträgt allerdings die Differenz zwischen Minimum- und Maximum-Temperatur gerade einmal rund 1,4 °C.

Interessant wird es im Ländervergleich.

Der European Office Contest

Wir haben hier nur Deutschland, die Schweiz, Österreich und Luxemburg beachtet, da pro Land mehrere Messstationen existieren. Wer es kühler mag, sollte interessanterweise nach Luxemburg, am wärmsten sind die Büros in Österreich.

Im Bundesländervergleich

Für Deutschland betrachten wir auch die Bundesländer näher. Da wir bei der Datenangabe nicht explizit nach dem Bundesland gefragt haben, nehmen wir die entsprechende Zuordnung über die Längen- und Breitengrad-Angabe der Messstationen in QGIS vor. Das Ergebnis exportieren wir per CSV und tragen es in der Datenbank nach. So müssen wir nur einige Datenbankabfragen durchführen, um nach Bundesländern sortiert die Median- und Durchschnittswerte zu erhalten.

Am kühlsten ist es in Büros in Rheinland-Pfalz und Schleswig-Holstein, am wärmsten in Berlin und Sachsen-Anhalt. Die Rangordnung dazwischen variiert hingegen je nachdem, ob der Median oder Durchschnitt beachtet wird. Bremen ist in der Liste leider nicht enthalten, da hier nur ein einzelner Messwert vorliegt.

Im Lauf der Jahreszeiten

Unser Messaufruf startete im Frühjahr und die Messperiode lief den Sommer hindurch - spiegelt sich das auch in den Bürotemperaturen wider? Hierfür betrachten wir den jeweiligen Durchschnitt und Median pro Tag für Deutschland, Österreich und die Schweiz. Luxemburg bleibt außen vor, da hier nicht über den gesamten Zeitraum Messwerte vorliegen.

Grundsätzlich ist die Temperaturentwicklung für alle drei Länder weitgehend gleich, die Erwärmung im Sommer wird auch in der Darstellung deutlich. Allerdings fällt auf, dass es in Deutschland geringere Schwankungen zwischen den Tiefst- und Höchstwerten gibt als in der Schweiz und Österreich. Dort gibt es aber auch deutlich weniger Messstationen als in Deutschland, so dass sich einzelne Extremwerte bei den Messungen deutlich stärker auf den Mittelwert auswirken können.

Die Außentemperatur im Vergleich

Doch wie verhalten sich die (deutschen) Bürotemperaturen im Vergleich zu den Außentemperaturen? Die dafür erforderlichen Wetterdaten gibt es beim Deutschen Wetterdienst. Die Daten können kostenfrei verwendet werden, es muss nur der Urheber genannt werden.

Verblüffende Datenvielfalt

Bevor es an den Download geht, müssen wir uns erst einmal entscheiden, welche Wetterdaten in welchem Umfang wir benötigen. Wir konzentrieren uns auf die Lufttemperatur. Daten mit täglichen oder monatlichen Durchschnittswerten reichen teilweise bis 1890 zurück, aktuelle Daten der vergangenen Monate bieten den Vorteil, Messwerte alle drei Stunden zu enthalten. Um die Datenmenge nicht ausufern zu lassen, beschränken wir uns auf die täglichen Durchschnittsmesswerte.

Nach dem Download wollen wir die Daten in unsere Datenbank packen. Das ist leichter gesagt als getan: Die Daten stecken pro Wettermessstation in einer Zip-Datei. Jede Zip-Datei umfasst die eigentlichen Messdaten und Informationen zur jeweiligen Messstation und den Messungen und Urheberrechtshinweise. Messdaten und Geoinformationen liegen jeweils als CSV vor. Insgesamt gibt es 505 Wettermessstation, also 505 Zip-Dateien. Wir schreiben ein Skript, das die Dateien entpackt und die Messdaten und Stationsinformationen jeweils in ein eigenes Verzeichnis kopiert.

Auch Wetterstationen ziehen um

Wir werfen einen näheren Blick in die Informationsdateien zu den Messstationen und uns wird klar, dass unsere Aufgabe noch einmal schwerer wird. Dass nicht jede Messstation dauerhaft aktiv war, konnten wir erwarten. Dass Wetterstationen aber auch bemerkenswert häufig umziehen, überraschte uns doch. Auch das müssen wir später berücksichtigen, wenn wir den Büromessstandorten jeweils eine Wetterstation zuordnen wollen.

Deshalb reicht es nicht, einfach für jede Wetterstation einen einzelnen Eintrag in der Datenbanktabelle anzulegen. Stattdessen berücksichtigen wir die Umzüge und behandeln einen Umzug wie eine Neueröffnung einer Wetterstation. So stehen zum Schluss 1.764 Wetterstationen jeweils mit einer eigenen ID in der Tabelle. Jetzt können wir auch die Temperaturdaten importieren, dabei benutzen wir als Verknüpfungsschlüssel zwischen der Temperatur und der jeweiligen Station unsere ID.

Die nächstgelegene Wetterstation ermitteln

Im nächsten Schritt wollen wir Büromesswerten mit Ortsangabe jeweils die räumlich nächsten zuordnen. Dabei reicht es eben nicht, einer Ortsangabe einmalig eine Wetterstation zuzuordnen, denn die nächstgelegene Wetterstation kann theoretisch jeden Tag eine andere sein. Deshalb erfolgt die Zuordnung tageweise. Dazu nutzen wir die Spatial-Erweiterung von MySQL und Python.

Und schließlich der Vergleich

Da die Außentemperatur nur als Tagesdurchschnitt zur Verfügung steht, legen wir für die nachfolgende Auswertung auch nur die jeweiligen Tagesdurchschnitte der Büros zugrunde. Dabei wird aus der Grafik ersichtlich, dass die Bürotemperatur dem Verlauf der Außentemperatur bemerkenswert übereinstimmend folgt. Allerdings hängt der Verlauf der Bürotemperatur den Außentemperaturen etwas nach. Kündigt der Wetterbericht also einige heiße Tage an, schlägt sich das nicht schon am ersten Tag im Büro nieder.

Wie viele haben denn nun gemessen?

Schließlich wollen wir uns noch einmal an die Schätzung der Teilnehmerzahl wagen, speziell der Teilnehmer ohne Token. Die Token-Nutzer bleiben dabei aber trotzdem wichtig, wir wollen ihr Verhalten als Basis unserer Abschätzung heranziehen.

Zuerst ermitteln wir, wie sich das Verhältnis von Nutzern mit Token und ohne Token überhaupt verhält. Die Anzahl der Messwerte mit Token sind deutlich in der Überzahl. Ab Juli gibt es praktisch keine Messwerte mehr ohne Token. Speziell vom 2. bis zum 5. Mai gibt es aber eine deutliche Anzahl an tokenlosen Messwerten (1.663, 2.029, 3.080, 2.571). Das macht uns neugierig. Im Gegensatz zu den Messwerten an den ersten Tagen und der kleineren Spitze um den 15. Juni herum korreliert das nicht mit einem Artikel zum Thema.

Lieferzeit von zwei Wochen?

Um diese Spitze besser zu verstehen, schauen wir uns an, welche Geräte bei den tokenlosen Messwerten zum Einsatz kommen. Zu unserer Überraschung handelt es sich fast ausnahmslos um Einträge vom Typ SBC, wir gehen von Raspberry Pis aus. Unser Verdacht ist: Nutzer haben sich anlässlich des Artikels vom 20. April 2016 einen Raspberry Pi bestellt und waren rund zwei Wochen später so weit, teilzunehmen.

Interessanterweise scheinen Token-Nutzer hingegen bereits die Hardware besessen zu haben. Wir haben geprüft, wann ein Token zum ersten Mal tatsächlich eingesetzt wurde. Im betreffenden Zeitraum vom 2. bis zum 5. Mai gibt es keine auffällige Häufung bei den Erstnutzungen.

Teilnehmer sind nur ganz kurz oder dauerhaft dabei

Versuchen wir eine andere Metrik, weiterhin in der Annahme, dass sich Nutzer ohne Token im Verhalten nicht wesentlich von Token-Nutzern unterscheiden. Wie viele Messwerte liefern Token-Nutzer im Median pro Tag ab?

Es sind rund 210 Messwerte pro Tag, pro Token. Da wirkt die anfangs genannte Zahl von 2.166 Messwerten pro Token-Nutzer über die gesamte Auswertungsdauer etwas klein. Ein Blick auf die Nutzungsdauer der Tokens löst allerdings das Rätsel: Rund ein Drittel lieferte nur Messwerte für einen Tag.

Wir haben eine Zahl!

Wir schauen uns deshalb als Nächstes an, wie viele Messwerte die Token-Nutzer mit weniger als einer Woche Nutzungsdauer pro Tag aufweisen. Deren Durchschnitt wollen wir dann tatsächlich als Berechnungsgrundlage für die Anzahl der tokenlosen Nutzer nehmen. Dabei berücksichtigen wir alle übermittelten Werte, auch fehlerhafte. Das entsprechende R-Skript steht auf Github zur Verfügung.

Wir ermitteln also die Zahl der Nicht-Token-Messungen pro Tag und teilen sie durch die Zahl der Teilnehmer mit Token, die weniger als sieben Tage teilnahmen. Der Einfachheit halber nehmen wir an, die tokenlosen Nutzer hätten lediglich an einem einzelnen Tag teilgenommen. So können wir die Zahl pro Tag einfach aufaddieren. Dabei erhalten wir eine Zahl von rund 1.000 Nicht-Token-Teilnehmern. Auch wenn diese Zahl zu hoch sein wird, halten wir sie doch für realistischer als die am Anfang ermittelten sieben Teilnehmer ohne Token.

Rechnen wir die Anzahl Nutzer mit und ohne Token zusammen, kommen wir also auf eine Zahl von bis zu 1.400 Teilnehmern.

Was wir gelernt haben

Mit den derzeit verfügbaren Programmierwerkzeugen ist es tatsächlich möglich, die Auswertung weitgehend zu automatisieren. Allerdings ist es nicht immer die einfachste oder attraktivste Methode. Der Import der Geodaten der deutschen Büros und ihre Zuordnung zu einem Bundesland erfordern in QGIS nur wenige Klicks. Ein entsprechendes R- oder Python-Skript oder eine MySQL-Lösung wären aufwendiger gewesen.

Als R-Einsteiger faszinieren uns auch die Möglichkeiten und die Bibliotheken der Sprache - was uns aber anfangs teilweise auch zu unnützen Auswertungen verleitete.

Wir haben uns an der Möglichkeit berauscht, Videos der Temperaturentwicklung in den Büros und bei den Außentemperaturen auf einer Deutschlandkarte zu produzieren. Dabei haben wir einiges an Rechenzeit verschwendet, bis uns klar wurde, dass die Aussagekraft der Videos im Endeffekt sehr gering war. Auch den Gedanken, das produzierte (Daten-)Material wenigstens in Form einer interaktiven Grafik bereitzustellen, mussten wir aufgrund der hohen Datenmengen verwerfen. Es hat uns aber insofern geholfen, als die Videos ein effektiver Weg waren, Probleme im Datenbestand zu entdecken - zum Beispiel im Umgang mit den DWD-Wetterstationen. Außerdem war es ein gutes Training für spatiale Operationen und den Umgang mit Kartenprojektionen.

Nur noch mit Anmeldung

Was uns erheblichen Aufwand verursacht hat, sind die fehlerhaften Ortsangaben. Deren Erkennung und Korrektur sind ebenfalls alles andere als trivial und praktisch im Rahmen unserer Möglichkeiten nicht sinnvoll automatisierbar. Dabei gilt es zu beachten, dass keine der Angaben an sich falsch oder betrügerisch war. Weiterhin überwog allein die Teilnahmedauer der Nutzer mit Token und Geoinformationen deutlich und gerade sie ermöglichten uns, weitergehende Untersuchungen anzustellen.

Wenn wir in Zukunft ähnliche Aktionen erneut durchführen sollten, halten wir es daher für sinnvoll, von einem registrierungsfreien Zugang abzusehen, die Anonymität soll dabei trotzdem gewahrt bleiben. Um fehlerhafte Ortsangaben auszuschließen, bietet sich im Rahmen der Registrierung an, die Ortsinformation zum Beispiel über eine eingebettete Openstreetmap- oder Google-Maps-Karte auszuwählen.

Dann ist auch eine vollautomatisierte Auswertung denkbar, inklusive häufigerer, regelmäßiger öffentlicher Darstellung der Ergebnisse.

Was noch wir vorhaben

Unsere Nutzer liefern immer noch Daten! Derzeit sind bereits 8 Millionen Messwerte in der Datenbank. Zum 1. Mai werden wir allerdings die entsprechenden API-URLs abschalten. Da dann ein Jahr vergangen ist, lohnt es sich, die Untersuchung noch einmal durchzuführen. Diesmal sollte es allerdings deutlich schneller gehen, da wir einen wesentlichen Teil der Aufgaben bereits automatisiert haben und auch fitter im Umgang mit den verschiedenen Werkzeugen sind.

In diesem Zusammenhang wird sich auch zeigen, ob wir uns datenjournalistische Projekte und Analysen leisten können. Bislang sind in das gesamte Projekt mehr als 400 Arbeitsstunden geflossen - wovon ein beträchtlicher Teil auch Lehrzeit war. Gelingt es uns, diese Zeitdauer im zweiten Anlauf deutlich zu drücken, könnte es auf Golem.de zukünftig mehr davon zu sehen und zu lesen geben.  (am)


Verwandte Artikel:
Mitmachprojekt: HTTPS vermiest uns den Wetterbericht   
(10.08.2017, https://glm.io/129378 )
US Air Force: Biegbares Arduino-Board für die Uniform oder den Jetflügel   
(12.02.2018, https://glm.io/132721 )
Raspad: Raspberry Pi kommt ins Bastel-Tablet-Gehäuse   
(06.03.2018, https://glm.io/133180 )
Uno SWU: Basteln mit programmierbarer Funksteckdose   
(04.10.2016, https://glm.io/123583 )
Mitmachprojekt: Wir haben bereits mehr als 1 Million Temperaturmessungen   
(13.06.2016, https://glm.io/121455 )

© 1997–2020 Golem.de, https://www.golem.de/