Proposal for Formal Adoption: add "stop_timezone" field for specifying the timezone of stations and stops

99 visualizações
Pular para a primeira mensagem não lida

Brian Ferris

não lida,
23 de jan. de 2012 09:19:1323/01/2012
para gtfs-c...@googlegroups.com
I'd like to nominate the "stop_timezone" extension to stops.txt for formal adoption in the GTFS specification.

This proposal has been previously discussed in a couple of places:


To restate the most recent version of the proposal:

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 
stops and stations 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. 

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 must be ignored. 

Even if stop_timezone values are provided in stops.txt, the times in 
stop_times.txt should continue to be specified as time since midnight 
in the time zone specified by agency_timezone in agency.txt.  This 
ensures that the time values in a trip always increase over the course 
of a trip, regardless of which time zones the trip crosses. 

Adoption and Testing:

A number of agencies are using this feature.  An example of an agency using this feature with a public feed is the chemultthruway-or-us feed hosted at oregon-gtfs.com:


An example of a consumer of GTFS data using this feature is Google Maps.  Let's consider the same chemultthruway-or-us feed as an example.  Look at the Ontario, OR Greyhound Bus station schedule listed at:


Even though the stop_times.txt entry for this stop shows a scheduled time of 9:10 am in the America/Los_Angeles timezone, the Ontario stops.txt entry specifies America/Denver as its timezone, so the timetable properly lists 10:10am.

Next Steps:

I'd like to start the clock for formal adoption of this proposal in one week.  If there are no major objections to the proposal or we have consensus that proposal is reasonable, we can add the proposal at that time.  Otherwise, we can continue the discussion and figure out what's needed to get this formally adopted.

I appreciate your feedback.

Thanks,
Brian



Brian Ferris

não lida,
30 de jan. de 2012 03:42:0730/01/2012
para gtfs-c...@googlegroups.com
Just pinging the list on this proposal one last time.  I will officially add this proposed extension to the spec tomorrow unless I hear any complaints.  Speak now or forever hold your peace.

Thanks,
Brian

Brian Ferris

não lida,
2 de fev. de 2012 09:49:3402/02/2012
para gtfs-c...@googlegroups.com
Ok, hearing no complaints, I've officially added the stop_timezone proposal to the GTFS spec:


For those of you working on epic multi-timezone transit journeys, hopefully this feature will prove useful ; )

Thanks,
Brian
Responder a todos
Responder ao autor
Encaminhar
0 nova mensagem