Schlagwort-Archive: OpenStreetMap

Werkzeugkiste

Mal wieder ein Open-Data-Rundumschlag: den Einsteig macht ein Interview der bpb mit Marian Steinbach, der auf der rp13 seine Bemuehungen vorstellte, die Datenformate von Ratsinformationssystemen zu standardisieren. Ueberraschenderweise machen hier die RIS-Anbieter richtig Dampf, man darf gespannt sein – nicht zuletzt, weil auch Ulm hier etwas anbieten moechte – und somit irgendwann auch fuer Ulm ein Angebot wie offeneskoeln moeglich sein koennte.

Aus Koeln kommen auch einige Wunschlisten, was man sich denn gerne so alles wuenschen wuerde: Einmal eine Open-Data-Wunschliste fuer NRW, einmal die Variante fuer die Stadt Koeln.

In Muenchen scheint das Engagement derweil eingeschlafen zu sein und sich gar nichts mehr zu tun – was Roland Moriz so geaergert hat, dass er ein Blog eingerichtet hat und nun nach MitstreiterInnen sucht.

 ♦

Oft ist das Problem ja nicht einmal, dass Daten gar nicht verfuegbar waeren, sondern dass sie in irgendwelchen PDFs versteckt sind. Noch schlimmer ist, wenn das PDF-Tabellen sind, da wird dann selbst das Parsing mit pdftotext… anstrengend.

Bildschirmfoto vom 2013-05-17 18:50:01

Introducing: Tabula. Die freie Software kann einfach von Github gezogen und lokal installiert werden – danach koennen beliebige PDFs hochgeladen und die zu parsenden Tabellen per Drag and Drop ausgewaehlt werden. Poof: Eine CSV-Tabelle! Hurra!

Eine Livedemo (bei der man aber nichts eigenes hochladen kann) gibt es hier.

Weitere PDF-Exporter neben tabula und pdftotext – insbesondere auch fuer Windows-Systeme – sind nebenan bei der Knight Foundation gesammelt.

 ♦

Nachdem’s hier schon lange nix mehr zu Geodaten und Karten gab, und R auch nicht jedermanns Sache ist, hier der Verweis auf Lisa Williams‘ Blog, speziell auf die zwei Artikel The Insanely Illustrated Guide To Your First Data-Driven TileMill Map und The Absurdly Illustrated Guide To Your First Dynamic, Data-Driven Timeline.

Beide Artikel sind in der Tat wahnsinnig absurd hervorragend bebildert und zeigen den kompletten Weg zum fertigen Produkt – im Fall der Karte also tatsaechlich von der Datenakquise ueber eigene Geocoding-Scripte in Google Docs (sic!) bis hin zur angepassten TileMill-Karte. Sehr schoen!

(Wer Spanisch kann, kann solcherlei Dinge auch im neuen MOOC der Knight Foundation lernen, der aktuell stattfindet)

 ♦

Wer trotzdem gerne mit R arbeiten moechte: Da gibts nun eine neue Version des OpenStreetMap-Packages, das nun auch jede Menge zusaetzlicher Tileserver unterstuetzt. Einziger Nachteil: Hat Java-Dependencies.

(via)

 ♦

Noch ein Kartenfundstueck: Die ÖPNVKARTE nutzt die OpenStreetMap-Daten, um eine um Nahverkehrsdaten angereicherte Karte auszugeben. Huebsch.

 ♦

Tiaga Peixoto stellt die Frage, ob „Open Government“ ueberhaupt etwas mit Transparenz und vor allem Rechenschaftspflicht zu tun haben muss:

ABSTRACT

By looking at the nature of data that may be disclosed by governments, Harlan Yu and David Robinson provide an analytical framework that evinces the ambiguities underlying the term “open government data.” While agreeing with their core analysis, I contend that the authors ignore the enabling conditions under which transparency may lead to accountability, notably the publicity and political agency conditions. I argue that the authors also overlook the role of participatory mechanisms as an essential element in unlocking the potential for open data to produce better government decisions and policies. Finally, I conduct an empirical analysis of the publicity and political agency conditions in countries that have launched open data efforts, highlighting the challenges associated with open data as a path to accountability.

[…] CONCLUSION

As a whole, this analysis advises caution on the part of policymakers and advocates with regard to the potential of open data to foster accountability. Even when data is politically important, accounting for the publicity and political agency conditions might be a commendable reflection for a better understanding of the prospects and limits of open data.

PEIXOTO, Tiago. The Uncertain Relationship Between Open Data and Accountability: A Response to Yu and Robinson’s The New Ambiguity of “Open Government”. DISCOURSE, 2013, 60. Jg., Nr. 6.

(via)

In eine aehnliche Richtung geht auch dieser DLF-Bericht u.a. mit Ina Schieferdecker, Michael Kreil et al.

(via)

Und zum Schluss noch ein wenig Urheberrecht. Denny Vrandečić (u.a. von Wikidata) exkursiert eine Weile ueber Lizenzfragen bei Daten(banken) und kommt zu dem Schluss, dass mensch hier bei der Veroeffentlichung allenfalls CC0 als „Lizenz“ verwenden sollte – mit dem Argument dass, wer CC-BY oder ODbL verwendet, die Position staerkt, dass rohe Daten ueberhaupt schutzfaehig im Sinne des Urheberrechts sind:

The extension from works to content, from expression to ideas, is another dimension, this time in scope instead of time, in the continuous struggle to extend and expand intellectual property rights. It is not just a battle over the laws, but also, and more importantly, over our believes and minds, to make us more accepting towards the notion that ideas and knowledge belong to companies and individuals, and are not part of our commons.

Every time data is published under a restrictive license, “they” have managed to conquer another strategic piece of territory. Restrictive in this case includes CC-BY, CC-BY-SA, CC-BY-NC, GFDL, ODBL, and (god forbid!) CC-BY-SA-NC-ND, and many other such licenses.

Every time you wonder what license some data has that you want to use, or whether you need to ask the data publisher if you can use it, “they” have won another battle.

Every time you integrate two data sources and want to publish the results, and start to wonder how to fulfill your legal obligation towards the original dataset publishers, “they” laugh and welcome you as a member of their fifth column.

Let them win, and some day you will be sued for mentioning a number.

(via @johl)

Langsam laeufts an

Seit eineinhalb Wochen gibt es nun offiziell die Soll-Fahrplandaten von den Stadtwerken unter freier Lizenz, und langsam faengt auch die Adaption und Integration in anderer Leute Werkzeuge an. Stefan Wehrmeyer hatte ja noch am Abend des VBB-EntwicklerInnen-Nachtreffens den Datensatz beantragt und Mapnificent entsprechend erweitert; mittlerweile hat auch Knut aus Berlin sein Werkzeug umgebaut, mit dem er die Haltepunkte aus dem GTFS-Feed mit den Haltepunkten in der OpenStreetMap vergleicht. Damit einhergehend kam auch gleich der erste Bug Report zum Feed, den ich heute mittag auch gleich loesen koennte — der bisherige Transformationswerkzeugkasten ist ein wenig codierungsagnostisch, so dass versehentlich UTF-8-codierte Zeichen in ASCII-Textdateien landeten.

Ein weiteres kleines Werkzeug habe ich aus der Ergebnispraesentation des VBB-EntwicklerInnen-Nachtreffens mitgenommen, das auch schnell auf Ulm adaptiert war: Analog zu Mapnificent eine Erreichbarkeitskarte, die Kreise mit waehlbarem Radius um Haltepunkte zeichnet und so anzeigt, wie „erreichbar“ der Nahverkehr in der Stadt ist. 800 Meter (der vorgegebene Wert aus Berlin) umfassen gleich quasi ganz Ulm, interessanter waere da die Abbildung des ganzen DING-Verbunds — die Daten hab ich zwar schon lange, aber leider nicht unter freier Lizenz 😉

Ein weiterer Kritikpunkt sowohl von Mapnificent als auch dieser Erreichbarkeitskarte ist ihre… begrenzte Aussagefaehigkeit (um den Begriff „Unsinnigkeit“ zu vermeiden :D). Konzentrische Kreise bilden quasi nie die Gehdistanz von/zu einem Haltepunkt ab. In einer typischen US-amerikanischen Planstadt waeren Rauten passender, in typischen europaeischen Staedten sieht es meist von Haltepunkt zu Haltepunkt anders aus. Hier mal eine Karte mit tatsaechlichem Fussgang-Routing zu bauen, das waer mal was 😉

Erste Schritte in QGIS

Ich schlage mich nun seit einigen Tagen bzw. Wochen damit herum, aus diversen Zwischenprodukten von DIVA einen funktionierenden GTFS-Datensatz zu bauen — beziehungsweise, einen Prozess zu bauen, mittels dessen die Stadtwerke das zukuenftig selber tun koennten, wenn sie das wollten. Die Fahrplaene sind dabei momentan das kleinste Problem, die koennen gemaess der Vorlage per rudimentaerem Hacktool automatisch aus den TSV-Dateien ueberfuehrt werden, die die SWU fuer den Satz ihrer Pocketfahrplaene verwendet.

Mehr Probleme machen derweil die scheinbaren Kleinigkeiten, die es in sich haben. Die Haltestellenorte hat einfach mal jemand irgendwo vom Server des Nahverkehrsverbund geparst. Die koennte man nehmen — dann waer’s aber nicht mehr sauber, weil die Datenquelle einer Nutzung unter freier Lizenz bislang nicht zugestimmt hat. Dasselbe gilt fuer die Fahrwege der Busse — die holt swu2gtfs bislang auch einfach aus der elektronischen Fahrplanauskunft des Verbunds.

Fuer beides habe ich testweise auch die Daten der Stadtwerke zur Verfuegung gestellt bekommen, die aber nur noch mehr Folgefragen aufwerfen. Eine Linie kann im Tages- und Wochenverlauf zig verschiedene Fahrwege haben, je nachdem, wo sie anfaengt, wo sie endet und welche Haltestellenreihung sie nimmt. Die haendisch zuzuordnen ist… aufwaendig. Noch umstaendlicher wird es bei den Haltepunkten: Die sind zentimetergenau vermessen — und zwar pro Haltepunkt, derer es pro Haltestelle gleich mehrere geben kann. Klar: Die meisten werden ja in zwei Richtungen bedient, und kompliziertere Halte wie der am Theater haben auch mal vier Steige, zwischen denen bis zu 50 Meter liegen.

Ich habe die KML-Dateien dann einfach mal in QGIS geladen und war ganz angetan, das auch mal im Ueberblick sehen zu koennen. Wunderbare freie Software, die per OpenLayers-Plugin auch gleich eine passende OpenStreetMaps-Hintergrundkarte einbinden koennen und vieles mehr.

Ich bin mir momentan noch nicht ganz sicher, wie ich hier weitermachen soll. Mehr oder minder ideal waere es, pro Haltestelle die mittlere Koordinate aller Haltepunkte zu berechnen, die dann als „virtuelle“ Oberhaltestelle aller Haltepunkte dient (Beispielsweise OLIF 9001010 fuer das Theater). Das ist eine eher krude Approximation und wird vor allem dann haesslich, wenn (wie aktuell) die Fahrplaene nicht den Steig angeben, von dem sie abfahren (z.B. 90010103 fuer die 6 in Richtung Uni, die am Theater-Steig 3 abfaehrt). Die Alternative ist, einfach immer den ersten Steig zu kopieren und als Oberhaltestelle zu definieren, um dann ggf. mit noch kruderen Abweichungen zu leben — aber hey, wenigstens eine Fahrtrichtung stimmt dann immer exakt. Naja.

tl;dr: QGIS scheint toll zu sein, es laesst einen Karten wie die obige machen. Geoinformationshackerei kann Leute in den Wahnsinn treiben.

Karten mal anders

Das schoene an der OpenStreetMap ist ja, dass man nicht nur der angekuendigten Google-Maps-Bezahlschranke entgeht, sondern die zugrundeliegenden Daten auch mal ganz anders verwenden kann. Zwei Beispiele der letzten Tage: Die Wasserfarben-Version der OSM, die aus der Welt ein abstraktes, aber doch wiederzuerkennendes Gemaelde macht (via @philipsteffan). Und Mapswithoutborders rendert die Karten ganz ohne Verwaltungs- und Staatsgrenzen — wenn dann noch Sueden oben ist, ermoeglicht das mal eine ganz neue Orientierung abseits der mental eingefahrenen Grenzen.

Gimmick: Karte sieht zu langweilig aus? Einfach falten — mit einem transparenten png. Sieht witzig aus. (via @betawax)

(Eingebettete Karte: Map tiles by Stamen Design, under CC BY 3.0. Data by OpenStreetMap, under CC BY SA.)