Informing a passenger to arrive early at a station

[Brian Ferris]

Some transit agencies suggest that passengers should arrive at their departure station a bit earlier than their scheduled departure time in order to coordinate tickets, boarding, etc.  For example, Amtrak in the US suggest arriving 30 minutes early:

http://goo.gl/maps/LveP

(See the alert at each station)

We'd like to provide some way in GTFS for an agency to specify that extra time in the feed directly.

I'll admit that I'm struggling with what exactly to even name such a field.  There are a lot of potentially confusing names (early_arrival_time, passenger_arrival_time, passenger_departure_buffer, ...) and only a handful which seem possibly not confusing.  Perhaps...

passenger_boarding_time

passenger_pre_boarding_time

passenger_departure_buffer

...

How would this field be used?  In practice, we believe it could be specified in either routes.txt, trips.txt, or stops_times.txt, with each more-specific instance overriding the parent definition.  You could perhaps imagine it being specified for a stop as well.  Any itinerary passing through a stop-time that includes or inherits this value would require the passenger to be at the stop the specified number of seconds before the departure, whether initially starting the trip or arriving via some other vehicle.

If the passenger is arriving at the station via a transfer, any applicable min_transfer_time value specified in transfers.txt would override the pre-boarding time.  I'd also think a timed-transfer (transfers.txt transfer_type=1) would override this value as well, but I'm less sure.

Thoughts?  Any edge cases I am missing?

Brian

[Roger Slevin]

Check-in time is how I would refer to it

 

Roger

--
You received this message because you are subscribed to the Google Groups "General 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.

[Stuart Heinrich]

Sounds like valid information, but rather than specifying an additional absolute check-in time to go along with every single stop-time, I prefer to have a single field associated at the trip or route level to specify the recommended duration of time to show up early.  ie, 30 minutes.  It could be called something like "checkin_duration."

 

I find it unlikely that agencies would have the need to control this field on a per-stop basis, and the advantage of keeping it out of stop_times.txt is that it would be simpler, and also stop_times.txt is already the bottleneck when it comes to parsing gtfs feeds.

Brian

[Matt Conway]

I could even see this going in agency.txt. For many agencies, pre-board time is constant everywhere.

[Brian Ferris]

Thanks for the feedback everyone.  I'm leaning towards "passenger_checkin_time" for the name.  Whether I end up proposing to attach the field to agency.txt, routes.txt, trips.txt etc will largely depend on how the agencies we are working with want to use the field. I will follow up when we've made more progress on that end.  I just wanted to have a semi-reasonable name before I went any further.

Thanks,

Brian

[Guillaume]

I find this idea very relevant. Any news about it?


I would allow it in all the proposed files : agency.txt, stops.txt, routes.txt, trips.txt, and stop_times.txt.

With an additional character to specify when a "passenger_checkin_time" should override conflicting "passenger_checkin_time" in other files.
For instance "300o" would mean a 5 minutes (300 seconds) checkin time ("o" = override).

Then we have to decide which file overrides wich other file, if both have "o" passenger_chekin_times.

[Andrew Byrd]

On 06/22/2013 09:34 PM, Guillaume wrote:
> I would allow it in all the proposed files : agency.txt, stops.txt,
> routes.txt, trips.txt, and stop_times.txt.

Hopefully we can come to agreement on a proper level of granularity. I'd
rather avoid adding an optional field to five different files.
Agency-wide might be a bit too broad. Routes.txt or trips.txt would
provide a decent level of detail without inflating stop-times.txt.

> With an additional character to specify when a "passenger_checkin_time"
> should override conflicting "passenger_checkin_time" in other files.
> For instance "300o" would mean a 5 minutes (300 seconds) checkin time
> ("o" = override).
> Then we have to decide which file overrides wich other file, if both
> have "o" passenger_chekin_times.

This seems like a fair bit of added complexity for what is really a
simple addition to GTFS. One principle of GTFS is to provide only for
real use cases and avoid "pre-emptive generality" in the interest of
simplicity.

Remember, for a new optional field to actually start appearing in
transit applications, feed consumers will need to rework their GTFS
loading code. If the change is overly complex it just might not catch on.

-Andrew

[Guillaume]

OK Andrew, no problem for me. Pre-board time is the same for all stops and all trips of my agency, so folks just tell me in which file you would like to have the "passenger_checkin_time" field, and I will add it in my GTFS feed (which is currently in preview mode).

[Brian Ferris]

Hey Guillaume,

Just to keep this proposal moving, any chance you could consider adding the "passenger_checkin_time" to routes.txt for your feed?

Thanks,

Brian

--

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 post to this group, send email to gtfs-c...@googlegroups.com.

Visit this group at http://groups.google.com/group/gtfs-changes.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Guillaume]

Hello Brian,

Done, I have added the passenger_checkin_time to my routes.txt (and uploaded it to the "Partner dash" on Google Transit).

I have also added stop_amenities.txt in the files : can you help us to keep this proposal moving ? : https://Groups.Google.com/d/msg/gtfs-changes/WRB5AgTA1bI/fiDz0d_Kzh8J

Thanks in advance!

[Andrew Byrd]

Yes, routes.txt is a good place to put it. It seems unlikely that
individual trips on a route would have different advance check-in
requirements, simply because of the practical difficulty of
communicating that information to passengers.

-Andrew

On 07/11/2013 03:14 PM, Brian Ferris wrote:
> Hey Guillaume,
>
> Just to keep this proposal moving, any chance you could consider adding
> the "passenger_checkin_time" to routes.txt for your feed?
>
> Thanks,
> Brian
>
>
> On Tue, Jul 2, 2013 at 9:59 PM, Guillaume <Ri...@wanadoo.fr
> <mailto:Ri...@wanadoo.fr>> wrote:
>
> OK Andrew, no problem for me. Pre-board time is the same for all
> stops and all trips of my agency, so folks just tell me in which
> file you would like to have the "passenger_checkin_time" field, and
> I will add it in my GTFS feed (which is currently in preview mode).
>

> Le samedi 22 juin 2013 22:23:43 UTC+2, Andrew Byrd a �crit :

> <mailto:gtfs-changes%2Bunsu...@googlegroups.com>.

> To post to this group, send email to gtfs-c...@googlegroups.com

> <mailto:gtfs-c...@googlegroups.com>.

[Marcy]

I have noticed passengers using Washington State Ferries (WSF) that I need to find the footnote to arrive ~6+ min. ahead of the scheduled time before the gate closes, so that the boats depart on-time & I am on-board at least 5 min. ahead of scheduled departure. http://www.wsdot.wa.gov/Ferries/infodesk/faq/general_info/ 

I suggested they just nudge up the time for departure in their GTFS feed but we all want it to be consistent with website & printed schedule.  So... we'll need a check-in time.

I wanted to cite this proposal for WSF at this page: https://sites.google.com/site/gtfschanges/home

however I could not (yet) spot it

where can I find "the spec"

may I reconfirm the data for "passenger_check_in" is a value in seconds?  

[Brian Ferris]

There isn't an official proposal documented yet.  And I'd actually like to propose a change to the proposal ; )

Specifically, I got some feedback that it might be more clear if we named the field "passenger_checkin_duration" to make it clear that this is a time interval, as opposed to a specific time (like "arrival_time" or "departure_time").  Any thoughts?

Brian

[Roger Slevin]

Brian

 

I am with you on this one – it is a duration.

 

Roger Slevin

Traveline south east & anglia

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/CAG9YwWBFj%2BfpiHipwvy-vBCVcCAkVED-QhQh5Qn7H6fdCApbSw%40mail.gmail.com.

[Andrew Byrd]

On 07/19/2013 09:25 AM, Brian Ferris wrote:
> There isn't an official proposal documented yet. And I'd actually like
> to propose a change to the proposal ; )
>
> Specifically, I got some feedback that it might be more clear if we
> named the field "passenger_checkin_duration" to make it clear that this
> is a time interval, as opposed to a specific time (like "arrival_time"
> or "departure_time"). Any thoughts?

+1 for clear terms. This is a duration, and 'time' is used elsewhere to
mean a time of day relative to noon-minus-12h.

-Andrew

[Guillaume]

+1 for passenger_checkin_duration

[Brian Ferris]

Guillaume, any chance you'd be willing to change your feed to reflect the new name?

--

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/949cba9f-4997-49d9-9f0a-109c4de8197a%40googlegroups.com.

[Guillaume]

Done and uploaded, acquisition is in progress.

I did not know the website https://Sites.Google.com/site/gtfschanges/home ; it seems it has not been active for a few years. Should I try to use it to promote the proposal about bike sharing systems / stop amenities, or that website is not used anymore?

(I.e. is this Google group the only place to submit proposals?)

[John L]

+1 for duration,  but why even have passenger in the column identifier and not just checkin_duration. This is different than dwell time which is covered in the arrival and departure time fields.

Not that my carrier does this but I am sure regular day service without sleeper cars or berths may have an added checkin time per trip on the same route.
Coastal ferries in Norway and as described, ferries in general, board differently than a commutation type transportation. Not all trips require a checkin however.
Overnight train service is another example where baggage may need to be loaded and a berth checkin is needed but the route is the same.
Otherwise, the feed would have to chande to add a new rout with the same stops just for a diff checkin duration.

I think the value should be optional and in the trip rather than the route to garner the most flexibility.

On Jul 13, 2013 6:27 AM, "Andrew Byrd" <and...@fastmail.net> wrote:

Yes, routes.txt is a good place to put it. It seems unlikely that
individual trips on a route would have different advance check-in
requirements, simply because of the practical difficulty of
communicating that information to passengers.

-Andrew

On 07/11/2013 03:14 PM, Brian Ferris wrote:
> Hey Guillaume,
>
> Just to keep this proposal moving, any chance you could consider adding
> the "passenger_checkin_time" to routes.txt for your feed?
>
> Thanks,
> Brian
>
>
> On Tue, Jul 2, 2013 at 9:59 PM, Guillaume <Ri...@wanadoo.fr
> <mailto:Ri...@wanadoo.fr>> wrote:
>
>     OK Andrew, no problem for me. Pre-board time is the same for all
>     stops and all trips of my agency, so folks just tell me in which
>     file you would like to have the "passenger_checkin_time" field, and
>     I will add it in my GTFS feed (which is currently in preview mode).
>

[Guillaume]

+1 for "checkin_duration" instead of "passenger_checkin_duration", since GTFS is focused on passengers transit anyways.

 

Just for the record, some years ago the intercity coach network that operates where I was living, used to accept parcels onboard : one person could buy a ticket, give the parcel to the driver and get immediately down from the coach, and the driver carried the parcel until the normal (passengers) coach destination, where another person could pick up the parcel. Even more efficient and far cheaper than UPS or FedEx ;-)

But since 2001.9.11 this probably doesn't exist anymore in "western" countries...

 

 

+1 also for checkin_duration in trips.txt rather than routes.txt (since I was even in favor of an exhaustive system...)

[Brian Ferris]

+1 for "checkin_duration" as well.

As far as I'm concerned, I'm happy to let agencies specify the field in either routes.txt or trips.txt.  It adds a bit more complexity for feed consumers, but it's not prohibitive and makes feed producers' lives easier.

Brian

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/b321e2f0-d42c-4d40-b108-4e0f9af73616%40googlegroups.com.

[Brian Ferris]

I know there hasn't been much action on this thread for a while, but I wanted to let everyone know that we added support for the "checkin_duration" field in our pipeline (agency.txt / routes.txt or trips.txt as needed).  Anyone else out there want to try it out by adding it to a feed?

[Hannes Junnila]

Hi,

I'd like to revive this proposal, but with a couple of additions. We would like to have the option to specify the checkin_duration also in either stops.txt or stop_times.txt, as we are currently adding domestic flights to the GTFS-feed provided by the Finnish Transport Agency and the check-in times vary between airports and airlines.

Also, it would be useful to use this together with the proposed "cars_allowed"-field for ferries/trains, where we would need to specify different check-in times for passengers boarding by foot and by car (and possibly also a third value for bikes).

A third proposal would be to add a column "checkout_duration", which describes the minimum time to get out of the terminal after the arrival time. Specifying this as a transfer would not suffice, since that would lead to walking being preferred as the last leg, as a transfer time would be possibly longer compared to walking directly to the destination when starting immediately at the arrival time (which is not realistic).

/Hannes

>     <mailto:gtfs-changes%2Bunsubscri...@googlegroups.com>.

>     To post to this group, send email to gtfs-c...@googlegroups.com
>     <mailto:gtfs-c...@googlegroups.com>.

>     Visit this group at http://groups.google.com/group/gtfs-changes.
>     For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> --
> 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 post to this group, send email to gtfs-c...@googlegroups.com.

> Visit this group at http://groups.google.com/group/gtfs-changes.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
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 post to this group, send email to gtfs-c...@googlegroups.com.

Visit this group at http://groups.google.com/group/gtfs-changes.
For more options, visit https://groups.google.com/groups/opt_out.

[Aaron Antrim]

Quick question on terms here.

Brian -- when you wrote that Google "added support for the "checkin_duration" field in our pipeline" does that mean that if we include the checkin_duration field today, this will affect outputs in Google Maps when the data goes live?

[Brian Ferris]

To the best of my knowledge, the field is supported in production.  I seem to remember at the time that I was having difficulty finding someone with a public feed who was using the field but maybe that's changed by now?  I believe we currently only support it for routes.txt but it looks like Madison, WI is specifying it in agency.txt?

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/627de63d-cfea-4b02-b84e-3b794a66d9b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Ferris]

It seems clear that specifying checkin duration in stops_times.txt would override any value in routes.txt or stops.txt.  But what's the override semantics if checkin_duration is specified for both a stop and a route (but not in stop_times.txt)?

I'm not necessarily opposed to checkin_duration for different mode types or checkout_duration, where it makes sense.

On Sat Feb 21 2015 at 10:20:49 AM Hannes Junnila <hannes....@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/627de63d-cfea-4b02-b84e-3b794a66d9b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hannes Junnila]

I would say it is best to specify this such that there would be no
conflicts, meaning route < trip < stop_times, or even just route and
trip_times.


I'll see what I can do about a generating a public feed with these
fields included.

>>>>>>> > <mailto:gtfs-changes%2Bunsu...@googlegroups.com>.

> --
> You received this message because you are subscribed to a topic in the

> Google Groups "General Transit Feed Spec Changes" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/gtfs-changes/J5RRU7sM-EE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> gtfs-changes...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/gtfs-changes/CAG9YwWAWDfFKmhttaYJGemp1-gg5bDko3oyTsR-2oPti-eqk9Q%40mail.gmail.com.

[Joris Wu]

+1 for checkout_duration

As for the location, I would expect airline feeds to have single-hop routes and trips only, per airline. Thus, annotating the duration on either route or trip will make it apply to a specific airline on a specific airport. stop_times is in many feeds already huge.

High-speed trains such as TGV, but also Amtrak, comunicate a checkin time to the passengers. At least in PDF timetables. Thus this information has its use. Without such knowledge, journey planners will happily propose 3-minute connections from a subway to a TGV which is not working.

I vote for having both fields part of the regular spec ( optional fields, default zero minutes )

Joris