proposal: add a per-stop timezone field
60 views
Skip to first unread message
Joe Hughes
Jan 30, 2008, 11:41:59 AM1/30/08
to Google Transit Feed Spec Changes
Summary:
Add the ability to specify which timezone a stop/station is in, in
order to facilitate the specification of intercity service.
Add the ability to specify which timezone a stop/station is in, in
order to facilitate the specification of intercity service.
Motivation:
For intercity services which cross timezone boundaries, it's necessary
to determine which timezone the start and end stops are in so that a
client can display the appropriate local time at each point. While
it's theoretically possible to determine a timezone from a
latitude/longitude geocode, it's non-trivial. Attaching a timezone to
each stop makes it easier for a GTFS-consuming application to
determine the correct offset while allowing stop times to still be
specified relative to a single time zone.
Proposal:
The following field would be added to the stops.txt file:
stop_timezone (optional):
The stop_timezone field contains the timezone in which this stop or
station is located. Please refer to
http://en.wikipedia.org/wiki/List_of_tz_zones for a list of valid
values. If omitted, the stop should be assumed to be located in the
timezone specified by agency_timezone in agency.txt.
Comments?
Joe Hughes
Google
Joe Hughes
Dec 11, 2008, 3:47:38 PM12/11/08
to Google Transit Feed Spec Changes
One clarification to the proposal: the values in stop_times should
continue to be specified as time since the midnight in the
agency_timezone. That way, the time values will always increase over
the course of a trip, regardless of which time zones the trip crosses.
continue to be specified as time since the midnight in the
agency_timezone. That way, the time values will always increase over
the course of a trip, regardless of which time zones the trip crosses.
Thanks,
Joe Hughes
Google
Yuriy Yakimenko
Dec 11, 2008, 4:04:15 PM12/11/08
to gtfs-c...@googlegroups.com
Time zone has to be part of the stops file, not stop_times. I have been doing it myself for quite a while because some lines (very few) have stops across different timezones. The time in stop_times however should remain the "agency time".
Yuriy
Yuriy
Joe Hughes
Dec 11, 2008, 4:09:01 PM12/11/08
to gtfs-c...@googlegroups.com
For reference, here's a link to the entire proposal thread:
http://groups.google.com/group/gtfs-changes/browse_thread/thread/2bb9026879bf10d9
It sounds like it's consistent with your comments.
Joe
http://groups.google.com/group/gtfs-changes/browse_thread/thread/2bb9026879bf10d9
It sounds like it's consistent with your comments.
Joe
Joe Hughes
Aug 21, 2009, 8:10:35 PM8/21/09
to gtfs-c...@googlegroups.com
I wanted to propose another clarification to the interpretation of
stop_timezone, based on Google's experience testing this proposal:
"When a stop has a parent station, the stop is considered to be in the
time zone specified by the parent station's stop_timezone value. If
the parent has no stop_timezone value, the stops that belong to that
station are assumed to be the time zone specified by agency_timezone,
even if the stops have their own stop_timezone values. In other
words, if a given stop has a parent_station value, any stop_timezone
value specified for that stop is ignored."
For testing purposes, this is the way that the Google Maps importer
currently handles this field. However, if this group ultimately
decides on a different approach, Google Maps will be updated to adhere
with the final spec.
Thoughts?
Incidentally, since we've had a few updates to this proposal, I'll
post an updated proposal incorporating all the tweaks in a new thread.
Joe Hughes
Google
stop_timezone, based on Google's experience testing this proposal:
"When a stop has a parent station, the stop is considered to be in the
time zone specified by the parent station's stop_timezone value. If
the parent has no stop_timezone value, the stops that belong to that
station are assumed to be the time zone specified by agency_timezone,
even if the stops have their own stop_timezone values. In other
words, if a given stop has a parent_station value, any stop_timezone
value specified for that stop is ignored."
For testing purposes, this is the way that the Google Maps importer
currently handles this field. However, if this group ultimately
decides on a different approach, Google Maps will be updated to adhere
with the final spec.
Thoughts?
Incidentally, since we've had a few updates to this proposal, I'll
post an updated proposal incorporating all the tweaks in a new thread.
Joe Hughes
Tom Hixson
Aug 24, 2009, 3:32:27 PM8/24/09
to Google Transit Feed Spec Changes
I agree that it's either the parent or the stop, not both. And
generally a 'parent' has say over any 'child'. However here the
parent is merely a logical grouping to make the display work better--
the trip planner still uses the stops, not the parent (yes?). So I'm
ok with using the parent, but using the stop would be a 'purer' choice
(simpler too).
Tom
Sacramento
On Aug 21, 5:10 pm, Joe Hughes <joe.hughes.c...@gmail.com> wrote:
> I wanted to propose another clarification to the interpretation of
> stop_timezone, based on Google's experience testing this proposal:
>
> "When a stop has a parent station, the stop is considered to be in the
> time zone specified by the parent station's stop_timezone value. If
> the parent has no stop_timezone value, the stops that belong to that
> station are assumed to be the time zone specified by agency_timezone,
> even if the stops have their own stop_timezone values. In other
> words, if a given stop has a parent_station value, any stop_timezone
> value specified for that stop is ignored."
>
> For testing purposes, this is the way that the Google Maps importer
> currently handles this field. However, if this group ultimately
> decides on a different approach, Google Maps will be updated to adhere
> with the final spec.
>
> Thoughts?
>
> Incidentally, since we've had a few updates to this proposal, I'll
> post an updated proposal incorporating all the tweaks in a new thread.
>
> Joe Hughes
> Google
>
>
>
> On Thu, Dec 11, 2008 at 2:09 PM, Joe Hughes<joe.hughes.c...@gmail.com> wrote:
> > For reference, here's a link to the entire proposal thread:
> >http://groups.google.com/group/gtfs-changes/browse_thread/thread/2bb9...
>
> - Show quoted text -
generally a 'parent' has say over any 'child'. However here the
parent is merely a logical grouping to make the display work better--
the trip planner still uses the stops, not the parent (yes?). So I'm
ok with using the parent, but using the stop would be a 'purer' choice
(simpler too).
Tom
Sacramento
On Aug 21, 5:10 pm, Joe Hughes <joe.hughes.c...@gmail.com> wrote:
> I wanted to propose another clarification to the interpretation of
> stop_timezone, based on Google's experience testing this proposal:
>
> "When a stop has a parent station, the stop is considered to be in the
> time zone specified by the parent station's stop_timezone value. If
> the parent has no stop_timezone value, the stops that belong to that
> station are assumed to be the time zone specified by agency_timezone,
> even if the stops have their own stop_timezone values. In other
> words, if a given stop has a parent_station value, any stop_timezone
> value specified for that stop is ignored."
>
> For testing purposes, this is the way that the Google Maps importer
> currently handles this field. However, if this group ultimately
> decides on a different approach, Google Maps will be updated to adhere
> with the final spec.
>
> Thoughts?
>
> Incidentally, since we've had a few updates to this proposal, I'll
> post an updated proposal incorporating all the tweaks in a new thread.
>
> Joe Hughes
>
>
>
> On Thu, Dec 11, 2008 at 2:09 PM, Joe Hughes<joe.hughes.c...@gmail.com> wrote:
> > For reference, here's a link to the entire proposal thread:
>
> > It sounds like it's consistent with your comments.
>
> > Joe
>
> > It sounds like it's consistent with your comments.
>
> > Joe
>
> > On Thu, Dec 11, 2008 at 1:04 PM, Yuriy Yakimenko <inthes...@gmail.com> wrote:
> >> Time zone has to be part of the stops file, not stop_times. I have been
> >> doing it myself for quite a while because some lines (very few) have stops
> >> across different timezones. The time in stop_times however should remain the
> >> "agency time".
>
> >> Yuriy
>
> >> On Thu, Dec 11, 2008 at 3:47 PM, Joe Hughes <joe.hughes.c...@gmail.com>
> >> Time zone has to be part of the stops file, not stop_times. I have been
> >> doing it myself for quite a while because some lines (very few) have stops
> >> across different timezones. The time in stop_times however should remain the
> >> "agency time".
>
> >> Yuriy
>
> >> wrote:
>
> >>> One clarification to the proposal: the values in stop_times should
> >>> continue to be specified as time since the midnight in the
> >>> agency_timezone. That way, the time values will always increase over
> >>> the course of a trip, regardless of which time zones the trip crosses.
>
> >>> Thanks,
> >>> Joe Hughes
> >>> Google
>
> >>> On Wed, Jan 30, 2008 at 8:41 AM, Joe Hughes <joe.hughes.c...@gmail.com>
>
> >>> One clarification to the proposal: the values in stop_times should
> >>> continue to be specified as time since the midnight in the
> >>> agency_timezone. That way, the time values will always increase over
> >>> the course of a trip, regardless of which time zones the trip crosses.
>
> >>> Thanks,
> >>> Joe Hughes
>
> >>> wrote:
> >>> > Summary:
> >>> > Add the ability to specify which timezone a stop/station is in, in
> >>> > order to facilitate the specification of intercity service.
>
> >>> > Motivation:
> >>> > For intercity services which cross timezone boundaries, it's necessary
> >>> > to determine which timezone the start and end stops are in so that a
> >>> > client can display the appropriate local time at each point. While
> >>> > it's theoretically possible to determine a timezone from a
> >>> > latitude/longitude geocode, it's non-trivial. Attaching a timezone to
> >>> > each stop makes it easier for a GTFS-consuming application to
> >>> > determine the correct offset while allowing stop times to still be
> >>> > specified relative to a single time zone.
>
> >>> > Proposal:
> >>> > The following field would be added to the stops.txt file:
>
> >>> > stop_timezone (optional):
> >>> > The stop_timezone field contains the timezone in which this stop or
> >>> > station is located. Please refer to
> >>> >http://en.wikipedia.org/wiki/List_of_tz_zonesfor a list of valid
> >>> > Summary:
> >>> > Add the ability to specify which timezone a stop/station is in, in
> >>> > order to facilitate the specification of intercity service.
>
> >>> > Motivation:
> >>> > For intercity services which cross timezone boundaries, it's necessary
> >>> > to determine which timezone the start and end stops are in so that a
> >>> > client can display the appropriate local time at each point. While
> >>> > it's theoretically possible to determine a timezone from a
> >>> > latitude/longitude geocode, it's non-trivial. Attaching a timezone to
> >>> > each stop makes it easier for a GTFS-consuming application to
> >>> > determine the correct offset while allowing stop times to still be
> >>> > specified relative to a single time zone.
>
> >>> > Proposal:
> >>> > The following field would be added to the stops.txt file:
>
> >>> > stop_timezone (optional):
> >>> > The stop_timezone field contains the timezone in which this stop or
> >>> > station is located. Please refer to
> >>> > values. If omitted, the stop should be assumed to be located in the
> >>> > timezone specified by agency_timezone in agency.txt.
>
> >>> > Comments?
>
> >>> > Joe Hughes
> >>> > Google- Hide quoted text -
> >>> > timezone specified by agency_timezone in agency.txt.
>
> >>> > Comments?
>
> >>> > Joe Hughes
>
> - Show quoted text -
Reply all
Reply to author
Forward
0 new messages