One thing that I've been wanting in Maps for a while is support for transit routing (for using public transportation options) in addition to our current ”turn-based” routing for car, bicycle, and walking powered by GraphHopper.
For a brief period in late summer took some time investigating the GTFS feed specification (for timetable data). The OpenTripPlanner project seemed rather fitting.
After a while of manually downloading some GTFS feed data and adding them to OTP's graph directory structure, I got a bit bored of that and wrote a little script to do the job https://github.com/mlundblad/otp-updater. It is quite crude and would probably need some better documentation (including a sample for the feed list configuration and such) and also currently requires quite a few command line parameters to point out the location for the OTP installation (used to run the graph rebuild command from there), these should probably be read from a global configuration by default…
Now, when things have calmed down a bit for 3.20 (and I wanted to try to keep main focus during my spare-time coding sessions getting the OpenStreetMap editing up to shape) I sat down and transformed the thoughts I've had in my head when it comes to integrating with an OTP server into a little proof-of-concept. The code is available in the https://git.gnome.org/browse/gnome-maps/log/?h=wip/mlundblad/transit-routing branch. The code is quite full of debug output code, is for the time being hard-wired to query an OTP instance running on localhost, and there's some duct tape here and there, but at least it does something…
OK, so enough of talking, now a little screenshot:
As you can here, there is now a new mode button to switch to transit mode. Currently, the only visible output is a raw debug dump of the JSON output from OTP. By the way, the blue route line shown in the screenshot is not actually from the transit routing, it's there since I first did the search using car mode and then switched to transit. And the reason it does a query also using the Estonian graph, seems to be some off coordinate in the data, I think.
I've also made a little list of feeds I've tried with here: https://wiki.gnome.org/Apps/Maps/Resources/GTFSFeeds
Running those feeds (plus a few more I had manually added before writing the updater script), the server takes around 7-8 GB RAM. So this would probably require a rather beefy machine to host the server.
Over and out for tonight! :-)
This app makes me happy. Thank you!
ReplyDeleteGlad to hear! Thanks!
DeleteHi, it would be useful to load GPX tracks and to view the elevation profile of the track. I think it would be not too hard.
ReplyDeleteThank you! :-)
Loading of GPX tracks will come in 3.20!
DeleteI'm not sure if it shows the elevation profile (is that included as some annotation of the track points?)
Yes, the elevation could be in the GPX file (but not always). An example is here (see the tag):
Deletehttps://drive.google.com/file/d/0B4fSap1DVc_VVXUwR3ZJX25TcUU/view?usp=sharing
Anway, the elevation value (that is taken from smartphone gps) is often incorrect.
See this site: http://www.lunicus.org/tacx/GPXsmoother.htm
There's a button "Add Elevation From Google Maps Service" that fixes the elevation value of the gpx to more correct values.
Maybe you know this but check out http://transitfeeds.com/, it's a nice database of known GTFS feeds there and you can request more to add, so is somewhat collaborative.
ReplyDeleteThey have an API to list all the available feeds in their database, so you can have a good source to feed your OTP instance.
Aha, no I hadn't seen that one!
DeleteI picked from some project on google code and from gtfs-exchange.
I imagine our server would download directly from the respective transit authority's servers when there's an update.
Question - do you consume only GTFS or do you add OSM data too? Last time I did full scan it barely could parse one city.
ReplyDeleteI have only imported GTFS data.
DeleteMy plan is to try and combine GraphHopper (which we currently use for turn-based routing) for car, bike, and walking with OTP for transit routing.
So, we'd basically do a search from start and end positions which OTP would return with itineraries from the closes transit stops in this case, and then reach out to GraphHopper to "fill in" walking to and from the transit endpoints (in case the distance is above some threashhold value perhaps).
This article is so innovative and well constructed I got lot of information from this post. Keep writing related to the topics on your site
ReplyDelete