proposal: add is_live field to routes.txt
15 views
Skip to first unread message
SamTrans...@gmail.com
Dec 11, 2007, 1:00:40 PM12/11/07
to Google Transit Feed Spec Changes
Summary:
Add is_live field to routes.txt for new routes that are being tested
for inclusion.
Motivation:
We wanted to start adding our Caltrain Shuttles to the feed. However,
we do not want to make this information "live" until it has been
reviewed and tested for accuracy.
The addition of this field would allow us, the feed providers, the
ability to control when a route in construction becomes "live".
Proposal:
The following field would be added to the routes.txt file:
is_live (optional):
The field would be an integer.
0 = Preview Mode
1 = Live or Production (default if field is not included in
routes.txt).
Testing:
Testing of this functionality could be similar to the current process.
Any routes where the is_live value is 0 will only appear when the feed
provider is logged in under the specified Gmail account. Otherwise,
the associated route will not be included in the itinerary.
Thanks.
Add is_live field to routes.txt for new routes that are being tested
for inclusion.
Motivation:
We wanted to start adding our Caltrain Shuttles to the feed. However,
we do not want to make this information "live" until it has been
reviewed and tested for accuracy.
The addition of this field would allow us, the feed providers, the
ability to control when a route in construction becomes "live".
Proposal:
The following field would be added to the routes.txt file:
is_live (optional):
The field would be an integer.
0 = Preview Mode
1 = Live or Production (default if field is not included in
routes.txt).
Testing:
Testing of this functionality could be similar to the current process.
Any routes where the is_live value is 0 will only appear when the feed
provider is logged in under the specified Gmail account. Otherwise,
the associated route will not be included in the itinerary.
Thanks.
Joe Hughes
Dec 11, 2007, 3:12:45 PM12/11/07
to gtfs-c...@googlegroups.com
Thanks for the proposal. While this would clearly help in the
situation in which you only want to check strictly new routes, I think
it could cause complications in cases where you wanted to preview
updates to existing routes. Basically, you'd need to create duplicate
entries for the existing routes that you were changing (and then take
them out when you were ready to make them "live"), which seems
error-prone.
situation in which you only want to check strictly new routes, I think
it could cause complications in cases where you wanted to preview
updates to existing routes. Basically, you'd need to create duplicate
entries for the existing routes that you were changing (and then take
them out when you were ready to make them "live"), which seems
error-prone.
It seems like previewing an entirely separate feed file would be
safer, not to mention easier to generate & maintain. What do you (and
others in the group) think?
Joe Hughes
Google
Devin Braun
Dec 11, 2007, 5:58:18 PM12/11/07
to Google Transit Feed Spec Changes
Hi Joe,
I agree that it would be more beneficial to have an entire version in
testing.
Just in regard to San Diego's feed, a testing version would have been
helpful in three cases so far:
1) Implementing a new fare structure without being able to test to
see if fares would be properly calculated.
2) Implementing shapes without seeing how the data would be viewed.
3) Making changes to the way the text for route and trip information
is viewed in the trip planner and showing it to agency staff without
implementing first.
The Feed Validator and Feed Viewer don't allow you to do itinerary
testing. As a result, it's a difficult step for agencies with live
feeds to implement new features or add functionality (such as shapes
or fares) to the feed without knowing how the changes will affect the
feed. The changes go live and affect everyone using the application
if the version of the feed that is changed is the one the customer is
planning trips against.
I would also suggest an "Agency Control Panel" where an agency would
be able to see what versions of their feed are live, what date the
feed was grabbed, what version the maps bus stops layer is using, and
also to submit notice that a new version of feed is ready to be
grabbed.
Devin Braun
San Diego MTS
On Dec 11, 12:12 pm, "Joe Hughes" <joe.hughes.c...@gmail.com> wrote:
> Thanks for the proposal. While this would clearly help in the
> situation in which you only want to check strictly new routes, I think
> it could cause complications in cases where you wanted to preview
> updates to existing routes. Basically, you'd need to create duplicate
> entries for the existing routes that you were changing (and then take
> them out when you were ready to make them "live"), which seems
> error-prone.
>
> It seems like previewing an entirely separate feed file would be
> safer, not to mention easier to generate & maintain. What do you (and
> others in the group) think?
>
> Joe Hughes
> Google
>
>
> - Show quoted text -
I agree that it would be more beneficial to have an entire version in
testing.
Just in regard to San Diego's feed, a testing version would have been
helpful in three cases so far:
1) Implementing a new fare structure without being able to test to
see if fares would be properly calculated.
2) Implementing shapes without seeing how the data would be viewed.
3) Making changes to the way the text for route and trip information
is viewed in the trip planner and showing it to agency staff without
implementing first.
The Feed Validator and Feed Viewer don't allow you to do itinerary
testing. As a result, it's a difficult step for agencies with live
feeds to implement new features or add functionality (such as shapes
or fares) to the feed without knowing how the changes will affect the
feed. The changes go live and affect everyone using the application
if the version of the feed that is changed is the one the customer is
planning trips against.
I would also suggest an "Agency Control Panel" where an agency would
be able to see what versions of their feed are live, what date the
feed was grabbed, what version the maps bus stops layer is using, and
also to submit notice that a new version of feed is ready to be
grabbed.
Devin Braun
San Diego MTS
On Dec 11, 12:12 pm, "Joe Hughes" <joe.hughes.c...@gmail.com> wrote:
> Thanks for the proposal. While this would clearly help in the
> situation in which you only want to check strictly new routes, I think
> it could cause complications in cases where you wanted to preview
> updates to existing routes. Basically, you'd need to create duplicate
> entries for the existing routes that you were changing (and then take
> them out when you were ready to make them "live"), which seems
> error-prone.
>
> It seems like previewing an entirely separate feed file would be
> safer, not to mention easier to generate & maintain. What do you (and
> others in the group) think?
>
> Joe Hughes
>
> On 12/11/07, SamTransCaltr...@gmail.com <SamTransCaltr...@gmail.com> wrote:
>
>
>
>
>
> > Summary:
>
> > Add is_live field to routes.txt for new routes that are being tested
> > for inclusion.
>
> > Motivation:
>
> > We wanted to start adding our Caltrain Shuttles to the feed. However,
> > we do not want to make this information "live" until it has been
> > reviewed and tested for accuracy.
>
> > The addition of this field would allow us, the feed providers, the
> > ability to control when a route in construction becomes "live".
>
> > Proposal:
>
> > The following field would be added to the routes.txt file:
> > is_live (optional):
>
> > The field would be an integer.
>
> > 0 = Preview Mode
> > 1 = Live or Production (default if field is not included in
> > routes.txt).
>
> > Testing:
>
> > Testing of this functionality could be similar to the current process.
> > Any routes where the is_live value is 0 will only appear when the feed
> > provider is logged in under the specified Gmail account. Otherwise,
> > the associated route will not be included in the itinerary.
>
> > Thanks.- Hide quoted text -
>
>
>
>
>
> > Summary:
>
> > Add is_live field to routes.txt for new routes that are being tested
> > for inclusion.
>
> > Motivation:
>
> > We wanted to start adding our Caltrain Shuttles to the feed. However,
> > we do not want to make this information "live" until it has been
> > reviewed and tested for accuracy.
>
> > The addition of this field would allow us, the feed providers, the
> > ability to control when a route in construction becomes "live".
>
> > Proposal:
>
> > The following field would be added to the routes.txt file:
> > is_live (optional):
>
> > The field would be an integer.
>
> > 0 = Preview Mode
> > 1 = Live or Production (default if field is not included in
> > routes.txt).
>
> > Testing:
>
> > Testing of this functionality could be similar to the current process.
> > Any routes where the is_live value is 0 will only appear when the feed
> > provider is logged in under the specified Gmail account. Otherwise,
> > the associated route will not be included in the itinerary.
>
>
> - Show quoted text -
miken
Dec 12, 2007, 6:30:52 AM12/12/07
to Google Transit Feed Spec Changes
I support the idea of separating a testing environment from the
public facing production system. All the journey planning systems
(transit and road based) I have been associated with have had a
testing environment that has allowed the bugs with new features or
major changes to data to be ironed out before being rolled out to the
public. The log in system provides a simple way of selecting testing
or production and is already used to bring in new agencies.
We currently add a pseudo journey, which is very unlikely ever to be
displayed to the public, to track which version of the data is in use.
A more up-front approach displaying the date of creation and possibly
period of validity of the data to the public would be very welcome. I
suggest a date_of_creation field is added to agency.txt.
Mike Ness
> > - Show quoted text -- Hide quoted text -
public facing production system. All the journey planning systems
(transit and road based) I have been associated with have had a
testing environment that has allowed the bugs with new features or
major changes to data to be ironed out before being rolled out to the
public. The log in system provides a simple way of selecting testing
or production and is already used to bring in new agencies.
We currently add a pseudo journey, which is very unlikely ever to be
displayed to the public, to track which version of the data is in use.
A more up-front approach displaying the date of creation and possibly
period of validity of the data to the public would be very welcome. I
suggest a date_of_creation field is added to agency.txt.
Mike Ness
SamTrans...@gmail.com
Dec 12, 2007, 11:10:26 AM12/12/07
to Google Transit Feed Spec Changes
Hi,
As for my original suggest, when we were first creating the feed for
our Caltrain service, we were able to see the connections made to
those services that have already been made public.
The proposal was not to add duplicate data. In the case you used, any
existing routes would be marked "live". Both types of information,
those being created/tested and those that have already been made
public, are contained in the same GTFS file.
If a separate test environment can be provided, that would be much
more ideal... That would allow us to test changes to existing
published services, create/test new services and see a preview of
shape files (for those that include shape files).
Thanks.
As for my original suggest, when we were first creating the feed for
our Caltrain service, we were able to see the connections made to
those services that have already been made public.
The proposal was not to add duplicate data. In the case you used, any
existing routes would be marked "live". Both types of information,
those being created/tested and those that have already been made
public, are contained in the same GTFS file.
If a separate test environment can be provided, that would be much
more ideal... That would allow us to test changes to existing
published services, create/test new services and see a preview of
shape files (for those that include shape files).
Thanks.
> Thanks for the proposal. While this would clearly help in the
> situation in which you only want to check strictly new routes, I think
> it could cause complications in cases where you wanted to preview
> updates to existing routes. Basically, you'd need to create duplicate
> entries for the existing routes that you were changing (and then take
> them out when you were ready to make them "live"), which seems
> error-prone.
>
> It seems like previewing an entirely separate feed file would be
> safer, not to mention easier to generate & maintain. What do you (and
> others in the group) think?
>
> Joe Hughes
> Google
>
> situation in which you only want to check strictly new routes, I think
> it could cause complications in cases where you wanted to preview
> updates to existing routes. Basically, you'd need to create duplicate
> entries for the existing routes that you were changing (and then take
> them out when you were ready to make them "live"), which seems
> error-prone.
>
> It seems like previewing an entirely separate feed file would be
> safer, not to mention easier to generate & maintain. What do you (and
> others in the group) think?
>
> Joe Hughes
>
> On 12/11/07, SamTransCaltr...@gmail.com <SamTransCaltr...@gmail.com> wrote:
>
>
>
>
>
> > Summary:
>
> > Add is_live field to routes.txt for new routes that are being tested
> > for inclusion.
>
> > Motivation:
>
> > We wanted to start adding our Caltrain Shuttles to the feed. However,
> > we do not want to make this information "live" until it has been
> > reviewed and tested for accuracy.
>
> > The addition of this field would allow us, the feed providers, the
> > ability to control when a route in construction becomes "live".
>
> > Proposal:
>
> > The following field would be added to the routes.txt file:
> > is_live (optional):
>
> > The field would be an integer.
>
> > 0 = Preview Mode
> > 1 = Live or Production (default if field is not included in
> > routes.txt).
>
> > Testing:
>
> > Testing of this functionality could be similar to the current process.
> > Any routes where the is_live value is 0 will only appear when the feed
> > provider is logged in under the specified Gmail account. Otherwise,
> > the associated route will not be included in the itinerary.
>
>
>
>
>
>
> > Summary:
>
> > Add is_live field to routes.txt for new routes that are being tested
> > for inclusion.
>
> > Motivation:
>
> > We wanted to start adding our Caltrain Shuttles to the feed. However,
> > we do not want to make this information "live" until it has been
> > reviewed and tested for accuracy.
>
> > The addition of this field would allow us, the feed providers, the
> > ability to control when a route in construction becomes "live".
>
> > Proposal:
>
> > The following field would be added to the routes.txt file:
> > is_live (optional):
>
> > The field would be an integer.
>
> > 0 = Preview Mode
> > 1 = Live or Production (default if field is not included in
> > routes.txt).
>
> > Testing:
>
> > Testing of this functionality could be similar to the current process.
> > Any routes where the is_live value is 0 will only appear when the feed
> > provider is logged in under the specified Gmail account. Otherwise,
> > the associated route will not be included in the itinerary.
>
Bob Heitzman
Dec 14, 2007, 11:19:32 AM12/14/07
to Google Transit Feed Spec Changes
> I agree that it would be more beneficial to have an entire version in
> testing.
>
Password access is sort of OK by another useful option for broader
testing would be a way to open the test feed to a wider test audience
- perhaps via a special URL or parameter. Providers could then direct
users to a test version with the caveats. I think I would even prefer
this option over the password protection version.
Reply all
Reply to author
Forward
0 new messages