Schlagwort-Archive: OpenData

Linksammlung, offene-Tabs-vom-Sommer-2018-Edition

Understanding the Users of Open Data – Studie vom Mai 2017, welche NutzerInnengruppen eigentlich die Offenen Daten von NYC nutzen, und daraus gebildete Personas (via Knut)

·

Scientists Warn the UN of Capitalism’s Imminent Demise – “Capitalism as we know it is over. So suggests a new report commissioned by a group of scientists appointed by the UN Secretary-General. The main reason? We’re transitioning rapidly to a radically different global economy, due to our increasingly unsustainable exploitation of the planet’s environmental resources.”

·

Five Things We Need to Know About Technological Change – Vortrag von Neil Postman von 1998, der nichts von seiner Aktualitaet verloren hat. Kernpunkte:

  • Jeder Fortschritt ist ein Kompromiss: Der entstandene Vorteil wird mit einem verbundenen Nachteil erkauft. “ulture always pays a price for technology”
  • Die Vor- und Nachteile der neuen Technologie sind nicht gleichverteilt – eine Gruppe profitiert, eine andere erleidet einen Nachteil, und vermutlich juckt’s eine große Gruppe gar nicht erst
  • Jede Technologie basiert auf einer darunterliegenden Philosophie, die wiederum die Denkweise von Menschen beeinflusst, die sich davon leiten lassen. So wie manche Leute gerade ueber alles eine Blockchain pflastern wollen. Vielleicht.
  • Technologischer Fortschritt ist nicht additiv, er verändert jeweils das Ökosystem, in dem er sich befindet
  • Medien [d.h. Technologien] haben die Tendenz, mythisch zu werden: “When a technology become mythic, it is always dangerous because it is then accepted as it is, and is therefore not easily susceptible to modification or control. If you should propose to the average American that television broadcasting should not begin until 5 PM and should cease at 11 PM, or propose that there should be no television commercials, he will think the idea ridiculous. But not because he disagrees with
    your cultural agenda. He will think it ridiculous because he assumes you are proposing that something in nature be changed; as if you are suggesting that the sun should rise at 10 AM instead of at 6.”

·

Tesla, software and disruption – “A great, innovative car and a great car company are not the same thing” (via @tobiasknobloch)

·

Anatomy of an AI System – Tiefer(!) Einstieg in die Zusammenhaenge von Rohstoffbeschaffung, Energiebedarf, Wertschoepfung (und der Ausbeutung privaten Handelns durch Unternehmen), Konsumverhalten etc. am Beispiel von Amazon Echo. (via @lorz)

wasfehlt: Gruendungsberatung fuer Civic-Tech-Projekte

Dieser Tage ging mein Blogpost wieder rum, in dem ich Hackathons als langsam etwas abgedroschenes Standardformat fuer Open Data und Civic Tech betrachtet und gefragt habe, wie sich die Community nachhaltiger foerdern liesse.

Tatsaechlich gibt es mittlerweile schon einige Ansaetze, wie auch die vielen ehrenamtlichen Gruppen gefoerdert werden koennen, und nicht nur die Fraunhofers und sonstigen etwas verstaubten grossen Player. Der Prototype Fund der OKF DE ist ein Beispiel, und dass die Stadt Ulm der Civic-Tech-Community ein ganzes Haus samt Ausstattung zur Verfuegung stellt, findet hoffentlich bald Nachahmung in anderen Staedten.

Eine Sache fehlt aber nach wie vor ganz gewaltig, und das ist Beratung. Auch als Bruecke, um die vielen Ideen, die in den OK Labs und anderen Initiativen entstehen, ueberhaupt erst in einen Zustand zu versetzen, um sich beispielsweise fuer den Prototype Fund bewerben zu koennen.

Startup- vs. Gemeinwohlberatung

Es ist ja eigentlich eine Crux: Wer heutzutage ein Startup gruenden und VC-Gelder verbrennen moechte, findet an jeder Ecke institutionalisierte Beratung. Gruenderzentren, IHK und Co. pruegeln sich geradezu, wer denn nun kompetenter beraten kann, Literatur gibts zuhauf, und wenn die politischen Signale guenstig stehen, fliessen auch die Foerdertoepfe grosszuegig.

Fuer Civic-Tech-Projekte – insbesondere diejenigen, aus denen sich kein Geschaeftsmodell entwickeln laesst, sondern deren Gemeinnuetzigkeit dem entgegensteht – sieht die Lage mau aus. Das klang neulich schon an, als ich nach Alternativen zu den von unbedachten Hackathon-Veranstaltern oft ausgelobten grossen Barpreisen fragte:

Was auffaellt: Viele der Vorschlaege drehen sich um Mentorierung und Folgefinanzierung – der Rest um die schon im Dezember angesprochenen Huerdensenker wie Reisekosten etc.

Weil

Das da oben habe ich mittlerwiele zigmal gehoert.

Jedes Mal in einer Runde mit faehigen Leuten[1], die die Idee garantiert umsetzen koennten. Und fuer die der Schritt aber gefuehlt zu gewagt ist, ihre (in der Regel) Festanstellung zu reduzieren und nebenher finanziert aus $Foerdertopf dieses Projekt voranzubringen. Oder es laeuft noch viel banaler, und die oertliche Civic-Tech-Gruppe bekommt von Lokalpolitikern eingefluestert, dass man sie schon laengst in einem Foerderprogramm untergebracht haette, wenn sie nur endlich mal einen gemeinnuetzigen Verein gegruendet haetten.

Diese Kluft haette ich gerne ueberbrueckt. Damit nicht nur Vereinsprofis und die jetzt schon freiberuflich arbeitenden Softwareentwickler*innen eine Chance auf Foerderung haben, sondern auch moeglichst viele andere.

Auf dass es bald in jedem OK Lab heissen kann:

Wiederkehrender Dialog:
„Ja ey, [XYZ] bräuchte es!“
„Ja, und das wuerde sogar zu [Foerdertopf] passen“
„Hm“
„Ich frag mal die Civic-Tech-Sprechstunde“
„Jo“

[1] Meine Definition in diesem Kontext: Leute, die etwa tausendfach besser Software entwickeln koennen als ich. Das fuehrt unweigerlich dazu, dass ich von enorm vielen faehigen Leuten umgeben bin.

Offene Daten für den Einzelhandel

Man kann eine ganze Reihe von Gruenden finden, warum man etwas im lokalen Einzelhandel und nicht online kauft. Weil man nicht dazu beitragen will, dass Menschen Robotergleich durch Versandzentren gescheucht werden, beispielsweise. Oder weil es um die Arbeitsbedingungen bei den Paketdiensten oft nicht besser ist. Oder weil man generell einen Wert darin sieht, vor Ort noch Ladengeschaefte zu haben – und die eben auch Umsatz brauchen, um zu ueberleben. Politischer Konsum, ganz klassisch.

In Ulm scheint man der Ansicht zu sein, den Einzelhandel vor allem durch Fahrspuren fuer Autos foerdern zu koennen. Weil, so die Logik, Leute ja staufrei mit dem KFZ in die Innenstadt fahren wollen, um dann zu konsumieren. Die angedachte Reduktion der Friedrich-Ebert-Strasse von vier auf zwei Fahrspuren wurde denn gleich als Untergang des Einzelhandels gebrandmarkt – egal was die verkehrsplanerische Vernunft sagt, denn das Braess-Paradoxon ist eben mal kontraintuitiv.

Aus Sicht einer, aeh, vielleicht mehr netz- als autoorientierten Generation laege die Loesung aber ganz woanders. Die Schmerzen bestehen fuer mich viel mehr darin, dass ich mich gar nicht damit beschaeftigen will, wo ich denn nun mein gewuenschtes Produkt im stationaeren Einzelhandel bekomme und wie ich da hinkomme. Je niedriger diese Schwelle ist, desto einfacher wird der Amazon-Verzicht. Eine Bierlaunenidee war da schnell gefunden:

Offene Daten ueber offene Schnittstellen aus dem Einzelhandel, dazu Soll-Fahrplandaten im GTFS-Format – damit waere das Feld bestellt, auf dem beliebige Browserplugins geschrieben werden koennten, um dem Ziel naeherzukommen.

Wie sich wenige Tage spaeter herausstellte, gibt es so etwas tatsaechlich schon:

Zugegeben, fuer den Buecher-Anwendungsfall ist die Angelegenheit etwas einfacher – jedes Buch laesst sich ja eindeutig ueber seine ISBN identifizieren, und quasi alle Bibliotheken haben irgendeine Form von OPAC, in den sich die ISBN fuettern laesst. Bei anderen Produkten ist das schwieriger aufzuloesen – und vor allem hat der Einzelhandel auch bislang seltenst ueberhaupt Schnittstellen fuer sein Inventar. Geschweige denn in standardisierter Form.

Langfristig waere aber genau das der richtige Ansatz: Offene, standardisierte Schnittstellen. Auf deren Basis dann jemand beispielsweise als Radkutschenkurier sein eigenes Geschaeft aufbauen kann, um entweder binnen einer Stunde die gewuenschte Ware aus dem Laden in der Stadt nach Hause liefert.

Das wird nicht gleich morgen entstehen, und es beraubt einen des befriedigenden Gefuehls der Geschaeftigkeit, das man beispielsweise beim Einrichten von Portalen hat (niemand braucht und/oder nutzt Portale). Geschaeftigkeit ist aber nicht Produktivitaet – und was ich fuer die nachhaltigere Loesung halte, duerfte klar sein, oder? 😉

Lieber Clever als Smart: Civic Tech fuer Menschen

Drei (plus x) Lese- und Ansehempfehlungen, die mir gestern nach und nach in den Twitterfeed gepurzelt sind und ebenfalls zur Frage passen, wie Civic Tech weitergesponnen werden kann.

Erstens das Boston Smart City Playbook, das schon gleich mit einem Kracher anfaengt:

The age of the “Smart City” is upon us!

It’s just that, we don’t really know what that means. Or, at least, not yet.

So far, every “Smart City” pilot project that we’ve undertaken here in Boston has ended with a glossy presentation, and a collective shrug. Nobody’s really known what to do next, or how the technology and data might lead to new or improved services.

Es folgt ein Rant ueber Vertriebsdrohnen von „Smart City“-Verkaufsbueros, eine Rueckbesinnung auf die Menschen, um die’s gehen soll, dass es nicht noch eine Plattform braucht (!!! zefix!!!), und dass im Zweifel eine „Clevere“ Stadt besser ist als eine „Smarte“: Mit einem Prototypen, einer intelligenten Strassenlaterne. Kleinen Spielplaetzen, die spaeter vielleicht hochskaliert werden, wenn sie sich bewaehren. Anstelle von Alles-oder-nichts-Megaprojekten.

Zweitens The Engine Room’s Advent Calendar mit einem Lesetipp fuer jeden Tag. Beispielsweise, dass „Startup-Kultur“ eine denkbar depperte Denkweise und Rahmenbedingung fuer gesellschaftsveraendernde Projekte ist. Dass „Innovation“ vollkommen ueberbewertet ist und „Wartung und Unterhalt“ eigentlich die wichtigeren Buzzwords sein sollten. Oder dass im Westen nach wie vor nicht-wohlhabende nicht-weisse Nicht-Akademikerinnen (hier: spezifisches Femininum) vergleichsweise wenig von Civic Tech haben.

Um Ausschluesse geht es – drittens – auch in Programming is Forgetting: Towards a New Hacker Ethic. Der etwas mehr als 20minuetige Vortrag (siehe oben) ist hier komplett transkribiert und lohnt sich zu lesen, gerne auch haeppchenweise. Am Beispiel einer Anekdote um die juengst mit der Presidential Medal of Freedom ausgezeichneten Margaret Hamilton zerlegt Allison Parrish Stueck fuer Stueck die „Hackerethik“, wie sie Steven Levy 1984 in seinem Buch “Hackers” dargestellt hatte. Nach einem Exkurs ueber soziale Kontexte stellt sie den urspruenglichen Lemmas jeweils eine Frage gegenueber. Und ich finde sie grossartig:

allison-parrish-programming-forgetting-26

(danke @lorz und @mjays fuer die Links. Ich weiss leider nicht mehr, von wem ich den Vortrag retweeted bekam.)

Von Hackathons und Communityfoerderung

Foto: Sebastián Laraia für Deutsche Bahn / CCBY4.0

Foto: Sebastián Laraia für Deutsche Bahn / CCBY4.0

Mittlerweile hat sich herumgesprochen, dass Hackathons eine ganz gute Moeglichkeit sind, die eigene Stadt, Behoerde oder Konzern zu oeffnen und sich frischen Wind in die verstaubten Hallen zu holen. Das BMVI lud derletzt zum zweiten Mal zum Data Run, und die Deutsche Bahn hatte gestern den fuenften Hackathon binnen 20 Monaten ueber die Buehne gebracht. Nicht schlecht, koennte man sagen.

Was mir aber schon bei unseren OpenCityCamps auffiel: Nach einer Weile scheint sich das etwas totzulaufen. Die ausrichtende Einrichtung darf von Mal zu Mal neue Datenquellen freischaufeln, um sich nicht dem Vorwurf auszusetzen, es bewege sich nichts mehr. Ob diese – muehsam irgendeiner grantelnden Fachabteilung abgetrotzten – Daten dann helfen, tatsaechliche Probleme echter Menschen zu beheben, weiss vorher kein Mensch. Und irgendwann ist auch der Punkt erreicht, an dem die naechsten grossen zu beackernden Baustellen einfach gar nicht mehr an einem 24-Stunden-Hackathon bearbeitet werden koennen.

Vor diesem Hintergrund deswegen mal ein paar halbgare Einwuerfe, was mir die letzten eineinhalb Jahre so durch den Kopf gegangen ist:

  1. Mit das wichtigste Ergebnis einer Open-Data-Veranstaltung ist, dass sich die Teilnehmer*innen live treffen und austauschen. Egal ob Freiwillige mit Ministeriumsleuten, Ministeriumsleute mit Konzernbeschaeftigten oder sonstwas: Diese Aufeinandertreffen motivieren, inspirieren und sorgen fuer die notwendige regelmaessige Hirnbelueftung mit frischen Ideen. Fuer diesen Austausch muss genuegend Zeit und Raum vorhanden sein. Das haben wir als blutjunge Fachschaftler*innen bei der Konferenzorga zwar gelernt, bei Behoerden darf man von dem Wissen aber nicht unbedingt ausgehen 😉
    Hierzu gehoert auch: Wenn ein Ministerium, eine Landeseinrichtung, ein Staedtetag oder sonstwer eine schicke Austauschveranstaltung macht, dann sollte sie unbedingt auch die Freiwilligen aus der Community mit einladen. Die OPEN! hat das nach der Kritik von 2015 dieses Jahr gemacht, das VDV-Verkehrscamp ebenso. Weiter so!
  2. Irgendwann ist jedoch der Punkt erreicht, an dem das klassische Hackathon-Wettbewerbs-Format nicht mehr traegt. Erstens, weil beim Coden immer die Frage im Raum steht, mit welchem Projekt man denn Preise gewinnen kann. Anstelle der Frage, was nuetzlich, wichtig und sinnvoll waere. Zweitens, weil es das Potenzial verschenkt, gemeinsam mit den vielen tollen, kompetenten Leuten mal ein Wochenende lang strategisch wichtige Dinge auszuarbeiten. Mal dieses Werkzeug uebersetzen. Oder dieses Tool schreiben, das es noch nicht gibt und das bisher jedes Mal irgendwie fehlte. Gruppenuebergreifende Metaprojekte, bei denen jede Gruppe einen kleinen Teil fuer das Gesamtprojekt entwickelt
  3. Aus 1) und 2) folgend: Der konsequente naechste Schritt waere, genau solche Zusammenkuenfte zu foerdern. Bei denen nicht kompetitiv Prototypen gebastelt, sondern gemeinsam die Dinge beackert werden, die fuer die Weiterentwicklung von Open Data in Deutschland wichtig sind.
  4. Die Teilnahme an den Aktionen in 3) darf nicht mehr nur auf den Schultern von Leuten mit viel Zeit oder ausreichend Geld oder beidem ruhen. Die Freiwilligen, die sich ein Wochenende um die Ohren schlagen, duerfen nicht auch noch aus eigener Tasche Anreise und Unterkunft bezahlen muessen, oder per Anhalter anreisen und dann irgendwo auf WG-Sofas pennen. Wer quer durch Deutschland zu so einer Aktion reist, gibt fuer solch ein Wochenende je nach Zeit-Geld-Tradeoff irgendwas zwischen 30 und 300 EUR aus. Das kann sich nur eine ueberschaubare Gruppe privilegierter Leute leisten.

An jeder Ecke wird derzeit haufenweise Kohle auf Big Data, Blockchain 4.0 in der Cloud as a Service und andere Ideen mit ueberschaubarer Halbwertzeit geworfen, die aus irgendeinem Berater-Powerpoint gefallen sind. Foerderfunds werden ins Leben gerufen, auf die sich aufgrund der Rahmenbedingungen letztlich eh nur die ueblichen Verdaechtigen bewerben und die Kohle in bekannter Manier zum Fenster rauswerfen.

Ich wage zu behaupten: Die Foerderung von Veranstaltungen wie in 3) beschrieben und die Vergabe von Reisestipendien fuer Open-Data-Aktivist*innen haette ein deutlich besseres Preis-Leistungs-Verhaeltnis. Da wuerde auch wirklich ein Bruchteil der 100 Millionen des BMVI reichen.

Mal grafisch aufbereitet: Der Status Quo zu Open Data im OPNV

Dreieinhalb Jahre ist es jetzt her, dass die kleinen SWU den bundesweit zweiten GTFS-Fahrplandatensatz veroeffentlichten. Und was sind wir in der Zwischenzeit alles rumgeturnt durch Deutschland, um Bruecken zu schlagen zwischen Civic-Tech-Szene und Verkehrsunternehmen: Auf der rp15, beim Verkehrscamp des VDV in Essen, und im letzten Jahr auch immer wieder bei der Bahn.

Hinter den Kulissen bewegt sich in der Tat sehr viel, was mich dieses Jahr auf der re:publica auch verhalten optimistisch gestimmt hat. Vorne ist davon aber nur maessig viel zu sehen. Ein aktueller Realitaetscheck: Die Verbundkarte, die ich auf dem letzten DB-Hackathon angefangen hatte, aber nun deutlich besser von Alexey umgesetzt wurde:

Ich wuerde sagen: Da geht noch was.

OPEN! 2015 ohne Community, und ein paar Fragen dazu

Vor wenigen Tagen war die OPEN!2015 im Stuttgarter Spitalhof mit einem ganz schoen imposanten Programm. Persoenlich finde ich es prima, dass eine Konferenz rund um Open Data, Open Source und OER in diesem Umfang stattfindet – ich behaupte jetzt einfach mal, das sei die Fortsetzung der OpenCityCamps, die 2012 und 2013 in Ulm und 2014 in Stuttgart stattfanden und sich mit Open Data und offener Verwaltung beschaeftigten 😉

Leider konnte dieses Mal wegen Terminkollisionen aus der Ulmer Arbeitsgruppe (mit Ausnahme des dienstlich anreisenden @geichris von der Stadt Ulm, der natuerlich schon dazugehoert 😉 ) gar niemand teilnehmen. Der offizielle Kontakt zur Ulmer Open-Data-Arbeitsgruppe fand naemlich erstmals fuenf Wochen vor der Veranstaltung statt, und das auch nur, weil wir mal nachfragten.

Und dazu haette ich dann doch mal ein paar Fragen.

  • Die MFG als ausrichtende Einrichtung ist seit 2012 Foerderer der OpenCityCamps gewesen und muesste eigentlich wissen, wo die Grass-Roots-Aktivitaeten zu Open Data in Baden-Wuerttemberg stattfinden. Warum wurde kein einziges Open Knowledge Lab angeschrieben und eingeladen?
  • Mehr noch: Warum mussten wir uns aktiv selber um den Kontakt zur MFG kuemmern, um mal die Frage zu stellen, wie sie sich die Einbindung der Community vorstellen?
  • Wie sollte sich die Community, die ihre Aktivitaeten in der Regel ehrenamtlich betreibt, an einem Arbeitstag (Mittwoch) freinehmen und dann noch 95 EUR Ticketgebuehren bezahlen, um selber vertreten zu sein? (Auf Rueckfrage gab es dann das Angebot, eingeladen zu werden, wenn das jeweilige OK Lab „als Multiplikator dient“. Leider terminlich zu spaet.)
  • In der Stuttgarter Erklaerung ist bei Open Data die Rede von „Rohstoffen“, „Geschaeftsfeldentwicklung“, und dass das Potenzial „prosperierend“ erschlossen werden muesse. In einem Nebensatz geht es dann noch um Daten- und Medienkompetenz, die in der Schule erarbeitet werden muesse – bitter angesichts des Hintergrunds, dass Informatik faktisch aus dem Unterrichtsplan in Baden-Wuerttemberg verdraengt wurde. Vom gemeinnuetzigen Aspekt, der nun seit mehreren Jahren im digitalen Ehrenamt u.A. von den Open Knowledge Labs bearbeitet wurde, keine Rede.

Ich verstehe, dass es bei Open Data immer auch um Businessmodelle geht, und dass – leider – die Wirtschaftsfoerderung ein gewichtiges argumentatives Zugpferd bei der Oeffnung von Regierungsdaten ist. Der Umgang der MFG mit der Civic-Tech-Community, die nun ueber Jahre hinweg mit der Verwaltung dieses Thema beackert und erste Pfade durchs Dickicht geschlagen hat, stoesst mir jedoch sehr sauer auf.

Sollte die Strategie am Ende darauf hinauslaufen, dass nun – wo die Bewegung langsam Fahrt aufnimmt – das digitale Ehrenamt vom Land Baden-Wuerttemberg einfach links liegen gelassen wird, waren wir alle wohl nichts weiter als nuetzliche Idioten.

Verkehrszaehlungsdaten mit R und ggplot2 visualisieren

Wie gestern erzaehlt, hatte ich mich beim Hackday Moers ja mit den Verkehrsmessdaten der Stadt Moers beschaeftigt. Die liegen als CSV-Export vor und umspannen jeweils einen Zeitraum von 48 Stunden – gemessen mit einer dieser Boxen, die am Strassenrand aufgestellt werden, und Geschwindigkeit, Fahrtrichtung und Laenge des Fahrzeugs erfassen. So sieht sowas aus:

14.05.13 07:39:33;00;030;07;0
14.05.13 07:39:35;00;030;04;0
14.05.13 07:39:37;00;027;04;0
14.05.13 07:40:52;00;024;07;0
14.05.13 07:40:53;00;024;07;1
14.05.13 07:41:39;00;035;01;0 

In der ersten Spalte kommt ein Zeitstempel, gefolgt von einem Platzhalter (00), der Geschwindigkeit in km/h, der Fahrzeuglaenge in Metern und der Fahrtrichtung. Auf den Beschreibungsseiten gibt es noch Hinweise zur Klassifizierung der Fahrzeuge nach der Laenge, und Angaben zum Dateinamen (Name der Messstelle und vorgeschriebene Hoechstgeschwindigkeit).

Ich habe das zum Anlass genommen, die nicht sonderlich uebersichtlichen Rohdaten grafisch in R mit ggplot2 aufzubereiten. Cave: Ich bin kein Statistiker, und auch kein R-Crack – das Ergebnis kam durch strategisches Googeln und Ausprobieren von Codeschnipsel zusammen mit dem Lesen der R-internen Dokumentation zustande, und war vor allem auch eine prima Gelegenheit, meine eingerosteten R-Faehigkeiten wieder aufzufrischen. Pull-Requests fuer Verbesserungen sind gerne gesehen 😉

Daten einlesen

Um die Daten zu analysieren, muessen sie natuerlich erst einmal eingelesen werden. Das geht recht fix – Separator fuer die CSV-Spalten ist das Semikolon, und da die Datei ohne Spaltenueberschriften kommt, wird header=FALSE gesetzt:

endstr <- read.csv("endstrasse_17_t50_03112014.txt",header=FALSE,sep=";")
names(endstr) <- c("date","place","tempo","length","direction")

Danach werden mit names() die passenden Spaltenueberschriften gesetzt.

Das reicht schon, um eine erste Auswertung zu machen:

summary(endstr)
                date          place       tempo        length      
 03.11.14 10:56:07:   2   Min.   :0   Min.   :12   Min.   : 1.000  
 03.11.14 12:42:34:   2   1st Qu.:0   1st Qu.:37   1st Qu.: 2.000  
 03.11.14 16:44:23:   2   Median :0   Median :42   Median : 3.000  
 03.11.14 16:44:30:   2   Mean   :0   Mean   :42   Mean   : 3.512  
 04.11.14 10:03:37:   2   3rd Qu.:0   3rd Qu.:47   3rd Qu.: 4.000  
 04.11.14 11:17:40:   2   Max.   :0   Max.   :89   Max.   :43.000  
 (Other)          :2723                                            

Das ist schon einmal ein aufschlussreicher erster Blick: Der Median der Geschwindigkeit ist 42 km/h – und nur ein Viertel der Messungen lag bei 47 km/h oder mehr.

Das laesst sich auch in einem Histogramm fuer die Geschwindigkeit auswerten:

jpeg('endstr_histo.jpg')
hist(endstr$tempo)
dev.off()

endstr_histo

Schoen ist natuerlich anders 😀

Ausgabe als Scatterplot

Passender waere, die Messung als Scatterplot ueber die Zeit hinweg auszugeben. Mein erster Ansatz analog zum unlaengst hier verlinkten Tutorial war ein wenig naiv:

library(ggplot2)
ggplot(endstr, aes(x=date, y=tempo)) +
geom_point()

endstr

Na, wem faellt auf, was da nicht stimmt? Klar, die Zeitpunkte werden nicht als Zeit interpretiert, sondern gleichverteilt auf der X-Achse aufgetragen. Ich habe am Anfang ein wenig herumgebastelt, das bei der Auswertung in POSIX-Zeit umzuwandeln, letztlich war aber die sinnvollere Variante, einfach die Tabelle um einen „richtigen“ Zeitstempel zu erweitern:

endstr$datetime <- as.POSIXct(endstr$date,format="%d.%m.%y %H:%M:%S")

ggplot(endstr, aes(x=datetime, y=tempo)) +
geom_point()

endstr_datetime

Schon besser 🙂 Analog habe ich auch fuer die Fahrzeuggroesse und die Tempoabstufungen Klassen angelegt – bei der Fahrzeuggroesse analog zur Klassifizierung in der Dateibeschreibung der Stadt, bei der Geschwindigkeit bis zum Tempolimit, bis 6 km/h ueber dem Tempolimit, und mehr als 6 km/h zu schnell:

endstr$tempoclass <- cut(endstr$tempo, breaks = c(0,50,56,Inf), labels=c("<50 km/h", "50–56 km/h", ">56 km/h"))
endstr$vehicleclass <-cut(endstr$length, breaks = c(0,8,12, Inf), labels=c("PKW", "LKW", "Lastzug"))

Einfaerben!

Mit diesen Daten lassen sich nun die einzelnen Punkte auch einfaerben. Ich habe die Punkte semitransparent gemacht, damit die Faerbung an den Haeufungen intensiver wird, und die Groesse anhand der Fahrzeugklasse gewaehlt. Fuer die Farben der Geschwindigkeitsklassen habe ich ein Pseudo-Rot-Gelb-Gruen-Schema gewaehlt, das auf eine fuer Farbenblinde taugliche Farbpalette zurueckgreift.

ggplot(endstr, aes(x=datetime, y=tempo, colour = tempoclass)) +
geom_point(alpha=0.2, aes(size=vehicleclass)) +
scale_color_manual(values= c("#009E73", "#E69F00", "#D55E00"), name="Geschwindigkeit")

endstr_colour

Feinanpassung

Ein wenig fehlt noch: Die Achsen und das Diagramm muessen noch richtig beschriftet werden: Die Zeitachse sollte ein im deutschen Sprachraum „passend“ lesbares Zeitformat bekommen, und in der Legende sollten die Punkte und ich wollte auch gerne eine Trendlinie sowie eine Hilfslinie bei der „richtigen“ Geschwindigkeit haben. Die Datumsformat-Umformatierung ist in library(scales) zu finden. Die Farben in der Legende sollten ausserdem nicht transparent angezeigt werden, das geht mit override_aes.

Fuer die Trendlinie habe ich den Tipp aus dem vorher verlinkten Tutorial verwendet, die ein Generalized Additive Model verwendet – ich habe keinen blassen Schimmer, ob das passt, aber es sieht zumindest fuer Semilaien wie mich passend aus 😉

Der komplette Code fuer den Graphen samt Ausgabe als PNG sieht nun so aus:

library(ggplot2);library(scales);library(Cairo);

ggplot(endstr, aes(x=datetime, y=tempo, colour = tempoclass)) +
# Punkte sind semitransparent, Größe abhängig von der Fahrzeugklasse
  geom_point(alpha=0.2, aes(size=vehicleclass)) +
  scale_color_manual(values= c("#009E73", "#E69F00", "#D55E00"), name="Geschwindigkeit") +
  # Hilfslinie bei 50 km/h
  geom_hline(yintercept=50, size=0.4, color="#efefef") +
  # Hilfslinie auf dem Nullpunkt der Y-Achse
  geom_hline(yintercept=0, size=0.1, color="black") +
  # Trendlinie mit Generalized Additive Model, siehe http://minimaxir.com/2015/02/ggplot-tutorial/
  geom_smooth(alpha=0.25, color="black", fill="black") +
  # Achsenbeschriftungen
  labs(title="Geschwindigkeitsmessung in der Endstraße", x="Zeit", y="Geschwindigkeit", size="Fahrzeugart") +
  guides(colour = guide_legend(override.aes = list(size=5 ,alpha=1))) + 
  scale_x_datetime(labels = date_format("%d.%m %H:%M"))

ggsave("endstr_final.png", width=8, height=4, dpi=300, type="cairo-png")

Mit library(Cairo) funktioniert die Transparenz auch bei der Bildausgabe wenigstens leidlich. Ich musste dazu libcairo-dev installieren (mehr Informationen dazu hier und hier)

Und voila – so sieht's aus:

endstr_final

Juka spielt gerade noch nebenher mit Leaflet herum, um die Graphen auch zu kartieren – die gesamte Ausgabe ist derweil auf Github anzusehen.

Vier Wochenenden voller Open Data

Es gibt ja so Veranstaltungen, nach denen geht man voller Motivation nach Hause. Bei mir sind es gerade fuenf Open-Data-Veranstaltungen in fuenf verschiedenen Staedten an den letzten vier Wochenenden gewesen, und sollte jetzt noch irgendwas kommen fallen mir vermutlich vor lauter Grinsen die Ohren ab.

Aber der Reihe nach.

Berlin: Bahn, die erste

IMG_1104

Beste Aussichten hatte am ersten Märzwochenende der Workshop, den die OKF fuer die DB Station&Service in Berlin ausrichtete – buchstaeblich wie metaphorisch. Die Station&Service moechte naemlich sich und ihre Daten oeffnen, wie das die SNCF in Frankreich bereits getan hatte. Die Personenzusammensetzung war genau richtig, und ich am Ende ganz schoen geschlaucht vom Brainstormen und reden. Ich bin sehr gespannt, wie es hier weitergeht, und hatte mir den gesamten Abend danach und die Heimfahrt noch ueberlegt, welche Community-Teile zum Beispiel aus der OpenStreetMap sich hier noch verknuepfen lassen.

Freiburg: Hackathon unterm Sternenbanner

Ganz ohne Getoese hat sich auch Freiburg einen festen Platz auf der Landkarte der innovationsbereiten Staedte verschafft. Das liegt auch an Ivan Acimovic, der in seiner Stadtverwaltung auf ueberraschend viele Open-Data-Vorantreiber_innen bauen kann – und gleich mit einer halben Armee von Mitstreiter_innen einen Open-Data-Hackathon im Carl-Schurz-Haus aus dem Boden stampfte.

Mit der Stadt alleine war es naemlich nicht getan – bwcon Suedwest, das Carl-Schurz-Haus und Profs der Hochschulen Offenburg und Furtwangen warfen sich mit ins Zeug, um diese Veranstaltung durchzufuehren. Dass alle Ergebnisse im Rathaus ausgestellt werden, ist da nur konsequent.

Neben den zu erwartenden Wiederkehrern auf allen Open-Data-Hackathons (natuerlich gab es eine neu erfundene Issue-Tracking-App, die nicht bestehende Loesungen wie Mark-A-Spot verwendet :D) stach fuer mich „Frieda“ besonders hervor: Eine benutzerfreundlichere Neuinterpretation des Freiburger Datenportals FR.ITZ, das bei der Usability noch… Potenzial hat.

Ein wenig schade, dass dieses Projekt bei der Preisvergabe nicht mehr gewuerdigt wurde – zusammen mit dem Projekt „Data Canvas“, das Datenangebot und Bedarfe anhand von Problemstellungen analysieren wollte, haette ich „Frieda“ deutlich hoeher gerankt. Ich bin gespannt, wie viele der Projekte noch weiter entwickelt werden – und wie viele der enthusiastischen Teilnehmer_innen beim kommenden OK Lab Freiburg zu sehen sein werden, das ich leider ganz alleine vertreten musste 🙂

Frankfurt: Die Bahn bewegt (sich) doch!

Und eine Woche spaeter verstummten die Voegel, und der Mond verdunkelte die Sonne, und das scheinbar undenkbare geschah: Die Deutsche Bahn lud zu einem Datenhackathon!

Gerade mal zwei Wochen vorher hatte ich ueberhaupt davon erfahren – ironischerweise auf dem Rueckweg vom DB-Workshop in Berlin, auf dem wir uns fragten, wann sich denn die DB Fernverkehr endlich bewegen wuerde. Der Hackathon war wohl binnen weniger Wochen auf die Beine gestellt worden und war fuer mich eine ausgezeichnete Gelegenheit, einmal mit den Leuten im Konzern zu sprechen, die gerne viel mehr Daten freigeben wuerden – die aber nicht einfach machen duerfen, wie sie gerne wuerden.

In gigantischer 1970er-Jahre-James-BondSuperschurken-Hauptquartier-Atmosphaere hackten immerhin rund 50 Teilnehmer_innen an den noch-nicht-wirklich-offenen Daten der Bahn – Daten, an die in einigen Faellen wohl bislang selbst die Bahn-Leute konzernintern noch nie herangekommen waren, und die es nur durch diesen Hackathon erstmals aus ihrem jeweiligen Silo herausgeschafft haben. Ausgangszustand: Dass die Teilnehmer_innen „nur“ ein einseitiges NDA-Dokument unterzeichnen mussten, ist bereits ein grosser Fortschritt.

Ich musste leider noch am selben Abend weiter, um rechtzeitig nach Moers zu kommen, aber Falco aus der Ulmer Arbeitsgruppe hatte sich spontan mit drei anderen zusammengetan und mit seiner Gruppe mal eben eine bessererere™ Reiseauskunft gestrickt, die historische Verspaetungen beruecksichtigt und die Wahrscheinlichkeit angibt, einen bestimmten Anschluss zu erreichen. Hut ab! Mehr Eindruecke gibt es in einem Youtube-Video der Veranstalter.

Ich warte jetzt jedenfalls ganz gespannt, dass die Ergebnisse des Hackathons konzernintern durch die Entscheiderpositionen sickern – und hoffe instaendig, dass wir demnaechst einmal ein Transit-Camp auf die Beine stellen koennen, bei dem Vortraege, Austausch und Coding Hand in Hand gehen. Idealerweise mit einem Augenmerk auf moeglichst hohe Diversitaet – Fahrtkostenbezuschussungen und eine inklusivere Ansprache koennten viel dazu beitragen, nicht nur die ueblichen Verdaechtigen bzw. die Leute aus dem direkten Umland anzulocken 😉

Moers: Die heimliche Open-Data-Hauptstadt im Nirgendwo

Solcherlei Inklusivitaetsfoerderung war fuer Moers dagegen gar kein Problem – Dank Reisekostenbezuschussung waren „die Ulmer_innen“ gleich zu zweit beim dortigen Hackday, und auch aus Berlin kamen Abordnungen an den Niederrhein.


Claus Arndt
tut sich schon seit einiger Zeit damit hervor, am Rande der Einoede zwischen Pott und den Niederlanden in seiner Kommune das Thema voranzubringen — und kann in seiner Position hierzu auch einiges bewegen. Zum Beispiel diesen Hackday zu veranstalten, bei dem sich auch gleich Interessierte aus dem gesamten Umland fanden, um auch gleich ueber eine Gruendung von „Code for Niederrhein“ nachzudenken.

Moers zeigt fuer mich vor allem, dass Erfolg bei Open Data momentan weniger das Ergebnis grossangelegter Strategiepapiere ist, sondern vom Aufeinandertreffen einer aktiven Community auf engagierte Einzelpersonen mit Gestaltungsspielraum in der Verwaltung lebt. Die besten Absichtserklaerungen, die tollsten Forschungsprojekte nuetzen nichts, wenn die Verwaltung nicht dafuer sorgen kann, dass die freiwilligen Datenveredler ihren Spass nicht verlieren. Indem sie zum Beispiel die Rahmenbedingungen schafft, dass 1.) Daten reibungsarm beschafft werden und 2.) Ergebnisse reibungsarm den Weg zurueck in die Verwaltung finden koennen. In Moers klappt das.

Mehr nachzulesen gibt es auf Wegweiser-Kommune [2], im Government-2.0-Netzwerk, bei Habbel, und in einem Flickr-Fotoset von @mrtopf. Und im Blog von Anke Knopp wird auch erklaert, was es mit der Feuerwehr auf sich hatte 😉

Im Video klingt es auch ein wenig an: Neben Redeployment-Auslotung hatten Juka und ich auch inhaltlich was gemacht, Verkehrszaehlungsdatenauswertung naemlich. Dazu kommt aber noch spaeter mehr 🙂

Leipzig: Code for Germany meets again

Etwas ueber ein Jahr nach dem Auftakt von Code for Germany waren Rens und ich zum gemeinsamen Workshop in Leipzig — um eine grossartig gewachsene Familie von OK Labs zu treffen, die sich mittlerweile auf verschiedenste Themengebiete verteilt hat, von Spielplatzkarten bis zu Feinstaubsensoren fuer jede_n zum Selbst-aufstellen.

Dementsprechend werden mittlerweile auch die Herausforderungen umfangreicher. Ging es anfangs um die Vernetzung an sich, Sichtbarkeit und Austausch, geraten wir als Gemeinschaft nun an die etwas knackigeren Probleme — offenbar genauso, wie das schon beim Vorbild Code for America der Fall war. Redeploying, also das Ausrollen bereits anderswo erprobter Loesungen mit den Daten der eigenen Kommune, scheitert allzu haeufig an der Vielfalt der Datenformate, die aus den Fachverfahren fallen, Standardisierung ist weit weit weg, und akademische Ideen wie die Semantifizierung aller Daten sind momentan leider noch wenig praxistauglich. Zudem sind vielfach Interessierte zu einem Thema bei sich eher alleine, und andere Interessierte anderswo muessen erst einmal gefunden werden.

Umso dankbarer bin ich mittlerweile fuer die verbindende Klammer, die CfG mittlerweile bildet, und bin gespannt auf das, was da noch kommt. Ich bin unglaublich froh darueber, dass schon sehr frueh Diskussionen ueber einen Code of Conduct begonnen hatten — aus Fehlern anderer lernen, ganz angewandt. Und ich moechte mal ganz ausdruecklich ein Dankeschoen an Fiona und Julia aussprechen, die sich nun ueber ein Jahr lang um Vernetzung, Bereitstellung passender Werkzeuge, und das Ruehren der Werbetrommel gekuemmert haben.

Auf das naechste Jahr! Und noch viele kommende Open-Data-Wochenenden 😉