Hier bloggt Julius Tröger über den digitalen Wandel in der Redaktion.

23. 04. 2013

Wir bauen uns eine Nachrichtenquelle – Werkstattbericht zum Flugrouten-Radar

Wenn wir Informationen zu Nachtflügen, Flugrouten oder Fluglärm brauchen, müssen wir jetzt nicht mehr immer tagelang auf Antworten von Behördensprechern warten. Wir interviewen einfach unsere eigene Datenbank. Mit dem Flugrouten-Radar haben wir uns also eine eigene, täglich aktualisierte Nachrichtenquelle geschaffen.

Mehr als eine halbe Million Flüge und viele Millionen Flugspuren befinden sich hinter unserer neuen News App. Mit den richtigen Datenbank-Queries kommen wir dadurch an Zahlen, die in keiner anderen Statistik auftauchen. Und obwohl das Thema von Redaktionen in Berlin wie kaum ein anderes bearbeitet wird, finden wir so neue Geschichten, wie etwa die über Hunderte Leerflüge zwischen den Berliner Flughäfen.

Flugrouten, Fluglärm, Nachtflüge

Nach der mehrfach geplatzten Eröffnung des Hauptstadtflughafens BER ist es in Berlin zu einer besonderen Situation gekommen: Über den Flughafen Tegel, der eigentlich bereits seit Juni 2012 geschlossen sein sollte, müssen die eigentlich für den BER geplanten Flüge zusätzlich abgewickelt werden. 

3-D-Ansicht der Flüge über Berlin und Brandenburg

3-D-Ansicht der Flüge über Berlin und Brandenburg

Statt leiser wurde es für die Anwohner in den Einflugschneisen also lauter. Beschwerden über steigenden Fluglärm, Routenabweichungen und Nachtflüge nehmen zu. Debatten über diese Themen waren dabei häufig von Vermutungen geprägt. Genaue Zahlen zu Randzeit- und Nachtflügen sind schwer zu bekommen. Offiziell heißt es etwa: “Nachfragen nach belastenden Störungen [bei Flügen nach 23 Uhr] sind bei der Luftfahrtbehörde grundsätzlich möglich, erfordern dort aber einen erheblichen Recherche-Aufwand.”

Mit dem Flugrouten-Radar wollen wir Betroffenen und Interessierten in der emotional aufgeladenen Debatte ihre ganz persönliche Faktenbasis bieten – täglich aktualisiert und mit automatisierter Analysefunktion. Und wir wollen Daten so verständlich, transparent und personalisiert wie möglich darstellen.

Statistik-Ansicht: Nachtflüge, Airlines, Ortsteile

Statistik-Ansicht: Nachtflüge, Airlines, Ortsteile

Einerseits zeigt die interaktive Anwendung erstmals Flughöhen, -zeiten und Flugzeugtypen mit Lärmberechnungen für alle Flüge über einem individuellen Standort in einer dreidimensionalen Ansicht. Andererseits gibt es exklusive Statistiken auf Basis von mehr als einer halben Million Flügen seit Januar 2011, wie sich die Fluglast auf die einzelnen Ortsteile bzw. Gemeinden der Hauptstadtregion über die Zeit verteilt.

Von der ersten Idee bis zur Veröffentlichung des Flugrouten-Radars verging ungefähr ein halbes Jahr. Die Redaktion der Berliner Morgenpost hat dabei mit dem Deutschen Fluglärmdienst (DFLD), dem Datenjournalismus-Team der US-Investigativredaktion ProPublica und der Agentur Kreuzwerker GmbH zusammengearbeitet.

Recherche der Daten

Einen Großteil der Zeit benötigten wir, Julius Tröger und André Pätzold, für die Recherche der Flugspur-Rohdaten. Die gibt es in Deutschland nämlich nicht öffentlich – im Gegensatz zu den USA und Kanada etwa. Dort werden Radardaten aller Flüge per Feed angeboten. Die Deutsche Flugsicherung (DFS) gibt ihre Rohdaten dagegen nicht frei. Entsprechende Anfragen unsererseits wurden abgelehnt. Die DFS veröffentlicht die Daten zwar in ihrer Online-Anwendung “Stanly-Track” – allerdings nur 14 Tage rückwirkend. Zu wenig für uns, da wir für Vergleiche die Zahlen aus den entsprechenden Vorjahreszeiträumen benötigten.

Unser Testgerät: AirNav RadarBox 3D

Unser Testgerät: AirNav RadarBox 3D

Ein anderer Weg an Flugspur-Daten zu gelangen sind so genannte ADS-B-Transponder in Flugzeugen. Die kann man in Deutschland legal mit entsprechenden Receivern wie Mode-S Beast, Transponder-Mouse oder Airnav Radarbox (ab rund 200 Euro bei eBay) empfangen. Live-Flugkarten wie Flightradar24 oder Metafly nutzen diese Technik. Nach einigen Tests entschieden wir uns allerdings gegen diese Variante. Es sind erst rund 70 Prozent der Flugzeuge mit ADS-B-Transpondern ausgestattet. Für detaillierte Analysen wäre das zu wenig.

Auch konnten wir die gewünschten Daten nicht über kostenpflichtige APIs wie Flightstats oder Flightaware bekommen.

Kooperation mit Deutschem Fluglärmdienst

Der DFLD archiviert Flugspuren in der Nähe großer Flughäfen in Deutschland. Diese können auf deren Webseite zudem mehrere Jahre rückwirkend angezeigt werden – mit einer Erfassung von mehr als 96 Prozent. Routen können auf einer statischen Karte oder auf Google Maps bzw. Earth angesehen werden. Die Daten kann man dort auch im Keyhole Markup Language (KML)-Format herunterladen.

Daten eines Air-Berlin-Flugs

Lat, Lng, dB(A): Flugspur-Daten eines Air-Berlin-Flugs

Nach mehreren E-Mails, Telefonaten und Teamviewer-Sitzungen mit Technik und Vorstand des Vereins einigten wir uns auf eine Zusammenarbeit. Wir bekamen die Flugspur-Daten mit Lärmberechnungen nach dem offiziellen AzB-Standard kostenlos im deutlich schlankeren CSV-Format geliefert – rückwirkend und täglich aktuell. Im Gegenzug verweisen wir in unserer Anwendung an mehreren Stellen auf das entsprechende Angebot des DFLD.

Die Datenqualität war von Anfang an sehr hoch. Sie wurde uns auch in Gesprächen mit Experten des Deutschen Luft- und Raumfahrtzentrums sowie Piloten und Flughafen- bzw. DFS-Angestellten, Abgleichen mit offiziellen Daten, ungezählten Stichproben und statistischen Auswertungen bestätigt. Hilfreich hierbei war auch der Data-Bulletproofing-Guide von ProPublica.

Umsetzung mit ProPublica-Datenjournalisten

Nun mussten wir einen Weg finden, eine Datenbank aufzubauen, die Daten visuell umzusetzen und Geschichten aus den Zahlen zu  gewinnen. Dafür bewarb ich mich in dem Datenjournalismus-Team von ProPublica in New York für das von der Knight Foundation unterstützte P5-Stipendium. In mehreren Telefonkonferenzen präsentierte ich das Projekt. Scott Klein und seine Kollegen fanden es spannend. Und einen Monat später, im November 2012, saß ich schon im Flieger nach New York.

Hier entstand der Flugroutenradar

Hier entstand der Prototyp des Flugrouten-Radars

Dort baute ich gemeinsam mit Jeff Larson und Al Shaw ein Grundgerüst mit dem Framework Ruby on Rails. Weil wir uns mit den Flugspuren im dreidimensionalen Raum befanden, wählten wir als Datenbank PostGIS, eine Erweiterung von PostgreSQL, die mit komplizierten Geoberechnungen umgehen kann. Damit kann etwa ganz leicht festgestellt werden, ob eine Polyline (Flugspur) in einem Polygon (Ortsteil) liegt.

Nach zwei Wochen hatten wir eine Anwendung programmiert, die genau das tat, was wir ursprünglich wollten: Überflüge über Ortsteilen und Gemeinden automatisch zählen sowie Ranglisten erstellen. Außerdem konnten Nutzer nach der Adresseingabe Flüge in einem gewissen Radius über ihrem Standort sehen. Erst noch in 2-D von oben.

3-D-Visualisierung im Browser ohne Plugins

Jeff experimentierte aber an einer 3-D-Darstellung der Flugrouten, da diese so auch bei größerem Flugaufkommen durch die horizontale Fächerung übersichtlicher und realistischer dargestellt werden können.

Programmiert von Jeff Larsson

Erster Prototyp der 3-D-Karte von Jeff Larson

Zwar gibt es 3-D-Karten wie etwa die von Nokia Maps, wie die von Apple oder Google auf Smartphones, Experimente auf Basis von Open Street Maps und natürlich Google Earth. Allerdings benötigt man für viele von ihnen Plugins wie etwa WebGL (Web Graphics Library), die nicht von allen Endgeräten unterstützt werden.

Da wir eine plattformübergreifende Anwendung veröffentlichten wollten, bedienten wir uns einer eigenen Lösung, einer Mischung aus CSS-3-D-Transforms, SVG-Vektoren und statischen Karten. Dabei wird der entsprechende Kartenausschnitt per CSS geneigt und die Flugspuren mit raphael.js als Vektoren auf Basis der Flughöhe projiziert.

Mapbox, Leaflet und Yahoo statt Google

Google stellt mit seinen Maps- und Geocoding-Diensten mitunter die besten auf dem Markt. Bei der Berliner Morgenpost kamen die Tools häufig zum Einsatz. Diesmal haben wir uns aber dagegen entschieden. Das hat zwei Gründe: Google verlangt viel Geld bei kommerzieller Nutzung über ein gewisses Kontingent (z.B. bei mehr als 2500 Geocoder-Abfragen) hinaus. Außerdem verbietet Google in seinen AGB die 3-D-Darstellung seiner Karten.

Google, OSM, Mapbox, Nokia hier vergleichen: http://bit.ly/16liEFI

Google, OSM, Mapbox, Nokia hier vergleichen: http://bit.ly/16liEFI

Nach einigen Tests und Vergleichen entschieden wir uns für die Karten von Mapbox. Die basieren auf den Daten der offenen Kartensoftware Open Street Maps. Die Straßen der Hauptstadtregion (Berlin und angrenzende Brandenburg-Gemeinden) sind dort nahezu 100% exakt erfasst. Mapbox bietet darüber hinaus eine Static-API für statische Tiles, die wir für die 3D-Darstellung benötigen. Außerdem lassen sich die Karten mit dem Tool Tilemill sehr einfach stylen. Mapbox bietet in der Bezahlvariante sogar mehr oder weniger brauchbare Satelliten-Bilder. Die 2-D-Karten wurden mit dem Framework Leaflet umgesetzt.

In der Anwendung kam ursprünglich Nominatim, der kostenlose (Reverse-)Geocoder von Open Street Maps, zum Einsatz. Der Dienst funktioniert zwar relativ gut und schnell, allerdings sind vor allem in Brandenburg und Berliner Randbezirken nicht alle Hausnummern indexiert. Da unsere Anwendung aber auf dem Geocoder als zentrales Element basiert, waren uns exakte Treffer bis auf Hausnummern wichtig. Wir entschieden uns also für den kostenpflichtigen Placefinder von Yahoo. In seiner Treffergenauigkeit kommt er dem Google-Geocoder schon sehr nahe.

D3, Responsive, Permalinks

“If it doesn’t work on mobile, it doesn’t work!” Wir haben die Anwendung nicht nur mobiloptimiert, da immer mehr Nutzer die Berliner Morgenpost per  Smartphones und Tablets besuchen. Mit der Standortsuche bieten wir auch ein Feature, das den Flugverkehr direkt über dem aktuellen Standort zeigt. Ohne Adresseingabe, sondern mit der HTML5 Geolocation API. Die Ansicht passt sich aufgrund des Responsive Designs der Größe des Gerätes automatisch an.

Responsive Design passt sich an Endgeräte an

Responsive Design passt sich an Endgeräte an

Dieses Vorhaben stellte sich als sehr kompliziert heraus, weil die Hauptseite der Berliner Morgenpost nicht responsive ist. Wir wollten die Anwendung aber nahtlos in unser Angebot integrieren. Außerdem konnten wir den Flugrouten-Radar nicht wie unsere bisherigen interaktiven Anwendungen bei der Berliner Morgenpost einfach als iframe einbinden. Ein Nachteil unserer früheren interaktiven Anwendungen war nämlich, dass sie eine URL haben, die einen bestimmten Anfangszustand zeigt. Wir wollten aber jeden Zustand und damit Einzelerkenntnisse der Anwendung bookmarkbar und teilbar machen. Die Adresse passt sich also jedem Zustand an und kann dann etwa bei Twitter, Facebook und Google+ geteilt werden. Die Lösung war eine hauseigene API, mit der Seitenteile dynamisch zugeschaltet werden können.

Für die Darstellung der Balkendiagramme kam DC.js, eine Erweiterung von Crossfilter basierend auf D3 (Data-Driven Documents) zum Einsatz. Für Balken- und Liniendiagrammen in unseren Artikeln nutzen wir Datawrapper.

Ausbau, weitere Ideen, Lehren

Wir wollen die historischen und täglich aktuellen Daten mit weiteren Daten verknüpfen. Auch wollen wir noch mehr den Fokus auf Prognosen für die künftigen BER-Routen mit dem Hintergrund der Einzelfreigaben-Praxis legen. Außerdem planen wir Twitter-Accounts, die automatisiert entsprechende Daten twittern. Darüber hinaus denken wir auch über eine Foursquare-Lösung nach, wie sie etwa ProPublica für eine Datengeschichte umgesetzt hat. Auch wollen wir Ideen in Richtung Crowdsourcing umsetzen.

Das Benutzerinterface entsteht

Das Benutzerinterface entsteht

Als besonders trickreich hat sich die 3-D-Karte als zentrales Element der Anwendung herausgestellt. Sie basiert auf nicht standardisierten Features und ist daher sehr experimentell. Besonders Chrome und iOS hatten Probleme, dass wir auf diesen Systemen die Anzahl der angezeigten Flugspuren begrenzen mussten. Auch funktioniert die 3-D-Karte nicht mit dem Internet Explorer, der das dafür nötige “preserve-3d” nicht unterstützt.

Außerdem hatten wir viele Erkenntnisse erst während der Arbeit mit den Daten und der Anwendung. Da es uns aber aufgrund unserer knappen Deadline nicht möglich war, den Flugrouten-Radar und dessen Logik dahinter immer wieder umzuwerfen, fehlen einige Features, die wir zum Start eigentlich gerne noch gehabt hätten.

Da wir den Flugrouten-Radar aber nicht als für immer abgeschlossene Anwendung, sondern eher als Prozess sehen, wollen wir die Funktionalität weiter verbessern und immer den aktuellen Möglichkeiten des Web anpassen. Währenddessen wird die Datenbank ein täglich umfangreicheres Recherchetool, das die Redaktion mit dem Tool pgAdmin befragen kann.

Der Flugrouten-Radar ist unsere LP. Es wird davon noch viele Single-Auskopplungen geben. Und bis zur BER-Eröffnung sind ja vermutlich noch ein paar Jahre Zeit für neue Features und Geschichten.

Über Kritik, Hinweise, Anregungen freue ich mich hier in den Kommentaren, bei Twitter, Facebook und Google+

20. 09. 2011

Making Of: Datenvisualisierung zur Berlin-Wahl

Berlin hat ein neues Abgeordnetenhaus gewählt. 1.486.616 1.487.487 (endgültiges Ergebnis) Millionen Menschen haben in 1736 Wahllokalen und per Briefwahl ihre Stimme in 78 Wahlkreisen der Hauptstadt abgegeben. 22 Parteien waren zur Wahl zugelassen.

Gegen 1 Uhr in der Nacht nach der Wahl veröffentlichte die Landeswahlleiterin von Berlin das vorläufige amtliche Endergebnis. Rund eine Stunde später wurde auf wahlen-berlin.de eine rund fünf Megabyte große Excel-Tabelle mit allen abgegebenen Stimmen zum Download angeboten. Einige Nachtschichtstunden später veröffentlichten wir gegen 8 Uhr am Tag nach der Wahl unsere interaktive Berlin-Wahlkarte, auf der alle zur Abgeordnetenhauswahl abgegebenen Stimmen dargestellt werden können.

Berlinwahlkarte der Berliner Morgenpost

Berlinwahlkarte 2011

Bereits lange im Vorfeld der Wahl am 18. September hatten wir uns überlegt, welche Darstellungsformen wir online einsetzen wollen, um den erwarteten Zahlenberg darzustellen. Wir hatten uns dafür entschieden, eine Karte mit allen Bezirken, Wahlkreisen und Wahllokalen zu bauen, auf der alle abgegebenen Stimmen bis auf Kiez- bzw. Straßenebene zurückverfolgt werden können. Diese sollte mit nicht-proprietären Online-Tools abseits von Flash umgesetzt werden und auf möglichst allen Endgeräten darstellbar sein.

Zum Einsatz kamen ausschließlich Tools von Google. Die Wahlkarte wurde mit Google Fusion Tables, Google Maps, Google Chart Tools und Google Spreadsheet sowie den jeweiligen APIs umgesetzt. Geschrieben ist die Webseite in XHTML, Javascript und CSS. Außerdem haben wir mit dem Tabellenverarbeitungsprogramm Microsoft Excel und den freien HTML-Editoren Komodo Edit, Aptana Studio und Smultron gearbeitet.

Da wir, André Pätzold und Julius Tröger, beide gelernte Journalisten und keine Programmierer sind, haben uns die Dokumentationen und Beispiele der APIs sehr geholfen. Ein fundiertes Grundlagenwissen der o.g. Techniken brachten wir beide allerdings bereits mit. Bei detaillierten Fragen wurden wir immer in den entsprechenden Foren unterstützt.

Entstehung der Wahlkarte in fünf Schritten:

  1. Daten besorgen, in Excel-Tabellen speichern, bereinigen und aufeinander abstimmen
  2. Excel-Tabellen in Google Fusion Tables importieren und verbinden
  3. Geodaten visualisieren, Polygone zeichnen und Infofenster bearbeiten
  4. Layout und Steuerung um die Google-Karte erstellen

1. Daten besorgen, in Excel-Tabellen speichern, bereinigen und aufeinander abstimmen

Die Daten zur Berlin-Wahl wurden von der Landeswahlleiterin bereitgestellt. Neben den detaillierten Wahlergebnissen konnten im Vorfeld zudem Wählerstrukturdaten wie z.B. Migrationshintergrund der Wahlberechtigten in den Wahlkreisen heruntergeladen werden.
Darüberhinaus stellte die Landeswahlleiterin die Adressen der 1736 Berliner Wahllokale und die Beschreibung der 78 Wahlkreise zur Verfügung.

Excel - Tabellenbereinigung

Excel - Tabellenbereinigung

Im nächsten Schritt mussten die benötigten Daten in einzelnen Tabellen so aufgearbeitet werden, dass sie ausschließlich die benötigten Daten in einer sinnvollen Reihenfolge und möglichst keine Umlaute mehr enthalten. Dafür kam vorwiegend Microsoft Excel und vor allem die entsprechenden Formel-Befehle “Verketten” und “MAX” sowie eine ausgiebige Zellenformatierung zum Einsatz.

Für Fusion Tables ist es außerdem wichtig, dass die Excel-Tabelle nicht größer als ein Megabyte sind. Das wurde bei den Wahllokal-Stimmen teilweise sehr knapp.
Außerdem mussten die unterschiedlichen Tabellen aufeinander abgestimmt werden. Dafür wurden eindeutige IDs für die zwölf Bezirke, 78 Wahlkreise und 1736 Wahllokale vergeben. Diese atomare Datenhaltung ermöglichte später eine beliebige Kombination aller Tabellen und Daten,

2. Excel-Tabellen in Google Fusion Tables importieren und verbinden

Fusion Tables - Datenhaltung

Fusion Tables - Datenhaltung

Um die Tabellen ins Netz zu bringen, wurde das Datenmanagement-Tool Google Fusion Tables eingesetzt. Die Besonderheit bei Fusion Tables ist, dass Geodaten in den Tabellen (Adressen oder KML-Polygone) dynamisch auf einer Google Map dargestellt werden.
Nachdem ein Google-Account erstellt wurde, konnten die vorbereiteten Excel-Tabellen mit einem Klick in Fusion Tables importiert werden. Im nächsten Schritt wurde bestimmt, welche Spalten Geodaten für die Visualisierung, wo Texte und wo Zahlen stehen. Dann mussten die Tabellen nur noch sinnvoll (z.B. Wahllokal-Adressen-Tabelle und Stimmen-in-den-einzelnen-Wahllokalen-Tabelle) miteinander verknüpft (merge) und unter neuem Namen abgespeichert werden und die Sichtbarkeit von “private” auf “unlisted” bzw. “public” gestellt werden.

3. Geodaten visualisieren, Polygone zeichnen und Infofenster bearbeiten

Fusion Tables erstellt automatisch für jede Adresse einen Punkt auf einer Google-Karte. Die Symbole dafür können aus einer kleinen Liste gewählt werden oder dynamisch anhand von Werten einer Tabelle (z.B. über 50 Prozent = rote Punkte, unter 50 Prozent = grüne Punkte) dargestellt werden.

KML-Polygone - Wahlkreise

KML-Polygone - Wahlkreise

Für die Wahlkarte sollten darüberhinaus aber auch die Berliner Bezirke und Wahlkreise mit ihrem exakten Grenzverlauf auf der Karte zu sehen sein, und die Bereiche dynamisch anhand von Tabellenwerten eingefärbt werden. Da diese Geodaten – im Gegensatz zu den 96 Berliner Ortsteilen – nirgends als KML-Daten zur Verfügung standen, mussten sie manuell eingezeichnet werden.
Die Bezirke und Wahlkreise wurden mit einem freien Tool Punkt für Punkt eingezeichnet und die Daten aus dem Polygon-Tag im KML kopiert und in die entsprechende Fusion Table als “Location” eingefügt.
Fusion Tables bietet umfangreiche Tools zur Erstellung so genannter Heatmaps, also Karten auf denen bestimmte Teile anhand von Tabellenwetten mit Farbverläufen (z.B. viele Arbeitslose = dunkel, wenig Arbeitslose = hell) dargestellt werden können.

Chart Tools - Diagramme

Chart Tools - Diagramme

Ein weiterer grundlegender Bestandteil der Wahldaten-Visualisierung war die Darstellung aller abgegebenen Stimmen auf Wahllokal, Wahlkreis und Bezirksebene in detaillierten Infofenstern. Fusion Tables bietet hierfür die Möglichkeit, Tabellendaten in diesen Infofenstern dynamisch und per HTML und CSS anzuzeigen.
Um das dynamische Kuchendiagramm in den Infofenstern darzustellen, wurden zusätzlich die Google Image Chart Tools eingesetzt. Damit konnten dynamisch Kuchen- und Balkendigramme mit entsprechenden Wahlergebnissen angezeigt werden. Die Ergebnisse in Rohform wurden per einfachem HTML in die Infofenster eingebunden.

4. Layout und Steuerung um die Google-Karte erstellen

Der mit Abstand aufwendigste Part war die Präsentation und der Aufbau einer dynamischen Steuerung der Wahlkarte.

FT-Builder - Grundgerüst

FT-Builder - Grundgerüst

In einem ersten Schritt kam das sehr hilfreiche Tool Fusion Tables Builder zum Einsatz. Damit lassen sich die initialen Layer (z.B. Alle Wahllokale) aus einer Tabelle auf einer Google-Karte darstellen. Zudem können dort Größe, Style, Startpunkt etc. Festgelegt werden. Der daraus entstandene Quellcode diente als Ausgangspunkt für die Wahlkarte.

Das Gerüst der Karte wurde komplett mit CSS verwirklicht. Die Karte wurde mit DIV-Elementen in vier Teile gegliedert: Den Karten-Hauptbereich, den Karten-Steuerungsbereich oben, die Wahllokal-Parteien-Steuerung links sowie die Bezirke-/Wahlkreis-Steuerung im unteren Bereich.
Das Styling der Karte wurde vorwiegend mit dem Google Styling Wizard vorgenommen. Dieser erlaubt es, beinahe alle Karten-Elemente farblich anzupassen bzw. ein- und auszublenden.

Wie die weiteren Features entstanden soll im Folgenden kurz dargestellt werden:

Die Adressuche wurde mithilfe der Google-Maps-Geocoding-API realisiert. Vorteilhaft dabei: Die Google-Suche ist sehr stark und kennt eigentlich alle Orte in Berlin.

Für die Abfrage der 100 Wahllokale, in denen die jeweiligen Parteien gepunktet haben, kam die Fusion Tables SQL API zum Einsatz. Bei Klick auf die gewünschte Partei wird per Javascript ein String als Parameter übergeben. Anhand des Werts dieses Parameters (z.B. “SPD”) wird die Abfrage gestartet, die die Spalte “SPD” in der entsprechenden Tabelle mit den höchten Werten absteigend ausliest und dabei nur die ersten 100 Werte ausgibt -also “SELECT Location FROM Wahllokale ORDER BY ‘SPD’ DESC LIMIT 100″.

API-Dokumentation - Hilfe

API-Dokumentation - Hilfe

Die Rangliste aller Ergebnisse in Tabellenform wurde – ähnlich der Diagramme in den Infofenstern – mit den Google Chart Tools umgesetzt. Die Daten dafür kommen aus einer Tabelle, die in Google Spreadsheet abgelegt wurde. Auch das Diagramm mit den Ergebnisse der Berlin-Wahlen seit 1950 wurden damit erstellt.

Die Legenden auf der Karte wurden mit HTML und Javascript nach einem von Google bereit gestellten Beispiel erstellt.

Die gesamte Berlin-Wahlkarte wurde dann im letzten Schritt als Iframe in das Content Management System der Berliner Morgenpost eingebunden.

Auch wenn der Arbeitsaufwand für die Erstellung der Karte hoch war und viel Zeit und Nerven gekostet hat, waren wir immer wieder erstaunt darüber, wie wir als Nicht-Programmierer alle Skripting-Probleme irgendwie gelöst bekommen haben und Dank einer einwandfreien API-Dokumentation seitens Google und Hilfe in verschiedenen Foren immer zum Ziel gekommen sind.

Wer sich in die Grundlagen der Programmierung einlesen möchte, dem seien die W3Schools Tutorials, die Codeacademy und diese Linkliste ans Herz gelegt.

Update (22.09.11):
Diese Fusion Tables kommen in der Berlinwahlkarte zum Einsatz:

Update 2 (26.09.11):
Hier wird unsere Karte erwähnt:

Update 3 (30.09.11)

Update 4 (15.03.12)

Update 5 (26.03.12)

Weiterführende Links und Inspirationsquellen:














Digitaler Wandel - Julius Tröger - Powered by Wordpress using the theme bbv1