--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
There are holes in the data and sometimes the data is just wrong. For example, a fairly common one I'm seeing is that adjacent stops for a route may have the same arrival and departure times which is just impossible. This really screws up the view in Google Maps when trying to display it.So you have a reference point to use, you can see this for TheBus agency in Hawaii.Vehicle 103 (5587795.1031.847835)Look at stops 4 and 5 that both have arrivals at 05:47 and departures at 05:48Here is another example for the Adelaide Metro in Australia.Vehicle 118 (159606)Look at stops 3 and 4 that both have identical arrival and departure times at 05:52Are there any moderator quality checks needed by the GTFS community to say the data can be posted or is there some inherent mistake in the definitions of what these data fields are supposed to contain?I would just like to hear from everyone since I've been pulling my hair out over this and I really should only be worrying about creating the end user app and not the data quality going into it.
+1 on all 3 from me, especially on point #1.
A best practices or style guide is much needed. Having worked with GTFS data of varying ‘quality’ from a number of agencies, I have encountered the need for this many times, and so am volunteering to help.
---
Ritesh Warade
Associate Director, IBI Group
I set up a google doc a while ago to collect thoughts regarding what might go into a GTFS best practices guide and shared with a few people. Here it is: https://docs.google.com/document/d/1FeAJNDs-1EdzcQq_daq8_uR0KIug6tzKDxdPxSdi8L4/edit?usp=sharing
Please feel free to use this however you see fit.
Regards,
Ritesh
From: Ritesh Warade
Sent: Monday, November 30, 2015 4:54 PM
To: 'transit-d...@googlegroups.com' <transit-d...@googlegroups.com>
Subject: RE: [transit-developers] A question to the GTFS community
+1 on all 3 from me, especially on point #1.
A best practices or style guide is much needed. Having worked with GTFS data of varying ‘quality’ from a number of agencies, I have encountered the need for this many times, and so am volunteering to help.
---
Ritesh Warade
Associate Director, IBI Group
617.699.9544 | ritesh...@ibigroup.com
From:
transit-d...@googlegroups.com [mailto:transit-d...@googlegroups.com]
Sent: Monday, November 30, 2015 4:48 PM
To: transit-d...@googlegroups.com
Subject: Re: [transit-developers] A question to the GTFS community
1) Agreed, a Style guide would be useful. We even tried making this happen (witness the beyond-sparse GTFS Style Guide) but it turns out that getting everyone to agree on best practices is easier said than done. I ran out of cycles to work on this myself, but I think having someone drive the consensus building process is going to be unavoidable no matter where the resulting document lands.
We even tried making this happen (witness the beyond-sparse GTFS Style Guide) but it turns out that getting everyone to agree on best practices is easier said than done.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-developers+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-developers+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-developers+unsub...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
Again, I don't think the communication medium is the hard part here. That said, I don't have any problem using GitHub if we think it'd help. I'd only add that I would prefer the published Style Guide to live with the published spec, no matter the underlying update mechanism.
On Tue, Dec 1, 2015 at 7:14 AM Sean Barbeau <bar...@cutr.usf.edu> wrote:
Agreed on all three points made by Aaron.We even tried making this happen (witness the beyond-sparse GTFS Style Guide) but it turns out that getting everyone to agree on best practices is easier said than done.Brian - would we be able to move this GTFS Style Guide to Github, similar to how the GTFS-rt spec was moved there?
We might be able to use the same process with contributions/discussions happening via issues/pull requests to help flesh this out a bit.
Sean
On Monday, November 30, 2015 at 5:14:22 PM UTC-5, Ritesh Warade wrote:I set up a google doc a while ago to collect thoughts regarding what might go into a GTFS best practices guide and shared with a few people. Here it is: https://docs.google.com/document/d/1FeAJNDs-1EdzcQq_daq8_uR0KIug6tzKDxdPxSdi8L4/edit?usp=sharing
Please feel free to use this however you see fit.
Regards,
Ritesh
---
Ritesh Warade
Associate Director, IBI Group
To unsubscribe from this group and stop receiving emails from it, send an email to transit-developers+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-developers+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-developers+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-developers+unsub...@googlegroups.com.
Defining best practices here might be an exercise in futility;
+1 for Sean’s point
And the same is true for GTFS-realtime
---
Ritesh Warade
From: transit-d...@googlegroups.com [mailto:transit-d...@googlegroups.com]
On Behalf Of Sean Barbeau
Sent: Thursday, December 03, 2015 10:01 AM
To: Transit Developers <transit-d...@googlegroups.com>
Subject: Re: [transit-developers] A question to the GTFS community
Defining best practices here might be an exercise in futility;
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
Towards that problem, we (big hat-tip to Sean Barbeau) actually tried creating a Stack Overflow site for transportation developers: https://groups.google.com/d/msg/transit-developers/GSpplsQ9Xcw/Rc6l-uffBIwJUnfortunately, we weren't able to demonstrate enough usage to get out of the StackExchange incubator. Maybe that's changed in the past two years?
Hi Joris,
> It seems to me that some feeds list trips from an operator point of view, resulting in suggested transfers whilst passengers perceive a continued connection. The block_id is often either not provided or not meant to be used to reconstruct the routes from a passenger point of view ( which is complicated anyhow). GTFS does not have a well-defined way to define 2 routes, with a single vehicle serving both, flipping headsigns and letting passengers stay.
There is in fact a standard way to represent this, and you mentioned it: the block ID.
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.
> On 31 Dec 2015, at 05:58, Joa <Joachim....@gmail.com> wrote:
> Not quite. Blocks and trips in of themselves have no meaning in traveler facing capacity (a couple of exception below). Trips are vehicle trips, not passenger trips. A block is an ordered set of trips. Blocks historically are the basis for the paddles that operators pick up at "window dispatch" before they leave the yard to work the block on their shift.
I am not disputing any of the issues Joris raised.
I presume that this is because the meaning of block_id was defined before the appearance of GTFS-RT, at a time when there was no other practical use for information about the series of trips served by a single vehicle.
On 05 Jan 2016, at 04:45, Joa <Joachim....@gmail.com> wrote:I presume that this is because the meaning of block_id was defined before the appearance of GTFS-RT, at a time when there was no other practical use for information about the series of trips served by a single vehicle.Yes, there is life before GTFS-rt. Real-time tracking and traveler information systems were being built for quite some time before. There are agencies that are at gen three. TriMet built their second system a few years back. For the curious, there is a great study that the FTA did in the mid 90's that you should be able to find referenced from the materials that the EFF used in their efforts to invalidate ArrivalStar's patents.