Schlagwort-Archive: OpenTransit

Eine etwas andere Transit-Karte

Von Transit-Livemaps hatte ich es hier ja schon haeufiger, das hier ist aber ein schicker und etwas anderer Ansatz: Christoph Doeberl hat den Linzer Nahverkehr auf eine Hardware-Karte gepackt.

Bild von Christoph Doeberl, CC-BY

Bild von Christoph Doeberl, CC-BY

Ein Rechner fragt die EFA-Daten der Linz Linien AG periodisch ab, und mittels Arduino werden dann RGB-LEDs angesteuert, um die jeweiligen Linienfarben an den passenden Haltestellen aufleuchten zu lassen.

Mir ist noch nicht ganz klar, ob da dann auch „Interims-LEDs“ fuer die Streckenabschnitte zwischen den Haltepunkten geplant sind, oder ob die Position immer „nur“ an den Haltestellen angezeigt werden kann; schick sieht’s allemal aus. Der Code steht auf Github einsehbar bereit.

Spassfakt zwischendurch: Etwa so funktionierten auch die Perlschnuranzeigen in Bussen und Bahnen: Ueber den mittlerweile ueber 30 Jahre alten IBIS-Wagenbus nach VDV-300 wurde die kommende Haltestelle und die Fahrtrichtung uebertragen, und im Fahrzeug mittels Laempchen hinter einer Durchlichtanzeige angezeigt. Bei manchen Verkehrsbetrieben sieht man solche Anzeigen gelegentlich noch – wenn ich mich richtig erinnere, z.B. in Stuttgart

An diesem Anwendungsfall zeigen sich auch die Probleme des leider von vielen Verkehrsverbuenden und dem VDV propagierten Modells, Fahrplandaten nicht als Open Data, sondern als „Open Service“ (also nur ueber Schnittstellen wie die EFA) bereitzustellen:

Leider ist ein Dauerbetrieb der Echtzeit-Abfrage von Daten sehr Bandbreiten intensiv, weshalb diese zeitweise ausgesetzt wird.

Deutlich sinnvoller erscheint an dieser Stelle der GTFS-Ansatz: Es gibt einen statischen Soll-Fahrplan, und Abweichungen von diesem werden als Realtime-Updates veroeffentlicht. Anstatt alle Fahrten bzw. Haltestellen periodisch komplett abfragen zu muessen, kann so der Soll-Fahrplan als Basis verwendet werden, und nur die Abweichungen muessen aus dem Internet bezogen werden. Das scheint man beim VDV vor lauter Angst vor Fremdnutzung aber nicht verstehen zu wollen.

Lebenszeichen

Wer hier mitliest, koennte meinen, ich existiere gar nicht mehr – ich kann wahlweise beruhigen oder enttaeuschen, dem ist nicht so.

Die letzten Monate waren ein wenig turbulent: Diplomarbeitsendspurt und -abschlussvortrag, nahtloser Uebergang in SoNaFe-Hilfsorganisatortaetigkeit wider Willen, parallel Arbeit im Mobilitaetsreferat, der datalove-Arbeitsgruppe, ein Open-Data-Workshop beim SWR in Stuttgart… was man eben so tut 😉

Die kommenden Wochen bleiben voller spannender Projekte: Ab Freitag abend bin ich in Berlin zum offiziellen Start von Code for Germany, ausserdem habe ich einige Texte zu Open Data und Nahverkehr auf dem Backburner, und Dominik und ich prototypen gerade Libraries fuer neue Busabfahrtsdisplays auf GTFS-Basis. Da Farnell element 14 uns hier freundlicherweise mit Hardware unterstuetzt, gibt’s bald auch eine Variante zum einfach-nur-installieren-und-verwenden – aber erstmal klinke ich mich nun in Richtung Berlin aus 🙂

Bis dahin ein Sneak Peak:

Roll your own transit display

@Lotterleben pointed out a hackaday project by Karlsruhe students today: Upcycling an old LED dot-matrix display, they outfitted their dorm with a real time bus departure monitor. Of course, there is a German word for that: Dynamische Fahrgastinformationsanzeige, or DFI 🙂

Apart from the cool technical solution the two came up with, this monitor is also interesting from yet another perspective. KVV, Karlsruhe’s integrated transit system, uses EFA by mentzDV for their online journey planner, which is in turn parsed for the display hack. EFA can output XML or JSON (depending on the installation), and the datalove working group used the EFA XML output for their own transit displays at ulm university (see below) – or for your own desktop, or for your smartphone.

uni-forum

 

Now, neither the departure monitor, nor the smartphone version, are works of art. They have severe usability and UI issues, and the EFA wrapper, while a cool hack by @taxilof, is tailored towards DING, our integrated transit system. Also, all of the systems completely rely on EFA – thus, whenever EFA fails or has scheduled downtimes, all displays fail.

I would love to bring together all interested parties who have hitherto put some efforts into any wrappers, libraries or solutions for EFA and create a unified and good library for EFA that is interchangeable to whatever version your local authority is running – just insert the API endpoint, choose whether it can output JSON or XML, and be a happy camper. Bonus points for also integrating GTFS as a fallback solution[1]!

The code for the mobile departure site is on Github; Documentation on the EFA interface is collected in the UlmAPI wiki. Interested? Get in touch!

[1] Yes, your transit system most likely does not provide GTFS yet. I am working on this as part of my thesis.

Update: @Natanji and @Feuerrot pointed me towards the projects site of Daniel Friesel, which includes command-line interfaces to – among others – EFA and Deutsche Bahn departure monitors. Front ends are available in the style of Deutsche Bahn and VRR.

Update2: There is another site serving as a entry point into creating your own Deutsche Bahn departure monitors.

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 😉