Skip to content
This repository has been archived by the owner on Nov 30, 2023. It is now read-only.

The feed_info.txt proposal has been officially adopted #303

Closed
bdferris opened this issue Sep 26, 2014 · 3 comments
Closed

The feed_info.txt proposal has been officially adopted #303

bdferris opened this issue Sep 26, 2014 · 3 comments

Comments

@bdferris
Copy link
Contributor

From [email protected] on October 05, 2011 09:07:44

When first proposed, the feed_info.txt proposal was meant to be the primary mechanism for specifying the default language and timezone for a GTFS feed.  Unfortunately, the feed_info.txt proposal was made over three years ago.  Since that time, there has been a lot of confusion on the part of agencies because the official spec made no mention of feed_info.txt.  However, the Google extension to the feedvalidator does include the proposal and additionally mentions that agency_lang and agency_timezone should be deprecated in favor of feed_info.txt.

In order to help rectify this situation and reduce agency and developer confusion, I formalized the feed_info.txt proposal a few weeks ago: https://groups.google.com/group/gtfs-changes/browse_thread/thread/4a1d1ee28f68d86c https://code.google.com/transit/spec/transit_feed_specification.html#feed_info_txt___Field_Definitions However, there were a couple of changes between the original proposal and the officially adopted proposal.  Chief among them is the removal of the feed_timezone field in feed_info.txt.  At the time of the original proposal, it's conceivable that the required agency_timezone field could have been deprecated in favor of feed_timezone without too much pain.  In the three years since, however, a lot of GTFS consumer code has been written that expects agency_timezone to be specified, as documented in the official spec.  To that end, the GTFS community decided to keep the existing agency_timezone field as the primary way of specifying the timezone for a feed.  One point of clarification was made to the spec, however.  If multiple agencies are specified in an agency.txt file, each must have the same agency_timezone value.  This removes any ambiguity around specifying multiple default timezones for the same feed.

Because agency_lang is an optional field, feed_lang was kept in feed_info.txt.

The only other major change to feed_info.txt proposal was renaming 'feed_valid_from' and 'feed_valid_until' to 'feed_start_date' and 'feed_end_date'.

What does this mean for feedvalidator?

  1. feed_info.txt code should be moved out of the googletransit extension module into the main transitfeed module.
  2. feed_timezone validation should be removed
  3. 'feed_valid_from' and 'feed_valid_until' should be changed to 'feed_start_date' and 'feed_end_date'
  4. agency_timezone should no longer be deprecated in the googletransit extension
  5. Additionally, agency_lang should not be deprecated in the googletransit extension either.  Because so few agencies have adopted feed_info.txt in practice, specifying an agency_lang directly is still a perfectly acceptable way to indicate a feed's language, especially for feeds with just one agency.

Since these changes are significant, I'm going to break them up into a couple of different patches.

Original issue: http://code.google.com/p/googletransitdatafeed/issues/detail?id=303

@bdferris
Copy link
Contributor Author

From [email protected] on October 06, 2011 09:55:17

Initial work on removing Google Transit extension deprecation of agency_lang and agency_timezone reviewed in http://codereview.appspot.com/5169054/ and committed in r1598 .

@bdferris
Copy link
Contributor Author

From [email protected] on October 14, 2011 05:50:49

Completed work by moving feed_info.txt into the main transitfeed module, reviewed in http://codereview.appspot.com/5240052/ and committed in r1601 .

Status: Fixed

@bdferris
Copy link
Contributor Author

From [email protected] on October 24, 2011 02:38:30

(No comment was entered for this change.)

Blocking: 304

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant