Transit Data REST standards

[Paul Harrington]

While GTFS is standardized, most implementation of it offer a REST API  so clients can access data easily.  Transit providers also make data available to end users via their own REST APIs.

Just wondering is there any standardization in this area or is every API different ? 

If for example you want to make a GTFS  implementation publicly available through REST/JSON, are there any guidelines for the format the URLs should take ?

[Paul Harrington]

Can I take it so that there are no standards, recommendations or best practices when it comes to making Transit data available via a REST/JSON interface ?

[Sean Barbeau]

Paul,

The short answer is no, at this point to my knowledge there are no widely agreed upon guidelines for representing GTFS data in REST API / JSON request/responses.

The closest would probably be this Data Package specification with validation accomplished with Good Tables. It includes a data package, schemas, tests, and uses South East Queensland GTFS data as an example:

https://github.com/Stephen-Gates/GTFS

I was working generalizing this to all GTFS but haven't finished it.

Sean

[Paul Harrington]

Thanks for getting back Sean. It is a little surprising that no efforts had been made in this direction given the effort that is being put into GTFS. 

Most Transit mobile apps get their data through some sort of REST call and a common standard would give an app access to multiple sources.

Paul.

On Thursday, 2 August 2018 17:12:00 UTC+1, Paul Harrington wrote:

[Sean Barbeau]

Paul,

I think the reason why this hasn't happened yet is primarily because in my experience REST API request/response aren't typically a good one-to-one match to the GTFS dataset, and the exact request depends on a variety of use cases.  Typically you're querying a small subset of GTFS that's a cross-section of a few .txt files, which means the server needs to process the entire dataset into an internal data model.

For example, for OneBusAway's APIs, the two most heavily used REST API calls for the native apps are stops-for-location (I'm looking at the map, and want to know which stops are nearby):

http://developer.onebusaway.org/modules/onebusaway-application-modules/current/api/where/methods/stops-for-location.html

...and arrivals-and-departures for stop (what are the upcoming arrivals at a stop):

http://developer.onebusaway.org/modules/onebusaway-application-modules/current/api/where/methods/arrivals-and-departures-for-stop.html

Stops-for-locations not only gives you the stops, but also the routes that visit that stop, which is a cross of stops.txt, routes.txt, trips.txt, and stop_times.txt.  arrivals-and-departures-for-stop also references data from most of the same files.

What were the specific types of API calls that you're thinking of?  And were you thinking of standardizing the request parameters, the response elements, or both?

Sean

--
You received this message because you are subscribed to a topic in the Google Groups "Transit Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/transit-developers/hjEVYCUyZmo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to transit-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Harrington]

Hi Sean,

Been away. I only make 2 server calls from the client, one is to get the stop list for a transit provider and the other is arrivals and departures for a stop. By having a format similar to other systems it would mean that my client could avail of other backends or different UIs could use my server. The thought had occurred to me to make changes to the URL and data format in a refactoring exercise if there was an established format. I see that onebusaway uses an XML format, I use JSON and no doubt there are more models out there.

Anyway it was more just a thought that I had. Being from Ireland, I'd like to implement Irish transport providers but there is no GTFS realtime here. There is a realtime REST interface but it is too different from my system to be easily incorporated and it is this that got me wondering about the existence or not of a standardized REST interface.

Regards Paul.

To unsubscribe from this group and all its topics, send an email to transit-developers+unsub...@googlegroups.com.

[Sean Barbeau]

OneBusAway does support XML and JSON responses.

Regarding standards, previously I neglected to mention MTA's SIRI-based REST API:

http://bustime.mta.info/wiki/Developers/Index

SIRI is a European standard and MTA uses it for realtime info, and the OneBusAway APIs for discovery of information typically in GTFS. I understand that SIRI 2.0 does support these types of discovery APIs too but I'm not sure if they are implemented at MTA now.

Sean 

To unsubscribe from this group and all its topics, send an email to transit-develop...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "Transit Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/transit-developers/hjEVYCUyZmo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to transit-develop...@googlegroups.com.

[Paul Harrington]

Interesting, the MTA REST data standard does seem quite complicated though with fields that are quite different from that returned by GTFS.  The REST data returned by dublin bus:

https://data.smartdublin.ie/cgi-bin/rtpi/realtimebusinformation?stopid=7602&format=json

is a format that would seem more amenable. This however is defined by a company called opensky and as far as I can see is proprietary:

https://data.smartdublin.ie/dataset/real-time-passenger-information-rtpi-for-dublin-bus-bus-eireann-luas-and-irish-rail

This goes back to your original assertion that there are no widely agreed formats for representing GTFS data in REST/JSON. 

As an aside, I do believe that there is scope for a standard API going forward as APIs currently provided by transit operators are what UI developers want and use. GTFS is a layer beneath this and could be best viewed as a building block used to produce such an API (which is what onebusaway provides)

To unsubscribe from this group and all its topics, send an email to transit-developers+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Transit Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/transit-developers/hjEVYCUyZmo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to transit-developers+unsub...@googlegroups.com.

[Nisar Ahmed]

SF Bay 511 provides a set of APIs in XML and JSON formats for static and real-time transit data. These APIs were developed based on the SIRI and NeTEx specs. Detail can be found at http://assets.511.org/pdf/nextgen/developers/Open_511_Data_Exchange_Specification_v1.26_Transit.pdf

To unsubscribe from this group and all its topics, send an email to transit-develop...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Transit Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/transit-developers/hjEVYCUyZmo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to transit-develop...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.