API Documentation

[dmccue]

@szlwzl Just made another major breakthrough, after a lot of investigation it turns out the apis and software are identical to the Transport for London Journey planner
http://content.tfl.gov.uk/journey-planner-api-documentation.pdf

This means that we can take advantage of the toolsets used for the likes of this:
https://www.youtube.com/watch?v=fEY0jnRs0os

[dmccue]

@stkdiretto This is very similar to your diva2gtfs project, afaik diva was the predecessor to EFA

[stkdiretto]

More or less. EFA is the trip planner frontend for end users, DIVA is the underlying scheduling software (the backend, if you will) which provides the source data for EFA.

EFA's API is pretty well documented by now – a couple of years back, TfL was the only documentation available (the underlying system is the same, also by Mentz). In the mean time, Linz Linien provided a rather comprehensive documentation: https://www.data.gv.at/katalog/dataset/9faa1734-607f-4bfd-b8c9-c5692bf37d55

We considered using EFA as a GTFS source, too. The problem is the lack of Umlauf information (can't recall the english name for it at the moment), i.e., after the first trip, which trips follow during the vehicles' services through the day. That information is paramount when offering transfer information, for instance when bus #5 becomes bus #3 and you can “transfer” by remaining sitting in the vehicle.

Also, EFA gives hardly any information on the underlying service structure: Which patterns exist on which days, what will happen on New Year's Eve, etcetera.

[stkdiretto]

I just realized, my comment sounds way too negative and wasn't intended that way :)

There are some things EFA really shines at, giving you data you wouldn't otherwise get through DIVA. Headsign validation is one thing, shapes(!!!) are kind of a mystery within DIVA. Other stuff you can't really get out of EFA. A two-pronged approach sounds like a sensible solution to me.

Is there anything I can help you with? There's a bunch of info in my diploma thesis on the topic, see http://dbis.eprints.uni-ulm.de/1054/

[dmccue]

Thanks @stkdiretto, yea the EFA API has been designed specifically to stop database exports it appears. I've been able to iterate over each stopID (which needs prior manual analysis to determine stopID range)

In addition to that I've been able to iterate over each known stopIDs (stop.txt) and return a list of routeIDs (routes.txt)

However i'm stumped on how query a route for stopIDs to form a path. A subset of routeIDs are shown when searching for a stopID, but I can't seem to specifically query a routeID for a list of stops. See https://github.com/dmccue/efa2gtfs/blob/master/get_trips.py

I'm sure i'll make a breakthrough eventually, lack of API docs is slowing progress. I guess i'm now at the point where a database is required, in which case pygtfs looks like a solution. Also for mapping, pygmaps is proving inadequate and looks like i'll be moving to pykml

[stkdiretto]

Ouch, I saw the notification on the comment only now, sorry. One way would be to probe for geocoordinates within the area of the transit agency in question.

As for extracting trips, have you had a look at https://github.com/derf/Travel-Routing-DE-VRR/blob/master/t/21-vrr.t ?