Stop early departure flag

[Yuriy Yakimenko]

Some train schedules have "train may leave early" flag. This is the
case with many NJT and Metro North schedules, for example. Often (but
not always) it's an indicator that train stops primarily to discharge
passengers. At the same time, passengers can also board the train at
these stops. I suggest adding an optional field to stop_times to
include this information. It's important when planning a trip: I don't
want to arrive at the station formally on time, only to find that
train already left and the schedule was suggesting that this can
happen.

[Tom Brown]

"train may leave early" leaves a lot of room for interpretation. I suggest that either the stop be made pickup_type=1 or use departure_time < arrival_time. The later is a little counter-intuitive but you can think of departure_time as "latest time you can arrive and be sure to see the door close" (ie a real trip planner will make sure you arrive before departure_time - planner_defined_safety_buffer) and arrival_time as "latest time door will open when everything is running perfectly" (again a trip planner should provide some padding from arrival_time to when a rider could start the next leg, even if it is at the same stop). If arrival_time < departure_time the vehicle is scheduled to wait at the stop.
A vehicle should never leave before departure_time; a late departure is harmless.
A vehicle should never arrive after arrival_time; an early arrival is harmless.
Missing these goals by more than the safety buffer can cause missed connections. I think a good range for the safety buffer is 3-8 minutes, depending on the reliability and frequency of the service and a rider's comfort with close connections. transfers.txt provides another way to control which connections are possible.

Perhaps a clarification along these lines should be added to the spec. Thoughts?

[Yuriy Yakimenko]

Listing stop departure_time < arrival_time is one way to indicate
possible early departure without introducing new fields. However, then
we should agree that the departure_time in this case becomes "soft
time". The railroads typically say the train may depart up to 5
minutes ahead of schedule for these stops.

Also, when displaying the departure time, we should stick to the
"official" time (arrival time). It would be very confusing to show
different time than indicated on paper schedules. Same applies to
planning, because in 80-90% of cases (that's my guess) trains don't
depart early.

In my software, all I do is show an "early departure" icon to warn the
user. In a way, specifying departure time 1 second before the arrival
time will be sufficient for this.

I would be very helpful to understand why railroads have "possible
early departure" stops to begin with. Anyone has an idea?

[Tom Hixson]

Sacramento has 'approximate arrives' at the end of bus commute trips.  Pickups there are rare, so we get downtown or home as fast as possible.  In this Depart<Arrive context, we publish Arrive with a warning.  Depart would be the limit of how early the arrive could be, used internally for the trip planner.

>>> "Yuriy Yakimenko" <inth...@gmail.com> 09/24/2008 7:28 PM >>>

[Greg]

> I would be very helpful to understand why railroads have "possible
> early departure" stops to begin with. Anyone has an idea?

My thought of this is when the train gets closer to the end of the
line, typically where they have the early departure stops, where
additional options exist, IE in Washington you would be crazy to pay
VRE $4.00 from Alexandria to Union Station when you can take Metro for
1/2 the cost. Most people on-board the train get frustrated when they
have to sit and wait for time and they are close to their stop.
Althought from experience anytime you are dealing with a train that
shares the tracks with other operators or freight traffic, you never
need to worry about the early departure stop it usually a few minutes
late.

That is just my thoughts and observations through.

[Aaron Antrim]

I’m emailing to revive this old discussion.

Do any feeds provide a departure_time that is earlier than arrival_time for the purpose of indicating trains that may depart from a stop early?

I don’t believe there is anything in the Spec that would prohibit this, but feed_validator flags this as an error:

Invalid value value in field departure_time. The departure time at this stop (%s) is before the arrival time (%s). This is often caused by problems in the feed exporter's time conversion (E14)

(https://github.com/google/transitfeed/wiki/FeedValidatorErrorsAndWarnings)

Metro-North includes notes on their schedules for possible early departures:

"Primarily to discharge customers. Train may depart 5 minutes earlier than the time shown."

http://web.mta.info/mnr/html/planning/schedules/ref.htm

-- 
Aaron Antrim
President & Founder
Trillium - www.trilliumtransit.com
Portland, Oregon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Google Transit Feed Spec Changes" group.
To post to this group, send email to gtfs-c...@googlegroups.com
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en
-~----------~----~----~----~------~----~------~--~---

[Stefan de Konink]

Hi,

On donderdag 23 november 2017 05:13:01 CET, Aaron Antrim wrote:
> Do any feeds provide a departure_time that is earlier than
> arrival_time for the purpose of indicating trains that may
> depart from a stop early?

If your departure is earlier, why wouldn't you update the earlier arrival
time too?

--
Stefan

[Aaron Antrim (Trillium)]

Tom Brown explained this in this post from 2008 (same thread as we're on):

"train may leave early" leaves a lot of room for interpretation. I suggest that either the stop be made pickup_type=1 or use departure_time < arrival_time. The later is a little counter-intuitive but you can think of departure_time as "latest time you can arrive and be sure to see the door close" (ie a real trip planner will make sure you arrive before departure_time - planner_defined_safety_buffer) and arrival_time as "latest time door will open when everything is running perfectly" (again a trip planner should provide some padding from arrival_time to when a rider could start the next leg, even if it is at the same stop). If arrival_time < departure_time the vehicle is scheduled to wait at the stop.
A vehicle should never leave before departure_time; a late departure is harmless.
A vehicle should never arrive after arrival_time; an early arrival is harmless.

[Stefan de Konink]

On donderdag 23 november 2017 06:57:54 CET, Aaron Antrim (Trillium) wrote:
> Tom Brown explained this in this post from 2008 (same thread as we're on):
> "train may leave early" leaves a lot of room for
> interpretation. I suggest that either the stop be made
> pickup_type=1

Pickup type is something from GTFS and can't be changed in realtime.

> or use departure_time < arrival_time. The later is
> a little counter-intuitive but you can think of departure_time
> as "latest time you can arrive and be sure to see the door
> close" (ie a real trip planner will make sure you arrive before
> departure_time - planner_defined_safety_buffer) and arrival_time
> as "latest time door will open when everything is running
> perfectly" (again a trip planner should provide some padding
> from arrival_time to when a rider could start the next leg, even
> if it is at the same stop). If arrival_time < departure_time the
> vehicle is scheduled to wait at the stop.

The semantics are invalidly "redefined" the departure time is when the
vehicle should drive, not when the passenger is lastly allowed to board.

--
Stefan

[Sean Barbeau]

I don’t like allowing stop_times.txt departure_time to be < than arrival_time.  IMHO this is a step backwards in terms of trying to enforce better feed quality, as you couldn’t tell if the producer intended this or it’s an error, and given that the GTFS validator flags this as an error it's likely to break some consumers.  I’m prefer an explicit flag or field saying that the vehicle may departure before the departure_time.

One way is the boolean "train may leave early" flag as proposed earlier in this thread.

Another possibility - I'd prefer a more specific field, something like "departure_time_uncertainty", that defines the window of time before the departure_time during which a vehicle may leave the stop.  This would allow producers to represent their local rules in the data, such as the Metro-North example mentioned above that "Train may depart 5 minutes earlier than the time shown" (i.e., departure_time_uncertainty = 300 sec).

Sean

[Andrew Byrd]

> On 23 Nov 2017, at 07:09, Stefan de Konink <ste...@konink.de> wrote:
>> or use departure_time < arrival_time. The later is a little counter-intuitive but you can think of departure_time as "latest time you can arrive and be sure to see the door close" (ie a real trip planner will make sure you arrive before departure_time - planner_defined_safety_buffer) and arrival_time as "latest time door will open when everything is running perfectly" (again a trip planner should provide some padding from arrival_time to when a rider could start the next leg, even if it is at the same stop). If arrival_time < departure_time the vehicle is scheduled to wait at the stop.
> The semantics are invalidly "redefined" the departure time is when the vehicle should drive, not when the passenger is lastly allowed to board.

GTFS and GTFS-RT are focused on passenger information (not transit operations). So actually I think it’s common for people to expect arrival and departure times from the rider perspective, i.e. when you can board or get off rather than when the vehicle will move.

Andrew

[Stefan de Konink]

From passenger perspective, do the doors close (whistle) before the
departure time, or at departure time. I think this is an less than vs equal
less than discussion.

--
Stefan

[Andrew Byrd]

On 27 Nov 2017, at 15:55, Sean Barbeau <sjba...@gmail.com> wrote:

I don’t like allowing stop_times.txt departure_time to be < than arrival_time.  IMHO this is a step backwards in terms of trying to enforce better feed quality, as you couldn’t tell if the producer intended this or it’s an error, and given that the GTFS validator flags this as an error it's likely to break some consumers.  I’m prefer an explicit flag or field saying that the vehicle may departure before the departure_time.

As much as I intuitively dislike the idea of departure_time < arrival_time (because it breaks an axiom I have long counted on in GTFS validation and routing), from a passenger information perspective the text from Tom Brown does make sense. It is however tied into a certain way of operating a network in which favors early arrivals over short and predictable boarding wait times.

The times in schedules are single numbers drawn from what are in practice probability distributions. The debate arises because we can read the times as either expected values or as “high probability” values from a tail of the distribution. 

For passengers to properly plan transfers and arrivals at important destinations, published arrival times must mean “arrives before” and published departure times must mean “departs after”. However, due to a characteristic bug/feature of our world, there is asymmetry in the level of certainty. Transportation systems are conventionally run such that published departure times mean “100% certain to depart after”, but no such certainty is ever possible about “arrival before”. You can never leave too early, but you can certainly leave too late.

The usual strategy for dealing with this asymmetry is to build sufficient slack into the schedule such that the arrival time is achieved with high probability, slowing down or waiting around to always “depart after” with 100% certainty. Our intuition that certain departure time is always later than high-probability arrival time is predicated on this operational strategy.

In the cited Metro-North case, that strategy is not applied. The stop is "Primarily to discharge customers” because this is a radial commuter line going out of a central business district into a residential area, designed for unidirectional flows of workers who value getting home 5 minutes earlier. Though it's inconvenient for trip planners, the only way to give passengers reliable information is to mark the stop as drop-off only or to specify a high-probability arrival time after the high-probability departure time.

Andrew

[Simon Jacobs]

Prediction engines will work better if GTFS models actual transit operations to some extent. To support both prediction and routing engines, I think we'd need to add an extra column as Sean suggests -- "departure_time_uncertainty". (Although my preference is a more concise name like "departure_buffer" :) ).

--Simon

[Andrew Byrd]

Hello,

Note that GTFS-RT already has an "uncertainty” field in StopTimeEvent messages.

"Uncertainty applies equally to both time and delay. The uncertainty roughly specifies the expected error in true delay (but note, we don't yet define its precise statistical meaning). It's possible for the uncertainty to be 0, for example for trains that are driven under computer timing control.”

It would be possible to provide such a column in static GTFS as well. The arrival/departure and uncertainty fields would be understood as the location and dispersion parameters of a distribution. But we would want the meaning to match that of the realtime data, so as indicated in the RT spec, we would first have to decide on the "precise statistical meaning” of the realtime data. That is to say: the uncertainty value is the dispersion parameter of which distribution? I suspect in practice these are usually very asymmetric.

Andrew

> --
> You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/b20a1375-6c52-4de3-98d1-e6bd5db745bd%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.