proposal: allow interpolated times to be specified in the feed

[Mike Gilligan]

Frank Purcell at TriMet has made changes to the open source
TimeTablePublisher (http://code.google.com/p/timetablepublisher/) to
utilize the timepoint field. If it exists, TimeTablePublisher can read
the field to reduce configuration time, determining which stops are
time points, for feeds using interpolated times.

There doesn't seem to be any opposition, so I suggest we move forward
to make this a permanent change.

Read the following thread for history:
http://groups.google.com/group/gtfs-changes/browse_thread/thread/f13ab94fe78d29ec

Thanks,
Mike Gilligan
TriMet

[Joe Hughes]

That's great to hear. Can you or Frank tell us more about how the
"timepoint" stops are treated in TTP, and how it's different than the
treatment of feeds without the timepoint information? In the
proposal, marking a stop as a timepoint is equivalent to simply
specifying a time at all in the current spec--it was intended to allow
agencies to provide additional interpolated times without implying
that those times are timepoints.

Joe

[Frank]

Hey Joe,

TTPUB allows you to configure a route by selecting the stops (whether
timepoint or not) that appear in the table. The initial list of
timepoints for a table (un-configured) are derrived by looking at the
trip times and figuring out which stops have times. For both the
trimet and hart (Hampton Roads) data, all stops (rather than just the
timepoints) have a stop time associated -- so for those feeds, the
initial table (without using a timepoint field) would be really
large. To trim the fat, the timepoint flag is used, and thus the
initial timetable will look closer (if not exactly) to what the final
configured table will look like. TTPUB can then be used to further
refine the set of stops that will be published in the table, thus
making the information more concise. EG: many routes have patterns
that only visit a stop once or twice a day, so you'd want to cut those
timepoints out of the table, saving valuable realestate. And where
further instruction is needed, a footnoted trip could take the place
of an otherwise sparsely populate column.

Cheers,
Frank

On Apr 14, 10:56 am, "Joe Hughes" <joe.hughes.c...@gmail.com> wrote:
> That's great to hear. Can you or Frank tell us more about how the
> "timepoint" stops are treated in TTP, and how it's different than the
> treatment of feeds without the timepoint information? In the
> proposal, marking a stop as a timepoint is equivalent to simply
> specifying a time at all in the current spec--it was intended to allow
> agencies to provide additional interpolated times without implying
> that those times are timepoints.
>
> Joe
>

> On Fri, Apr 11, 2008 at 1:10 PM, Mike Gilligan <mgilli...@gmail.com> wrote:
>
> > Frank Purcell at TriMet has made changes to the open source
> > TimeTablePublisher (http://code.google.com/p/timetablepublisher/) to
> > utilize the timepoint field. If it exists, TimeTablePublisher can read
> > the field to reduce configuration time, determining which stops are
> > time points, for feeds using interpolated times.
>
> > There doesn't seem to be any opposition, so I suggest we move forward
> > to make this a permanent change.
>
> > Read the following thread for history:

> > http://groups.google.com/group/gtfs-changes/browse_thread/thread/f13a...
>
> > Thanks,
> > Mike Gilligan
> > TriMet

[Brian Ferris]

So here's what I know about the stop_times.txt proposal in practice.  As far as I know, these are the only public feeds including the field:

Adelaide Metro

ETran Sacramento

Hampton Roads Transit

Metro Transit - City of Madison

North County Transit District (CA)

Roseville Transit (CA)

Trimet

Yolobus

In each case, the agency is supplying arrival_time and departure_times for ALL stop_times.txt, but annotating some as timepoints.

As far as I know, the TimeTable Publisher is the only user of this field.  Google does not use it, for example.  Anyone else out there using it?

Historically, the main way of modeling timepoints has been to only specify arrival and departure times for stop_times.txt entries that are timepoints.  Anything without a time is considered to be not a timepoint, with approximate arrival and departure times.  Indeed, the official spec advises: "To ensure accurate routing, please provide arrival and departure times for all stops that are time points. Do not interpolate stops."  In practice, hundreds of agencies use this approach.

I'm a little worried about mixing the two and I'd want to flesh out the details before adopting anything.  For example, if a stop-time is annotated with timepoint=1 but no arrival_time or departure_time, what does that mean?  Is it an error?  And if the default value for timepoint when not specified is 1, how do we interpret this for all existing feeds which have unspecified arrival and departure times?  Do we generally prefer agencies use timepoint fields or unspecified arrival and departure times for indicating approximate arrival times?

Thoughts?

Brian

On Thu, Apr 18, 2013 at 11:07 PM, Aaron Priven <aa...@priven.com> wrote:

Would it be possible to get the timepoint field officially added to the GTFS spec? I know this is used a lot by a lot of feeds, but it's always easier to get people to support it if it's officially added.

Thanks,

--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andrew Byrd]

Hi,

I have also observed that in practice feeds often contain
pre-interpolated stop times for non-timepoint stops.

It is of course possible for feed consumers to interpolate stop times by
assuming constant velocity, especially when shapes are available in
shapes.txt. However, this will not necessarily give the projected stop
times used internally by the operator, which could account for traffic
speeds, signals etc. If feed producers follow the existing spec exactly,
they could be throwing away some interesting information.

Often (when shapes are not available) we must interpolate along an
unknown path assuming constant velocity. In this case having
producer-interpolated times is clearly better.

I find that the combination of stop time presence/absence with the
timepoint field is well-defined:

A) stop has no arrival or departure times
no timepoint field : times must be interpolated by feed consumer
timepoint = 0 : times must be interpolated by feed consumer
timepoint = 1 : error, warn producer and interpolate anyway

B) stop has arrival or departure times
no timepoint field : times assumed to be exact by feed consumer
timepoint = 0 : times assumed inexact by consumer
timepoint = 1 : times assumed exact by consumer

i.e. :
if the timepoint field is absent, the presence or absence of
arrival/departure times determines whether they are exact or interpolated.
if the timepoint field is present, it determines that exactness of
arrival/departure times that are present. missing departure times must
still be interpolated.

-Andrew

> (http://code.google.com/p/__timetablepublisher/
> <http://code.google.com/p/timetablepublisher/>) to

> utilize the timepoint field. If it exists, TimeTablePublisher
> can read
> the field to reduce configuration time, determining which stops are
> time points, for feeds using interpolated times.
>
> There doesn't seem to be any opposition, so I suggest we move
> forward
> to make this a permanent change.
>
> Read the following thread for history:

> http://groups.google.com/__group/gtfs-changes/browse___thread/thread/f13ab94fe78d29ec

> <http://groups.google.com/group/gtfs-changes/browse_thread/thread/f13ab94fe78d29ec>
>
>
> Thanks,
> Mike Gilligan
> TriMet
>
> --
> 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

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

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

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

[Mike Gilligan (TriMet)]

We supply interpolated times at TriMet because internally we have the concept of a pseudo-timepoint. It is a point along a trip that allows us to adjust the "constant velocity interpolation" described by Andrew. They are used strictly for interpolation between timing points and the operators are not required to adhere to the running times produced by them in the same way as “regular” timepoints.

I believe it would be possible for us to supply times at timepoints only and add stops.txt, stop_times.txt entries with drop_off_type=1 & pick_up_type=1 for the pseudo-timepoints. However, I believe adding interpolation-only non-boarding/non-alighting pseudo-timepoints to our GTFS would be more confusing than adding a new field when times are supplied for all entries.

Mike Gilligan

TriMet

[Devin Braun]

San Diego MTS uses the timepoint field as well.

 

The timepoint field has two uses for us.  The first is to show which timepoints are scheduled and not interpolated.  The second is to designate which times to specify in a timetable (the ones the bus won’t pass by early).

 

We spent a lot of money for scheduling software which does the interpolation for us.  We provide interpolated times because we can’t assume that individual developers will create valid times or that they will create even similar times between each app.  If we provide the interpolation, our passengers receive the same times, no matter what app or website they use.

 

Devin

San Diego MTS

[Dan Holmes]

I also would like the ability to provide interpolated times.  We write software that does the interpolations and it provides as Devin stated a uniform schedule for all consumers.

[Brian Ferris]

I'm +1 on Andrew's interpretation.  To clarify the original proposal text, how about the following?

To add to stop_times.txt:

timepoint: Optional. The 'timepoint' field can be used to indicate if the specified arrival and departure times for a stop are strictly adhered to by the transit vehicle or if they are instead approximate and/or interpolated times.  The field allows a GTFS producer to provide interpolated stop times that potentially incorporate local knowledge, but still indicate if the times are approximate.  For stop-time entries with specified arrival and departure times, valid values for this field are:

* empty - Times considered exact.

* 0 - Times considered approximate.

* 1 - Times considered exact.

For stop-time entries without specified arrival and departure times, feed consumers must interpolate arrival and departure times.  Feed producers may optionally indicate that such an entry is not a timepoint (value=0) but it is an error to mark a entry as a timepoint (value=1) without specifying arrival and departure times.

[Koch]

+1 on Andrew with a remark

In the Netherlands there is no concept of interpolated times but a concept where a vehicle can depart 1-2 minutes early and timingstops where a vehicle always will wait for the departuretime.

The only thing worrying is the NULL vs 0, so far in the GTFS standard NULL has been equivalent to 0 which translates in to unknown or conventional cq "the way it always used to be", this will conflict with that.

Kind regards,

Thomas Koch

Op dinsdag 23 april 2013 17:20:17 UTC+2 schreef Brian Ferris het volgende:

[Frank]

+1

[Brian Ferris]

We have some proposed text, we have some feeds producing the data, and we have a few people using the data.

I'm curious to hear more how feed consumers are actually using the field.  Aaron, what's your use case?  Do you have actual code using this field?  Mike or Frank or anybody working with TimeTablePublisher, how does the field get used in rendering timetables?

Brian

[Frank]

As others have said, having timepoint information in gtfs is a good thing that has many potential uses.  

TimeTablePublisher (TTPUB) is all about selecting what information makes it into the limited real estate of a (printed) timetable, where adding to (or more likely subtracting from) the list of stops and times being published is a primary task.  Having the timepoint flag in a feed provides TTPUB an initial set of stops that are then shaped into a timetable that's meant to be read and understood by the public.

Without the timepoint flag -- and in feeds where all stops have stop_times assigned -- the initial set of stops for a table are chosen based on an equal spacing of time (e.g., first stop of route, next stop with a stop time 10 minutes after the first stop, next stop 10 minute later, etc..., last stop of route).  The timepoint flag eliminates this klunky automatic stop selection in TTPUB.  In general, timepoint information works to highlight the most important schedule data, since it's the timepoint information that really determines the vehicle's movement over time on the route.  

[Brian Ferris]

The only reason I brought this up is that I'm currently +0.5 on this proposal, but I'd be a full +1 if I heard from at least one other person who has written code that uses the timepoint field or from someone who is using TimeTablePublisher with a timepoint feed who isn't TriMet.  Not to single out TriMet, but I'm worried that since TriMet is both producing a feed with a timepoint field and using/maintaining the software that uses that field, it's a bit of a closed loop and we haven't shown someone outside of TriMet cares enough about timepoints to write software that uses the field.

Again, I'd ask Aaron P, who resurrected this thread, to chime in.  It sounds like you were perhaps using the timepoint field from feeds in some way?  Anybody else out there using as well?  Anybody outside of TriMet using TimeTable Publisher with a timepoint-enabled feed?

[Andrew Byrd]

In the Netherlands we have operator-provided stop times for every stop,
but only some of them are designated as timepoints. We also have
real-time delay data for every vehicle. When projecting arrival times
based on real-time schedule deviation, the timepoint field allows us to
judge whether negative schedule deviations (early arrivals) will
propagate down the line or stop propagating at a particular location
(i.e. the vehicle will wait to return to schedule and regulate traffic).

Therefore the timepoint field is already being included in the OpenOV
GTFS feed, and both our real-time processing module and the routing
software we are developing will certainly use this field.

-Andrew

> �regular� timepoints.

> 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?hl=en <http://groups.google.com/group/gtfs-changes?hl=en>.
> For more options, visit
> https://groups.google.com/__grou__ps/opt_out
> <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?hl=en
> <http://groups.google.com/group/gtfs-changes?hl=en>.
> For more options, visit
> https://groups.google.com/__groups/opt_out
> <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

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

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

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

[Aaron Priven]

On Apr 26, 2013, at 6:26 AM, Brian Ferris wrote:

> The only reason I brought this up is that I'm currently +0.5 on this proposal, but I'd be a full +1 if I heard from at least one other person who has written code that uses the timepoint field or from someone who is using TimeTablePublisher with a timepoint feed who isn't TriMet. Not to single out TriMet, but I'm worried that since TriMet is both producing a feed with a timepoint field and using/maintaining the software that uses that field, it's a bit of a closed loop and we haven't shown someone outside of TriMet cares enough about timepoints to write software that uses the field.
>
> Again, I'd ask Aaron P, who resurrected this thread, to chime in. It sounds like you were perhaps using the timepoint field from feeds in some way? Anybody else out there using as well? Anybody outside of TriMet using TimeTable Publisher with a timepoint-enabled feed?
>

Sorry for the delay.

The answer is that I'm in this catch-22 position where I can't use GTFS for my code until the I receive a feed that uses the timepoint field, which it won't as long as it's just a proposal. I'm the first to agree that this shouldn't be changed based on my *current* usage, and I wouldn't have suggested it ab initio if there weren't other use cases out there. Nonetheless I genuinely believe it would make things a lot easier for many people, not just me.

Just to give you the idea of what I'm doing and why this matters, one of my main projects is to create schedules posted at stops. It is much better to provide an interpolated time than just say "the time ten blocks back is 5:15, it's up to you to guess how long it will take to get here from there." At the same time, it's important to be able to tell people "this is a scheduled time" or "this is an approximate time" since it's a different commitment on the part of the agency.

At the moment, I'm working to include a custom export from Hastus. But I would rather not do that. My code is ultimately intended to be public (you can see it now -- code.google.com/p/actium -- but it's extremely ugly at the moment, and doesn't include the databases and graphic files it depends on), but will be of very limited use if it can't use a public standard for data.

No question that, if the bar is "is this person using the field already," the answer is no. But I think a number of other people on the thread have explained that it is useful for them and would be a useful addition to the standard.

--
Aaron Priven, aa...@priven.com, apr...@actransit.org

[Brian Ferris]

On Fri, Apr 26, 2013 at 4:29 PM, Andrew Byrd <and...@fastmail.net> wrote:

> both our real-time processing module and the routing software we are developing will certainly use this field.

But just to clarify, you aren't using these fields yet? ; )

>                     “regular” timepoints.

[Sonia Morgan]

Hi all,

 

I’d also be interested in an explicit timing point field.  We’re not currently using this field but we plan to in an upcoming application.  At the moment we’ll probably derive this based on whether the times are specified, but an explicit field would clarify the intention of the transit authority.  The key issue being that if real time information is available showing the service arriving at 11:04 and the schedule is 11:10 it would be good to let the consumer know that even though the service is arriving early they will still be able to make the bus/train/etc. Although naturally the information is still relevant to scheduled data by itself.

 

I’m wondering whether the default for the new field should be “approximate times” for backwards compatibility.  For datasets which have not been upgraded to specify the new field it’s probably a lesser evil to flag a timing point as approximate than to flag an approximate time as a timing point.

 

Regards

Sonia

 

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of Brian Ferris
Sent: Tuesday, 30 April 2013 6:38 AM
To: gtfs-c...@googlegroups.com
Subject: Re: [gtfs-changes] Re: proposal: allow interpolated times to be specified in the feed

 

On Fri, Apr 26, 2013 at 4:29 PM, Andrew Byrd <and...@fastmail.net> wrote:

[Andrew Byrd]

On 04/29/2013 10:37 PM, Brian Ferris wrote:
> On Fri, Apr 26, 2013 at 4:29 PM, Andrew Byrd <and...@fastmail.net
> <mailto:and...@fastmail.net>> wrote:
>> both our real-time processing module and the routing software we are developing will certainly use this field.
>
> But just to clarify, you aren't using these fields yet? ; )

No, they are included in the feeds but we're not yet consuming them.
Considering that there seems to be a good deal of support for this
amendment, we will go ahead and use the proposed field and inform the
list when it is in active use.

-Andrew

[Brian Ferris]

Awesome, thanks!

-Andrew

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

[Brian Ferris]

Hey Andrew,

Just wanted to check to see if you guys had made any progress in using the "timepoint" field in any of your software?  Or anyone else on the list for that matter?

Thanks,

Brian

-Andrew

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

[Andrew Byrd]

On 07/11/2013 03:12 PM, Brian Ferris wrote:
> Hey Andrew,
>
> Just wanted to check to see if you guys had made any progress in using
> the "timepoint" field in any of your software? Or anyone else on the
> list for that matter?

The timepoint information is present in the ETL database but I do not
see it in the most recent OpenOV Netherlands feed. Thomas, could you add
this field to the NL GTFS feeds, after which we can add it to the GTFS
reader, then use it for calculating arrival times in our new router core?

-Andrew

[Andrew Byrd]

My mistake, the timepoint fields are indeed present in the per-operator
feeds in the Netherlands, but not in the unified feed ...because the One
Bus Away GTFS merge does not recognize the field :)

We are not yet making use of it in routing though. We should be by
mid-August at the latest.

-Andrew

[Brian Ferris]

Now that is something I can help with.  I've added support for the timepoint field to the OBA GTFS library (which should include the merge tool).  It's currently only supported in the latest SNAPSHOT version, but I'm guessing there will probably be an official release in the next week.

Brian

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

Visit this group at http://groups.google.com/group/gtfs-changes.

[Sean Barbeau]

Just wanted to revive this discussion - looks like we were waiting for additional consumers before adopting the time_point field as an official part of the spec.

Has anyone else made progress on consuming the time_point field?

Some background on my interest - PSTA (Clearwater, FL) is currently working with their AVL vendor to implement a GTFS-rt feed.  As part of this, they are changing to new software to generate their GTFS feed (so the same vendor is producing both GTFS-rt and GTFS). 

PSTA currently provides interpolated values in stop_times.txt, but the AVL vendor wants to remove this interpolated data from their GTFS, since the current GTFS spec wording makes it fairly clear that interpolated values shouldn't be included (even though there are reasons for including it, discussed earlier in this thread). 

It would be great if we could get this time_point field officially adopted so there would be some official guidance for keeping interpolated values (and adding a new time_point field) in PSTA's data.

Sean

[Brian Ferris]

I'm still not aware of someone using the field, but as a minor point, I think the proposed field name is "timepoint", not "time_point" (just want to make sure they are using the same field name if they start adding it to their feed). 

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/0732c64b-30db-450f-bca8-fa856cab5888%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Barbeau, Sean]

Whoops, thanks!  Yes, it should be “timepoint”.

 

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
Sent: Friday, May 09, 2014 4:52 PM
To: gtfs-c...@googlegroups.com
Subject: Re: [gtfs-changes] Re: proposal: allow interpolated times to be specified in the feed

 

I'm still not aware of someone using the field, but as a minor point, I think the proposed field name is "timepoint", not "time_point" (just want to make sure they are using the same field name if they start adding it to their feed). 

--
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/Ah-J9JP2rJY/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/CAG9YwWBFu4RP%3DtWZsnUbuOsNV_%2BbAS98HNPQ-Mn2VDoaB%3DTuqA%40mail.gmail.com.

[Sean Barbeau]

Brian,
Just wanted to follow up on this - are the responses at https://groups.google.com/forum/#!topic/transit-developers/157phXoYdaE enough to get the timepoint field into the spec?

Thanks,
Sean

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/0732c64b-30db-450f-bca8-fa856cab5888%40googlegroups.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 "General Transit Feed Spec Changes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gtfs-changes/Ah-J9JP2rJY/unsubscribe.

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

[Brian Ferris]

Sorry for missing the original message.  If Michael affirms that he is in fact using the timepoint field from an existing GTFS feed in a meaningful way, then yeah, let's see if we can get this finalized.

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/7ce7a558-0cef-4207-a738-1bd04e5b9d99%40googlegroups.com.

[Barbeau, Sean]

(cc’ing Mike)

 

Mike,

Please see Brian’s last post in this thread - could you provide a little more detail about how you’re using the timepoint field in your software?

 

In other words, what feature(s) is the timepoint field being used for?

 

Thanks,

Sean

 

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
Sent: Monday, June 02, 2014 10:31 AM
To: gtfs-c...@googlegroups.com
Subject: Re: [gtfs-changes] Re: proposal: allow interpolated times to be specified in the feed

 

Sorry for missing the original message.  If Michael affirms that he is in fact using the timepoint field from an existing GTFS feed in a meaningful way, then yeah, let's see if we can get this finalized.

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/0732c64b-30db-450f-bca8-fa856cab5888%40googlegroups.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 "General Transit Feed Spec Changes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gtfs-changes/Ah-J9JP2rJY/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/CAG9YwWBFu4RP%3DtWZsnUbuOsNV_%2BbAS98HNPQ-Mn2VDoaB%3DTuqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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/7ce7a558-0cef-4207-a738-1bd04e5b9d99%40googlegroups.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 "General Transit Feed Spec Changes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gtfs-changes/Ah-J9JP2rJY/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/CAG9YwWDVOgy6Mk4C-FCgH9PtJQUabSmeGT7QbEQk8qsh%3DvKN7w%40mail.gmail.com.

[Michael Smith]

This topic was also discussed on the transit-developers list so I'm repeating things here.

An additional reason for adding a timepoint field is for schedule adherence management reports. Showing data for every single stop would likely be overwhelming to the user. By having a  timepoint field the report can show only data for the more important stops.

Mike

[Brian Ferris]

I hate to be the stick-in-the-mud on this, but I'll blame it on the guardians of GTFS who came before me (ie Joe Hughes) who pushed back on my own proposals, where everyone agreed it was a good idea but no one has actually written the code to back it up.  We all agree that the timepoint field could be useful, but if it's so useful, where's the code?  I'm looking for these magic words:

"I integrated some code into my app/library/widget that reads and uses the timepoint column in a non-trivial way.  I tested it on one of the feeds that has the column and everything worked as intended."

Mike, your message on transit-developers said you were going to use the field in your new project.  How'd that go?

Brian

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

[Andrew Byrd]

On 06/02/2014 06:05 PM, 'Brian Ferris' via General Transit Feed Spec

Changes wrote:
> I hate to be the stick-in-the-mud on this, but I'll blame it on the
> guardians of GTFS who came before me (ie Joe Hughes) who pushed back on my
> own proposals, where everyone agreed it was a good idea but no one has
> actually written the code to back it up. We all agree that the timepoint
> field could be useful, but if it's so useful, where's the code? I'm
> looking for these magic words:
>
> "I integrated some code into my app/library/widget that reads and uses the
> timepoint column in a non-trivial way. I tested it on one of the feeds
> that has the column and everything worked as intended."

+1 on Brian's position here. This resistance to "theoretical"
improvements in GTFS is what keeps it lean. There's no reason to rush to
add something to the standard if it's not yet being used non-trivially
by GTFS consumers. The timepoint proposal will be quite useful for
propagating real-time delays intelligently (e.g. resetting negative
delays to zero at timepoints because drivers will wait there to get back
on schedule) but this has not been implemented yet in OpenTripPlanner. I
have made a note to do this and will be sure to email this list when it
is done.

-Andrew

[Sean Barbeau]

I agree, I'll be patient ;).

Sean

[Rodney Bunner]

On Tuesday, April 23, 2013 at 11:10:46 AM UTC-4, Devin Braun wrote:
> San Diego MTS uses the timepoint field as well.
>
>  
>
> The timepoint field has two uses for us.  The first is to show which timepoints are scheduled and not interpolated.  The second is to designate which times
> to specify in a timetable (the ones the bus won’t pass by early).
>
>  
>
> We spent a lot of money for scheduling software which does the interpolation for us.  We provide interpolated times because we can’t assume that individual
> developers will create valid times or that they will create even similar times between each app.  If we provide the interpolation, our passengers receive the same times, no matter what app or website they use.
>
>
>  
>
> Devin
>
> San Diego MTS

>
>  
>
> From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
> On Behalf Of Brian Ferris
>

> Sent: Tuesday, April 23, 2013 2:41 AM

>
> To: gtfs-c...@googlegroups.com
>
> Subject: Re: [gtfs-changes] Re: proposal: allow interpolated times to be specified in the feed
>
>  
>
>
>
>
>

> So here's what I know about the stop_times.txt proposal in practice.  As far as I know, these are the only public feeds including the field:
>
>
>
>
>  
>
>
>
>
> Adelaide Metro
>
>
>
>
> ETran Sacramento
>
>
>
>
> Hampton Roads Transit
>
>
>
>
> Metro Transit - City of Madison
>
>
>
>
> North County Transit District (CA)
>
>
>
>
> Roseville Transit (CA)
>
>
>
>
> Trimet
>
>
>
>
> Yolobus
>
>
>
>
>  
>
>
>
>
> In each case, the agency is supplying arrival_time and departure_times for ALL stop_times.txt, but annotating some as timepoints.
>
>
>
>
>  
>
>
>
>
> As far as I know, the TimeTable Publisher is the only user of this field.  Google does not use it, for example.  Anyone else out there using it?
>
>
>
>
>  
>
>
>
>
> Historically, the main way of modeling timepoints has been to only specify arrival and departure times for stop_times.txt entries that are timepoints.  Anything without a time is considered to be not a timepoint, with approximate arrival
> and departure times.  Indeed, the official spec advises: "To ensure accurate routing, please provide arrival and departure times for all stops that are time points. Do not interpolate stops."  In practice, hundreds of agencies use this approach.
>
>
>
>
>  
>
>
>
>
> I'm a little worried about mixing the two and I'd want to flesh out the details before adopting anything.  For example, if a stop-time is annotated with timepoint=1 but no arrival_time or departure_time, what does that mean?  Is it an error?
>  And if the default value for timepoint when not specified is 1, how do we interpret this for all existing feeds which have unspecified arrival and departure times?  Do we generally prefer agencies use timepoint fields or unspecified arrival and departure
> times for indicating approximate arrival times?
>
>
>
>
>  
>
>
>
>
> Thoughts?
>
>
>
>
>  
>
>
>
>
> Brian
>
>
>
>
>
>  
>
>
>
> On Thu, Apr 18, 2013 at 11:07 PM, Aaron Priven <aa...@priven.com> wrote:
>
> Would it be possible to get the timepoint field officially added to the GTFS spec? I know this is used a lot by a lot of feeds, but it's always easier to get people to support it if it's officially added.
>
>
>
>  
>
>
>
>
> Thanks,
>
>
>
> On Friday, April 11, 2008 1:10:42 PM UTC-7, Mike Gilligan (TriMet) wrote:
>
> Frank Purcell at TriMet has made changes to the open source
>
> TimeTablePublisher (http://code.google.com/p/timetablepublisher/) to
>
>
> utilize the timepoint field. If it exists, TimeTablePublisher can read
>
> the field to reduce configuration time, determining which stops are
>
> time points, for feeds using interpolated times.
>
>
>
> There doesn't seem to be any opposition, so I suggest we move forward
>
> to make this a permanent change.
>
>
>
> Read the following thread for history:
>
> http://groups.google.com/group/gtfs-changes/browse_thread/thread/f13ab94fe78d29ec
>
>
>
>
> Thanks,
>
> Mike Gilligan
>
> TriMet

>
>
> --
>
> 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-...@googlegroups.com.
>
> Visit this group at
> http://groups.google.com/group/gtfs-changes?hl=en.

>
> 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-...@googlegroups.com.
>
> Visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>  
>
>  

Hello,

This is my first post in this group so my apologies for the length. In conjunction with CUTR, my company (ServiceEdge Solutions) has developed the Florida Department of Transportation TBEST (tbest.org) transit planning software. TBEST has possessed the capability to directly import a GTFS network for several years now. We are interested in implementing functionality to generate a segmented network based on time point locations to better represent localized congestion speeds and provide TBEST users with the ability to analyze network production at the segment level.

As a background, a TBEST network is a synthesis of the GTFS in that it utilizes GTFS route, pattern and stop information to generate a GIS representation of the network and it also aggregates service attributes (trips, travel-times, service spans) into time periods (AM Peak, Off Peak, PM Peak, Night, Saturday and Sunday) so that TBEST can utilize this information in combination with Census, ACS, Employment and parcel-level land use data to forecast ridership at the stop-level by time-of-day. TBEST contains a network editor which allows users to modify the service so that planned transit service changes can be performance tested prior to implementation. TBEST also utilizes the GTFS-based network in combination with socio-economic data to perform market analysis, network accessible market analysis, FTA Title VI analysis and Comprehensive Operational Analysis.

TBEST contains a GTFS Network Import UI which allows users to specify a source GTFS zip file and from the source file TBEST will then provide a list of service_id's and GTFS routes to import into a TBEST planning scenario. In past iterations of the software, during the import process the in-vehicle travel time/speed was calculated for the extent of a pattern (shape). We realized that this pattern-level calculation was not adequately accounting for localized congestion speeds. The method to better account for local speeds plus provide TBEST users with a segmented network for enhanced segment-level analysis was to break route pattern alignments at time points and calculate travel times between time points. While the GTFS spec supports time point designation through populating arrival and departure times at time points only, in my experience few transit properties implement this scheme. The addition of the timepoint column within stop_times.txt provides a specific method for identifying time point stops and easily creating segmented networks within TBEST. We have implemented the segmentation functionality within a TBEST 4.2 beta release and tested using a recent TriMet GTFS. The full TBEST 4.2 release will be published by March 2015.

Thanks.

Rodney Bunner

[Brian Ferris]

So just to get a tl;dr on your email - you are confirming that you are using the proposed timepoint field in the latest version of TBEST, correct?

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/728fc90d-6281-4b9f-88a3-6e48d098a532%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rodney Bunner]

Yes, the timepoint field is being used in a beta release now and will be released to the general public in March.  

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.

[Brian Ferris]

Those are indeed the magic word we have been looking for.

So at this point we have GTFS feeds producing data with the timepoint field and we have at least one consumer who is using that data in a meaningful way.  I think this might be ready for formal adoption in the spec.

To recap, here is the proposed text:

To add to stop_times.txt:
timepoint: Optional. The 'timepoint' field can be used to indicate if the specified arrival and departure times for a stop are strictly adhered to by the transit vehicle or if they are instead approximate and/or interpolated times.  The field allows a GTFS producer to provide interpolated stop times that potentially incorporate local knowledge, but still indicate if the times are approximate.  For stop-time entries with specified arrival and departure times, valid values for this field are: 

* empty - Times considered exact.
* 0 - Times considered approximate.
* 1 - Times considered exact. 

For stop-time entries without specified arrival and departure times, feed consumers must interpolate arrival and departure times.  Feed producers may optionally indicate that such an entry is not a timepoint (value=0) but it is an error to mark a entry as a timepoint (value=1) without specifying arrival and departure times.

Any last-minute objections?  If not, I will start the clock on getting this adopted.

Thanks,

Brian

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/6fc3ab43-4338-465c-aa09-108dc2856972%40googlegroups.com.

[Ivan Egorov]

Brian,

No objections on my side.

I am looking for clarification how (if at all) this proposal relates to realtime feeds with respect to propagation. For example, it was earlier mentioned that in the Netherlands vehicles use some stops to catch up on schedule.

Does timepoint=1 imply that: not-on-schedule arrival does not trigger not-on-schedule departure if the arrival is not too late?

Is there a reverse situation: a stop where vehicle stays for, say, 3 minutes no matter when it arrives? Is it possible to express such situation with current GTFS or GTFS with the current proposal?

[Brian Ferris]

Unfortunately, I don't think "timepoint" is always enough to define explicitly what a vehicle that's running early or late at the stop point will do, but hopefully the default behavior should work for the majority of agencies.  The "schedule is strictly adhered to" language implies the following for me:

1) A vehicle that's running early will likely pause at a timepoint and leave at the originally scheduled time.

2) A vehicle that's running late will likely leave as close to the originally scheduled depart time as is feasible (aka layover eats up the delay).

That said, some agencies are know to have different policies, which is why someone proposed an additional extension at some point that would allow agencies to define their policy explicitly.  I think once timepoint is adopted, we would push on that extension for agencies who need it.

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/2c012b2c-5230-4f12-85f9-032b2d22dac5%40googlegroups.com.

[Brian Ferris]

Ok, hearing no objections, I'd start the clock on final approval of this proposal.  If there are no major objections between now and next Monday (Feb 2), the timepoint proposal will be officially adopted in the spec.

Thanks,

Brian

[Brian Ferris]

Well it took almost six year's from Mike's original proposal, but I'm happy to announce that the "timepoint" field has officially been added to the spec:

https://developers.google.com/transit/gtfs/reference#stop_times_timepoint_field

Thanks,

Brian

[Barbeau, Sean]

Yay! J  Better late than never.

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/6fc3ab43-4338-465c-aa09-108dc2856972%40googlegroups.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 "General Transit Feed Spec Changes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gtfs-changes/Ah-J9JP2rJY/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/CAG9YwWBKQnC1BC9cWJAS09-1E87eNmyTNwjtup9tD2wueu_mkw%40mail.gmail.com.

[Merlos]

Thanks Brian for the announcement.

At the top of the reference page (https://developers.google.com/transit/gtfs/reference), it says that was revised on June 20, 2012.  Two questions:

• What is the criteria to update that date?
• Apart from this list, is there any kind of document/summary that includes incremental changes like this one on the spec so that a developer keep track of them?

Thank you.

Best, Juan.

[Brian Ferris]

Ha true, I forgot that date was up there.

The spec has a revision history at https://developers.google.com/transit/gtfs/changes#RevisionHistory that describes each change to the spec.  That's probably more useful for tracking changes.

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/2f7a4cf0-2412-432f-896a-add4773f1b50%40googlegroups.com.

[AJ West]

A way to indicate the 'truthfulness' of timepoints was a much-needed addition to the GTFS, but I do have a few questions and I would like to request an update to the stop_times.txt documentation for clarity.

1. The documentation for arrival_time and departure_time says "If this stop isn't a time point, use an empty string value for the arrival_time and departure_time fields... Do not interpolate stops." Given that this is no longer the case, it should be indicated here that publishers may use the timepoint boolean to specify that they have interpolated or estimated these values.
   
2. Additionally, I don't think it's unreasonable that I am confused as to the nature of the following documentation sentence, which is duplicated verbatim for both arrival_time and departure_time: "You must specify arrival and departure times for the first and last stops in a trip." I would suggest that this be split into: "You must specify a departure_time for the first stop in a trip." and "You must specify an arrival_time for the last stop in a trip." The people I've been dealing with are mostly in Montreal and speak French as a first language, so it's very confusing when we're told that we must provide an arrival_time for the first stop in a trip, and a departure_time for the last stop in a trip, which is the sentiment being conveyed in that sentence. Alternatively you could add the word "respectively" to the end of the existing statement if you change the order to "You must specify departure and arrival times for the first and last stops in a trip respectively."
   
3. "Stops without arrival times will be scheduled based on the nearest preceding timed stop."
   This sentence is duplicated for both arrival_time and departure_time and I'm genuinely confused as to the behaviour of leaving either field blank. So if I want to indicate that my vehicle leaves at a particular departure_time but the arrival_time at the next stop is not known, the concept for me is being conflated with "If you don't have separate times for arrival and departure at a stop, enter the same value for arrival_time and departure_time." If I want the feed reader to know that they may project/calculate the arrival_time and/or departure_time it is not clear to me whether or not leaving either of these fields blank is valid or what's happening here. If you could please make this more clear I think everyone would appreciate it (describe the actual behaviour, and is the "nearest preceding timed stop" the nearest preceding departure_time?).

And finally my real reason for posting here: Why must the timepoint field include an arrival_time and departure_time? Presumably I should be able to provide an exact departure_time without knowing my arrival_time, which is the case for most real world use-cases (where the bus is set to depart each stop at an exact departure_time, but arrival_time is wishy-washy so the driver will wait until the scheduled departure_time at the stop). "...it is an error to mark a entry as a timepoint (value=1) without specifying arrival and departure times."

[Brian Ferris]

I'd be up for a wording change on interpolated times now that we've added the timepoint field.

As for the rest, where to start?  I agree the wording around stop_times.txt arrival_time and departure_time is not the most straightforward bit of text, but let's start with the basics.  Arrival and departure time are both required fields (except when they are not...).  I think you'd agree that in most cases it's useful to know both when the vehicle is arriving and departing for a particular stop (I'll come to your point about approximate arrival times shortly).  So the spec makes them both required by default.

The spec does let you leave arrival/departure time blank if you would otherwise be interpolating the times because it's a non-timepoint stop.  As you rightly point out, we can probably relax this language now that we have explicit timepoint support in the spec.  However, we've still got plenty of feeds that use this convention and will probably continue to do so.  I think you'd agree that to do interpolation, you definitely need a start and end time for the trip.  If you combine the "both arrival and departure time are required" with "you must specify a trip start and end time", you get "You must specify arrival and departure times for the first and last stops in a trip" as result.

Every so often, someone points out that you don't technically need an arrival time for the first stop in a trip or departure time for the last stop.  I think that's potentially true in some cases, but not all.  For example, if the trip is linked via a block transfer, then suddenly it matters very much what the incoming arrival time and outgoing departure times are.  Instead of making the spec a nest of exceptions ("Departure time is required for the first stop in a trip.  Generally, arrival time must always be specified if departure time is specified.  However, it may be omitted for the first stop in a trip if the trip is not linked to another incoming trip via block transfer.") I think it's just simpler to make arrival/departure time both required for the first/last stop.

But to your larger point, could we have some way of indicating that an arrival time is only approximate?  I'm not opposed to that.  I'm hesitant to implement it by leaving arrival time blank and departure time specified because I think there are a lot of existing GTFS parser that assume either both are specified or neither are.

Also, I agree that language about "Stops without arrival times will be scheduled based on the nearest preceding timed stop." is definitely confusing, especially in the departure_time field (that must be a typo).  I think what this text is trying to say is if you don't specify an arrival/departure time, times will be interpolated from the surrounding stop-times.  The interpolation strategy is left up to the client, but some clients might take a very conservative approach.  For example, if you have the following trip:

stop_id,arrival_time,departure_time

A,09:00:00,09:00:00

B,,

C,09:30:00,09:30:00

You might try to interpolate the arrival/time at B based on it's relative location between A and C.  Or, you might take an extremely conservative approach and say "If you want to depart from B, you should be at the stop at 9:00 am because that's the most conservative departure bound."  This is actually the approach used by Google Maps and I think some of that implementation detail snuck into the spec.  I'm all for trying to refine that language.

Brian

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/ef5ab12b-3178-4c39-93d3-5eae13d90342%40googlegroups.com.

[Marcy]

My understanding & use of the split on arrive/depart offers the trip or service to HOLD at a stop (for a break, transfer center loading, etc.). I'll trust and always appreciate creative solutions that are backwards compatible, and appreciate the efforts for more precise language. ~Marcy

[Stefan de Konink]

On Friday, September 25, 2015 7:41:04 PM CEST, AJ West wrote:
> Do you (or anyone) have an example where the arrival_time is
> used for the first stop in a trip for an actual function? Or by
> the same token, where the last stop's departure time is used for
> any practical purpose?

A train arrives at a terminus station. Its first arrival time allows new
passengers to board in time, and obviously a departure time when the train
moves to the second station.

--
Stefan

[AJ West]

Sorry that was a cached message I accidentally posted and so I removed it. I understand that a transfer block can connect trips and then the arrival_time for the first stop in that next trip makes sense. Thanks everyone for the clarification here.