Proposal: feed_info.txt
Brian Ferris
http://groups.google.com/group/gtfs-changes/browse_thread/thread/9aec66b34d22068b
Summary of proposal:
The addition would add an optional feed_info.txt section to the GTFS
spec, with the following fields:
feed_publisher_name (required):
The feed_publisher_name field contains the full name of the
organization that publishes the feed. (This may be the same as one of
the agency_name values in agency.txt.) GTFS-consuming applications
can display this name when giving attribution for a particular feed's
data.
feed_publisher_url (required):
The feed_publisher_url field contains the URL of the feed publishing
organization's website. (This may be the same as one of the
agency_url values in agency.txt.) The value must be a fully qualified
URL that includes http:// or https://, and any special characters in
the URL must be correctly escaped. See
http://www.w3.org/Addressing/URL/4_URI_Recommentations.html for a
description of how to create fully qualified URL values.
feed_timezone (required):
The feed_timezone field specifies the timezone in which the times in
the feed will be given. Any stop/stations which don't have a
stop_timezone specified are also assumed to be located in this
timezone. For feeds containing feed_info.txt, this value is used
instead of the agency_timezone values in agency.txt. Please refer to
http://en.wikipedia.org/wiki/List_of_tz_zones for a list of valid
values.
feed_lang (required):
The feed_lang field contains a IETF BCP 47 language code specifying
the default language used for the text in this feed. This setting
helps
GTFS consumers choose capitalization rules and other language-specific
settings for the feed. For an introduction to IETF BCP 47, please refer to
http://www.rfc-editor.org/rfc/bcp/bcp47.txt and
http://www.w3.org/International/articles/language-tags/.
feed_valid_from (optional)
feed_valid_until (optional):
The feed provides complete and reliable schedule information for
service in the period from the beginning of the feed_valid_from day to
the end of the feed_valid_until day. Both days are given as dates in
YYYYDDMM format as for calendar.txt, or left empty if unavailable. The
feed_valid_until date must not precede the feed_valid_from date if
both are given. Feed providers are encouraged to give schedule data
outside this period to advise of likely future service, but feed
consumers should treat it mindful of its non-authoritative status.
feed_version (optional):
The feed publisher can specify a string here that indicates which
version of their feed this is. GTFS-consuming applications can
display this value to help feed publishers determine whether the
latest version of their feed has been incorporated.
Initial implementation from a GTFS producer and consumer:
Producers: Over 6% of the feeds in the current Google Transit corpus
define an feed_info.txt file.
Consumers: The feed_info.txt file is validated in the googletransit
extension of the feed validator and used in the Google Transit
product.
Status:
There are still some questions about the semantics of feed_timezone.
Specifically, should an agency.txt:agency_timezone be allowed to
override the feed_timezone? There was a question in the original
proposal about whether there are any existing GTFS feeds with multiple
agencies and multiple timezones. I’ve verified that no agencies
currently use different timezones in the same feed against the Google
Transit corpus. This is currently not checked in the validator.
Instead, the validator checks that any timezone mentioned in
feed_info.txt matches any timezone mentioned in agency.txt and throws
an error if not. We could clarify this in the spec by stating that
feed_timezone must mach any agency_timezone value in a supplied feed
(aka they are both the same).
Unless there are objections in the next week (Sept 6), we will
formally add this proposal to the GTFS spec.
Thanks,
Brian
Joe Hughes
practice, because it contains many diverse fields. That said, as a
rare instance where the community is choosing to add a new file to the
spec, it's a rare opportunity to add new required fields (required if
the feed_info.txt file is included in a feed).
Regarding feed_timezone and agency_timezone, we should be explicit
about how they relate to each other. The simplest solution would be
to require them to both be the same when they're both present, or else
the feed is invalid.
Regarding feed_valid_from and feed_valid_until, it's worth including a
bit of detail that Arno mentioned in his original proposal (
http://groups.google.com/group/gtfs-changes/msg/c1aee20ecc7d7fd1 ):
that if these dates extend beyond the provided calendar dates, the
feed is making an assertion about dates on which there is not service.
It's also worth revisiting the names of these two fields. First,
there was feedback from Roger Slevin that he did not want to make an
assertion about how long the data he was publishing would be
"valid" (because of later service changes):
http://groups.google.com/group/gtfs-changes/msg/21e79503d9960a7e
Also, it's a bit of an odd pairing: I'd expect "from" to be matched
with "to", not "until". This reminds me of the unfortunate
"pickup_type"/"drop_off_type" pairing in the original spec.
Finally, unlike all the other fields in the spec that use a YYYYMMDD
format, they don't have "date" in the name.
Because of these reasons, I'd like to propose naming those fields
"feed_start_date" and "feed_end_date" in the official spec.
Joe
On Aug 30, 1:01 pm, Brian Ferris <bdfer...@google.com> wrote:
> Original Discussion:
>
> http://groups.google.com/group/gtfs-changes/browse_thread/thread/9aec...
> Summary of proposal:
>
> The addition would add an optional feed_info.txt section to the GTFS
> spec, with the following fields:
>
> feed_publisher_name (required):
> The feed_publisher_name field contains the full name of the
> organization that publishes the feed. (This may be the same as one of
> the agency_name values in agency.txt.) GTFS-consuming applications
> can display this name when giving attribution for a particular feed's
> data.
>
> feed_publisher_url (required):
> The feed_publisher_url field contains the URL of the feed publishing
> organization's website. (This may be the same as one of the
> agency_url values in agency.txt.) The value must be a fully qualified
> URL that includes http:// or https://, and any special characters in
>
> feed_timezone (required):
> The feed_timezone field specifies the timezone in which the times in
> the feed will be given. Any stop/stations which don't have a
> stop_timezone specified are also assumed to be located in this
> timezone. For feeds containing feed_info.txt, this value is used
>
> feed_lang (required):
> The feed_lang field contains a IETF BCP 47 language code specifying
> the default language used for the text in this feed. This setting
> helps
> GTFS consumers choose capitalization rules and other language-specific
Brian Ferris
both be the same when they're both present in agency.txt and
feed_info.txt, or else
the feed is invalid.
Regarding feed_valid_from and feed_valid_until, I'd point out that
they are both optional, so if a provider is uncomfortable setting
either value, they don't have to (I believe they were required in the
original proposal). Regarding the names, I'm not opposed to changing
them.
Brian
> --
> 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.
>
>
MVTA Users
the feed might contain data from multiple agencies which are on
different timezones. So I would argue against invalidating a feed
based on disagreement between the feed_info:feed_timezone and
agency:agency_timezone fields. How the applications deal with it is
another matter, but conceptually one could have a correct feed with
two agencies on different timezones, and somehow the application uses
the feed_info timezone to line things up properly.
But if feed_info:feed_timezone and agency:agency_timezone are required
to be the same, why have both? It goes against good database design
to have two separate fields storing exactly the same information.
Note also that the "Transit Feed Report" one receives upon manually
Fetching a New Feed already reports agency:agency_timezone as a
Deprecated Column. (As well as agency:agency_lang.) So we need to
match that application up to the decision of the mob.
Mike
Michael Abegg, Transit Planning Mgr
Minnesota Valley Transit Authority
100 Hwy 13 E
Burnsville, MN 55337
952-882-7502
mab...@mvta.com
Brian Ferris
Do you actually know of an agency pair where they would be in
different timezones? I'm definitely curious to know.
And even if we do find an agency pair with different timezones, I'm
wondering if that situation couldn't be handled by just splitting the
agencies into two separate feeds.
Brian
tompw
the basis that the lower (more specific) level should always over-ride
the higher (more general) level. To put it another way, the higher
level provides a default only.
Tom
On Aug 30, 8:01 am, Brian Ferris <bdfer...@google.com> wrote:
> Original Discussion:
>
> http://groups.google.com/group/gtfs-changes/browse_thread/thread/9aec...
> Summary of proposal:
>
> The addition would add an optional feed_info.txt section to the GTFS
> spec, with the following fields:
>
> feed_publisher_name (required):
> The feed_publisher_name field contains the full name of the
> organization that publishes the feed. (This may be the same as one of
> the agency_name values in agency.txt.) GTFS-consuming applications
> can display this name when giving attribution for a particular feed's
> data.
>
> feed_publisher_url (required):
> The feed_publisher_url field contains the URL of the feed publishing
> organization's website. (This may be the same as one of the
> agency_url values in agency.txt.) The value must be a fully qualified
> URL that includes http:// or https://, and any special characters in
>
> feed_timezone (required):
> The feed_timezone field specifies the timezone in which the times in
> the feed will be given. Any stop/stations which don't have a
> stop_timezone specified are also assumed to be located in this
> timezone. For feeds containing feed_info.txt, this value is used
>
> feed_lang (required):
> The feed_lang field contains a IETF BCP 47 language code specifying
> the default language used for the text in this feed. This setting
> helps
> GTFS consumers choose capitalization rules and other language-specific
Bernard Au
When a user sets the agency_timezone, shouldn't that be the default timezone? If so, why require another feed_timezone?
Also, if an agency passes multiple timezones (ie. Amtrak, Megabus and possibly some longer distance bus service in the Chicago area). How would this affect them?
Bernard
--
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.
--
Bernard Au, M.U.P.
Transportation Planner / Analyst.
Mike Gilligan
overwrite agency_timezone
http://groups.google.com/group/gtfs-changes/browse_thread/thread/2bb9026879bf10d9
>
> > > feed_lang (required):
> > > The feed_lang field contains a IETF BCP 47 language code specifying
> > > the default language used for the text in this feed. This setting
> > > helps
> > > GTFS consumers choose capitalization rules and other language-specific
> > > settings for the feed. For an introduction to IETF BCP 47, please refer
> > tohttp://
> > .
Bernard Au
Brian Ferris
In the first iteration of GTFS, only one agency was allowed in
agency.txt (note that it's not agencies.txt). With just one agency
and one timezone, stops could always be attached to the that timezone.
At some point, agency.txt was extended to allow multiple agencies.
But this creates an ambiguity in the spec, as its not clear which
agency (and resulting timezone) you attach a stop to.
I believe the intention of feed_info.txt:feed_timezone is to clarify
that there should be just one default timezone that applies to stops.
Regarding the relationship between feed_timezone and agency_timezone,
to me, the critical question is "Is there a need to support different
agency timezones in the same feed?"
I think it's perhaps conceptually satisfying to say 'agency_timezone'
overrides 'feed_timezone' and allow different agencies with different
timezones, but I'm not certain it's worth the trouble. I've yet to
see a compelling example of a single feed needing multiple timezones.
Thus, my vote is for requiring multiple agencies in the same feed to
all have the same timezone. This should break backwards compatibility
with any existing feeds or parsers. Regarding 'feed_timezone', it's
perhaps a bit redundant if we require the 'agency_timezone' values to
be the same. I'm not opposed to cutting it from the proposal, but I'd
be interested in hearing counter-arguments.
Also, to be clear, nothing in feed_info.txt is going to help if you
have stops in different timezones. The 'stop_timezone' proposal will
help with that and assuming no one tackles it sooner, I'm happy to
take it up after the first round of proposals ; )
Brian
Mark Backman
I wish I was around when that happened. I would have fought against
it, unless there is some compelling reason I'm unaware of. Why was
this done? This has annoyed me so much in the past, I'd almost argue
for rolling it back, although I don't want to break everything. Much
of this discussion would be moot if "agency.txt" lived up to its name.
-Mark
Mark Backman
know what problem was solved with multiple agencies in agency.txt, if
anyone remembers.
Thanks,
-Mark
On Wed, Aug 31, 2011 at 1:10 PM, Brian Ferris <bdfe...@google.com> wrote:
> Whoops, meant to say "This should NOT break backwards compatibility
> with any existing feeds or parsers."
>
>
Bernard Au
Brian Ferris
with any existing feeds or parsers."
Aaron Antrim
* allows preferred transfers to be defined between different operators
* allows stops to be shared by agencies
* group multiple agencies' stops into a single station
Derek Hofmann
Brian Ferris
Bend, Indiana) would ever be included in the same feed. They are
separate agencies and would likely publish their data as separate
feeds. In fact, NICTD is already publishing a feed, while Transpo is
not (as far as I can tell).
Just to be clear, it's tempting to imagine using GTFS as a container
for aggregating a number feeds from separate agencies into one unified
feed, but I think GTFS just wasn't designed for this. For example,
there are no guarantees about uniqueness of ids (stops, routs, trips,
etc), which makes merging arbitrary GTFS feeds dangerous. I think
you'd typically consider including more than one agency in a GTFS feed
only when the schedules for those agencies are managed in a unified
system. At that point, the difference between the agencies is more in
terms of branding than organization.
Thanks,
Brian
Bernard Au
Brian Ferris
the original decision to add feed_timezone. I think it still
basically boils down to making it more clear that there is just one
timezone per feed. If someone has a better motivating reason, I'm all
ears. If not, I'm up for changing the proposal to state
"agency_timezone must be the same for all agencies in a feed" and
removing "feed_timezone".
Brian
Bernard Au
Brian Ferris
current round.
Brian Ferris
repost the proposal with a few changes based on the discussion over
the last week. Summarizing the relevant changes:
1) Removed feed_timezone from the proposal.
2) Changed "feed_valid_from" and "feed_valid_until" to
"feed_start_date" and "feed_end_date".
3) Added explanatory text to "feed_start_date" and "feed_end_date" to
clarify that if the range extends beyond the service calendar dates,
then the feed is making an assertion about dates where there is no
service.
See the full proposal below. If there are no major comments during
the next week (until Sept 12), I'll consider consensus reached and the
proposal ready for adoptions.
Thanks,
Brian
===
The addition would add an optional feed_info.txt section to the GTFS
spec, with the following fields:
feed_publisher_name (required):
The feed_publisher_name field contains the full name of the
organization that publishes the feed. (This may be the same as one of
the agency_name values in agency.txt.) GTFS-consuming applications
can display this name when giving attribution for a particular feed's
data.
feed_publisher_url (required):
The feed_publisher_url field contains the URL of the feed publishing
organization's website. (This may be the same as one of the
agency_url values in agency.txt.) The value must be a fully qualified
URL that includes http:// or https://, and any special characters in
the URL must be correctly escaped. See
http://www.w3.org/Addressing/URL/4_URI_Recommentations.html for a
description of how to create fully qualified URL values.
feed_lang (required):
The feed_lang field contains a IETF BCP 47 language code specifying
the default language used for the text in this feed. This setting
helps GTFS consumers choose capitalization rules and other language-specific
settings for the feed. For an introduction to IETF BCP 47, please refer to
http://www.rfc-editor.org/rfc/bcp/bcp47.txt and
http://www.w3.org/International/articles/language-tags/.
feed_start_date (optional)
feed_end_date (optional):
The feed provides complete and reliable schedule information for
service in the period from the beginning of the feed_start_date day to
the end of the feed_end_date day. Both days are given as dates in
YYYYDDMM format as for calendar.txt, or left empty if unavailable. The
feed_end_date date must not precede the feed_start_date date if
both are given. Feed providers are encouraged to give schedule data
outside this period to advise of likely future service, but feed
consumers should treat it mindful of its non-authoritative status. If
feed_start_date or feed_end_date extend beyond the provided calendar
dates, the feed is making an assertion about dates on which there is
not service
feed_version (optional):
The feed publisher can specify a string here that indicates which
version of their feed this is. GTFS-consuming applications can
display this value to help feed publishers determine whether the
latest version of their feed has been incorporated.
Thanks,
Brian
On Thu, Sep 1, 2011 at 2:08 PM, Bernard Au <bernie.a...@gmail.com> wrote:
Brian Ferris
discussion about 'feed_timezone', I realized that a lot of the same
issues apply to 'feed_lang'. After looking back at the original
feed_info.txt proposal, I realized that the 'feed_lang' proposal was
actually changed at some point to add 'This value overrides any
agency_lang values in agency.txt'. At this point we're back to the
same issues as 'feed_timezone'. Namely, is the 'override' behavior
working in the expected direction? Is there ever a reason to have
agencies with different default languages in the same feed?
I think the answers are mostly the same. That is, I haven't been able
to find a GTFS feed with two agencies and more than one language
defined in the Google Transit corpus. As such, we could pretty safely
constrain the spec to say that 'agency_lang' must be the same for all
agencies if multiple agencies are defined in the same feed. And
finally, we'd come to the same conclusion that 'feed_lang' isn't
really buying us all that much and should probably be removed.
Any thoughts on this?
Thanks,
Brian
Joe Hughes
agency_timezone case: agency_lang is optional in agency.txt, but
(according to the proposal) feed_lang is required if feed_info.txt is
present. Its presence might encourage some agencies who currently
omit agency_lang to specify the base language of their feed content,
allowing clients to have a clearer understanding of which language
stop names are expressed in.
(We can't just change agency_lang to be required because that would
make existing and historical feeds invalid.)
Now, whether this makes much difference in practice is unclear, but if
memory serves, that was one reason that some people at Google were
proponents of that field.
Joe
On Sep 7, 4:59 pm, Brian Ferris <bdfer...@google.com> wrote:
> I actually have to ask a question about my own proposal. After the
> discussion about 'feed_timezone', I realized that a lot of the same
> issues apply to 'feed_lang'. After looking back at the original
> feed_info.txt proposal, I realized that the 'feed_lang' proposal was
> actually changed at some point to add 'This value overrides any
> agency_lang values in agency.txt'. At this point we're back to the
> same issues as 'feed_timezone'. Namely, is the 'override' behavior
> working in the expected direction? Is there ever a reason to have
> agencies with different default languages in the same feed?
>
> I think the answers are mostly the same. That is, I haven't been able
> to find a GTFS feed with two agencies and more than one language
> defined in the Google Transit corpus. As such, we could pretty safely
> constrain the spec to say that 'agency_lang' must be the same for all
> agencies if multiple agencies are defined in the same feed. And
> finally, we'd come to the same conclusion that 'feed_lang' isn't
> really buying us all that much and should probably be removed.
>
> Any thoughts on this?
>
> Thanks,
> Brian
>
> >> Personally having worked with different timezones for our intercity bus services, as long as stop timezone could override feed timezone, then changing it shouldn't be a problem.
>
>
> >>> Joe and I went back to see if we could find the more context around
> >>> the original decision to add feed_timezone. I think it still
> >>> basically boils down to making it more clear that there is just one
> >>> timezone per feed. If someone has a better motivating reason, I'm all
> >>> ears. If not, I'm up for changing the proposal to state
> >>> "agency_timezone must be the same for all agencies in a feed" and
> >>> removing "feed_timezone".
>
> >>> Brian
>
> >>>> With agency timezone and stop time zones adequately looking after the cross timezones for single and multiple agencies, I still don't see the benefits or justification of having a feed timezone.
>
>
> >>>>> It's not clear to me that NICTD (Northern Indiana) and Transpo (Sound
> >>>>> Bend, Indiana) would ever be included in the same feed. They are
> >>>>> separate agencies and would likely publish their data as separate
> >>>>> feeds. In fact, NICTD is already publishing a feed, while Transpo is
> >>>>> not (as far as I can tell).
>
> >>>>> Just to be clear, it's tempting to imagine using GTFS as a container
> >>>>> for aggregating a number feeds from separate agencies into one unified
> >>>>> feed, but I think GTFS just wasn't designed for this. For example,
> >>>>> there are no guarantees about uniqueness of ids (stops, routs, trips,
> >>>>> etc), which makes merging arbitrary GTFS feeds dangerous. I think
> >>>>> you'd typically consider including more than one agency in a GTFS feed
> >>>>> only when the schedules for those agencies are managed in a unified
> >>>>> system. At that point, the difference between the agencies is more in
> >>>>> terms of branding than organization.
>
> >>>>> Thanks,
> >>>>> Brian
>
> >>>>>> NICTD (mostly Central time) + Transpo (Eastern time).
>
>
> >>>>>>> Hey Mike,
>
> >>>>>>> Do you actually know of an agency pair where they would be in
> >>>>>>> different timezones? I'm definitely curious to know.
>
> >>>>>>> And even if we do find an agency pair with different timezones, I'm
> >>>>>>> wondering if that situation couldn't be handled by just splitting the
> >>>>>>> agencies into two separate feeds.
>
> >>>>>>> Brian
>
>
> read more »
Brian Ferris
question. Thanks!
Brian Ferris
proposal, I'm going to call this one as officially adopted. My next
steps on this will be to:
1) Add the updated language to the official spec change.
2) Update the feed validator to reflect these changes.
3) Reach out to any agencies already using this extension to make sure
the changes between the initial and final version of the proposal are
reflected in their feeds.
I will try to keep everyone posted as I work through this, since it's
a pretty major addition to the spec.
Thanks,
Brian
Brian Ferris
Devin Braun
Brian Ferris
--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/duF6vI4kCSMJ.