Open Data: Rechte und Pflichten

Heute habe ich bei der GEOSummit einen Vortrag über Open Data gehalten: Die Verfügbarkeit von Open Government Data ist ein gemeinsamer Prozess, der sowohl Datenherren als auch Datennutzenden Rechte einräumt und Pflichten einfordert. In dem Vortrag werden einige der Rechte und Pflichten aufgelistet, die unter Anderem eine sorgsamen, ethischen und fachgerechten Umgang mit den Daten beinhaltet.

Um das Pflicht- und Rechtbewusstsein zu förden, schlagen wir vor, dass bei der Datenabgabe neben juristischen Datenlizenzen auch die ethischen und moralischen Aspekte berücksichtigt werden sollen. In verschiedenen Disziplinen wie Statistik oder 3D-Darstellungen wird bereits ein Berufsethos vermittelt, das u.A. moralische Grundsätze für das Handeln definiert. Aufgrund der Prominenz der Geodaten in OGD bietet es sich an, dass die GIS-Gemeinschaft der Schweiz vorangeht und Vorgaben zum Umgang mit „Geo-OGD“ sowohl für Datenproduzenten als auch Datenkonsumenten festlegt. Eine Zusammenarbeit mit dem Schweizer OpenData Verein soll zu einem von Produzenten und Nutzenden akepztierten Dokument führen, das die moralischen Rechte und Pflichten zusammenfasst und neben der Datenlizenz als Grundsatzdokument bei der Abgabe eines Datensatzes beigelegt werden kann.

Am Ende des Vortrages habe ich auch um Online Feedback gebeten. Dazu können Sie unten in den Kommentaren ihre Rückmeldung geben. Ich freue mich auf eine Diskussion hier oder bei einem GeoBeer.

Zusammenfassung

 

 

Blick in die Werkzeugkiste: Offene Daten in R – Teil 3

VeloIm ersten Teil dieser Miniserie über R habe ich einfache Standard-Visualisierungen vorgestellt und Tipps zu Entwicklungsumgebungen gegeben. Der zweite Teil hat dann etwas speziellere Visualisierungen und eine Demonstration einer Datenaggregation in R enthalten. In diesem, dem letzten, Teil möchte ich  nochmals zwei Visualisierungen zeigen: eine thematische Karte und eine derzeit sehr populäre Visualisierung, die sogenannte Heatmap.

Nachdem ich im letzten Blogpost den Wochenrhythmus in den Velozähldaten der Stadt Zürich untersucht habe, fokussieren die heutigen Visualisierungen auf andere Zeitskalen. Die bereits vorgestellten Aggregationsoperationen können natürlich für die Darstellung anderer Zeitperioden als Wochentag angepasst werden.

Thematische Karten

Der nächsten Darstellung liegt der Jahresrhythmus zugrunde. Für die Messung der Saisonalität des Veloverkehrs habe ich (sehr vereinfachend!) den Quotienten aus der Veloanzahl im Juli und jener im Dezember verwendet. Diese einfache Operationalisierung erlaubt mir, auch die Zählstelle an der Langstrasse (LANG) einzubeziehen, denn diese ist erst im Juli 2013 in Betrieb genommen worden.

Den Saisonalitätsfaktor habe ich dann, kombiniert mit der mittleren Anzahl von Velos pro Stunde, wiederum im räumlichen Kontext visualisiert. Die Karte verknüpft proportional skalierte Symbole mit einer Farbgebung, welche die Saisonalität darstellt:

Wie man unschwer erkennt, schwingen die peripher gelegenen Zählstellen an der Andreasstrasse (ANDR) in Schwamendingen und am Mythenquai (MYTH) bezüglich Saisonalität obenaus. Demgegenüber fahren an den Zählstellen Schulstrasse (SCHU) in Oerlikon und Langstrasse (LANG) „nur“ circa doppelt soviele Velofahrende im Sommer vorbei als im Winter. Wegen des geringen Veloaufkommens (rund um die Uhr gemessen durchschnittlich weniger als 5 Velos pro Stunde) ist aber auch klar, dass diese Aussage für die Schulstrasse eher unsicher ist.

Basierend auf diesen Betrachtungen und jenen aus dem zweiten Blogpost kann man also sagen: Die Zählstelle am Mythenquai gibt zwei Hinweise auf starken Freizeitverkehr: aussergewöhnlich hohe Saisonalität bei sehr gleichmässigem Wochenrhythmus. Demgegenüber scheinen zum Beispiel Scheuchzerstrasse (SCHE), Mühlebachstrasse (MUEH) und Sihlpromenade (SIHL) (zu einem etwas geringeren Grad auch die Langstrasse) typische „Pendlerstrecken“ zu sein.

Heatmap

Bei einer Heatmap handelt es sich um eine mit Farben codierte Matrix von Werten.

In meinem Beispiel habe ich den täglichen Verlauf der Aktivität an einzelnen Zählstellen anhand der Stundenmittel richtungsgetrennt visualisiert. (Alle Zählstellen bis auf jene an der Hofwiesenstrasse messen den Veloverkehr in beide Fahrtrichtungen.)

Je intensiver das Grün in einem Zeitabschnitt, desto mehr Velos sind in dieser Stunde an der jeweiligen Zählstelle vorbeigefahren. Mit der Heatmap lassen sich beispielsweise identifizieren:

  • Zählstellen mit ausgeprägten Belastungsspitzen: Die Belastungsspitzen treten morgens von 7–8 Uhr und nachmittags von 17–18 Uhr auf. Es gibt Zählstellen, bei denen beide Fahrtrichtungen morgens und abends Spitzen aufweisen. Andere haben eine Belastungsspitze am Morgen in eine Fahrtrichtung und am Abend in die entgegengesetzte Fahrrichtung. Typisch für diese zweite Gruppe sind zum Beispiel Lux-Guyer-Weg (LUXG), Scheuchzerstrasse (SCHE) oder Sihlpromenade (SIHL).
  • Zählstellen ohne ausgeprägte Belastungsspitzen: Der Verkehr ist über den gesamten Tagesverlauf recht gleichmässig verteilt. Die üblichen Spitzen am Morgen und am Abend sind vergleichsweise gering ausgeprägt. In diese Kategorie gehört zum Beispiel die Schulstrasse (SCHU).

Zählstellen mit sehr ausgeprägten Belastungsspitzen weisen auf einen hohen Anteil Berufspendlerinnen und -pendler im Tagesablauf hin. Die Lage im Verkehrsnetz führt dann zu einer starken Richtungsausprägung am Morgen und/oder am Abend: Bei „Randlagen“ bzw. einem Ring um die Innenstadt (zum Beispiel Mythenquai, Mühlebachstrasse, Sihlpromenade) tritt das morgendliche sogenannte Einpendeln und am Abend das Auspendeln auf, also morgens in die Innenstadt hinein, abends wieder in die umliegenden Quartiere und Vororte.

Bei zentralen Lagen überlagern sich Pendlerwege so, dass Spitzen in beide Richtungen gleichzeitig auftreten können. Meist kommen in zentralen lagen weitere Aktivitäten hinzu (wie Freizeit, Einkauf), welche zu einem insgesamt stärker geglättetem Veloaufkommen über den Tag sorgen.

Interessant ist schliesslich noch die Langstrasse: Dort deutet der zunehmend starke Verkehr am Nachmittag, die gegenüber der Morgenspitze grössere Abendspitze sowie der wahrnehmbare Verkehrsanteil bis nach Mitternacht auf die hohe Bedeutung des Freizeitverkehrs hin.

Trotzdem sind an der Langstrasse noch signifikanten Belastungsspitzen am Morgen und Abend und zwar für beide Fahrtrichtungen zu erkennen. Hier zeigt sich, dass die Langstrasse eben auch eine wichtige Tangentialverbindung zwischen bedeutenden Zürcher Wohn- und Arbeitsquartieren ist, welche in beiden Fahrtrichtungen annähernd gleich grosse Verkehrsströme anzieht.

Fazit

Ich hoffe, ich konnte unterstützt von meinem Kollegen Toralf Dittrich einige interessante Einblicke in den Veloverkehr von Zürich geben. Daneben wollte ich auch aber auch aufzeigen, was alles mit der Software R möglich ist:

  • Import von Daten und Geodaten in zahlreichen Formaten (auch Geodaten)
  • Datenmanipulation: Umklassieren, Säubern, Filtern, Gruppieren, Aggregieren, etc. (auch mit räumlichen Funktionen)
  • Berechnung beschreibender Statistiken: Mittelwert, Median, Standardabweichung, Schiefe einer Verteilung, und vieles mehr
  • Gängige Visualisierungen wie zum Beispiel Balkendiagramme, Liniendiagramme und Karten
  • Spezialisiertere Visualisierungen wie Starplots/Spiderplots, kombinierte Diagramme und Heatmaps

Natürlich ist R als Ganzes noch sehr viel mächtiger und umfasst zum Beispiel Tools zur Klassifikation bzw. Clustering, für Data Mining, Regressionsanalysen, schliessende Statistik, und vieles mehr. Auf diese gehe ich vielleicht mal zu einem anderen Zeitpunkt genauer ein.

Hat die Mini-Serie Ihr Interesse an R geweckt? Ist R das richtige Tool für Ihre Organisation? Möchten Sie gerne eine vertiefte Einführung erhalten? Wie kann R mit Ihren GIS-Tools und Ihren Python-Skripts kombiniert werden? Oder haben Sie eine andere Frage in diesem Zusammenhang? Kontaktieren Sie mich unverbindlich.

 

Blick in die Werkzeugkiste: Offene Daten in R – Teil 2

Letzte Woche habe ich den ersten Teil dieses Blogposts veröffentlicht, in dem ich einige einfache Visualisierungsmöglichkeiten der Statistiksoftware R vorgestellt habe. Daneben enthielt der Blogpost einige Empfehlungen zu Entwicklungsumgebungen und Beschreibungen des Arbeitens mit R.

In diesem zweiten Teil möchte ich nun zwei Beispiele speziellerer Visualisierungsformen zeigen und erklären, wie man mit R Daten für solche Visualisierungen aufbereiten kann. Wie gehabt drehen sich meine Betrachtungen um die Daten der permanenten Velozählstellen in der Stadt Zürich. Die Stadt stellt diese Daten verdankenswerterweise im Rahmen ihrer Open Data-Strategie frei zur Verfügung.

Visualisierungs-Klassiker: Nightingale-Plot

Als erstes möchte ich die Wochenrhythmen des Veloverkehrs an den einzelnen Zählstellen visualisieren. Das habe ich mit einem sogenannten Nightingale-Plot gemacht. Ich habe den Plot aus R im PDF-Format exportiert und im Vektorgrafikprogramm Inkscape noch etwas verschönert. Generell gilt: man kommt mit R grafisch relativ weit. Insbesondere mit ggplot2 erstellte Grafiken kann man in der Regel direkt zum Beispiel in Berichten einsetzen. Je nach Grafik bzw. dem verwendeten R-Paket kann sich das „Nachpolieren“ meiner Meinung nach aber schon lohnen. Ich habe dies bei beiden folgenden Grafiken (jeweils in einem Umfang von weniger als 10 Minuten) getan.

Der Nightingale-Plot vergleicht die mittlere Anzahl Velos pro Stunde über die Wochentage hinweg und visualisiert diese über den Radius (hier gibt es eine kritische Diskussion dazu). Die einzelnen Darstellungen zeigen damit das Geschehen an der jeweiligen Zählstelle (man darf also nicht einen absoluten Vergleich zum Beispiel zwischen den Dienstags-Zahlen an der Andreasstrasse und jenen an der Binzmühlestrasse anstellen).

Beim Prüfen der einzelnen Wochenmuster fällt auf, dass an den meisten Stationen der Veloverkehr am Samstag und Sonntag gegenüber den Arbeitstagen deutlich abfällt. Prominenteste Ausnahme ist der Mythenquai (MYTH) für Samstag und Sonntag sowie die Schulstrasse (SCHU) am Samstag. Die Langstrassen-Zählstelle (LANG) im Ausgangsquartier hat auch noch ein respektables Veloaufkommen am Samstag. Der rege Wochenendverkehr am Mythenquai und an der Schulstrasse lässt sich wohl primär aus Freizeitaktivitäten wie zum Beispiel einem Veloausflug entlang des linken Seeufers oder der entlang der Glatt begründen.

Kombination: Box-Plot und Liniendiagramm

Die nächste Grafik mit normalisierten Velozahlen pro Wochentag und Zählstelle reflektiert denselben Sachverhalt. Hier lassen sich aber Werte gut ablesen, während der Nightingale-Plot oben vor allem eine qualitative Übersicht gibt (und gewisse Probleme birgt).

Das spezielle Verkehrsmuster an Mythenquai und Schulstrasse ist auch in dieser Grafik augenfällig. Für die meisten anderen Zählstellen fallen die Zahlen am Samstag und am Sonntag auf circa 70% bzw. 50% des Tags mit den meisten Velos (in der Regel der Dienstag) ab.

Die kombinierte Grafik mit Boxplots und Liniendiagramm konnte in R einfach erstellt werden. Populäre Visualisierungspakete wie ggplot und ggmap setzten das Layer-Modell für Grafiken um. So konnte ich sehr einfach zuerst die Boxplots zeichnen und diese dann mit einer Liniengrafik überlagern. Das Layer-Modell bietet grosse Flexibilität. Aber: Wie immer wenn die technischen Möglichkeiten gross sind, ist aber das gesunde Augenmass der Anwenderin bzw. des Anwenders umso wichtiger.

Datenumformungen

In diesem Abschnitt erläutere ich einige Datenbearbeitungsschritte, welche für die hier vorgestellten Beispiele nötig waren, um die Daten der Stadt Zürich für die Visualisierungen passend aufzubereiten. Weniger technisch Interessierte können sich die Lektüre sparen und direkt zum Ende springen.

Das Einlesen der Velodaten der Stadt Zürich (Zählstände und Orte der Zählstellen) in R geschieht mit einigen Standard-Funktionen, die man bald memorisiert hat:

Einlesen von Daten im CSV-Format
Einlesen von Daten im CSV-Format

Nach dem Einlesen werden die Daten für die verschiedenen Visualisierungen unterschiedlich aggregiert. Dies kann mit einer Reihe von R-Bibliotheken und -Funktionen geschehen – zum Beispiel mit reshape und plyr. Oft führen mehrere Wege zum Ziel. Im folgenden Beispiel habe ich die beiden Tools kombiniert eingesetzt.

Wir starten mit diesem Datensatz (Auszug):

Um zu einen Datensatz zu erhalten, der für Visualisierung wie oben geeignet ist, aggregieren wir mit einer ersten Datenumformung per Wochentag. Als Aggregationsfunktion wird der Mittelwert (mean) gewählt:

Dadurch werden die Daten in die sogenannte long form (wenige, dafür lange Spalten) konvertiert. Der neue Datensatz listet alle Daten (also die Mittelwerte an allen Wochentage an allen Zählstationen) in je einer Spalte:

Mit einer zweiten Umformung erreichen wir, dass die einzelnen Wochentage jeweils ihre eigene Spalte erhalten und dass eine Zeile jeweils alle Daten einer Zählstelle umfasst (die wide form):

Nun gilt es für schöne Darstellungen nur noch, die Reihenfolge der Spalten so zu verändern, dass die Wochentage in ihrer korrekten Reihenfolge aufgelistet sind. Der folgende Datensatz diente als Grundlage für die Erstellung sowohl des Nightingale-Plot als auch des Boxplots mit Linien:

Und sonst?

Mit anderen Aggregationsoperationen können in R natürlich auch bequem andere Zeitperioden als Wochen untersucht werden, zum Beispiel der Jahresrhythmus des Veloverkehrs. Einige solcher Darstellungen werden Sie im dritten Teil dieser Serie finden.

Ich hoffe, dass ich mit diesem Artikel einige Einblicke in die Fähigkeiten von R im Bereich der komplexeren Datenumformung und der Visualisierung geben konnte. Für den letzten Teil halte ich noch zwei weitere Visualisierungstypen bereit: eine thematische Karte, die zwei Dimensionen visualisiert, sowie eine Heatmap.

Abonnieren Sie unseren RSS-Feed, um keinen unserer Artikel zu verpassen!

[Beim Schreiben dieses Artikels wurde ich unterstützt von Toralf Dittrich, Spezialist für Verkehrstechnik und Verkehrsmanagement in unserem Geschäftsbereich Verkehr.]

Services or raw data? Invalidate your cache, stupid!

Imagine, you are dependent on Open Government Data and want to include them in your workflow. Do you prefer web services (like WFS or Esri’s Feature services) or do you want the raw data? On Twitter and offline, I had several discussions on this topic. In the following, I summarize my thoughts for future reference1.

What is Open Government Data anyway?

I like to think of the use of Open Government Data (or Open Data) as using layers of services2:

pyramid-services-data

  • Raw data contains the actual measurements or atomic information. It is usually served as one block in a basic file format (CSV, Excel or even worse as unstructured PDF), may be zipped and delivered via websites, ftp or, shockingly, using traditional media such as DVD.
  • Individual features are usually served by an API, like WFS or a proprietary JSON API. The features may also be requested in bulk.
  • Aggregations or topics are based on the inidviual features and provide higher level abstractions, like a summary of the population of all cantons, based on raw population numbers.
  • Presentations may be reports, websites or even apps, which present the aggregated data in a form that is structured as a response to a problem.

It’s easy to see that raw data is the basis for all of the subsequent layers. If the raw data changes, so do the derived features, aggregations, presentations and possibly decision that has been informed by the data (products).

Consuming Open Data – It’s about invalidating your cache

In the long-term, one of the biggest challenges of Open Data is not to have the raw data publicly available, but to provide and consume up-to-date and high quality services based on the original data. As a consumer, you have to keep in mind that everything is a cache, as long as you are not the owner of the data. And arguably, handling caches is a hard thing to tackle3: You are in a dependency chain and you are not in control of the whole chain. Keep in mind that the uncontrollability of the dependency chain applies to both the provider and the consumer of third party data.

Keep Calm And Clear Cache
(Source: Flickr, nodespt, CC BY 2.0)

The Open Knowledge Foundation says: „Our Mission is a World of Frictionless Data“. In my opinion, the challenge of keeping up-to-date is one of the long-term frictions we have to overcome. By the way, other frictions are astutely described in Tyler Bell’s write-up on using 3rd party data.

Invalidating your cache means being responsible with data: If you use raw data for your services or apps, you have the responsibility to make sure your data is up-to-date for your service (or otherwise clearly mark the source and the compilation date of your content).

What should be offered, services or raw data?

But looking at this from the other end: what should the government provide? Raw data for sure. If it is part of their mission, they should also provide at least feature level and aggregation services. For example, geodata is used within many governmental processes. So, an agency has to provide services like maps or cadastral information in order to make sure others can fulfill their task, like issuing building permits. On the other hand, there are cases where services or apps are not part of the government’s mission and they should not build them (example: location analysis for real estate).

If the dataset is huge and not too many things change, data services are favorable instead of raw data downloads since it is easier to invalidate your local data cache using up-to-date data services. The turn-around from changes at the local government to changes within your workflow is generally faster than with raw data downloads (which may only be available every six month, if at all).

In Switzerland, the recently launched Open Data government portal is a great step towards frictionless data. It is a common landing point to get data that can be referenced using permalinks. However, most of the data is in Excel format with unstructured metadata (some of it zipped) or, even worse, in PDFs. And it’s still raw data.

The canton of Zurich experimentally started an approach towards services with its geodata: Currently, there are 8 WFS services, which can be accessed directly with common GIS tools, or in more popular formats like JSON with HSR’s GeoConverter.

Update 2014-04-03: On opendata.admin.ch, there is now a WFS service category (currently from canton Zürich). If you look for service for the city of Zürich, there is a catalog with 90+ datasets and services in various formats.

Update 2016-09-29: Good news: The national open data platform has been released at opendata.swiss. Among other organizations, SBB and both the canton and city of Zürich have joined the national portal. And some organiozations provide their data even both as a download and as a service – great!

What can you do as an Open Data consumer?

As said above, both the provider and the consumer should act responsibly since they are both part of the unavoidable dependency chain. As a consumer of data, you can do lots of things, some of them are:

  • Provide exact attribution with exact reference and timestamp.
  • Make sure that you get notified when the original data changes.
  • Make sure your workflow keeps your product up-to-date, such as Mike Bostock’s data compilation approach.
  • As a community: Think of an ethos of data consumers, which reminds everyone in the dependency chain to act responsibly.

Did I miss something? Probably lots of things. Let me know by pinging me on Twitter: @ping13 or by commenting below.


  1. An earlier version of this article was published on my personal blog
  2. You might be reminded of the disputable DIKW pyramid: Wisdom > Knowledge > Information > Data
  3. There is a variant of the „two-hard-things“ saying, namely: There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors (Source). 

Blick in die Werkzeugkiste: Offene Daten in R – Teil 1

Saisonale Muster: An manchen Zählstellen gibt es mehr "Gförli" als an anderen

R?

Mit dem Satz „R ist ein freier Dialekt von S“ kann man immer wieder für Verwirrung sorgen; aber es stimmt: Die Statistiksoftware R implementiert eine freie Variante von S, welches zum Beispiel im kommerziellen Produkt S-PLUS enthalten ist (Man stelle sich nur vor, welche Kunststücke Google und Co. wohl vollführen müssen, damit man auf der Suche nach R-Ressourcen fündig wird; das klappt mittlerweile aber sehr gut. Fürs Twittern empfiehlt sich übrigens der Hashtag #rstats.). Neben den zahlreichen gängigen und auch exotischeren GIS-Programmen verwenden wir für die Datenanalyse zum Beispiel im Business Intelligence-Bereich eben auch R.

R erfreut sich grosser und steigender Beliebtheit in den Bereichen Statistik, Big Data und Data Mining. Das SwarmLab am New Jersey Institute for Technology vergleicht aktuell in einer unterhaltenden Serie R mit Python (unserem zweiten ‚work horse‘ für die Analyse von Daten). Gerade wenn man Python kennt, kann diese Artikelreihe auch als kompakter Einblick in die Fähigkeiten von R dienen.

Visualisierungen in R

In diesem Blogpost möchte ich etwas auf die Visualisierungsfähigkeiten von R eingehen. Neben den sehr umfassenden Funktionalitäten in den Bereichen der Datenbearbeitung und -analyse hat sich R mittlerweile auch zu einem mächtigen Visualisierungswerkzeug gemausert. Ich werde dies anhand von offenen Daten der Stadt Zürich demonstrieren. Für die Visualisierungen verwende ich verschiedene R-Module, neben zahlreichen anderen etwa ggplot2 und ggmap. Als Entwicklungsumgebung empfehle ich übrigens RStudio, aber es gibt diverse andere Optionen.

Aufgeräumt und anpassbar: Die Oberfläche von RStudio
Aufgeräumt und anpassbar: Die Oberfläche von RStudio

Fallstudie: Velozähldaten

Ich habe für meine Fallstudie die Daten der permanenten städtischen Velozählstellen heruntergeladen. Dank dem übersichtlichen Portal der Stadt Zürich waren die Daten schnell gefunden. Hier möchte ich auch erwähnen, dass Marco Sieber und sein Team via Twitter Fragen zu den städtischen Datenbeständen stets sehr schnell und umfassend beantworten – ein grosses Lob an das Open Data-Team für diese Initiative!

Das Messnetz der Stadt Zürich umfasst 11 Stationen, von denen 10 den Veloverkehr in zwei Richtungen erfassen. Zusätzlich zu den stündlichen Messwerten von 2009-2013 kann man vom Portal der Stadt auch einen Datensatz der Standorte der Zählstellen beziehen. Es ist ein leichtes, die Daten im CSV-Format in R einzulesen und mittels Merge einen Join der Geodaten an die Attributdaten durchzuführen. Swisstopo stellt freundlicherweise sogar ein kleines R-Modul für die Projektion von Schweizer Landeskoordinaten in das international gebräuchliche WGS 1984 zur Verfügung. Die Verarbeitung temporaler Daten ist in R einfach und umfassend möglich. Beispielsweise kann aus einem Zeitstempel einfach der jeweilige Wochentag abgeleitet werden, was praktisch ist um zum Beispiel Wochenrhythmen in Daten zu eruieren.

Meine Analyse begann mit einer Bestandsaufnahme der Daten aus fünf Jahren und ihrer Qualität. Eine Analyse der als fehlerhaft ausgewiesenen Messungen (zum Beispiel infolge Konfigurationsumstellungen, Wartung) zeigte leider, dass die Stadt bei solchen fehlerhaften Messungen nicht einen Nodata-Wert für die Anzahl gemessener Velos einfügt, sondern tatsächlich einen Wert von 0 setzt. Natürlich verzerrt solch ein Wert jegliche Statistik ziemlich drastisch, was einmal mehr den Nutzen und die Notwendigkeit von solchen Qualitätssicherungsschritten demonstriert.

Nicht ideal: "0" statt Nodata bzw. fehlendem Wert
Nicht ideal: „0“ statt Nodata bzw. fehlendem Wert

Räumliche Visualisierungen

Mit ggmap kann ich den Anteil an fehlerhaften Messungen pro Station auch räumlich visualisieren. Hierzu können Basiskarten von Google Maps, Cloudmade (auch mit selbstdefinierten Styles), Stamen und OSM direkt aus R mit einer Zeile Code abgerufen und verwendet werden:

Einfacher Aufruf: Karten in R mit ggmap
Einfacher Aufruf: Basiskarte mit Punktdaten in R mit ggmap

Das Resultat eines nur wenig komplexeren Aufrufs sieht dann so aus:

Fehlerhafte Messungen pro Zählstelle
Fehlerhafte Messungen pro Zählstelle

Natürlich ersetzt R kein vollumfängliches GIS. Aber die Fähigkeiten reichen allemal, um einfachere Kartenansichten zu generieren. Auch Small-Multiples-Darstellungen sind zum Beispiel einfach möglich (und im GIS etwas komplexer umzusetzen). Obige Karte verrät uns auf jeden Fall, dass die Zählstellen Sihlpromenade, Andreasstrasse (Oerlikon) und Mythenquai in der Negativwertung der Messunterbrüche obenaus schwingen.

Nicht-räumliche Darstellungen

Nachdem die insgesamt 2.8% fehlerhafter Messungen aus dem Datensatz herausgefiltert waren, konnte ich genauer den Datenumfang und die Güte beurteilen. Zum Beispiel zeigt die folgende Grafik, dass für verschiedene Messstationen und Monate unterschiedliche viele Messwerte vorliegen. Dies ist einerseits bedingt durch Ausfälle, aber auch dadurch, dass nicht alle Stationen gleichzeitig und zum Jahresbeginn in Betrieb genommen wurden. Die Station an der Langstrasse (LANG) ist zum Beispiel erst seit Juli 2013 operativ.

Anzahl gültige Messungen pro Station pro Monat: Stationen haben sehr unterschiedliche Laufzeiten
Anzahl gültige Messungen pro Station pro Monat: Stationen haben sehr unterschiedliche Laufzeiten

Ebendiese jüngste Station an der Langstrasse kommt bei der Anzahl vorbeifahrender Velos regelmässig auf Rekordwerte von bis maximal circa 600 Velos pro Stunde. Auf dem zweiten Platz rangiert die Station am Mythenquai, wo auch mal um die 450 Velos pro Stunde registriert werden.

In der Folge konzentrierte ich mich auf die Aufdeckung zeitlicher Muster. Beginnend beim saisonalen Rhythmus habe ich die mittlere Anzahl Velos pro Stunde in den Monaten Juli und Dezember verglichen. Durch die Verwendung des Julis (anstatt zum Beispiel dreier Sommermonate) konnte ich auch die Station an der Langstrasse in der Analyse weiterziehen. Der Vergleich der saisonalen Zählungen offenbart bei manchen Stationen doch ziemlich deutliche Unterschiede, welche auf den veränderten Pendlerverkehr (der harte Kern, der auch im Winter Velo fährt, ist halt doch nicht so gross) und sicherlich auch den Freizeitverkehr zurückzuführen sind:

Saisonale Muster: An manchen Zählstellen gibt es mehr „Gförli“ als an anderen

Teil 2 dieses Blicks in die Werkzeugkiste folgt in den nächsten Wochen.


Unterdessen möchte ich noch auf das GeoBeer #6 vom 20. März in Lausanne hinweisen. Wir freuen uns auf zahlreiche Gäste! Mehr Informationen und der Link zur (kostenlosen) Anmeldung finden sich wie immer auf der GeoBeer-Website.

Event-Processing mit FME Server: Zugverspätungen als Push Event

Da unser Bürohaus gleich neben dem Bahnhof Stadelhofen liegt, erreicht man die S-Bahn in einer Minute. Wenn man nun schon am Schreibtisch wüsste, dass der Zug Verspätung hat, könnte man also noch etwas länger sitzen bleiben. Und so eine Nachricht wäre sicher auch nützlich, wenn man an einem anderen Ort unterwegs ist…

dampflokomotive

S-Bahn vor der Erfindung von Smartphones 😉

Da mein iPod auch bei längeren Wartezeiten zuverlässig für gute Unterhaltung sorgt, muss ich zugeben, dass mir die paar Minuten Wartezeit auf einen verspäteten Zug nichts ausmachen. Ausserdem gibt es schon nette Apps der SBB, welche einen über die Verspätungen ausgewählter Züge (und vieles mehr) informieren. Als Übungsanlage für unseren internen Creativity Day war die Aufgabenstellung oben aber ganz gut geeignet, um einige Dinge auszuprobieren: Event-Verarbeitung in FME Server, Azure, Pushover,…

FME ist eine Software zur Format-Umwandlung, Prozessierung und Überprüfung von räumlichen und nicht räumlichen Daten. Format- und Modelltransformationen können in sogenannten Workspaces definiert werden. Zur Transformation von Daten führt man den Workspace entweder in einer Desktop-Applikation (FME Desktop) oder auf einem FME Server aus.

In der Vergangenheit konnten Workspaces in FME Server entweder durch eine Benutzerinteraktion oder zu vordefinierten Zeiten gestartet werden. Seit FME Server 2012 ist es möglich, die Ausführung von Workspaces durch Ereignisse auslösen zu lassen. So ein Ereignis kann alles mögliche sein: ein Messwert eines Sensors, die Positionsmeldung einer Smartphone-App aber auch eine einfache E-Mail. FME Server unterstützt verschiedene Protokolle, über welche Ereignisse übermittelt werden können. Davon ist HTTP wohl für viele Anwendungen die naheliegendste Lösung.

Für die Abfrage der Verspätungsmeldungen haben wir einen recht einfachen Workspace entwickelt. Zuerst ermitteln wir die nächste ÖV-Haltestelle zu einem Punkt, der in unserem Fall die Positionsmeldung eines Smartphones ist. Mit dieser Information fragen wir den Dienst transport.opendata.ch ab (weitere Infos), um den Fahrplan bzw. die Verspätungsmeldungen für diese Station zu bekommen. Wenn Verspätungsmeldungen vorliegen schicken wir diese per Push-Nachricht an das Smartphone.  Dafür haben wir den Dienst Pushover genutzt.

pushover

Aus unserer Sicht stechen vor allem zwei Stärken der Event-Prozessierung mit FME Server hervor: Einerseits können Ereignisse mit einem Raumbezug sehr einfach verarbeitet werden, da die ganze Palette von FME-Werkzeugen zur Verfügung steht. Andererseits ist ist die Entwicklungszeit sehr kurz: Für den oben beschriebenen Prototypen haben wir rund einen Tag aufgewendet, wobei in diesem Aufwand der Aufbau der Infrastruktur enthalten ist.

Potenzial für den FME-Einsatz sehen wir vor allem bei Fragestellungen mit Geofencing. Der „Geofence“ – ein virtueller Zaun – definiert dabei ein bestimmtes Gebiet. Wenn darin ein bestimmtes Ereignis auftritt, löst dies eine Aktion aus. Beispielsweise kann ein System eine Benachrichtigung senden, wenn ein Objekt den Geofence betritt oder verlässt.

Übrigens: Esri unterstützt ab ArcGIS 10.2 ebenfalls Events. Darüber berichten wir vielleicht zu einem späteren Zeitpunkt mal.

PS 1: Many thanks to Safe: Firstly for providing us with a demo license to try out events and notifications in FME Server ourselves. Secondly to Steve from the Safe support team for providing us with a very quick answer to a configuration issue.

PS 2: Zum Schluss noch eine kleine Werbung in eigener Sache: Ich wurde von Safe als „FME Certified Professional“ zertifiziert.

Web Scraping von Wikipedia-Koordinaten

Wikipedia ist eine fast unerschöpfliche Informationsquelle: Die deutsche Ausgabe umfasst mittlerweile mehr als 1.5 Millionen Artikel. Wenn ich jeden Tag 100 Artikel daraus lesen würde, wäre ich ungefähr für die nächsten 40 Jahre beschäftigt, sofern keine neuen Artikel hinzukämen. Aus geographischer Sicht bemerkenswert und möglicherweise nicht so bekannt ist die Georeferenzierung von vielen Artikeln. Im WikiProjekt Georeferenzierung werden Lageinformationen für Wikipedia-Inhalte bestimmt. Mittlerweile gibt es deshalb in der deutschsprachigen Wikipedia über 340’000 Koordinatenangaben.  Beispielsweise sind neben den Artikeln für Städte oder Berge auch Artikel zu Bauwerken georeferenziert. Die Koordinaten eines Orts sind jeweils oben rechts eines Artikels zu finden. Praktischerweise kann man sich den Ort auch gleich auf einer Open Street Map-Karte anzeigen lassen.

millionenstaedte307 Millionenstädte gemäss Wikipedia

„Web Scraping von Wikipedia-Koordinaten“ weiterlesen

GIS-Netzwerk im Zeitalter von Social Media

Geographie („Erdbeschreibung“) beschäftigt sich mit Raum. Spätestens seit Michael Hermanns und Heiri Leutholds Arbeiten (sotomo) ist aber klar, dass diese Räume nicht immer geographisch im Sinn von „physisch“ sein müssen: Wir können zum Beispiel auch Merkmals-Räume, topologische Räume (Netzwerke, wie zum Beispiel Strassennetze oder Entwässerungssyteme) oder virtuelle Räume analysieren. Letzteres habe ich mir in diesem Blogpost vorgenommen.

Stephan Heuel (@ping13) und ich (@rastrau) sind beide schon länger auf Twitter. Wir schätzen die schnelle, unkomplizierte Art von Twitter als Plattform zur Kommunikation und zum Austausch von Informationen. Wir beide verfolgen auch zahlreiche GIS-Blogs und Twitter ist die schnellere, interaktivere Ergänzung dazu. Erfreulicherweise sind immer mehr Kolleginnen und Kollegen aus der GIS-Welt auch auf Twitter vertreten. Ein systematischer Überblick fehlte (zumindest mir) aber. Das habe ich zum Anlass genommen, die meines Wissens erste

Vermessung der Schweizer GIS-Szene 2.0

vorzunehmen. Dazu habe ich aus der Schar der Leute, denen ich auf Twitter folge, eine Liste erstellt mit Schweizer Twitter-Accounts, die sich mit Themen rund um GIS, räumliche Analyse und Kartographie auseinandersetzen. Etwas angereichert habe ich die Leute, indem ich auf Twitter noch um weitere GIS-bezogene Accounts nachgefragt habe. So erhielt ich meine circa 35 sogenannten „seed users„, also Ausgangspunkte

Diese subjektive Auswahl erfüllte mein Ziel einer Vermessung der Schweizer GIS-Szene 2.0 aber natürlich noch nicht! Ich habe dann ausgehend von dieser Liste einen Ansatz umgesetzt, mir unbekannte Accounts mit denselben Eigenschaften zu entdecken: Unter Entlehnung von Know How aus einem privaten Projekt, habe ich für die seed users diejenigen Accounts ermittelt, denen sie folgen und die ihnen folgen. Alle so entdeckten neuen Twitter-Accounts, welche mindestens vier Beziehungen mit meiner Gruppe von seed users hatten, habe ich anschliessend manuell geprüft. „Vier Beziehungen“ heisst hier beispielsweise: ein bestimmter Account folgt zwei seed users und zwei seed users folgen ihm. Bei der Prüfung habe ich aufgrund des Standorts und der Beschreibung („Twitter Bio“) eines Accounts (und in Zweifelsfällen aufgrund abgesetzter Tweets) entschieden, ob er der Schweizer GIS-Szene 2.0 zugeordnet werden kann oder nicht. Nach der Prüfung hat sich die Anzahl auf immerhin 74 Schweizer-GIS-Accounts verdoppelt!

Erkenntnisse

Hintergrund der Twitter-Nutzerinnen und -Nutzer

Die erste Abbildung zeigt eine Wordcloud der Begriffe aus den „Twitter-Biographien“ der gefundenen GIS-Twitter-Nutzerinnen und -Nutzer. Die üblichen Verdächtigen – gis, geospatial, schweiz, geoinformation, developer, geographer, data, geomatik/géomatique – sind natürlich vertreten. Daneben ist auch die „Open“-Community enthalten mit open, openstreetmap, qgis.

CH-GIS-Szene: Twitter-Biographien

 

Wer folgt wem und wer bildet zusammen eine Community?

Die nächste Abbildung zeigt das Netzwerk, das die 74 Twitter-Nutzerinnen und -Nutzer zusammen aufspannen. Mit Software für die Analyse sozialer Netzwerke habe ich die Knoten Gruppen (Communities) zuweisen lassen. Die verwendete Methode hat eine Zufallskomponente, aber die meisten der hier gezeigten Gruppen bleiben ziemlich stabil bei wiederholter Berechnung.

Die Knoten sind zudem gemäss der Anzahl ihrer „Branchen-Follower“ skaliert. Das bedeutet, ich habe für die Skalierung nicht die Anzahl Gesamt-Follower benutzt, sondern die Anzahl Follower im unten abgebildeten Netzwerk. Ansonsten wären manche Accounts, zum Beispiel jener des Bundesamts für Statistik und des Bundesamts für Umwelt deutlich grösser.

CH-GIS-Szene: Anzahl Follower

Sprachgrenzen aufgehoben?

„GIS-Netzwerk im Zeitalter von Social Media“ weiterlesen

Offene Daten: Was läuft in der Schweiz?

Es gibt das interessante aber nicht ganz unumstrittene geflügelte Wort, dass 80% aller Informationen einen räumlichen Bezug haben. Ob die 80% nun stimmen oder ob es eher 60% sind, sicherlich sind Geoinformationen weit verbreitet und von immer noch wachsender wirtschaftlicher Bedeutung. Letzte Woche fanden dann auch dicht an dicht gerade zwei sehr interessante Veranstaltungen mit Geoinformationsbezug statt: Das sogenannte Spirgartentreffen der etablierten Schweizer GIS-Community und das Open Data Camp zur Erkundung offener Daten. Wir haben beide Veranstaltungen besucht und schauen zurück:

Offene Daten: Frischer Wind für die Verwaltung? (www.opendata.ch)

„Offene Daten: Was läuft in der Schweiz?“ weiterlesen

Ist OpenStreetMap das Wikipedia für Karten?

Vor vier Jahren haben wir im Rahmen eines Projekts in München das erste Mal OpenStreetMap (OSM) in einem Kundenbericht erwähnt. Damals bedurfte das freie Geodatenprojekt bei unserem Auftraggeber einiger Erklärungen, obwohl schon zu diesem Zeitpunkt die Stadt München in OSM qualitativ und quantitativ sehr gut abgedeckt war. In den letzten Jahren ist OSM immer mehr ins öffentliche Bewusstsein gerückt und Unternehmen wie Apple nutzen die Daten von OSM. Doch was ist OpenStreetMap genau? Eine gängige Erklärung war und ist weiterhin, OpenStreetMap sei „Wikipedia für Karten“. Als erste Näherung ist die Definition nicht schlecht, da damit insbesondere der Crowdsourcing-Charakter herausgestrichen wird. Der Vergleich wird aber eigentlich beiden Projekten nicht ganz gerecht und hilft auch nicht, OpenStreetMap im Detail zu verstehen.

Ich möchte in diesem Blogpost den Vergleich von OpenStreetMap und Wikipedia nutzen, um uns dem Phänomen freier Geodaten zu nähern. Vor anderthalb Jahren hat Oliver Kühn bereits einen Blogpost über OpenStreetMap und Wikipedia geschrieben. Wir nehmen die Idee auf und möchten eine Reihe von Ähnlichkeiten und Unterschieden aufzeigen. Wir hoffen, dass dies dem besseren Verständnis für Crowdsourcing-Projekte allgemein und OSM im Besonderen dient.

Die Ähnlichkeiten und Unterschiede zwischen Wikipedia und OpenStreetMap

„Ist OpenStreetMap das Wikipedia für Karten?“ weiterlesen