Schlagwort-Archive: OpenStreetMap

OSM-Routing führt zur Mate

wpid-wp-1438105280442.jpeg

Bislang waren Ausfluege zum Mate-Dealer fuer mich hier immer was, das man mit nem Auto macht. Schliesslich ist der Mate-Dealer im Industriegebiet NU-Offenhausen, was selbst fuer Neu-Ulm am Arsch der Welt ist.

Das hier schon beschriebene OSM-Fahrradrouting hat aber ne Strecke in petto, die auch ganz gut fahrradgeeignet ist. Die angegebene Viertelstunde je Richtung klappt mit vollem Haenger eher nicht, aber trotzdem.

Im Uebrigen soll angemerkt werden, dass die Radverkehrsfuehrung in Neu-Ulm zum Kotzen ist.

 

Randnotiz: Ja, es gibt „den“ Matedealer. Also den einzigen. Laut Matekarte gibt’s das zwar auch im Marktkauf Soeflingen und dem Oststadt-REWE, zu ersterem isses aber auch ne halbe Weltreise, und in letzterem hab ich die nie gesehen. Goebel in Neu-Ulm fuehrt das Zeug seit @hey_johnnypark die Belegschaft dort 2011 so lange geloechert hat, bis sie’s mal testweise bestellt hatten. Der Erfolg blieb nicht aus.

 

OSM rendert jetzt auch Fahrradstellplaetze

Letzten Sommer hatten wir auf dem Campus alle Fahrradstellplaetze in OpenStreetMap nacherfasst, nachdem die Vorlage der Verwaltung leider nicht so praxistauglich war. Mit Leaflet und Overpass kamen die dann auch auf eine klickbare Karte – denn in der normalen Einstellung hat die OSM Fahrradabstellanlagen nicht gerendert.

fahrradstellplaetze_osm

Das ist seit dem Rollout von openstreetmap-carto v2.30.0 anders: Ueberall, wo Anlagen gemappt sind, tauchen sie auch im Default-Kartenstil auf. Yay 😉

OSM kann jetzt auch Routing

Der Titel ist ein wenig irrefuehrend, denn mit der OpenStreetMap konnte man schon frueher automatisiert herausfinden, wie man von A nach B kommt – aber nun ist das Feature auch direkt auf der Startseite implementiert.

„Hae, Routing auf ner Onlinekarte, das ist doch ein alter Hut“, moechte man sagen. Die OSM erklaert selbst:

Well, the first thing to note is that the philosophy of OpenStreetMap is not to offer a one-stop-shop on our main website, but to create truly open data to empower others to do great things with it. So there has already been fantastic OSM-based travel routing for many years, on excellent websites such as OSRM, Mapquest, Graphhopper, Cyclestreets, Komoot, cycle.travel… the list goes on and on.

But all of those things are on other websites and apps, so people don’t always realise that OpenStreetMap has this power. What this latest development has done is really neat: the OSM website offers directions which are actually provided by third-party systems, but they are included in the main site via some crafty JavaScript coding. So as well as being really handy in itself to have directions available, it helps “first glancers” to see all the things they can do with OSM.

Ich habe das Feature gleich mal ausprobiert und durfte gleich als erstes feststellen: Wow, das Ding ist schnell! Probiert das mal aus: Gebt eine wie auch immer formatierte Adresse in das Start- oder Zielfeld ein und seht zu, wie diese quasi instantan in das richtige Format aufgeloest und einem OSM-Punkt zugeordnet wird. Im etwas seltsamen Format [Hausnummer], [Strasse], [Viertel], [Ortsname], [Regierungsbezirk] und so weiter, aber trotzdem 😉

Zweite Feststellung: Das Ding ist gut! Ich habe als Test mal die Strecke zwischen meiner WG in Ulm und meinem Elternhaus genommen, die ich immer wieder mal mit dem Fahrrad fahre. Und tatsaechlich, je nachdem, welche der beiden Fahrrad-Routing-Engines ich verwende, bekomme ich entweder den Weg an der Iller entlang, oder die Kette von Fahrradwegen durch die Ortschaften im Illertal vorgeschlagen – bis auf zwei kleine Ausnahmen exakt die Wege, die ich auch sonst genommen habe, weil sie die kuerzesten sind.

OSM-Fahrradrouting an Voehringen vorbei. Karte: © OpenStreetMap-Mitwirkende

OSM-Fahrradrouting an Voehringen vorbei. Karte: © OpenStreetMap-Mitwirkende

Womoeglich hat mich die OSM sogar auf einen besseren Weg gebracht: Ich fuhr immer den ausgewiesenen Fahrradweg oestlich an Voehringen vorbei, waehrend die OSM mich ueber Illerzell leiten wuerde. Vielleicht ist das kuerzer, ziemlich sicher spare ich mir dabei jedenfalls den Anstieg ueber die Bahnueberfuehrung. Muss ich mir mal genauer ansehen.

Seltsames Routing in Illertissen. Karte © OpenStreetMap-Mitwirkende

Seltsames Routing in Illertissen. Karte © OpenStreetMap-Mitwirkende

An anderer Stelle scheint das Routing weniger Sinn zu ergeben. In Illertissen werde ich einen grossen Umweg mit mehreren Zacken ueber den Bahnhof geleitet, weil der getrennte Radweg irgendwann an der Ulmer Strasse aufhoert, und die Ortsdurchfahrt der S2031 vom Fahrradrouter wohl als zu „gefaehrlich“ eingeordnet wird – womoeglich fehlt in der OSM einfach die Information, dass die Ulmer/Memminger Str. in Illertissen mittlerweile sogar mit Fahrrad-Schutzstreifen ausgestattet ist. Ich konnt’s leider nicht auf die Schnelle nachvollziehen, weil mich der Flash-Editor an der Stelle ueberfordert 😀

Solche Fehler zu finden und dadurch zur Korrektur der Kartendaten aufzurufen ist naemlich noch ein weiteres Ziel der Routing-Implementierung auf der OSM-Hauptseite:

ften you don’t notice a bit of data that needs tweaking unless it actually shows up on the map image. Lots of things aren’t shown on our default rendering, so the feedback loop offers less incentive for people to get them correct. And that goes doubly for things that you never “see” on the map – subtle things like “no left turn” at a particular junction, or “busses only” access on a tiny bit of road, or tricky data issues like when a footpath doesn’t quite join a road that it should join on to. Now that people can see a recommended route directly on the OSM homepage, they have an incentive to quickly pop in and fix little issues like that. The end effect will be OSM’s data going up one more level in terms of its quality for routing. This will empower everyone to do great things with geographic data and getting from A to B.

Also: Probiert mal rum – und wenn z.B. Routen nur strassengenau funktionieren, nehmt’s als Anlass, Hausnummern nachzutragen, wo ihr koennt 😀

Immer aktuelle POI-Karten mit Leaflet und Overpass

uulm-map

Wir hatten neulich das Gebaeudemanagement der Uni um eine Uebersicht der von ihr aufgestellten Radparkanlagen gebeten – mit dem Hintergedanken, das schoen aufbereitet zu veroeffentlichen, um moegliche Bedarfe zu erkennen und potenziellen Radler*innen eine schoene Uebersicht an die Hand zu geben.

Die Uebersicht kam dann in Form eines PDF-Plans mit blauen Bobbeln je Abstellanlage – und der PDF-Plan war nicht etwa irgendein Geospatial PDF, nein, das war einfach „nur“ ein Umgebungsplan ohne auch nur den Ansatz eines Koordinatensystems oder sonstiger Hinweise, wo man sich denn befaende. Leider benutzt man in der Univerwaltung kein GIS, so dass es kein Repository fuer relevante Geodaten (z.B. auch Hoersaele, Eisautomaten,…) an der uulm gibt.

Passt genau!

Passt genau!

Als Fingeruebung habe ich deswegen erst einmal die Karte (bzw. einen Export davon) in QGIS georeferenziert. Anstatt (wie geplant) daraus eine Onlinekarte mit qgis2leaf zu exportieren, habe ich dabei erst einmal Dinge gelernt, von denen ich nicht dachte, dass ich sie einmal lernen wuerde. Zum Beispiel, dass WGS84 nicht gleich WGS84 ist, sondern einmal WGS84 als Koordinatensystem auf dem Referenzellipsoiden (EPSG:4326) und einmal als sphaerische Merkatorprojektion (EPSG:3857). Waehrend die OSM-Ursprungsdaten in EPSG:4326 sind, werden die Kacheln (wie auch bei Google Maps) als Projektion in EPSG:3857 referenziert; Koordinateneingaben werden aber als EPSG:4326 angenommen und dann in EPSG:3857 umprojiziert…

Das interessiert natuerlich keine Sau, die ihr Fahrrad abstellen will.

Nach einigem Ueberlegen kam ich daher zum Schluss, die Punkte auf der Karte mit der OpenStreetMap abzugleichen. Dort wird naemlich nicht nur der Ort abgelegt, sondern auch Metainformation wie die Zahl der Abstellplaetze, ob eine Ueberdachung besteht, etc. Die habe ich also bei den fehlenden Anlagen noch nachgetragen, und so ist seit dem Wochenende die OSM an der Uni Ulm mit der Realitaet der Abstellplaetze wieder weitgehend in Einklang 😉

Blieb die Frage, wie diese Daten dann den Weg in eine interaktive Karte finden, die ein wenig moderner ist als ein 2,5 MB grosses PDF.

Ich hatte mich neulich schon einmal mit der Overpass API fuer die Openstreetmap beschaeftigt, um komplette OSM-Dumps fuer Ulm zu ziehen. Eher wenig Beachtung hatte ich dabei dem Detail geschenkt, dass das ja 1.) eine API ist und 2.) damit auch Selektionen auf bestimmte Tags moeglich sind.

Mit Overpass Turbo ist das leicht auszuprobieren: Einfach mal im Wizard oben links eine beliebige Abfrage eingeben (Beispiele stehen schon darunter) und Ausfuehren – voila, da kommen die Daten als GeoJSON und werden auch auf der Karte angezeigt. Und von einer Aenderung eines solchen Punkts im OSM-Originaldatensatz dauert es nur wenige Sekunden, bis eine neuerliche Overpass-Abfrage die aktualisierten Daten anzeigt. Wohoo!

Mit leaflet-layer-overpass existiert derweil eine JS-Bibliothek, die Overpass mit Leaflet verknuepft, und so dauerte es nicht lange, bis die erste fertige Fahrradabstellanlagenkarte fertig war. Das einzige, was noch verbleibt, sind kleine Tweaks wie bessere Infopopups und eine Unterscheidung zwischen offenen und ueberdachten Abstellmoeglichkeiten.


Größere Karte anzeigen

Ich faende es cool, wenn moeglichst viele Geodaten der uulm nach und nach den Weg in die OSM finden wuerden. So blieben die Daten zentral in der Karte schlechthin, anstelle in verschiedenen dezentralen Repositories zu versauern – und nach und nach koennten Dinge wie Hoersaalfinder oder Uebersichtskarten von Eisautomaten allesamt mit Leaflet und Overpass realisiert werden 😉

Civic Issue Tracking mit Mark-A-Spot

@ManuelBogner von der SWP machte die datalove-Gruppe vor gut zwei Wochen auf eine Anwendung der SZ aufmerksam, in der Unfallschwerpunkte markiert werden koennen – und die dafuer verwendete Drupal-Distribution Mark-A-Spot. Die kann beliebige Eingaben verwalten (z.B. uebervolle Muelleimer, kaputte Strassenlaternen oder aehnliches), die entgegennehmende Stelle kann den Status der Eingabe aktualisieren (von „in Bearbeitung“ bis „wurde abgearbeitet“), und das Ganze ist dann auch noch mit dem Open311-Standard kompatibel.

markaspot

Weil ich mir das mal ansehen wollte, habe ich mir das mal testweise auf meinem Raspberry Pi installiert – und weil es dabei einige Fallstricke gab, ist das hier kurz dokumentiert.

Exkurs: Ich habe fuer solche RasPi-Spielereien ein Minimal-Image auf einer 1-GB-SD-Karte (bitte dortige Installations- und Konfigurationsanleitung beachten). Das reicht locker aus; gegebenenfalls muss zwischendurch der apt-Cache mit apt-get clean geleert werden. Fuer die hier gezeigte Installation sind folgende zusaetzlichen Pakete noetig: apache2 apache2-utils libapache2-mod-php5 php5 php5-sqlite php5-common php5-cgi php5-gd unzip

Mark-A-Spot wird als komplette Distribution ausgeliefert, d.h. im aktuellen Master-Branch von Github liegt ein komplettes Drupal samt aller Erweiterungen, um eine lauffaehige Mark-A-Spot-Instanz zu bauen. Analog zum Installationsvideo laeuft die Installation folgendermassen:

Mark-a-Spot Open311 Server from Holger Kreis on Vimeo.

cd /var/www
wget https://github.com/markaspot/mark-a-spot/archive/master.zip
unzip master.zip
mv mark-a-spot-master/* .
rm master.zip

Wie in der Drupal-Anleitung angegeben muessen fuer die Installation noch einige Rechte gesetzt werden:

chmod a+w sites/default
cp sites/default/default.settings.php sites/default/settings.php
chmod a+w sites/default/settings.php

Da der RasPi fuer so eine Installation eine verdammt untermotorisierte Maschine ist, muss noch der Speicher fuer PHP und die maximale Scriptausfuehrungszeit hochgesetzt werden, sonst wird der Installer mit einem AJAX-Fehler 400 abbrechen:

nano /etc/php5/apache2/php.ini

service apache2 restart

Danach wird einfach der RasPi im Browser aufgerufen und der Installationsprozess so wie im Video vervollstaendigt. Dauert etwa eine halbe Stunde (ja, das Ding ist zu langsam dafuer…)

Danach sollte die Seite an sich laufen – bis auf vielleicht den Seiteneffekt, dass keine der Unterseiten laedt, sondern einen 404 liefert. Das liegt in der Regel an den Clean URLs; in der Installationsbeschreibung wird das en passant erwaehnt:

Make sure that clean urls are supported and active: http://yourserver/?q=admin/config/search/clean-urls

Falls Clean URLs nicht funktionieren, kann man die also dort abstellen (einfach den Haken wegmachen) – oder aber analog zu dieser Anleitung den Apache konfigurieren:

a2enmod rewrite
service apache2 restart
nano /etc/apache2/sites-enabled/000-default

Bleibt zuletzt nur noch, wie im Initial Configuration-Abschnitt angegeben, die Startpositionen und Karteneinstellungen anzupassen.

Hope this helps 😉

Selbstgemachte Haltestellen-Umgebungsplaene

Es gibt ja so Momente, in denen moechte man ein Problem loesen, und dann schliesst man sich so lange ein, bis man hinreichend nahe an eine Loesung gekommen ist. So in der Art erging es mir am Schwoerwochenende, eigentlich wegen einer ganz trivialen Sache: Ich haette gerne Umgebungsplaene fuer die Bushaltestellen rund um die Uni.

Ein Grund, warum ich hier im Blog nicht mehr so viel schreibe ist naemlich, dass ich seit gut einem Jahr der Mobilitaetsreferent der Uni-Studierendenvertretung bin und in dieser Eigenschaft umso mehr anderswo schreibe. Und ein Problem, auf das ich in diesem Rahmen stiess, war der Umstand, dass es an vielen Haltestellen in der Stadt mittlerweile Orientierungsplaene fuer die naehere Umgebung gibt – es so etwas aber ausgerechnet an der Uni, an die immer wieder Konferenzteilnehmer*innen und sonstige Externe anreisen, ausschliesslich an der Haltestelle Kliniken Eselsberg gibt.

In einer Besprechung hatten die Stadtwerke zugesagt, Plaene nachzuruesten, sofern die Haltestellen dafuer noch freie Plaetze haben – und wir sagten zu, die dazugehoerigen Plaene zu bauen. Und nachdem Stefan Wehrmeyer mir beim occ13 noch einige Funktionen von TileMill naeher brachte, die ich bis dato nicht kannte, war der Weg schon einmal vorgezeichnet 🙂

Die Idee

Lokalen OpenStreetMap-Auszug von Ulm und Umgebung (genauer: Regierungsbezirk Tuebingen) downloaden, mit TileMill stylen, exportieren und aufbereiten

umgebplan

Die Umsetzung

Vorbereitung: TileMill und PostGIS installieren

(Siehe hierzu auch https://github.com/mapbox/osm-bright und http://wiki.openstreetmap.org/wiki/PostGIS/Installation

 sudo apt-get install tilemill postgresql postgresql-contrib postgis osm2pgsql
 sudo -u postgres createuser stk # as superuser
 sudo -u postgres createdb --encoding=UTF-8 --owner=stk tuebingen
 sudo -u postgres createlang plpgsql tuebingen

PostGIS einrichten, Karte laden und importieren

 sudo -u postgres psql -d tuebingen -f /usr/share/postgresql/9.1/contrib/postgis-1.5/postgis.sql
 sudo -u postgres psql -d tuebingen -f /usr/share/postgresql/9.1/contrib/postgis-1.5/spatial_ref_sys.sql
 sudo -u postgres psql -d tuebingen -f /usr/share/postgresql/9.1/contrib/postgis_comments.sql
 sudo -u postgres psql -d tuebingen -c "ALTER TABLE geometry_columns OWNER TO stk;"
 sudo -u postgres psql -d tuebingen -c "ALTER TABLE spatial_ref_sys OWNER TO stk;"
 wget http://download.geofabrik.de/europe/germany/baden-wuerttemberg/tuebingen-regbez-latest.osm.pbf
 osm2pgsql -c -G -d tuebingen tuebingen-regbez-latest.osm.pbf

osm-bright laden und anpassen

 git clone https://github.com/mapbox/osm-bright.git
 cd osm-bright
 cp configure.py.sample configure.py
 # edit according to readme
 ./make.py

Projekteinstellungen in project.mml:

"bounds": [
          9.9376,
          48.4151,
         9.971,
          48.4294
],
"center": [
          9.9535,
          48.4243,
          15
]

POIs hinzufuegen

Icons: http://www.sjjb.co.uk/mapicons/downloads (SJJB)

sudo apt-get install librsvg2-bin
./generatepngall.sh

Waehrend die PNGs gerendert werden, Layer in Tilemill hinzufuegen:

{
      "geometry": "point",
      "extent": [
        8.252064998851305,
        47.14375559492619,
        10.28521039856825,
        48.91388219485537
      ],
      "Datasource": {
        "type": "postgis",
        "table": "( SELECT name, highway, way\n  FROM planet_osm_point\n  WHERE building IS NULL AND highway IN ('bus_stop')\n  ORDER BY z_order ASC NULLS LAST\n) AS data",
        "key_field": "",
        "geometry_field": "way",
        "extent_cache": "auto",
        "extent": "918615.673665123,5965570.29255198,1144944.3842703,6260261.61701241",
        "dbname": "tuebingen",
        "user": "stk"
      },
      "id": "transit",
      "class": "",
      "srs-name": "900913",
      "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over",
      "advanced": {},
      "name": "transit"
    },
    {
      "geometry": "point",
      "extent": [
        8.252064998851305,
        47.14375559492619,
        10.28521039856825,
        48.91388219485537
      ],
      "Datasource": {
        "type": "postgis",
        "table": "( SELECT name, way, highway\n  FROM planet_osm_point\n  WHERE building IS NULL AND highway IN ('bus_stop')\n  ORDER BY z_order ASC NULLS LAST\n) AS data",
        "key_field": "",
        "geometry_field": "way",
        "extent_cache": "auto",
        "extent": "918615.673665123,5965570.29255198,1144944.3842703,6260261.61701241",
        "dbname": "tuebingen",
        "user": "stk"
      },
      "id": "transitlabel",
      "class": "",
      "srs-name": "900913",
      "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over",
      "advanced": {},
      "name": "transitlabel"
    },
    {
      "geometry": "point",
      "extent": [
        8.252064998851305,
        47.14375559492619,
        10.28521039856825,
        48.91388219485537
      ],
      "Datasource": {
        "type": "postgis",
        "table": "( SELECT *\n  FROM planet_osm_point\n  WHERE building IS NULL AND amenity IN ('biergarten', 'cafe', 'restaurant', 'bicycle_parking', 'charging_station', 'parking', 'atm') \n ORDER BY z_order ASC NULLS LAST\n) AS data",
        "key_field": "",
        "geometry_field": "",
        "extent_cache": "auto",
        "extent": "918615.673665123,5965570.29255198,1144944.3842703,6260261.61701241",
        "dbname": "tuebingen",
        "user": "stk"
      },
      "id": "uulmpoi",
      "class": "",
      "srs-name": "900913",
      "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over",
      "advanced": {},
      "name": "uulmpoi"
    }

und dann folgendes Styling in uulm.mss:

/* ****************************************************************** */

 #transitlabel[zoom >= 16] {
  text-name: [name];
  text-face-name: @sans;
  text-placement: point;
  text-wrap-width:60;
  text-fill: @poi_text;
  text-halo-radius: 2;
  text-halo-fill: @road_halo;
  text-min-distance: 2;
  text-placement-type: simple;
  text-allow-overlap: true;
  text-placements: "S,E,N,W,NE,SE,NW,SW,14,12,10";
  text-dx: 10;
  text-dy: 20;
 }

 #transit[zoom = 16] {point-file: url(img/sjjb/transport_bus_station.glow.999999.12.png); }
 #transit[zoom >= 17] {point-file: url(img/sjjb/transport_bus_station.glow.999999.20.png); }
 #transit[zoom >= 19] {point-file: url(img/sjjb/transport_bus_station.glow.999999.24.png); }

 #uulmpoi [amenity='cafe'][zoom <= 16] {point-file: url(img/icon/cafe-12.png); }
 #uulmpoi [amenity='cafe'][zoom >= 17] {point-file: url(img/icon/cafe-18.png); }
 #uulmpoi [amenity='cafe'][zoom >= 19] {point-file: url(img/icon/cafe-24.png); }

 #uulmpoi [amenity='restaurant'][zoom <= 16] {point-file: url(img/sjjb/food_restaurant.glow.8E7409.12.png); }
 #uulmpoi [amenity='restaurant'][zoom >= 17] {point-file: url(img/sjjb/food_restaurant.glow.8E7409.20.png); }
 #uulmpoi [amenity='restaurant'][zoom >= 19] {point-file: url(img/sjjb/food_restaurant.glow.8E7409.24.png); }

/*
 #uulmpoi [amenity='bicycle_parking'][zoom <= 16] {point-file: url(img/sjjb/transport_parking_bicycle.n.0092DA.12.png); }
 #uulmpoi [amenity='bicycle_parking'][zoom >= 17] {point-file: url(img/sjjb/transport_parking_bicycle.n.0092DA.20.png); }
 #uulmpoi [amenity='bicycle_parking'][zoom >= 19] {point-file: url(img/sjjb/transport_parking_bicycle.n.0092DA.24.png); }
*/

 #uulmpoi[amenity='restaurant'][zoom >= 16] {
  text-name: [name];
  text-face-name: @sans;
  text-placement: point;
  text-wrap-width:60;
  text-fill: @poi_text;
  text-halo-radius: 2;
  text-halo-fill: @road_halo;
  text-min-distance: 2;
  text-placement-type: simple;
  text-allow-overlap: true;
  text-placements: "S,E,N,W,NE,SE,NW,SW,14,12,10";
  text-dx: 10;
  text-dy: 10;
 }

FIXME die Marker sollten SVG sein, das ist noch TODO

Labelprobleme

Beim Rendern nach SVG oder PDF sehen die Labels (Strassennamen etc) seltsam aus: Buchstaben und Halos werden jeweils einzeln gerendert, so dass die Halos jeweils den naechsten Buchstaben ueberdecken. Das Problem scheint bekannt, siehe http://support.mapbox.com/discussions/tilemill/6001-text-halos-look-bad-in-pdfsvg-export, bleibt wohl nur die manuelle Beschriftung. Ich habe einfach die Labels in einem separaten Layer exportiert, der eingeblendet werden kann (oder auch nicht)

Handarbeit

Die Idealvorstellung war ja, dass sich der Prozess irgendwie automatisieren lassen wuerde, insbesondere wegen der Labels ging das aber nicht so einfach. Deswegen ging ich den folgenden Weg:

  • Einzelne Layer nacheinander exportieren, Breite 4000, Zoomlevel 17, Ausgabeformat PDF
    • Baselayer (Geometrien)
    • Strassenlabels
    • Transitmarker
    • POIs
  • Alle Layer in Illustrator (ich weiss, keine freie Software, gibts aber im PC-Pool an der Uni) zu einem Composite zusammenfuegen
  • Haendisch Beschriftungen hinzufuegen, einmal detailliert und einmal fuer den Uebersichtsplan
  • Alles in InDesign fuer den Druck anpassen

  • Optional: Versehentlich Schriftfarbe auf Passermarken setzen und sich wundern, warum die Glyphen pixelig rauskommen, bis man den Fehler bemerkt

Eine bessere Variante waere es, die Beschriftungen nochmals als eigene Datenquelle vorzuhalten und einzublenden, dann liesse sich das auch als SlippyMap exportieren, haette aber genau wieder dasselbe Problem, wenn man PDFs fuer den Druck exportieren moechte. Den derzeitigen Weg halte ich fuer einen gangbaren Kompromiss aus Aufwand/Ergebnis.

Betaversionen:

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 😉