Flow of questions about the GTFS-realtime standard

[Xavier Prudent]

Dear all,

I am using the standard gtfs-rt and have basic questions about how certain situations in a transportation network are described:

(1) concerning the prediction of the arrival time, one could imagine different ways of estimating the arrival time. Is the standard google-gtfs estimation StopTimeUpdate well spread among transportation? More 20, 50 or 90% of transportation companies ?

(2) if a detour takes place during a trip, does the gtfs-rt take it into account? What if this detour was not planned?

(3) concerning doubling vehicles, that is for a same route to have different vehicles to relieve the load, are these double-vehicles included separately in the gtfs-rt thanks to their vehicle-id, even though they ride on the same trip?

(4) concerning block-trips, if a vehicle does the line 1, and then line 7. Any delay on the line 1 may cause a delay on the line 7, is that delay included in the gtfs-rt before the trip on the line 7 even starts? Can the gtfs-rt consider block sequence? 

That's all, I hope I could make my questions clear and thank you in advance for any enlightenment on the subject.

Regards,

Xavier

--

Xavier Prudent 

Analyste de données - Forage de données - Apprentissage statistique

Data Scientist  - Data Mining - Machine Learning

Web    : www.xavierprudent.com

Tel      : 06 66 61 19 31

Skype : xavierprudent

[Stefan de Konink]

On vrijdag 24 maart 2017 19:08:10 CET, Xavier Prudent wrote:
> (1) concerning the prediction of the arrival time, one could
> imagine different ways of estimating the arrival time. Is the
> standard google-gtfs estimation StopTimeUpdate well spread among
> transportation? More 20, 50 or 90% of transportation companies ?

There are different methods used in many standards. From punctuality
(prediction of arrival at the next stop) to full estimation along the
route.

> (2) if a detour takes place during a trip, does the gtfs-rt
> take it into account? What if this detour was not planned?

GTFS-RT allows you to model the detour. It doesn't state if the consumer is
capable of handeling it. For example for some consumers it is virtually
impossible to add unscheduled journey patterns and still produce meaningful
results on the detour part. While others have no problems at all.

> (3) concerning doubling vehicles, that is for a same route to
> have different vehicles to relieve the load, are these
> double-vehicles included separately in the gtfs-rt thanks to
> their vehicle-id, even though they ride on the same trip?

Or a different starttime.

> (4) concerning block-trips, if a vehicle does the line 1, and
> then line 7. Any delay on the line 1 may cause a delay on the
> line 7, is that delay included in the gtfs-rt before the trip on
> the line 7 even starts? Can the gtfs-rt consider block
> sequence?

Again dependent on the inference of the consuming application. But consider
the following, what if the operator decides to unblock the trip because it
is late? :)

--
Stefan

[Sean Barbeau]

Xavier,

A few answers inline.

(1) concerning the prediction of the arrival time, one could imagine different ways of estimating the arrival time. Is the standard google-gtfs estimation StopTimeUpdate well spread among transportation? More 20, 50 or 90% of transportation companies ?

GTFS-rt defines a way to share predictions for a vehicle, but is agnostic to how those predictions are produced.  The propagation rules for StopTimeUpdates down a trip are there to define standard behavior so producers and consumers can have consistent and predictable behavior, but the spec doesn't define how an individual prediction for a vehicle and/or stop is produced.

(2) if a detour takes place during a trip, does the gtfs-rt take it into account? What if this detour was not planned?

Agencies may choose to express changes in service via GTFS-rt.  The simplest approach is to simply stop providing real-time information for a trip that changes - this indicates to consumers that no real-time information is available for that trip.  In this case, a consumer can choose to show schedule info from GTFS to the consumer, or just say that no real-time info is available.  People are exploring more advance ways of expressing changes to planned trips, either via added/canceled trips and ScheduleRelationship (https://developers.google.com/transit/gtfs-realtime/reference/ScheduleRelationship-td) as well as ServiceAlerts (https://developers.google.com/transit/gtfs-realtime/reference/Alert), although I don't think there is a widely accepted best practice method of doing this yet.

(3) concerning doubling vehicles, that is for a same route to have different vehicles to relieve the load, are these double-vehicles included separately in the gtfs-rt thanks to their vehicle-id, even though they ride on the same trip?

Yes, I would expect two vehicles to appear in the feed, with the same trip_id and different vehicle_id.  start_time should match GTFS trip start_time, unless the trip is not scheduled based (i.e., is frequency-based exact_times=0)

(4) concerning block-trips, if a vehicle does the line 1, and then line 7. Any delay on the line 1 may cause a delay on the line 7, is that delay included in the gtfs-rt before the trip on the line 7 even starts? Can the gtfs-rt consider block sequence? 

In my option the best practice is to propagate delays down the block, but being sure to honor any layovers (i.e., a layover might be able to absorb small delays, which would result in the vehicle departing the layover stop on time).  IMHO early arrivals also shouldn't be propagated past stops with timepoint=1, although neither of these behaviors are currently specified in GTFS-rt, and as a result consumers will have different behavior.  

For example, OneBusAway (https://onebusaway.org/) propagates delays across blocks in the same trips, but OpenTripPlanner (http://www.opentripplanner.org/) does not.  We're using OTP for trip planning within OneBusAway, and we'd like to change OTP to match the behavior of OBA and propagate delays across trips in the same block.  We're finding that often we know a bus is running really late (e.g., 20 minutes), and a user tries to plan a journey for a trip further down the block, but OTP prevents that real-time delay from showing up in the user's trip plan until the vehicle actually running that trip.  So we show no real-time info until only a few minutes before the bus will actually arrives, at which point we suddenly show a huge delay.

Sean