Vom 6. bis 8. Mai ist in Berlin wieder Re:publica. Diesmal ist Offenes Köln auch im Programm vertreten.In der Session am Mittwoch, dem 8. Mai um 16:45 Uhr mit dem Titel “Offene API für die Lokalpolitik” wird es um eine rosige Zukunft gehen, in der lokalpolitische Inhalte praktisch universell zugänglich sind.

Dieser Version der Zukunft kommen wir gerade ein gutes Stück näher, denn unter dem Namen OParl entsteht in diesem Moment eine Standard-Schnittstelle für den Zugriff auf parlamentarische Informationssysteme – oder genauer: Ratsinformationssysteme. (Um die Informationslücke seit dem letzen Blog-Beitrag vom 15. April zu schließen: OParl ist das unmittelbare Ergebnis des darin angekündigten Workshops in Köln.)

Was sollte eine solche API können? Und was könnte die breite Verfügbarkeit einer solchen API für die Transparenz der Lokalpolitik bedeuteten? Welche Anwendungen wären damit denkbar?

Alle Re:publica-Teilnehmerinnen und -Teilnehmer lade ich herzlich dazu ein, die Session durch Fragen und eigene Ideen zu bereichern. Auch außerhalb des Programms freue ich mich über jede Möglichkeit am Rande zum Austausch. Bis nächste Woche!

Weil das momentan eine ferne Utopie ist, ist es höchste Zeit, daran zu arbeiten, dass sie ein wenig näher rückt. Deshalb treffen sich am Mittwoch erstmals Vertreter von Software-Herstellern, Kommunen, IT-Dienstleistern und zivilgesellschaftlichen Organisationen (hier ist die Liste der eingeladenen Organisationen und Firmen) zu einem gemeinsamen Workshop in Köln. Das Thema: Eine Standard-Schnittstelle für Ratsinformationssysteme (RIS).

Veranstalter des Treffens sind Jens Klessmann vom Fraunhofer-Institut FOKUS, Christine Siegfried von der Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister VITAKO und meine Wenigkeit. Die Stadt Köln stellt die Räumlichkeiten zur Verfügung und ist selbst als Teilnehmer auch daran interessiert, die Entwicklung mit eigenen Anforderungen zu begleiten und möglichst selbst von den Ergebnissen der Initiative zu profitieren.

Erstes Ziel des Treffens ist es, herauszufinden, ob die RIS-Hersteller daran interessiert sind, einen offenen Standard zu unterstützen und ihre Produkte im Sinne der gemeinsamen Schnittstelle anzugleichen. Mir persönlich geht es bei der Initiative wohl gemerkt nur um den lesenden Zugriff auf öffentliche RIS-Daten, damit diese möglichst einfach und einheitlich für weitere Anwendungen genutzt werden können. Die Funktionen der RISe gehen normalerweise weit darüber hinaus. So werden damit beispielsweise die Sitzungsgelder verwaltet und die fristgerechte Einreichung von Anträgen, Anfragen etc. geprüft. All das sind Funktionen, die für die Öffentlichkeit, die vor allem die lokalpolitischen Inhalte verfolgen möchte, nur von geringer Bedeutung sind.

Die langfristige Vision ist die, dass Kommunen auf der Suche nach einem RIS-Produkt die Unterstützung des offenen Schnittstellen-Standards als Auswahlkriterium nutzen können. Indem sie auf ein Produkt setzen, dass diesen Standard unterstützt, können Sie davon ausgehen, dass ihre RIS-Inhalte für ein wachsendes Ökosystem von freien Software-Produkten offen stehen. Open-Source-Software wie Offenes Köln sollte dann im Handumdrehen für eine solche Kommune einsetzbar sein. Spezielle Anwendungen wie beispielsweise für mobile Endgereäte oder hundert Prozent barriefefreie Such-Oberflächen wären dann denkbar. Denn der Aufwand, der in die Entwicklung solcher Werkzeuge fließen würde, würde sich in vielen Kommunen auszahlen.

Das wird noch ein spannender Weg. Was denkt Ihr, muss passieren, um diesen Weg erfolgreich zu gehen?

Es wird länger dauern, bis dieses Problem behoben ist. So lange ist die Umfeldsuche mit Kartendarstellung leider nicht benutzbar. Wer Dokumente zu einer bestimmten Straße finden möchte, ist daher auf die ganz normale Stichwortsuche (unterhalb der Karte auf der Startseite) angewiesen. Dort gibt man dann die Namen der Straßen und Plätze ein, zu denen man Inhalte finden möchte.

Die Ursache des Problems: Yahoo hat seinen Placefinder Dienst abgeschaltet und gegen einen kostenpflichtigen Service ersetzt. Mit Placefinder haben wir bisher relativ erfolgreich Eure Eingaben zu einem Ort in Köln aufgelöst – das nennt man “Geocoding”. Das ist bei Adresseingaben übrigens nicht immer ganz einfach, denn Nutzer verwenden unterschiedlichste Schreibweisen, und einige Straßennamen existieren mehrfach in Köln.

Hätte man davon nicht früher erfahren können? Ja, ich denke schon. Aber offensichtlich habe ich bei Yahoo dafür keine passende E-Mail-Adresse hinterlegt. Mein Fehler.

Nun war es vielleicht ohnehin keine so gute Idee, Yahoo Placefinder hierfür zu verwenden. Aber der Dienst hat vor über einem Jahr, als ich Offenes Köln veröffentlicht habe, gut funktioniert und kam mit einer Reihe von verschiedenen Eingaben gut klar.

Eine Umstellung auf einen anderen Geocoding-Dienst dauer leider eine gewisse Zeit (deutlich länger als das Schreiben dieses Blog-Beitrags!), denn jeder Dienst funktioniert auf seine Weise. Die Logik unserer Startseiten-Funktion war eben recht genau an die Möglichkeiten von Yahoo Placefinder angepasst.

Überhaupt stellt sich die Frage nach der richtigen Alternative. Eine naheliegende Möglichkeit ist der Umstieg auf den Nominatim-Dienst von OpenStreetMap. Allerdings ist der nicht unbedingt performant. Gut, es gibt noch die von MapQuest gehostete Version. Aber dann wiederum habe ich ein wenig das Vertrauen in die kommerziellen Anbieter verloren.

Da wir ohnehin schon die Geodaten zu Kölns Straßen aus OpenStreetMap vorhalten, wäre es eine Möglichkeit, einen eigenen Geocoding-Dienst anzubieten. Tatsächlich bietet unsere API schon eine Funktion, die dem sehr nahe kommt. Zwei Dinge fehlen aber noch, um die Funktionen des bisher genutzten Dienstes zu ersetzen:

• Ein Verständnis von nicht exakt passenden Eingaben. Wer “aachener” oder “aachenerstraße” eingibt, möchte in jedem Fall die “Aachener Straße” finden.
• Die Zuordnung von Straßen zu “Gebieten”. Da die Aachener Straße nicht nur mehrmals existiert, sondern sie auch noch sehr lang ist, haben wir bislang bei solchen Straßen alle PLZ-Gebiete, die diese Straße durchquert, zur Auswahl gestellt. Damit konnten Nutzer die Positionierung für die Umfeldsuche besser eingrenzen.

Und noch ein Problemchen: Momentan sind wir ohnehin damit beschäftigt, Offenes Köln hinter den Kulissen komplett umzubauen.

Es sieht daher nach einer Schnelllösung, wahrscheinlich auf Basis von MapQuest Nominatim, aus. Ihr erfahrt natürlich hier und auf Twitter, wenn das Problem behoben ist. Vielen Dank für das Verständnis!

Gerade beschäftige ich mich mit der Erzeugung von Vorschaubildern (Thumbnails). Nutzer, die sich ein Dokument auf Offenes Köln anschauen, sollen sofort erkennen können, worum es sich handelt, noch ohne das Dokument herunter laden zu müssen. Dazu müssen zu allen Dokumentenseiten die Vorschaubilder vorgehalten werden. Immerhin handelt es sich um über 200.000 Seiten, und die Bilder werden jeweils in drei verschiedenen Größen erzeugt.

Bislang war die Thumbnail-Erzeugung auf ImageMagick angewiesen, das wiederum auf Ghostscript vertraute, um PDFs erst in PostScript-Daten und dann in Pixelbilder umzuwandeln. Die erstellten Thumbnails mussten mit dem PIL-Modul in Python geöffnet werden, um die tatsächlichen Abmessungen in Erfahrung zu bringen. Klingt nicht gerade optimal.

(Wer gerne den Python-Code zu dem Script, um das es hier geht, einsehen möchte: Es handelt sich um die Datei scripts/generate_thumbs.py in unserem Repository.)

Ghostscript wird nun immer noch benötigt, auf ImageMagick wird jedoch zukünftig verzichtet. Das Erzeugen der verschiedenen Größen-Versionen macht nun unser Python-Script selbst. Das hat den Vorteil, dass jedes Bild, das von Ghostscript angelegt wird, nur einmal in den Speicher geladen werden muss und keine weiteren externen Prozesse gestartet werden müssen. Das ist ein immenser Vorteil gegenüber der früheren Vorgehensweise, wo mittels “convert” Tool von ImageMagick für jede Thumbnail-Größe erst mal das PDF mittels Ghostscript gerastert werden musste. Ausgerechnet dieser rechenintensivste Vorgang der ganzen Arbeitskette wurde dreimal statt nur einmal erledigt.

Es erweist sich übrigens als entscheidend, die Ausgabe-Auflösung von Ghostscript sehr bewusst zu setzen. Nicht nur kostet jedes zusätzliche Pixel beim ersten Erstellen mehr CPU-Zeit, es wirkt sich auch bei jedem Verkleinerungsvorgang erneut aus. Nach anfänglichen 200 ppi, habe ich später zu 100 ppi gewechselt. Die Auswirkung war enorm. Bei 200ppi dauerte der Ghostscript-Teil für ein Dokument im Mittel 2,2 Sekunden, bei 100 ppi nur 0,9 Sekunden. Die Thumbnail-Erzeugung, also das Anlegen der finalen Größen-Versionen, reduzierte sich dabei von 221 auf 80 Millisekunden im Mittel je Bild.

Wenn man die Bildverkleinerung schon selbst kontrolliert, gibt es weitere Optimierungsmöglichkeiten.

Auf die eine hat mich ein Beitrag im Blog eines Entwicklers gebracht. Nennen wir sie Zwei-Wege-Verkleinerung. Sie besteht darin, dass das Bild zunächst mit einem ressourcenschonenden Algorithmus auf eine Zwischengröße verkleinert wird und dann mit einem ressourcenintensiven, aber hochqualitativ arbeitenden, auf die finale Größe. Ich verwende, wie vom Schreiber vorgeschlagen, als Zwischengröße die doppelte Zielgröße. Damit sind für den finalen Verkleinerungsschritt mit dem ANTIALIAS Algorithmus von PIL für jedes endgültige Pixel exakt vier Zwischenpixel vorhanden- ausreichend Bildinformation also.

Ein weiterer Ansatzpunkt für die Beschleunigung bietet sich speziell bei den Dokumenten, mit denen wir es zu tun haben, an. Denn diese enthalten zum großen Teil nur Graustufen, aber keine Farben. Ghostscript kann das beim Erzeugen der Pixelbilder aus den PDF-Seiten noch nicht unterscheiden und speichert daher immer RGB-Dateien. Mit den Funktionen von PIL ist es sehr leicht, festzustellen, ob das Bild auch tatsächlich Farbinformationen enthält: Man vergleicht einfach die Histogramme der drei Farbkanäle. Sind sie identisch, kann das Bild getrost in den Graustufen-Modus konvertiert werden. Das alles geschieht natürlich vor den Verkleinerungen zu den endgültigen Größenstufen, mit dem Effekt, dass die Resize-Funktion von PIL bei vielen Bildern nur noch einen Farbkanal statt dreien behandeln muss.

Das einzig unpraktische ist, dass die histogram() Funktion von PIL erst mal alle Farbkanäle aneinander hängt. So sieht die entsprechende Funktion zur bedingten Konvertierung in Graustufen aus:

def conditional_to_greyscale(image):
    """
    Konvertiert das übergebene Image in Graustufen,
    falls es keine Farbinformationen enthält
    """
    bands = image.getbands()
    if len(bands) >= 3:
        hist = image.histogram()
        if len(hist) >= 768:
            hist1 = hist[0:256]
            hist2 = hist[256:512]
            hist3 = hist[512:768]
            if hist1 == hist2 == hist3:
                return image.convert('L')
    return image

Wie wirken sich diese Optimierungen aus?

Vorher hatten wir, wie oben geschrieben, im Mittel 80 Millisekunden für ein Thumbnail benötigt. Das beinhaltet sowohl die Skalierung als auch das Speichern als JPEG (auf einer SSD). Durch die Zwei-Wege-Skalierung reduzierte sich die Zeit auf 55 Millisekunden je Thumbnail. Mit zusätzlicher bedingter Graustufen-Konvertierung beträgt die mittlere Zeit noch 31 ms. Das sind noch 14 % from Ausgangswert.

Eine weitere Möglichkeit, die Thumbnail-Erzeugung zu beschleunigen, könnte übrigens in der verwendeten JPEG-Bibliothek liegen. Im Netz gibt es Hinweise, dass mit der libjpg-turbo das Schreiben von JPEG-Dateien deutlich (Faktor 5) schneller sein kann als es mit der Standard-libjpeg funktioniert. Leider ist mir bislang unklar, wie man PIL mit turbo-libjpg kompilieren könnte.

Allerdings macht die Erzeugung der Thumbnail-Bilder nun noch etwa ein Drittel der Arbeitszeit des gesamten Scripts aus. Zwei Drittel hingegen nimmt das Erzeugen der Ausgangsbilder mit Ghostscript ein.

Ob Endnutzer letztlich von diesen Optimierungen etwas merken werden, ist fraglich. Die Graustufen-JPEGs scheinen, was die Dateigröße betrifft, nicht kleiner zu sein, als RGB-Dateien mit derselben Bildinformation. Kürzere Ladezeiten sind also nicht zu erwarten. Allerdings könnte es sein, dass wir zukünftig auch Thumbnails für die vereinzelten Riesen-PDFs anbieten können, zu denen es bisher keine gab. Das sind beispielsweise sehr großformatige Pläne. Bisher wurde die Thumbnail-Erzeugung immer dann abgebrochen, wenn sie an einem Dokument zu lange benötigt hat. Möglich, dass wir hier demnächst eine bessere Abdeckung anbieten können.

Der gerade hinter uns liegende Monat Februar hat uns einen Besucherrekord* beschert. Während wir normalerweise im Schnitt etwa 1.500 Besuche (Visits) je Monat verzeichnen, waren es im Februar fast doppelt so viele, nämlich stolze 2.838. Die Zahl der eindeutigen Besucher (Unique Visitors), im Durchschnitt bei 1.200, betrug 2.224. Das hat sich auch merklich auf die Zahl der Seitenzugriffe ausgewirkt, die mit 9.971 Seiten ebenfalls deutlich über dem Mittel von 5.600 liegt.

Der Anstieg dürfte vor allem durch den Open Data Day mit der damit verbundenen medialen Berichterstattung verbunden sein. Aber auch im Rahmen des Launchs von GovData.de gab es viel Aufmerksamkeit, unter anderem durch den Blogbeitrag dazu.

Die Rohdaten mit mehr Details gibt es in diesem Google Tabellendokument.

Aktuell gibt es übrigens keine Auswertung darüber, wie häufig die API genutzt wird. Die Zahlen oben enthalten dies nicht. Die entsprechende Logfile-Auswertung steht auf der ToDo-Liste.

* Der Rekord bezieht sich auf den Zeitraum seit August 2012. Da haben wir angefangen, Google Analytics einzusetzen. Für die Zeit vorher gibt es keine vergleichbaren Zahlen.

Für Bürger Nordrhein-Westfalens ist ein Teil dieser Daten auf den Online-Angeboten von Straßen.NRW sichtbar, Betreiber ist der “Landesbetrieb Straßenbau Nordrhein-Westfalen”. Die Anwendung autobahn.nrw.de beispielsweise bietet eine Anzeige der aktuellen Auslastung der Autobahnen im Bundesland. Die nachstehende Abbildung zeigt den Ausschnitt einer Kartendarstellung der Anwendung.

Dazu werden auch aktuelle Baustellen und weitere Störungen angezeigt. Und es ist möglich, eine Prognose für die nächsten 30 Minuten, 60 Minuten oder bis zu 7 Tage im Voraus abzurufen. Für Nutzer von Smartphones mit Internetzugang gibt es auch eine optimierte Variante unter autobahn.nrw.de/mobil. Im Unterschied zur Standard-Variante ist diese komplett in HTML und JavaScript, ohne Flash, realisiert. Und – Trommelwirbel – die mobile Variante bekommt die angezeigten Daten als JSON von einer Webservice-API.

Ein Blick auf die Kommunikation zwischen Browser und Server zeigt vier verschiedene API-Aufrufe:

• /mobil/maps.json – lädt Objekte, die für die Kartendarstellung benötigt werden, wie z.B. die Position wichtiger Städte, Gewässer und ein paar Straßenverläufe.
• /mobil/streets.json – Enthält Informationen über die Autobahnen, zu denen die API weitere Auslastungsdaten liefert
• /mobil/bau.json – Liste mit Baustellen
• /mobil/upd.json – Auslastungsdaten je Autobahnabschnitt und Auslastungsprognose

Wie es aussieht, werden die Daten aus upd.json minütlich aktualisiert und repräsentieren jeweils den Zeipunkt von vor 5 Minuten.

Die genaue Funktionsweise zu ermitteln, dürfte ein wenig mehr Aufwand erfordern. Alles, was ich bisher nach Gutdünken herausfinden konnte, habe ich in einem Etherpad festgehalten. Wer Lust hat, darf dieses gerne ergänzen.

Jedenfalls sieht das nach einem Datenangebot aus, mit dem man einiges sinnvolles anstellen könnte. Bleibt die Frage, warum es noch nicht mit einer Lizenz versehen und als Open Data veröffenlticht ist. Falls die Landesregierung von NRW auf dem Weg zu einer Open-Data-Strategie mal fragt, welche Daten Ihr denn gerne hättet, dann verweist ruhig auf diesen Artikel und sagt: “Alles, was bei Straßen.NRW so anfällt”.

Am vergangenen Wochenende hat der Open Data Day Köln stattgefunden, eine lokale Veranstaltung vor dem Hintergrund des internationalen Open Data Day. Aber das weißt Du sicher schon, und als aufmerksame Leserin/aufmerksamer Leser dieses Blogs warst Du bestimmt sogar selbst dabei.

Ich persönlich (als einer der Veranstalter, aber auch als Teilnehmer) sehe die Veranstaltung als großen Erfolg an. Ich sage Euch auch warum:

• Wir haben es geschafft, eine relevante Teilnehmerzahl zu mobilisieren. Mit etwa 45 Leuten haben wir im Vergleich zur Veranstaltung vom Vorjahr ungefähr dreimal so viele Leute zusammen bekommen.
• Wir haben eine Mischung von TeilnehmerInnen mit verschiedenen Hintergründen erreicht, so wie wir uns das erhofft haben. Schätzungsweise die Hälfte der Teilnehmer hat sich den Techie-Aufkleber angeheftet, der Rest war bunt gemischt aus Bereichen wie Journalismus, Design, Business, Daten/Statistik etc. Das hat aus meiner Sicht viel ausgemacht und die Gruppenarbeit sehr bereichtert.
• Die Verwaltung der Stadt Köln war mit mehreren VertreterInnen da. Und nicht nur das. Sie waren auch sehr angetan von der Veranstaltung.
• Es wurde an tollen Projekten gearbeitet. Obwohl sich die Teams erst am Morgen zusammengestellt haben, hat die Zusammenarbeit offensichtlich sehr gut funktioniert.
• Das Thema Open Data hat viel Aufmerksamkeit (siehe Presselinks weiter unten) bekommen und offensichtlich wurde eine ganze Menge positive Energie freigesetzt.

Woran genau wurde denn gearbeitet?

Tagessieger und deshalb mit Sachpreisen von O’Reilly überhäuft wurde die Gruppe Wegmarker. Die hatte sich das Ziel gesetzt, eine mobile Webanwendung für Fahrradfahrer zu bauen, mit der man die Qualität von Wegen/Straßen einfach in die OpenStreetMap-Datenbank eintragen kann. Und es ist ihnen offensichtlich gelungen, diese Funktionen bis zum Abend des ersten Tages nutzbar zu machen. Hier geht es zum Prototyp.

Eine weitere Gruppe hat sich die von der Piratenpartei veröffentlichten Haushaltsdaten von 380 Kommunen vorgenommen und beispielsweise verglichen, wie die Pro-Kopf-Ausgaben für Kultur zwischen den Kommunen variieren.

Meine Gruppe hat die Anwendung OpenOrgData entwickelt. Damit kann man über 2 Mio. Einträge aus Handelsregistern und Vereinsregistern nach Stichworten im Namen durchsuchen. Als Ergebnis wird die Verteilung der Treffer nach Bundesland auf einer Karte angezeigt. Die Datengrundlage steht leider nicht unter einer offenen Lizenz. Mit der App wollen wir auch den Finger in diese Wunde legen und ein Beispiel dafür geben, dass die bloße Verfügbarkeit einer Auskunftsmöglichkeit (Website mit Suchmöglichkeit wie handelsregister.de) und ein Open-Data-Angebot nicht vergleichbar sind.

Für das große Engagement, das den Open Data Day in Köln möglich gemacht hat, gilt es Dank auszusprechen:

• dem Startplatz, namentlich Lorenz Gräf, Julia Schäfer, Sara Usinger und Tine für die Gastfreundlichkeit am Samstag
• Thomas Riedel a.k.a. Droidboy für das Zusammenbringen von Nachfrage und Angebot sowie Live-Begleitung auf Nerdhub
  
• Jan Kus, Coworking Cologne und Railslove für die Gastfreundlichkeit am Sonntag
• den Mitarbeiterinnen und Mitarbeitern der Stadt Köln für das Sponsoring und die Teilnahme
• NetCologne/koeln.de für die fantastische Subdomain opendataday.koeln.de
• O’Reilly für Bücher und E-Books
• allen Teilnehmern für ihre hochmotivierte Teilnahme und die Offenheit

Zur Nachlese bieten sich auch die folgenden Berichte an:

• WDR.de: Treffen der Überzeugungstäter, von Rainer Striewski
• ZDF Hyperland: Open-Data-Day: Freiheit für die Daten, von Torsten Klenz
• Koeln.de: Open Data Day Köln: Datenschätze heben in Teamarbeit, von Ulrich Babiak
• Nerdhub: Videos mit Interviews einiger Teilnehmer, von Thomas Riedel/Droidboy

Nun, wo die Veranstaltung vorbei ist, stellt sich die Frage: Wie geht es weiter mit Open Data in Köln und der Region? Meine Meinung: Wir sollten weiter daran arbeiten, die Community derer, die Open Data nutzen und vorantreiben wollen, auf- und auszubauen. Damit sollte es zukünftig immer einfacher und selbstverständlicher werden, zu Veranstaltungen oder auch gemeinsamen Projekten zusammen zu rufen. Und nicht zuletzt hilft dies auch der Stadt Köln, Ansprechpartner für die Unterstützung beim Open-Data-Prozess zu finden.

Eine Anlaufstelle für alle, die weiter am Ball bleiben wollen, ist die offene Open Data NRW Mailingliste, gehostet von der Open Knowledge Foundation. Wie der Name schon sagt, geht es hier um Open Data in unserem Bundesland. Die Liste wird bisher sehr wenig genutzt. Hier muss daher niemand befürchten, dass eine Mail eventuell zu unwichtig für die Abonnenten ist. Die Liste darf also auch gerne für sehr lokal begrenzte Themen genutzt werden.

Für die Facebook-NutzerInnen unter Euch könnte auch unsere eigene Facebook-Seite (von Offenes Köln) interessant sein. Dort erfährt man sowohl von neuen Datenangeboten als auch von Veranstaltungen und mehr. Auf Facebook gibt es auch eine Gruppe Open Data, wo sich Teilnehmer aus dem gesamten Deutschsprachigen Raum austauschen.

Und natürlich gibt es dieses Blog, wo wir uns freuen, Open-Data-Interessierten aus Köln immer wieder interessante Daten von der Stadt, dem Land oder sonstwem vorzustellen.

Was wollt Ihr noch zum Open Data Day loswerden? Was habt Ihr mitgenommen, was hat Euch gefehlt? Was können wir beim nächsten Mal anders machen?

• Ist die Amsterdamer Straße stadtauswärts immer so voll wie jetzt?
• Wann kann man generell gut über die Zoobrücke in die Stadt kommen und wann nicht?
• Sollte ich grundsätzlich lieber später zur Arbeit fahren? Oder eine andere Strecke nehmen? Oder die Bahn?
• Ist heute verkehrstechnisch ein guter Tag, oder ist die Stadt relativ verstopft?
• Gibt es typische zeitliche Stau-Muster?
• Ist Berufsverkehr abhängig von der Jahreszeit bzw. Sommer- und Winterzeit?
• Lassen sich Staus durch andere Ereignisse wie Veranstaltungen, Wetter etc. erklären und sogar vorhersagen?

Deshalb sammeln wir, seit die Stadt Köln die Stau-API am 7. Februar öffentlich bekannt gemacht hat, die Auslastungsdaten. Seit dem Start sind 440.000 Datensätze aufgelaufen, die jeweils Datum/Uhrzeit, die ID des Straßenabschnitts und den Auslastungswert enthalten.

Damit kann man dann zum Beispiel die durchschnittliche Auslastung auf den Straßen je Stunde als Zeitreihe darstellen. Dazu werden ganz einfach alle Messwerte aus derselben Stunde über alle Straßen hinweg gemittelt. Straßen, für die keine validen Daten berichtet wurden, werden nicht berücksichtigt. Da die Auslastungswerte 0 (frei), 1 (zähfließend) oder 2 (Stau) betragen können, steht ein höherer Mittelwert für eine insgesamt höhere Auslastung. Die Zeitangaben sind übrigens UTC (d.h. Greenwich-Zeit). Für unsere lokale Zeit muss also eine Stunde addiert werden.

(Die Anzeige der Timeline-Grafik erfordert JavaScript und Flash. Auf mobilen Geräten und in RSS-Readern könnte es damit Probleme geben.)

Man kann sehen, dass die letzten Tage seit Montag, 18. Februar ein ganz anderes Bild erzeugen als die Vorwoche (ab 11. Februar), denn da war schließlich Karneval. Auch kann man am 18 bis 20. Ferbuar deutlich erkennen, dass sich in der Stunde von 8 bis 9 Uhr Ortszeit (7:00 UTD in der Darstellung) ein erster deutlicher Peak für den Berufsverkehr ergibt. Der Vorabend-Peak um 17 bis 19 Uhr (16 bzw. 17 Uhr UTC in der Grafik) dauert aber deutlich länger und erreicht auch noch höhere Ausschläge. Übrigens steht jeder Stunden-Mittelwert in der Grafik für ca. 600 bis 700 Einzelwerte.

Wenn wir Daten für einen längeren Zeitraum überschauen können, wird das alles noch deutlich interessanter. Dann wird es möglich sein, einen Donnerstag mit anderen Donnerstagen zu vergleichen, einen Messetag mit anderen Messetagen und einen Regentag mit anderen Regentagen. Und vielleicht ergeben sich daraus interessante Anwendungen. Deshalb speichern wir weiter. Und bei Interesse werden wir die Daten natürlich gerne weiter geben bzw. eine Downloadmöglichkeit einrichten. Das alles natürlich nur, bis die Stadt Köln einen solchen Service selbst anbietet.

Beim Open Data Day am kommenden Wochenende kann selbstverständlicher jeder, der möchte, unkompliziert einen Export des aktuellen Datenbestands haben.

Update, 30. März 2013: Die Datensammlung umfasst nun schon 52 Tage. Immerhin lässt sich bereits ein statistisch signifikanter Zusammenhang zwischen Ereignissen und der mittleren Verkehrsauslastung je Tag feststellen, nämlich beim Vergleich von Messetage und Nicht-Messetagen. Nicht-Messetage haben eine mittlere Auslastung von 0.0467, Messetage eine von 0.0603. Keine Signifikanz gibt es derzeit beim Vergleich der Wochentage, zwischen Werk- und Sonn-/Feiertagen oder zwischen Tagen mit FC Heimspielen und anderen Tagen. Die Daten dazu sind in einem Google Tabellendokument einsehbar.

Update, 2. April 2013: Etwas über drei Tage und zwei Feiertage später ist auch beim Vergleich zwischen Feiertagen und Werktagen ein signifikanter Unterschied feststellbar. Werktage haben aktuell eine durchschnittliche Auslastung von 0.056 (Median 0.050), Feiertage nur 0.038 (Median 0.026). Die Auslastungsadaten spiegeln also auch hier das, was man erwarten würde.

Die obige Demo zeigt die aktuelle Anzahl freier Parkplätze in Parkhäusern an. Jedes Parkhaus wird von einem pinkfarbenen Kreis gekennzeichnet. Je größer der Kreis, desto mehr freie Plätze sind vorhanden.

Wie bei der Stau-API ist auch hier bislang nicht klar, wie aktuell die Daten bei Abruf sind. Auf den Verkehrs-Seiten der Stadt Köln gibt es hierzu keine Information.

Im Gegensatz zu den Daten der Stau-API sind die hier gezeigten Daten von der Stadt Köln noch nicht offiziell zur Nutzung durch Dritte freigegeben und mit einer Lizenz versehen. Daher der Zusatz “Sneak Preview”. Angesichts des Open Data Days am kommenden Wochenende erscheint es aber durchaus interessant, etwas mehr Licht auf wertvolle Daten zu werfen, die technisch für eine Veröffentlichung bereit sind.

Im Code zur obigen Demo (siehe http://jsfiddle.net/Lhaz7/3/) erfahrt Ihr, wie Ihr die API nutzen könnt.

Update 26. Ferbuar 2013: Dieses Datenangebot ist inzwischen von der Stadt Köln auch offiziell veröffentlicht und unter CreativeCommons Lizenz CC-BY-3.0 nutzbar.

Hier eine Vorschau der Daten, die einen Eindruck des Detailgrades vermittelt. (Diese bildet übrigens die entspannte Verkehrssituation am späten gestrigen Abend ab.)
Wenn man weiter hinein zoomt, sieht man, dass auf einigen Straßen sogar zwischen der Fahrtrichtung unterschieden wird.

Die API liefert den genauen Verlauf aller Straßenabschnitte sowie die Auslastung in einer von mehreren Kategorien: frei, zähfließend und Stau. Für einige Straßen gibt es aktuell keine Verkehrs-Informationen. In der Darstellung oben sind das die grauen Linien.

Im Blogbeitrag zur Veröffentlichung des Datensatzes auf offenedaten-koeln.de habe ich ein paar Verbesserungsvorschläge unterbreitet. Beispielsweise wären die Daten als JSONP noch einfacher in Webanwendungen zu integrieren. Und das Ergebnis eines API-Abrufs ist mit 580 KB aktuell noch ziemlich groß, was vor allem an unnötigen Umbrüchen und Leerzeichen sowie an der übermäßigen Genauigkeit der Koordinatenangaben liegt. Fragen sind auch noch offen. Zum Beispiel, wie aktuell die Daten bei einem Abruf sind.

Wenn Euch selbst Anregungen einfallen, wie die Daten verbessert werden könnten, kommentiert am besten auch direkt bei der Stadt.

Wer selbst mal hinein zoomen möchte, kann hier die interaktive Version der obigen Darstellung finden: http://jsfiddle.net/wnKGh/ – mit Code zum Nachbauen und anpassen. Die Daten des API-Aufrufs von gestern Abend sind dort einfach als Objekt im JavaScript Code abgelegt.

Die Daten

• Info-Seite zum Datenangebot
• API: http://www.stadt-koeln.de/externe-dienste/open-data/traffic.php

Update (19. Februar 2013):

Hier ist ein aktualisiertes Beispiel, das tatsächlich die aktuellen Daten von der API anzeigt.

Der Code (siehe http://jsfiddle.net/NEpXG/4/) zeigt außerdem, dass die API auch JSONP unterstützt und dass es durchaus möglich ist, die API-Antworten mit deutlich weniger als 500 KB je Anfrage zu bekommen. Wie das geht? Indem man statt der API-URL von offenedaten-koeln.de direkt auf die eigentliche Webservice API zugreift, wie es auch diese Seite der Stadt Köln tut.

In Kürze wird das Bundesinnenministerium eine Plattform eröffnen, mit der einige Menschen in diesem Land eine gewissen Erwartung verbinden. Eine Erwartung, dass Daten aus den Verwaltungen und Regierungen dieses Landes zugänglicher werden. Dass es einfach möglich sein wird, über eine einzige Plattform auf bedingungslos nutzbare Datenangebote von Bund, Ländern und Kommunen zuzugreifen. Dass Regierungen und Verwaltungen mit diesem Schritt ein gutes Stück transparenter werden und sich neue Möglichkeiten für Dienstleistungen und Innovation auftun.

Diese Erwartung hat in den letzten Wochen einige Dämpfer bekommen. Im Netz wird schon an verschiedener Stelle darüber geschrieben (z. B. von Sebastian Haselbeck auf opengovgermany.com, von Lorenz Matzat auf Netzpolitik.org und von Jan Brennenstuhl auf OpenEverything) und es wird hoffentlich weiter darüber geschrieben werden. Wenn es nach mir geht, gerne auch über die unsichtbaren Grenzen des Netzes hinaus. Gerade weil mich das Thema besonders betrifft, möchte ich gerne ausführlich dazu Stellung nehmen und ein paar Argumente und Hintergründe beisteuern und zur Diskussion stellen. Auch deswegen, weil ich noch nicht recht weiß, wie ich die Situation einordnen soll.

Am vergangenen Freitag, dem 1. Februar, fand der zweite (und vor dem Launch letzte) Community-Workshop zur Plattform, die nun GovData heißen wird, bei Fraunhofer FOKUS in Berlin statt. Mit geschätzten 30 anderen Vertretern war ich, auf Einladung der Open Knowledge Foundation,  dabei, um mir einen eigenen Eindruck vom Stand der Dinge zu machen. Das war nicht mein erster Berührungspunkt mit dem, was die Projektverantwortlichen Beteiligung der Zivilgesellschaft nennen. Schon am 1. und am 20. März 2012 habe ich als Gast an Treffen der “Unterarbeitsgruppe Technik” bei Fraunhofer FOKUS teilgenommen, damals auf Einladung des Open Data Network. Dort präsentierten Fraunhofer FOKUS, Lorenz-von-Stein-Institut und Partnerschaften Deutschland Teile der Inhalte, die im Sommer 2012 als Studie mit dem Titel Open Government Data Deutschland veröffentlicht werden würden.

Alles in allem waren das zwei durchaus interessante Veranstaltungen. Irgendwie seltsame Einblicke in eine ferne Welt, in der Open Data etwas sehr kompliziertes sein muss. Sicherlich haben diese Treffen bei mir eins bewirkt: Sie haben Empathie für Verwaltungsmitarbeiter geweckt. Ob das etwas gutes ist, weiß ich nicht. Wie Tony Bowden von mySociety es ausdrückt:

“Never ever work with the administration! It’s going to melt your brain!

Am ersten Community-Workshop (am 7. Dezember 2012), bei dem der Prototyp der Datenplattform gezeigt wurde, konnte ich leider nicht teilnehmen. Für mich war Mitte Dezember die Veröffentlichung des Vattenfall-Datenportals, das die gleiche Software-Grundlage besitzt wie die Datenplattform von Bund und Ländern, ein erster Einblick in das, was kommen würde. Das erste, was mir daran auffiel war, dass im Datenkatalog die Links zu den Suchergebniseinträgen keine echten Hyperlinks sind, sondern JavaScript-Aufrufe. Möchte man einen solchen Pseudo-Link in einem neuen Browser-Tab öffnen, öffnet sich in dem neuen Tab nicht die erwartete Treffer-Seite, sondern wieder die Suchergebnis-Liste. Damit ist ein häufig verwendetes Nutzungsmuster zum Durcharbeiten von Linklisten, nämlich das Öffnen von Treffern in neuen Tabs, dort nicht anwendbar. Nutzer werden auf das Anti-Pattern namens Pogosticking zurück geworfen. Das bedeutet: Man ist gezwungen, zum Ansehen des Treffers die Suchergebnisliste zu verlassen, um danach über die Back-Funktion wieder dorthin zurück zu kehren, woher man gekommen ist. Und das immer wieder, bis man sicher ist, dass man den richtigen Treffer vor sich hat.

Dieses Problem alleine wäre für mich Grund genug, die Daten des Katalogs zu exportieren und mir eine eigene Suche dafür zu bauen, wenn ich sie brauche.

Am 9. Dezember habe ich direkt über Fraunhofer FOKUS versucht, Zugang zu dem Prototypen der Bund-Länder-Plattform zu bekommen. Die Antwort darauf war, dass dies nur im Rahmen des Community-Workshops am 7. Dezember möglich gewesen wäre, aber man sich erkundigen würde, ob erneut Zugang hergestellt werden kann. Nachdem ich das Problem auf der Vattenfall-Plattform bemerkt hatte, habe ich nachgefragt, ob sich daraus etwas ergeben hat und außerdem das Problem geschildert sowie meine Befürchtung geäußert, dass das Problem auch bei der Bund-Länder-Plattform bestehen könnte. Ich erwähne das hier nur deshalb, weil ich beim zweiten Workshop von einem Fraunhofer-Mitarbeiter gefragt wurde, warum ich das Problem denn nicht schon früher gemeldet hätte.

Wie sich beim zweiten Community-Workshop heraus stellte, war dieses Problem auch bei der GovData-Plattform vorhanden. Und nicht nur das, sondern auch viele andere. Unter anderem verhinderte das Session-Management, dass man in zwei Browserfenstern oder -tabs verschiedene Suchergebnisse navigierte — stattdessen beeinflussten die Klicks in dem einen Fenster, was im anderen Fenster beim nächsten Klick angezeigt würde. Und ganz generell ließ die Gestaltung (und ich spreche hier nicht über Geschmacksfragen, sondern über grundlegendes Informationsdesign) einiges an Sorgfalt vermissen. Der Gesamteindruck, was dies betrifft, zeigte deutlichen Verbesserungsbedarf.

Der (zweite) Community-Workshop bot Zeit von 15 bis 17 Uhr, über Usability zu sprechen. Diese zwei Stunden reichten bei weitem nicht aus, um auch nur die Suche im Datenkatalog im Detail zu evaluieren und alle gefundenen Probleme anzusprechen. Von den weiter verborgenen Anwendungsfällen wie der Registrierung als neuer Nutzer, dem Einstellen neuer Datenangebote, dem Bewerten und Kommentieren und ähnlichem ganz zu schweigen.

Getrieben von der Befürchtung, dass jemand irgendwann, irgendwo fragen könnte “Warum habt Ihr das denn nicht damals beim Workshop gesagt?“, verschafften wir Teilnehmer uns recht deutlich Gehör und brachten zum Ausdruck, dass der vorliegende Zustand bei weitem nicht unseren Erwartungen gerecht wurde.

Nun könnte man meinen, dass Usability und User Experience ja nur Teilaspekte des ganzen Projekts seien. Ich sehe das so: Für eine Plattform, deren Zweck vor allem darin besteht, Datenangebote zugänglich zu machen, die bereits an anderer Stelle öffentlich zur Verfügung gestellt werden, sind User Experience, Usability und die Qualität des Zugangs sehr zentrale Themen. Wenn ich als Nutzer besser dran bin, indem ich nach den Daten google, ist zumindest ein wesentliches Teilziel des Angebots nicht erreicht worden.

Dieser Teilaspekt wiegt um so schwerer, je weniger die Plattform andere Erwartung erfüllt. Beispielsweise die, dass durch die Plattform wichtige, bisher nicht veröffentlichte Datensätze zugänglich gemacht werden. Der Datenkatalog zum Stand des zweiten Community-Workshops enthielt genau ein Angebot von einem Bundesministerium (Absender-Angabe: “UBA Adressen, BMELV – Bundesministerium für Ernährung, Landwirtschaft und Verbraucherschutz”). Der damit verknüpfte Datensatz namens “Grüner Bildungskatalog” ist als “other-closed” lizensiert und angeblich ein WMS (Web Mapping Service). Tatsächlich zeigt die URL aber nicht auf einen WMS, sondern auf eine gewöhnliche Webseite. Was Licht auf einen weiteren, aus meiner Sicht entscheidenden Qualitätsaspekt der Plattform wirft, nämlich die Datenqualität.

Zum Umfang des Datenkatalogs sagen BMI und Fraunhofer FOKUS, dass dieser gerade noch deutlich ausgebaut wird. Insofern lässt sich aktuell nicht vorhersagen, ob zum Launch der Plattform nicht doch der eine oder andere wesentliche Datensatz (hallo Bundesfinanzmininsterium, Bildungs- und Forschungsministerium, Wirtschaftsministerium und ja, auch Bundesinnenministerium) enthalten sein wird. Darauf wetten möchte ich aber nicht.

Doch zur angesprochenen Qualität der bereits vorhandenen Metadaten. Die GovData-Plattform steht vor der Herausforderung, Metadaten aus verschiedenen Quellen zu harmonisieren und in einem Katalog einheitlich abzulegen. Unklar ist bislang, wieviel Wert bereits auf die Harmonisierung gelegt wird. Mein Eindruck vom Eingabeformular für Metadaten ist, dass es dort an Hilfestellungen und Beispielen fehlt, um bei der manuellen Eingabe einen einheitlichen Standard zumindest zu fördern.

Die aktuellen Metadaten sind wohl größtenteils automatisiert importiert worden — mit gemischten Ergebnissen. Da heißt dann ein Datensatz “Gemeindegrenze“, ein anderer “Bestände von Unternehmen (ab 250.000 EUR Umsatz): Deutschland, Jahre, Art der Bestände,Zeitpunkt der Bestände, Wirtschaftsabschnitte, Größenklassen (Umsatz/tätige Pers.)“. Ein weiterer Datensatz heißt schlicht “Umsatz und Beschäftigung 2011″, andere Metadaten dieses Datensatzes legen jedoch nahe, dass er eigentlich nur Umsatz und Beschäftigung bestimmter Branchen, nämlich Handel, Kraftfahrzeug- und Gastgewerbe, umfasst. Zur Beschreibung des Datenbereitstellers gibt es zwei Felder: Das Feld ‘author’ und das Feld ‘maintainer’. Mal wird das eine Feld verwendet, mal das andere, mal beide und mal keins von beidem. In beiden stehen Namen von Personen, Behörden und E-Mail-Adressen bunt durcheinander.

Gut, dass die Plattform eine Bewertungs- und Kommentarfunktion besitzt. Hier können Nutzer dann in den Kommentaren darauf drängen, dass ungenaue oder falsche Metadaten korrigiert werden. Und sie können darauf hoffen, dass die Bereitsteller der Daten davon erfahren. Denn, soweit ich die Erläuterungen verstanden habe, gibt es keine automatische Benachrichtigung für die Bereitsteller, wenn zu ihren Datensätzen neue Kommentare eingegangen sind. Es gibt auch keinen RSS-Feed oder ähnliches. Und die Kommentar- und Bewertungsdaten sind nicht Teil der Katalog-Metadaten, die über eine API abgerufen werden können. Man muss kein Schwarzmaler sein, um vorherzusagen, dass die Datennutzer im Kommentarbereich vor allem unter ihresgleichen bleiben werden.

Die API des Katalogs, gerade erwähnt, ist aus meiner Sicht die wichtigste verbleibende Funktion des Portals. Denn sie erlaubt den automatischen Lesezugriff auf alle Metadaten. Beim letzten Community-Workshop war sie nur für Kenner der verwendeten Datenkatalog-Software (CKAN) zu finden. Auf der Plattform fehlte jeglicher Hinweis darauf. Anders als beim Beispiel netzdaten-berlin.de war die CKAN-API von GovData beim Workshop erreichbar und auf Nachfrage wurde explizit bestätigt, dass dies auch so bleiben soll. Nur auf eine Lizenz für die darüber erhältlichen Daten hat man sich noch nicht festgelegt, glaubt aber, dass es eine offene Attribution-LIzenz werden wird.

Wenig gesagt und geschrieben wurde bislang zu den weiteren Bestandteilen des Portals jenseits des Datenkatalogs. Und weil auch für mich diese Bereiche von nachrangigem Interesse sind, seien sie hier nur kurz erwähnt: Es gibt im Katalog neben Datensätzen auch noch Apps und Dokumente. Apps sind eben Anwendungen, sei es mobil, im Web oder sonstwelcher Art, die mit den Daten auf der Plattform zu tun haben sollen. Perspektivisch ist auch denkbar, dass die Verbindung zwischen Apps und Datensätzen auf der Plattform angezeigt wird, jedoch ist dies noch nicht umgesetzt. Und Dokumente sind, im Großen und Ganzen, PDFs. Warum es diese hier gibt und nach welchen Kriterien diese ausgewählt werden, bleibt vorerst offen. Im Gegensatz zu den Datensätzen, die mit großer Mehrheit offen lizensiert sind, tragen die Dokumente größtenteils den Lizenzvermerk “other-closed”.

Das soll reichen, um zu erklären, warum von meinen Erwartungen an den Launch-Termin nicht mehr all zu viel übrig geblieben ist. Die Leuchttürme leuchten anderswo. Wenn von dieser Plattform ein Impuls für Open Government Data ausgeht, wird das eine Überraschung sein.

Was macht man damit? Den Kopf in den Sand stecken? Oder Flames und Rants schreiben? Mich beschäftigt die Frage, auf welcher Ebene das so schief gelaufen ist. Und ob die Community hier (im Prozess) etwas hätte anders oder besser machen können.

Vorläufig komme ich mit meinen Überlegungen zu dem Ergebnis, dass der Prozess vom BMI und Fraunhofer FOKUS nicht vernünftig aufgesetzt wurde. Wenn innerhalb von Fraunhofer FOKUS, das für die Entwicklung der Plattform verantwortlich ist, nicht genug Kompetenz/Zeit/Sorgfalt aufgebracht werden kann, dann hätte man sich stärker für freiwilligen Input aus der Community öffnen können. Natürlich setzt das scheinbar voraus, dass man einen Kompetenzmangel vorzeitig erkennt. Tatsächlich könnte es auch bedeuten, dass man die eigenen Kompetenzen grundsätzlich in Frage stellt. Schließlich sind wir alle nur Menschen — ob im BMI, bei FOKUS oder sonstwo. Wenn man die Grundannahme stellt, dass es irgendwo draußen Menschen mit zusätzlichem brauchbaren Input gibt (“given enough eyeballs, all bugs are shallow“), muss man Wege finden, wie man diese stärker einbindet. Da reichen zwei Community-Workshops wohl bei weitem nicht aus.

Aber vielleicht sind wir nur zu ungeduldig. Vielleicht ist das, was wir gesehen haben, die Version 0.0.1 pre-alpha. Und was vor der Cebit gelauncht wird, wird die 0.0.1 rc1 sein. Möglich, dass wir in den nächsten zwei Jahren im Zweiwochenrhythmus Verbesserungen und neue Funktionen erleben werden. Dass wir im GovData-Entwickleblog lesen und über die Mailingliste Bugreports einreichen, Vorschläge diskutieren und Pull Requests auf Github senden werden. Vielleicht müssen wir die “Fehlerkultur”, die andernorts beschworen wird, wenn es um Open Data geht, hier bei diesem Projekt vorleben, indem wir den Verantwortlichen zeigen, dass wir trotz eines enttäuschenden Zwischenstands weiter bereit sind, das Projekt zu unterstützen. Tatsächlich bin ich zu neugierig, zu sehen wie es weiter geht, als dass ich einen Aufruf, das ganze Ding zu stoppen, unterstützen könnte.

Nachdem der Community-Workshop zu Ende war, kamen Stefan Wehrmeyer (z. B. verantwortlich für Frag den Staat), Dominik Moritz (CKAN Entwickler) und ich nicht umhin, uns Gedanken über die anstehenden Aufgaben für die Open Data Community zu machen: Die Metadaten des OpenGov-Katalogs (abzüglich Apps, Dokumente und allem, was nicht offen lizensiert ist) nehmen und ein anständiges Angebot für Open-Data-Nutzer machen. Mit automatischem Qualitäts-Auditing, Änderungsverfolgung an Metadaten und Daten, Kommentar-Benachrichtigung und so weiter und so weiter.

Das hätte natürlich überhaupt keinen Einfluss darauf, welche Daten überhaupt veröffentlicht werden. Darüber wird das nächste mal wieder am 22. September abgestimmt, unter grundgesetzlich verbriefter BürgerInnenbeteiligung.

Update (21. Februar 2013): Die Plattform ist seit dem 19. Februar offiziell online (www.govdata.de). Der Start war begleitet von technichen Pannen – die Server-Infrastruktur war dem Andrang der NutzerInnen offenbar nicht gewachsen. Doch inzwischen sieht es so aus, als könnte sich jeder selbst ein Bild machen. Probleme oder Verbesserungsvorschläge können auf der Github-Seite eingetragen werden (Github Account vorausgesetzt). Probleme mit bestimmten Datensätzen oder deren Beschreibung sollten direkt auf GovData als Kommentar vermerkt werden. Dazu ist die Nutzerregistrierung auf GovData erforderlich. Wie auf der Todo-Liste zu sehen ist, ist auch geplant, die Kommentare per RSS Feed zur Verfügung zu stellen. Damit würde die Wahrscheinlichkeit, dass die Bereitsteller der Daten die Kommentare verfolgen können, deutlich steigen.

Die Rohdaten, also alle Abfuhrtermine für 2013, gibt es von uns eine Nur-Text-Version und eine JSON-Version. Die Nur-Text-Version dient vor allem der einfachen Übersicht. Als App-Entwickler wirst Du vermutlich mit der JSON-Version mehr anfangen können.

Zur Struktur gibt es noch ein bis zwei Dinge zu sagen. Die richtet sich ganz nah an der Struktur der Vorlage aus. Auf oberster Ebene findet man die Unterscheidung nach Art der Tonne. Es gibt graue_tonne (Restmüll), blaue_oder_gelbe_tonne (Papier, Verpackungen) und biotonne. Blaue und gelbe Tonne sind im Original zusammengefasst, deshalb auch hier. Auf der nächsten Ebene folgt entweder direkt der Abfuhrtag (siehe graue-tonne) oder noch die Unterscheidung zwischen roter_aufkleber und gruener_aufkleber. Die Unterscheidung bedeutet: wer einen roten Aufkleber auf der betreffenden Tonne hat, wählt diese Kategorie, wer einen grünen hat wählt die andere. Und, wenn wir es richtig verstanden haben: Wer keinen Aufkleber hat, für den gelten sowohl die Termine unter roter_aufkleber als auch unter gruener_aufkleber. Alles klar? Gut.

Die Daten

• JSON
• Text

Die Hansestadt Rostock, die in Kürze auch ein Datenportal startet, bietet schon jetzt eine Vielzahl von Geodaten in den unterschiedlichsten Formaten an. Darunter auch die Umrisse von Bebauungsplänen. Und damit kann man dann in weniger als einer Minute eine solche Karte bauen:

Hier geht es zur großen Karte auf Google Maps. Zur schnellen Voransicht haben wir auch einen Screenshot.

Mit solchen Daten sind beispielsweise Benachrichtigungsfunktionen, wenn in meiner Nähe ein neues Bauvorhaben geplant wird, sehr leicht umzusetzen. Aufgrund der offenen Lizenz (ODC-BY) sind die Daten für jegliche Anwendung kostenlos nutzbar, solange die Quelle angegeben wird.

Über solche Daten würden sich auch die Macherinnen von Bürger baut Stadt freuen. Das Team arbeitet mit Unterstützung von StadtLandCode an einer Plattform, auf der Berliner Bürger sehen können, welche Planungen um sie herum passieren. Damit soll auch der Zugang zu Beteiligungsverfahren erleichtert werden.

Und Du, Stadt Köln, wann gibst Du uns solche Daten?

Den gesprächigen Besuchern unter Euch ist es vielleicht aufgefallen: Die Kommentarfunktion zu Beiträgen hier im Blog ist weg. Das ist keine Absicht und gerne würden wir die Kommentare wieder anzeigen.

Leider stimmt aber was mit der Template-Logik nicht (mehr). WordPress (wir verwenden Version 3.5) zeigt die einzelnen Artikel nicht mehr in dem dafür vorgesehenen Template an (single.php bzw. content-single.php). Stattdessen wird nur noch das Haupttemplate (index.php) und darin content.php aufgerufen. Unser Theme basiert auf Twenty Eleven Version 1.0.

Kennt sich hier jemand mit WordPress aus und kann uns helfen, die richtige Template-Logik wieder herzustellen?

Wegen fehlender Kommentarfunktion nehmen wir Hinweise über Twitter oder E-Mail kontakt bei offeneskoeln punkt de entgegen. Vielen Dank!

Update 18. Januar 2013: Dank der großen Hilfsbereitschaft von Mateng ist das Problem nun behoben. Der Grund war ein ziemlich unwichtiges Plugin (“Google authorship for multiple authors”), das einfach nur deaktiviert werden musste. Mateng, vielen Dank für den Einsatz!

Inzwischen sind alle wichtigen Eckpunkte der Veranstaltung geklärt. Wir haben ein Organisationsteam. Wir haben eine, nein zwei, Locations. Wir haben ein Programm. Wir haben eine Website und einen Twitter-Account.

Damit haben wir eine Plattform für etwas großartiges. Aber das wichtigste bei diesem Event, das werdet Ihr sein.

Der Open Data Day in Köln ist eine offene Veranstaltung für die Umsetzung von Ideen mit offenen Daten. Ganz gleich, aus welchem Bereich Ihr kommt, beim Open Data Day sollt Ihr die Möglichkeit haben, zusammen mit anderen ein Projekt voran zu treiben. Sei es zum Erschaffen von neuem Nutzen oder von mehr Transparenz.

• Du bist Entwicklerin für mobile Anwendungen und liest außerdem gerne? Dann bau doch eine mobile Webapp für das Durchsuchen der Kölner Bibliothekskataloge. Vielleicht hilft Dir ein Informationsarchitekt bei der Konzeption der Oberfläche.
• Du bist Statistiker und träumst von seriösen Auswertungen von Wahlergebnissen, die endlich mal die wirklich interessanten Details beleuchten? Dann schnapp Dir den Informationsdesigner und die Web-Entwicklerin, damit die Visualisierungen interaktiv und benutzbar werden und auch noch vernünftig aussehen.
• Du bist Umweltaktivistin und willst erreichen, dass Daten zur Flächennutzung in einem auswertbaren Format zur Verfügung gestellt werden? Sprich beim Event mit Leuten von der Stadt. Recherchiere mit anderen nach bestehenden Daten. Baue mit Entwicklern einen Scraper, der automatisiert Daten sammelt und stelle die Daten für andere zur Verfügung.
• Du bist Computerlinguist und willst analysieren, welche Kölner Ratsfraktion die kompliziertesten und welche die verständlichsten Anträge schreibt? Mit Hilfe von Designern und App-Entwicklern wird vielleicht eine echte Anwendung daraus.
• Du bist Journalistin und willst zeigen, wie die Kölner Haushaltsmittel wirklich eingesetzt werden? Finde einen Entwickler, eine Datenanalystin und einen Wirtschaftswissenschaftler und steckt die Köpfe zusammen. Am Ende habt Ihr vielleicht eine Visualisierung, die andere auch verstehen können.

Diese Beispiele zeigen, wie vielseitig die Möglichkeiten sein werden und wie viele verschiedene Nutzergruppen wir mit der Veranstaltung zusammen bringen wollen. Übrigens: Obwohl Open Data bei uns noch in den Kinderstuhen steckt, stehen die oben genannten Daten stehen zum großen Teil schon zur Verfügung. Auf der Website zum Open Data Day haben wir einige Links zu bestehenden Datenangeboten mit besonderer Berücksichtigung der Relevanz für den Raum Köln bzw. NRW zusammen gestellt.

Damit wir diese bunte Zusammenstellung von Teilnehmerinnen und Teilnehmern erreichen, benötigen wir Eure Unterstützung. Bitte helft uns, die Informationen zur Veranstaltung in Eurem Umfeld und darüber hinaus zu verbreiten.

Die Website: http://opendataday.koeln.de

Twitter: https://twitter.com/oddcgn

Solche Zahlen sind für das Verständnis der sozialen Verhältnisse in der Stadt von grundlegender Bedeutung. Und sie sind eine wichtige Basis für viele Analysen. So zum Beispiel, als wir hier beim Datendienstag zum Thema U3-Betreuung versucht haben, herauszufinden, ob sich die Betreuungsquote in den verschiedenen Stadtteilen an den sozio-demografischen Verhältnissen ausrichtet.

Um so wichtiger ist es, solche Daten in auswertbarer Form vorliegen zu haben. PDFs sind zwar hilfreich zum Lesen und Ausdrucken. Sie helfen aber nicht, wenn man Daten mittels Programmen (wie z.B. OpenOffice oder Excel) auswerten oder visualisieren möchte. Und mal ehrlich, wer möchte seitenweise Tabellen lesen?

Für den Datendienstag haben wir uns wieder mal die Mühe gemacht und aus der PDF-Veröffentlichung eine echte Tabelle gemacht. Wer neugierig ist und wissen will, wie das geht, kann sich das nachstehende Video ansehen.

Aber damit nicht genug. Nach dem Extrahieren der Statistiken aus dem PDF haben wir zahlreiche Spalten mit abgeleiteten Statistiken hinzugefügt. Die Tabellen enthalten im Original neben den absoluten Werten auch schon einige abgeleitete Werte. Ein Beispiel: Es ist zu jedem Stadtteil nicht nur die Einwohnerzahl und die Fläche in Quadratkilometern angegeben, sondern auch die Einwohner je Quadratkilometer (Einwohnerzahl geteilt durch Fläche in Quadratkilometern).

Weil solche “normalisierten” Werte für die Vergleichbarkeit zwischen den einzelnen Stadtteilen entscheidend sind, haben wir dafür gesorgt, dass es sie für beinahe jede Spalte gibt. Die meisten beziehen sich auf die Einwohnerzahl in einem Stadtteil, einige beziehen sich auf die Zahl der Haushalte oder der Wohnungen. So gibt es beispielsweise zur Angabe “Verheiratete” nun auch die Angabe “Verheiratete je 100 Einwohner” und zu “Genehmigte Wohnungen” die Spalte “Genehmigte Wohnungen je 1000 vorhandene Wohnungen”.

Wer sich zum Beispiel auf die Suche nach Zusammenhängen (Korrelationen) zwischen zwei Kennzahlen macht, wird in den meisten Fällen diese normalisierten Werte nutzen wollen.

Die erweiterten Stadtteildaten umfassen 190 Spalten mit Kennzahlen. Wenn nicht anders angegeben, beziehen sich die Zahlen auf das Jahr 2011. Bis auf wenige Ausnahmen sind sämtliche Spalten vollständig ausgefüllt. Dort, wo im Original Leerstellen oder Striche statt einer Zahl standen, sind die Felder leer geblieben. Die Spaltenbeschriftungen sind in der Regel recht ausführlich. Eine Erläuterung der Spalten gibt es auch, sofern sie bereits im Original vorhanden war.

Was kann man nun damit anfangen?

Eins von tausenden Verhältnissen in den Daten: Das Verhältnis zwischen der Arbeitslosenquote und den durchschnittlichen Wohnjahren in der selben Wohnung. Jeder Punkt steht für einen Stadtteil, die Linie (lineare Regression) zeigt die Tendenz an. Es zeigt sich, dass in den Stadtteilen, wo die Arbeitslosigkeit größer ist, die Verweildauer in einer Wohnung kürzer ist.

Man könnte zum Beispiel einen interaktiven Stadtteil-Atlas bauen, der die Daten ganz einfach auf der Karte anzeigt. Oder man könnte eine Anwendung wie Yourtopia bauen, die den Nutzer fragt, welche Kriterien für ihn wichtig sind, und dann anzeigt, welche Stadtteile nach den Prioritäten des Nutzers am besten abschneiden. Oder man könnte die Daten mit anderen Stadtteil-bezogenen Daten – sofern vorhanden – wie Wahlergebnissen, Mietspiegel, Gesundheitsdaten, Kinderbetreuung etc. korrelieren und nach Zusammenhängen fahnden. Aber auf die besten Ideen kommen sowieso nicht die Leute, die Daten veröffentlichen, sondern “die anderen”. Und das seid in diesem Fall Ihr!

Wie immer gilt auch hier, dass Eure Kommentare sehr willkommen sind, wenn Ihr Fragen zu den Daten habt, Fehler gefunden habt oder selbst auf eine Anwendung dieser Daten hinweisen wollt.

Übrigens ist am 23. Februar der Open Data Day in Köln und weltweit. Das wäre eine super Gelegenheit, um an einem solchen Projekt zu arbeiten.

Die Daten

Die Daten gibt es wieder mal als Google Drive (ehemals Google Docs) Tabellendokument. Ihr könnt sie dort über das Datei-Menü oder über die folgenden Links in maschinenlesbaren Formaten herunter laden:

• CSV (Nur die Datentabelle, keine Erläuterungen)
• OpenDocument .ods
• Excel .xlsx

Interessant waren an der Datensammlung gleich mehrere Details:

• Zum einen wurden hier Messergebnisse von Verkehrsmessungen veröffentlicht. Bislang bleiben diese Daten meist unter Verschluss.
• Es wird ein Vorher-Nachher-Vergleich ermöglicht: Welchen Einfluss hat eine Anzeige auf das Fahrverhalten der Nutzer?
• Der Vergleich verschiedener Stellen wird möglich: Funktioniert das, was an der einen Stelle funktioniert, auch an einer anderen?

Nun gibt es eine neue Ausgabe des Berichts über den Einsatz der Geschwindigkeitstafel. Im Jahr 2012 wurde die Tafel demnach an 15 Standorten eingesetzt. Die Messdaten gibt es wie üblich in einem PDF-Dokument. (Für besser nutzbare Daten, siehe weiter unten.)

Unter den bemerkenswerten Ergebnissen des letzten Berichts (für das Jahr 2011) war auch die Straße “Am Feldrain” im Stadtbezirk Rodenkirchen. An der Messstelle gilt eine Höchstgeschwindigkeit von 30 km/h. Hier noch mal unser Diagramm, das die Messungen illustriert:

Dort ist zu sehen, welcher Teil der Verkehrsteilnehmer (Auto-, LKW-, Motorradfahrer etc.) in welchem Geschwindigkeitsbereich lag. Die grauen Balken stehen für die Messung bei ausgeschalteter Geschwindigkeitsanzeige. Die blauen Balken zeigen, wie schnell die Fahrzeuge bei eingeschalteter Anzeige fuhren. Man sieht, dass der größte graue Balken im Bereich von 41 bis 50 km/h zu finden ist. Ohne Anzeige fahren die meisten Fahrzeuge also zwischen 11 und 20 km/h zu schnell. Mit aktiver Anzeige verschiebt sich die Verteilung merklich. Die meisten fahren zwar immer noch zu schnell, aber langsamer als vorher.

Interessanterweise hat de Stadt Köln entschieden, am Feldrain im Jahr 2012 wieder eine Messung durchzuführen. An dieser Stelle müssen Fragen erlaubt sein: Warum? Traute man den Ergebnissen der ersten Messung nicht? Was hat man sonst noch getan, um das Verhalten der Verkehrsteilnehmer zu beeinflussen, damit sie sich an die gebotene Geschwindigkeit halten? Warum hat man nicht dauerhaft eine Geschwindigkeitsanzeige installiert?

Die Messergebnisse von 2012 zeigen, dass sich gegenüber 2011 vor allem eins verändert hat: Die Autofahrer fahren (ohne Anzeige) anteilig deutlich schneller als im Jahr 2011.

Der Anteil der Fahrer, die sich (ohne Geschwindigkeitsanzeige) an das Tempolimit gehalten haben, ist von 3,07 % auf im Diagramm nicht mehr darstellbare 0,11 % gesunken. Mit aktiver Anzeige waren knapp 20 % im erlaubten Bereich. Wie man auch sehen kann, sind die sehr starken Geschwindigkeitsüberschreitungen sehr deutlich zurück gegangen.

Wieder kommt die Stadt Köln zu dem Ergebnis, dass die Anzeigetafel sich auf das Fahrverhalten in der wünschenswerten Weise ausgewirkt hat. Diesmal sogar “sehr effektiv”.

Die Frage ist: Wie viele solche Messungen wird man noch brauchen, bis man darüber nachdenkt, ob das Tempolimit an der Stelle in dieser Form sinnvoll ist oder ob es weitere Maßnahmen braucht, um dei Verkehrsteilnehmer zur Einhaltung zu bewegen?

Der Feldrain ist nicht die einzige Straße, die nun schon mehrmals gemessen wurde. Auch die Brühler Landstraße taucht im 2012er Bericht ein zweites Mal auf. Bei beiden Messungen kommt man zu dem Ergebnis, dass sich der Anteil der Vekehrsteilnehmer, die sich an das 50-km/h-Gebot halten, mit Anzeigetafel auf fast 100 % steigern lässt. Auch hier stellt sich die Frage, wie es nun weiter geht. Wird die Tafel auch hier im nächsten Jahr wieder für ein paar Wochen montiert werden?

Daten

Wer selbst in die Daten schauen möchte und Fragen stellen möchte, hier ist das Tabellendokument (Vorschau siehe unten). Das Dokument kann über den Menü-Eintrag “Datei” > “Herunterladen …” in verschiedenen Formaten gespeichert werden.

Dazu gibt es nun hier auf Offenes Köln eine kleine Anwendung, die Open Government Timeline für NRW, unter der URL

http://offeneskoeln.de/lab/nrw-opengov-timeline/

Der Hintergrund dieses Angebots ist ein eigennütziger. Ich habe mir in Vorbereitung auf die Anhörung am 6. Dezember Protokolle vorangegangener Sitzungen des Innenausschusses zu dem aktuellen Open-Government-Antrag von SPD und Grünen rausgesucht. Zwar gab es da nur eine Sitzung (nämlich die vom 27. September 2012), und besprochen wurde da laut Protokoll auch noch nicht viel. Aber es wurden Fragen zu einer ressortübergreifenden Projektgruppe gestellt, die schon vorher ihre Arbeit begonnen hat. Wie sich herausstellte, musste damit Open.NRW gemeint sein. So kam ich vom Hölzchen aufs Stöckchen und habe beschlossen, das Ergebnis um ein paar weitere Ereignisse aus den Kommunen anzureichern und öffentlich zu machen.

Einen Anspruch auf Vollständigkeit gibt es selbstverständlich nicht. Wer meint, dass ein wichtiges Ereignis oder Dokument fehlt, darf gerne hier in den Kommentaren weitere nennen – bitte immer mit hinreichend ausführlicher Beschreibung und Link. Ich füge das dann gerne bei Zeiten hinzu.

Wenn Euch die Timeline gefällt, zögert nicht, sie auf den Sozialen Netzwerken Eurer Wahl zu “mögen”!

Schon vor einem Monat wurde hier im Blog ein Datensatz zur Kinderbetreuung für Kinder unter 3 Jahren (U3) vorgestellt. Da ging es um das ganze Land Nordrhein-Westfalen.

Der heutige Datensatz stellt die Situation der Kinderbetreuung in Köln genauer dar, und zwar für jeden einzelnen Stadtteil. Außerdem werden diesmal nicht nur U3-Betreuungsplätze aufgeführt, sondern auch Betreuungsplätze für Kinder von drei bis unter sechs Jahren.

Aus den Daten für NRW (Link siehe oben) ging bereits hervor, dass die U3-Versorgungsquote im Kindergartenjahr 2011/2012 bei knapp 30 Prozent lag. Das heißt: Für 3 von 10 Kindern unter 3 Jahren steht ein Kita-Platz oder ein Platz bei einer Tagesflegeeinrichtung zur Verfügung. Laut den Daten soll dieses Verhältnis für das Kindergartenjahr 2012/2013 auf über 37 Prozent ansteigen bzw. gestiegen sein.

In ihrem Statusbericht zum Ausbau der Kindertagesbetreuung von Ende Oktober veröffentlichte die Kölner Stadtverwaltung aktualisierte Zahlen mit Stand 15. Oktober 2012. Daraus geht insgesamt eine U3-Betreuungsquote von 31,3 Prozent hervor.

In den einzelnen Stadtteilen ist der Ausbau deutlich unterschiedlich fortgeschritten. Hier ist die Betreuungsquote U3 nach Stadtteilen:

Der Statusbericht der Verwaltung liefert auch die entsprechenden Zahlen für die 3- bis unter 6-jährigen. Dort steht die Quote (Anzahl Plätze im Verhältnis zur Anzahl der Kinder) bei 97,65 Prozent. Betrachtet man einzelne Stadtteile, sieht das Bild auch hier recht unterschiedlich aus.

Wie zu sehen ist, liegt die Quote zwischen null Prozent (in Porz-Elsdorf) und 162 Prozent (Porz-Wahnheide).

Wie lassen sich die großen Unterschiede erklären?

Eine nahe liegende Erklärung für Versorgungsquoten jenseits von 100% wäre, dass Eltern aus anderen Stadtteilen ihre Kinder dort in die Betreuung geben. Gehäuft tritt dies sicherlich dort auf, wo viele größere Unternehmen ansässig sind, wo aber verhältnismäßig wenige Kinder wohnen. Hierzu wäre es interessant, die Zahl der Einwohner mit den ansässigen Arbeitsplätzen im jeweiligen Stadtteil vergleichen zu können. Leider liegt die Zahl der Arbeitsplätze je Stadtteil mir aktuell nicht vor (Hinweise sind wollkommen!).

Eine Feststellung, die wenig überrascht, ist: Die Betreuungsquoten für U3 und für Kinder von 3 bis 6 korrelieren. Das bedeutet: Generell gilt, dass in den Stadtteilen, in denen die eine Quote hoch ist, auch die andere Quote vergleichsweise hoch ist. (Für die Statistiker: Der Korrelationskoeffizient r ist 0,3 und p ist kleiner 0,005. Für Nicht-Statistiker: Der Zusammenhang darf als “signifikant” bezeichnet werden. Das folgende Streudiagramm visualisiert den Zusammenhang für alle Stadtteile.) Diese Korrelation lässt sich vermutlich leicht dadurch erklären, dass es in einigen Fällen dieselben Einrichtungen sind, die sowohl Plätze für unter-dreijährige als auch für drei- bis sechsjährige Kinder anbieten.

Gibt es noch weitere Hinweise, warum in einigen Stadtteilen die Versorgung mit Betreuungsplätzen besser ist als in anderen? Ich habe weitere Versuche unternommen, die ungleichen Quoten auf Basis von anderen stadtteilbezogenen Daten zu erklären. Die Stadt Köln bietet (im bekanntermaßen verarbeitungs-unfreundlichen PDF-Format) eine Publikation namens Kölner Stadtteilinformationen – Zahlen 2011. Darin finden sich einige sozio-demographische Indikatoren, die ich für die Suche nach Korrelationen mit den Betreuungsquoten herangezogen habe.

Naheliegend schien mir die Vermutung, dass in den dichter besiedelten Stadtteilen die Versorgung besser sein müsste, weil sich dort die Betreuung aufgrund kurzer Wege besser organisieren oder nutzen lässt. Fehlanzeige. Es gibt keine Korrelation zwischen Einwohnerdichte und Betreuungsquoten. Mit anderen Worten: Die dicht besiedelten Stadtteile haben keine höheren Betreuungsquoten als weniger dicht besiedelte.

Die Versorgung mit Kindergartenplätzen (also Angebote für 3- bis 6-jährige) scheint – statistisch betrachtet – im Zusammenhang mit mehreren sozio-demographischen Kennziffern zu stehen:

• Die Betreuungsquote für 3- bis 6-jährige korreliert negativ mit dem Anteil der Haushalte mit Kindern (r=-0,221, p<0.05). Das bedeutet: Dort, wo mehr Haushalte mit Kindern sind, ist die Betreuungsquote niedriger.
• Die Betreuungsquote für 3- bis 6-jährige korreliert negativ mit der Wohnfläche je Wohnung (r=-0.379, p<0.0004) bzw. der Wohnfläche je Einwohner (r=-0.317, p<0.003). Das heißt: Wo mehr Wohnfläche zur Verfügung steht, sind die Betreuungsquoten tendenziell niedriger.
• Ein weitere negative Korrelation gibt es zwischen der Betreuungsquote für 3- bis 6-jährige und der Anzahl privater PKWs je 1000 Einwohner. Wo die Menschen mehr Autos besitzen, scheint die Kita-Versorgung dünner zu sein.

Nur eine einziger Zusammenhang ließ sich in den Daten feststellen, der sich bei näherer Betrachtung jedoch als nicht belastbar herausstellt. Tatsächlich gibt es in den Daten auf den ersten Blick eine signifikante, positive Korrelation zwischen der Wohnfläche je Einwohner in einem Stadtteil und den Betreuungsquoten. Beide Werte sind im Stadtteil Hahnwald (wo bekanntlich vornehmlich gut betuchte leben) deutlich höher als im Rest der Stadt. Die Betreuungsquote für U3 liegt bei 84 Prozent, die Wohnfläche je Einwohner bei fast 80 Quadratmetern. Nimmt man aber Hahnwald als “Ausreißer” von der Betrachtung aus, bleibt keine Korrelation übrig. Nach Betrachtung anderer Indikatoren ist auch nicht ersichtlich, dass die U3-Betreuungsquote mit dem Einkommen in einem Stadtteil zusammen hängt.

Sicher wäre es interessant, anhand weiterer Kriterien nach Zusammenhängen zu suchen. Die Vorbereitung dieses Datendienstages hat jedoch leider den Rahmen schon gesprengt, so dass ich den Ball hiermit an die Allgemeinheit abspiele. Was findet Ihr heraus?

Die Daten

• Google Docs Tabelle mit Exportfunktion für die üblichen Tabellenformate wie Excel, Open Office etc. Darin sind auch die vielen ebtrachteten Indikatoren enthalten. Eine Erläuterung findet Ihr auf dem zweiten Tabellenblatt. Vorschau siehe unten.

Zu diesem Thema habe ich heute einen Vorschlag auf der Beteiligungsplattform der Enquete-Kommission Internet und digitale Gesellschaft eingereicht. Der Titel: Offene Standard-Schnittstelle für Ratsinformationssysteme

Meine Bitte:

• Lies den Vorschlag
• Richte Dir, falls noch nicht geschehen, einen Account auf der Plattform ein
• Bewerte und kommentiere den Vorschlag

und hilf dadurch mit, dieses Thema auf die politische Agenda zu setzen. Du hast dafür Zeit bis zum 3. Dezember.

Es wäre so einfach. Vielen Dank!