Consuming GTFS Real Time in a Mobile App

[John Rellis]

Hello all,

I am trying to get an understanding of how GTFS RT is consumed on a mobile device.  

Is the parsing of the protocol buffer typically done on the mobile device or is it better to have a REST API sitting in front of the GTFS RT feed to provide an API to the mobile app?

Initially I thought it was the latter as parsing on the device may be too slow but as I read more, it looks as though the mobile devices are connecting to the feed.

Can anyone fill me in on what people seem to be doing?

Thanks,

John

[Stefan de Konink]

On dinsdag 29 augustus 2017 15:49:26 CEST, John Rellis wrote:
> Hello all,
>
> I am trying to get an understanding of how GTFS RT is consumed
> on a mobile device.

It is not ;-) Unless you are using it to communicate *all* data of a
service provider on a mobile device.

> Is the parsing of the protocol buffer typically done on the
> mobile device or is it better to have a REST API sitting in
> front of the GTFS RT feed to provide an API to the mobile app?

You can use a REST API as filter and even use protocol buffers as a
serialisation.

> Initially I thought it was the latter as parsing on the device
> may be too slow but as I read more, it looks as though the
> mobile devices are connecting to the feed.
>
> Can anyone fill me in on what people seem to be doing?

Protocol buffers parsing is not slow, and it is quite an efficient wire
protocol. But I doubt you want to do anything with the raw data of protocol
buffers, unless you want something like moving vehicles on a map, or an
"also offline working" realtime planner.

--
Stefan

[@makar]

Hi John

If we speak about bus arrival's ETAs then for every bus stop best implementation is REST api.

For vehicle locations, the following technique can be implemented

1. When mobile app is coming into active mode, it requests vehicle locations via REST api

2. At the same time, opens a websocket (zmq or any other stream connection) - subscribes to events from required list of vehicles. (other type - periodic REST update)

3. Mobile app can cache a graph of routes and after receiving latest positions by method 1 and 2, constantly "move vehicles on the map" - making virtual prediction between GPS location updates on mobile. (REST backend may also return either "last known position" or "predicted position" or a combination).

Above methods can be used in different combinations with filtering of data/streams over visible map bounding box/route/city/district etc

Hope that helps

BR

EM

вторник, 29 августа 2017 г., 21:49:27 UTC+8 пользователь John Rellis написал:

[John Rellis]

Hi Stefan and @makar,

Great stuff, thank you!

Are you aware of any best practices or currently existing REST APIs to put in front of the GTFS RT feed?

Thanks,

John

[@makar]

Yes, definitely aware because previously implemented this in some cities :)

In general 

1. you need to have server who can consume GTFS-RT stream into "local database".

2. you need to make REST/websockets (in parallel with static route API) to send info from your server to mobile apps

3. develop mobile app which can consume REST and realtime

BR

EM

вторник, 29 августа 2017 г., 22:28:15 UTC+8 пользователь John Rellis написал:

[@makar]

For REST/websockets/any other stream API you can take any framework, depending on the language that you're using

There's many ways how to do that

Or you can try to find some open source server for such task

вторник, 29 августа 2017 г., 22:32:07 UTC+8 пользователь @makar написал:

[John Rellis]

@makar, many thanks for the replies, this helps me a lot!