FW: Google Transit GTFS spec for DRT--first steps
Kevin Chambers
This is the first in a series of emails I'm forwarding to the new GTFS Flexible Transit Working Group. These emails make up the initial conversation that led to the creation of the working group. I'm sending them with permission of the original senders for archival purposes, allowing new participants to the conversation to get up to speed.
From: Roger Teal [mailto:Roger...@demandtrans.com]
Sent: Tuesday, April 02, 2013 10:22 AM
To: jeff....@rtd-denver.com; Kevin Webb (kw...@conveyal.com); Kevin Chambers; Aaron Antrim (aa...@trilliumtransit.com);
bar...@cutr.usf.edu;
heather....@gmail.com
Subject: Google Transit GTFS spec for DRT--first steps
Hi Everyone:
Thanks to all of you for agreeing to participate in this informal group whose intent is to provide “industry” input to Brian Ferris at Google re extending the GTFS spec to include demand responsive services. Our members include the Chief Service Planner for a major regional transit agency (Jeff Becker of Denver RTD) which has extensive experience with DRT for general public services, including hybrid services such as “flex-point” that include significant service structuring; consultants with extensive experience in working with agencies that provide DRT services and have a mobility management focus (Heather Menninger, Kevin Chambers); consultants who have lots of experience with GTFS for fixed route transit including getting multiple agency web sites operational with the spec (Aaron Antrim, Kevin Webb); academic researchers who have lots of practical experience with IT and using GTFS for mobile apps (Sean Barbeau of USF); folks with IT experience and open source project experience with a transit and DRT focus (Chambers and Webb); and myself, who has long experience in DRT, IT, and data-related work, but am a newcomer to the GTFS world. So I think we have the collective knowledge, experience, and (hopefully) appropriate perspective to provide Google with the sort of input that can move the process of getting a GTFS spec for demand responsive services in place along at a brisk pace.
My motivation to help shepherd this collaboration with Brian Ferris stems in important part from the TCRP study that Suzanne O’Neill and I are currently conducting on the possibility of developing data standards for mobility management initiatives. Heather Menninger helped Suzanne and myself understand the importance of standardized “descriptive data” for service discovery by consumers of information and referral applications for mobility management, and it was clear that while GTFS had made possible I&R systems that could consume fixed route data in a standard format and provide a good user experience for those who wanted information about many bus services in a region, including trip planner type information, nothing like this existed for DRT service. While many mobility management initiatives go well beyond I&R and simple one-call one-click functionality, service discovery is still the basic information that everyone needs, and extending GTFS to demand responsive service seemed to be the best way to achieve this functionality. Aaron Antrim provided me with some helpful background on the GTFS process, and the timing was fortuitous when I contacted Brian Ferris to explore what it would take to get Google to move forward with a DRT spec, so here we are.
In terms of group process, I don’t see myself as a leader, but as a facilitator. My personal objective is for Google to take the lead on this, informed by our collective input to Brian Ferris. Ferris indicated when I talked to him last week that he has his own ideas about how to extend the spec, and I suspect that amongst rational, knowledgeable people there will be much convergence on what we will want in the spec and how it should be expressed. Standards processes can be easy or difficult, I would hope that this one would be easy, and I think having Google in the lead is the best way to do that. So what I would hope can come out of our own group process is some quick, mid-level consensus on the scope of the demand responsive spec, the development of low level details on data elements that should be present, but also the willingness to agree to disagree about low level details if we have consensus on structure and important data elements—and let our interaction with Google be the vehicle for working through any significant disagreements about low level details.
I expect that each of you has a slightly different conception of what should be included in a demand responsive spec, and I think that is the appropriate point at which to begin our conversation. I am going to put forth my “functional requirements” below, and would like for each of you to respond to the entire group with your view on what should be covered by the spec. Of necessity this includes the important data elements, but not precisely how they would be handled/structured by the spec. For example, service area boundaries could potentially be handled by shapes.txt, but Ferris and people who have posted on the GTFS forum have suggested a different approach. For now, those are details that as a group we can deal with in the next phase of our internal process (pre-Google interaction).
Roger
Roger F. Teal, Ph.D.
President, DemandTrans Solutions
847-256-8866 office
847-858-8028 mobile
Roger’s proposed GTFS scope:
1. Services included
a. General public dial-a-ride (many to many—pickup and drop-off locations at passenger request)
b. Restricted ridership dial-a-ride (many to many)
c. Structured demand responsive services
i. Cyclic DRT—serves single point in service area on schedule and also provides general demand responsive service (hence involves both many to many and many to one/one to many service)
ii. Feeder DRT—serves single point in service area on schedule, provides demand responsive service only to/from that point, hence many to one/one to many service only
iii. Checkpoint (other names may be used, e.g. flex-point)—serves pre-determined MULTIPLE points in service area on time window schedule, other pickup and drop-off points can be requested by passengers and will be served on demand when sufficient capacity (time, not space) available on vehicle tour. Usually a service that involves a cycle.
iv. Flex-route (also called route deviation)—serves multiple stops on a fixed route on a scheduled basis, other pickup and drop-off points can be requested by passengers and will be served on demand when sufficient slack in fixed route schedule to accommodate detour from route. Very similar in operational requirements to checkpoint services, primary difference is that checkpoint services are focused on a service area whereas flex-route services are focused on a linear route and its adjacent (rectangular) catchment area. May not be different from a spec perspective.
2. Service description data structures (high level)
a. Service name—also organizational sponsor of service
b. Service phone number to reserve trip
c. Service web site URL
i. Trip reservation URL if Web reservation option exists
d. Service area boundaries—in form of data akin to a GIS shape file where each line segment is connected to adjacent segment and is a closed shape
i. Full service area
ii. Service area zones—sub-regions of a service area that may be used to restrict service delivery during specified service hours
e. Service operating hours—day of week, service start time, service end time
i. Full service area
ii. Service area zones
f. Ridership restrictions—general public/public with individual certification required (e.g., ADA in U.S.)/organizational affiliation required (including agency name)
g. Reservations policies
i. One-time trips
1. Non-scheduled stops
a. Hours in advance of pickup that service request must be made
b. Indicator if immediate response service is required
2. Scheduled stops (cycle points, checkpoints, fixed route stops)
a. Hours in advance of scheduled time that request for delivery to non-scheduled point is required
b. Indicator if request for delivery to non-scheduled point can be made upon boarding vehicle
ii. Subscription trips
1. Available or Not Available
2. Hours in advance of service that reservation is required—same scheme as with one-time trips
h. Cancellation policies
i. Hours in advance of service delivery that cancellation request must be received
ii. Time of day restrictions on when cancellation request can be made (e.g., office hours of 8 AM to 5 PM)
i. Accessibility of service—fully accessible (all vehicles can be accessed by individuals using mobility devices)/partially accessible (some vehicles can be accessed)/accessible only to ambulatory individuals
j. Scheduled points served (similar but not identical to existing GTFS spec)
i. Service point identifier (name, ID, etc.)
ii. Route identifier—optional, only relevant for flex-route services
iii. Geo-coded coordinates for each point
iv. Service point type
1. Cycle point
2. Scheduled checkpoint
3. Non-scheduled checkpoint
4. Route stop
k. Timetables for scheduled points served (similar to existing GTFS spec, possibly identical)
i. By day of week
ii. Arrival time
iii. Departure time—will be same as arrival time for conventional fixed route stops that are part of service
l. Fares—existing GTFS functionality may be sufficient
3. Service request data structures—optional at this point from my perspective, for one-time trips only at this juncture, input to trip planners for interface to actual DRT service via GTFS-compliant API
a. Pickup address or location
b. Delivery address or location
c. Pickup request time
d. Delivery request time—optional
e. Accessible vehicle required—Y/N
f. Space type—seat, wheelchair space
g. Number of travelers
h. Service animal flag?
i. Restricted service passenger identifier—if relevant?
Kevin Chambers
This is one in a series of emails I'm forwarding to the new GTFS Flexible Transit Working Group. These emails make up the initial conversation that led to the creation of the working group. I'm sending them with permission of the original senders for archival purposes, allowing new participants to the conversation to get up to speed.
From: Becker, Jeff [mailto:Jeff....@rtd-denver.com]
Sent: Friday, April 05, 2013 8:27 AM
To: Roger Teal; Kevin Webb (kw...@conveyal.com); Kevin Chambers; Aaron Antrim (aa...@trilliumtransit.com); bar...@cutr.usf.edu; heather....@gmail.com
Subject: RE: Google Transit GTFS spec for DRT--first steps
Roger and All –
This is off to a good start and I have a few comments on Roger’s proposal and then some additions for a Trip Planner-DRT API. Item 1 covers the general range of the potential services that may be provided and items 2f thru 2i allow for this general approach where there are potentially multiple DRT providers. Items 2g and h are needed if reservations are made, so perhaps not for information and referral (I&R), but for an API only. I have some reservations about the Trip Planner being able to offer, for example, an itinerary from a scheduled cycle point connection for a spontaneous boarding (a customer is given a scheduled time for pickup in the itinerary), but only I&R for the trip to the connection because a pickup time must be booked. Partial satisfaction can sometimes be a real negative.
Denver RTD offers general public DRT using a Web-based automated scheduling system, so if there were an API we could schedule trips to the Google Trip Planner in real-time. Thus I would extend the functional flow in item 3 as follows:
Add 3j Boarding time and 3k Special notes.
1. Google Trip Planner (GTP) determines the best fixed-route paths between the requested origin and destination. Also GTP identifies if the origin and/or destination of the requested trip is within a DRT polygon and its service day and time span.
2. If both origin and destination are within the same DRT polygon, send customer/trip to DRT Web booking.
3. Need to specify a connection between fixed-route and DRT, which would be a fixed-route stop that is coincident with a DRT checkpoint. Probably the only sensible approach to begin with is a single fixed-route stop and a single scheduled checkpoint (usually a feeder cycle point) that are coincident and designated within the DRT polygon.
4. If no specified connection for origin or destination, GTP continues without DRT input. Otherwise the connection can now be at both or either end of the fixed-route portion of the trip (or even in the middle, for that matter).
5. If the connection is at the origin end (from DRT) of the trip request, then the origin location, date and time must be passed to DRT booking as a committed drop-off.
a. DRT cannot book trip.
b. DRT can book trip and passes estimated pickup time and drop-off time back to GTP. Customer must confirm? Customer ID?
c. If DRT has options, say within ± 2 hours of request, is further customer interaction allowed?
6. If the connection is at the destination end (to DRT) of the trip request, then the destination location, date and time must be passed to DRT booking as a committed pickup.
a. DRT passes the closest scheduled (cycle) times at the connection before and after the request back to GTP. No customer confirmation or ID needed; trip becomes a spontaneous pickup.
b. Not a scheduled checkpoint:
i. DRT cannot book trip.
ii. DRT books trip as committed pickup and passes estimated pickup and drop-off times back to GTP. Customer must confirm? Customer ID?
iii. If DRT has options (± 2 hours of request), is further customer interaction allowed?
- JB
Kevin Chambers
This is one in a series of emails I'm forwarding to the new GTFS Flexible Transit Working Group. These emails make up the initial conversation that led to the creation of the working group. I'm sending them with permission of the original senders for archival purposes, allowing new participants to the conversation to get up to speed.
From: Aaron Antrim [mailto:aa...@trilliumtransit.com]
Sent: Saturday, April 06, 2013 3:45 PM
To: Becker, Jeff
Cc: Roger Teal; Kevin Webb (kw...@conveyal.com); Kevin Chambers; bar...@cutr.usf.edu; heather....@gmail.com
Subject: Re: Google Transit GTFS spec for DRT--first steps
Hi Roger and all,
I have questions about our process here and I'd like to clarify them. Our discussion here is a closed email discussion, whereas it is more standard for proposals to enhance the General Transit Feed Specification (GTFS) to be considered in open, public groups.
A great example is the ongoing GTFS Fares Working Group. This is a self-selected sub-group of people from the gtfs-changes list with an interest in augmenting the capabilities of GTFS to describe transit fares. See the group welcome email for a full description of the process.
- The initial process began by inviting anyone with an interest to join the working group email list.
- Then, there was a collaborative inventory of Transit Fare Systems of the World.
- In response to the inventory, Brian Ferris created the GTFS Fare Model Proposal (in-progress).
The open process enables wide participation and capture of useful knowledge. It also generates a useful log of correspondence to trace decision processes.
Back to our process here. I would like to understand the envisioned advantage of keeping this discussion closed to a particular group, instead of conducing it through the gtfs-changes list or an open working sub-group.
Further, it would be useful to understand exactly what Brian Ferris (Google) committed to contribute. I cannot pretend to speak for Google. But, on the basis of working with the transit team for half a decade, I believe that it is unlikely Google Maps will, at least in the next several years, include services that have special eligibility requirements and are not open to the general public. One of the guidelines to govern the Spec is that "speculative features are discouraged" (see gtfs-changes charter). So for our effort to bear fruit, we need software to consume data. I see this as another reason to open up discussion.
My feedback is a little late to the game, for which I apologize. But I only now have been able to fully consider process, and believe this is probably a good discussion for the assembled group to have.
-Aaron
--
Aaron Antrim, Principal
Trillium Solutions, Inc.
www.trilliumtransit.com
Portland, Oregon
503.567.8422
Kevin Chambers
This is one in a series of emails I'm forwarding to the new GTFS Flexible Transit Working Group. These emails make up the initial conversation that led to the creation of the working group. I'm sending them with permission of the original senders for archival purposes, allowing new participants to the conversation to get up to speed.
From: Roger Teal [mailto:Roger...@demandtrans.com]
Sent: Sunday, April 07, 2013 3:00 PM
To: Aaron Antrim; Becker, Jeff
Cc: Kevin Webb (kw...@conveyal.com); Kevin Chambers; bar...@cutr.usf.edu; heather....@gmail.com
Subject: RE: Google Transit GTFS spec for DRT--first steps
Not sure where to begin on this in terms of a response. I can’t speak for Brian Ferris re why he saw some advantages in a small, highly knowledgeable group providing some initial input to him, but I will say why I see advantages in this as the first step forward.
Let me be perfectly clear at the outset—I don’t have any ideological preference for an open process or a closed process to get to a GTFS spec for demand responsive services. What I do have is a strong desire for an effective process, one which produces a spec relatively quickly that can achieve 90% approval by the relevant community. And I would submit that the current GTFS community is only one component of the relevant community, as they are focused on fixed route transit, and include few folks are have expert level knowledge about DRT. As for the DRT community itself, few of its members are even aware of the possible relevance of the GTFS process. Even fewer have the IT knowledge base—with the exception of the paratransit software vendors—to participate in a spec development process without some hand holding by those with such a knowledge base. Which is not to say that such hand holding is inappropriate, but is to emphasize that this is new territory for most of the folks who would benefit from DRT services being brought under the GTFS (to at least some extent). If others have data which would suggest that my observations are inaccurate, please bring it forward, but I think that there are a very small number of people who understand DRT and who have the background to effectively participate in a GTFS spec creation process.
So I am going to come back to my statement to Aaron in Phoenix at the APTA workshop, namely where would GTFS be without Google? And the obvious answer is nowhere. All the cool stuff that is possible with GTFS data is possible only because Google—by itself—developed the original GTFS spec. Which is why I reached out to Brian Ferris, because it seemed to me that in the current situation with no DRT data in the spec, that a leadership role for Google was the most expedient and effective way to get some forward motion for DRT in GTFS. It was my conversation with Brian that led to the notion of a small group to provide some initial input to him about scope and content of DRT elements of the spec. I am totally confident that if Google does take the lead in proposing DRT additions to the spec, it will be in conjunction with the normal community process to review, comment, propose modifications, etc. But from my perspective, there is huge benefit in Google taking the lead in proposing DRT additions to the spec, as that will insure intellectual coherence and careful thought about how the DRT elements will fit with the existing elements from the organization which effectively “owns” the spec.
It is often said that the perfect is the enemy of the good, and I’m personally not interested in a perfect process to get DRT into the GTFS. The group process I have proposed is purely about getting some useful input to Google from folks who understand DRT and how to describe its services with data, in the expectation that Google will use that input to inform an initial proposal of its own for spec additions for DRT. Aaron, if you are uncomfortable with Google taking the lead on this, then you obviously don’t need to participate and I would suggest that you communicate your concerns directly to Brian Ferris. I WANT Google to take the lead, just like I indicated in Phoenix, and just like they did when they developed this spec for fixed route services a number of years ago.
I also didn’t understand the comment about Google Maps and services not open to the general public. If Google wishes to exclude publicly sponsored DRT services that have ridership restrictions from the spec, that is totally their right—it’s their product. At the same time, that will exclude service discovery for a large number of DRT services, namely the hundreds of ADA paratransit services restricted to passengers with a qualifying disability. I don’t have a strong opinion about this, and ultimately Google will have to make the call as to whether to not include information about these services in the spec. It is precisely because of the central role of Google in this process that it seems to make most sense to look to them from the outset to take the lead with initial input from a small number of knowledgeable people, and then the audience will be immediately broadened as soon as some sort of proposal or pre-proposal is published.
Roger
Kevin Chambers
This is one in a series of emails I'm forwarding to the new GTFS Flexible Transit Working Group. These emails make up the initial conversation that led to the creation of the working group. I'm sending them with permission of the original senders for archival purposes, allowing new participants to the conversation to get up to speed.
From: Heather Visscher [mailto:heather....@gmail.com]
Sent: Tuesday, April 09, 2013 10:53 AM
To: Roger Teal
Cc: Aaron Antrim; Becker, Jeff; Kevin Webb (kw...@conveyal.com); Kevin Chambers; bar...@cutr.usf.edu; hea...@ammatransitplanning.com
Subject: Re: Google Transit GTFS spec for DRT--first steps
Greetings to all,
I have just a few comments to add to this dialogue. The first is to consider our audiences and this responds, in part to both Aaron's and Rogers's most recent comments.
I think the Google Transit audiences are likely sevearal --
1. Tech savvy aging baby boomers who are enlightened enough to think about alternatives to driving as they age, and before the must cease driving;
2. Relatives from afar, worried about connecting an aged parent with something, those adult children who are likely at quite a distance, unfamiliar with communtiy names and services that provide specialized transportation;
3. Agency or caseworker staff who are trying to help connect a consumer with available specialized transportation;
4. Newly returning vets -- many in rural areas -- trying to get into regional destinations to go the VA or to the veterans benefits offices and "can't get there from here"
5. Newly enrolling persons in Obama care who are being directed to regional health care facilities and also "can't get there from here."
So, notions of audience says several things to me. One is that moving quickly and encouraging Google to do so is worthwhile. Helping these new vets "connect" and not linger in that post-war fog and haze of isolation has merit. Their challenge, and that of other rural consumers seeking specialized transit and demand responsive transit find connections -- however imperfect -- is timely and now. Power on!
For audiences in urban settings, they may not know the mix of services available that include demand responsive transportation. And they may have no clue about what is ADA, what does that mean and how do they go about becoming ADA eligible. So the opening question or choice under Google Transit requires thought. Do you pick the Fixed Route/ Big Bus icon or is there a smaller paratransit bus icon? And when you arrive at an ADA only service -- how do the screens inform about next steps.
Finally, is there a way to help capture the requests that come in -- the origins and destinations -- to feed these back to the transit planners? This is powerful regional information and I am wondering how and if it can be shared in a very rudimentary way by Google -- corridors of travel and numbers of inquiries.
I appreciate Aaron's comments about opening up the dialogue but I would most assuredly be in the class that Roger characterizesof of those with no language for this discssion and most unlikely to be a part of it. That said, I do feel some urgency about this effort. It is needed. But thorny issues lie in the decision trees you are presenting. How and where in these processes do we send people to the ADA eligibility person at a given transit agency or the regional mobility manager? how do we manage a soft transfer for assistance in naviagating a further complexity of issues -- usually eligibility -- that reflect specialized transportation?
And yet, how powerful to identify those regions, probably still small in number, where you can actually click through to booking a trip? And if those cases are presently still few, can we nonetheless have place-holder architecture that is waiting for them when they are ready?
One final data comment - I don't think I saw in the reservation window the notion of how many days ahead can you book? Is it up to two weeks in advance? Must it be 24 or 48 hours in advance and cannot be same day? Is it same day, is this in addition to in
advance?
Thank you for including me in this exchange. Also, I have included my work email above -
hea...@ammatransitplanning.com -- in hopes that futher emails will end up in that particular "inbox."
Best,
Heather
Kevin Chambers
This is one in a series of emails I'm forwarding to the new GTFS Flexible Transit Working Group. These emails make up the initial conversation that led to the creation of the working group. I'm sending them with permission of the original senders for archival purposes, allowing new participants to the conversation to get up to speed.
From: Roger Teal [mailto:Roger...@demandtrans.com]
Sent: Tuesday, April 09, 2013 3:46 PM
To: Heather Visscher
Cc: Aaron Antrim; Becker, Jeff; Kevin Webb (kw...@conveyal.com); Kevin Chambers; bar...@cutr.usf.edu; hea...@ammatransitplanning.com
Subject: RE: Google Transit GTFS spec for DRT--first steps
Hi Everyone:
Sean Barbeau has been kind enough to set up a Google Docs site for us where we can share information in the context of this activity. He also pasted in the content from my initial email that had some ideas about spec content and structure. The link is below and I suggest that those of you who have responded via email add your contributions to that emerging document. In that way all of the content can be found in one location without going through a bunch of emails. You can also add comments similar to those in a Word document, and I suggest that you do. I will leave it to each person to figure out how to incorporate their stuff into the overall document, but at a minimum if you can create some section headings and move things around so like content is juxtaposed to like content it will be helpful. Many of Heather’s comments below, for example, could be placed in a new section with a title of her choosing, whereas others might be initial thoughts in section(s) on functionality that don’t yet exist.
https://docs.google.com/document/d/1hB5ItKLWRtMQ4Iuap9wk9NwvzQRC7LQVPht_9oySO2M/edit?usp=sharing
Roger
Kevin Chambers
This is one in a series of emails I'm forwarding to the new GTFS Flexible Transit Working Group. These emails make up the initial conversation that led to the creation of the working group. I'm sending them with permission of the original senders for archival purposes, allowing new participants to the conversation to get up to speed.
From: Kevin Chambers
Sent: Wednesday, April 10, 2013 7:39 PM
To: 'Heather Menninger'; 'Roger Teal'; 'Aaron Antrim'; 'Becker, Jeff'; 'Kevin Webb'; bar...@cutr.usf.edu
Subject: RE: Google Transit GTFS spec for DRT--first steps
Hi all--
Sorry to be so late to the conversation. I'm very excited by the conversation happening here, and equally appreciative to Roger for helping to get the ball rolling on this aspect of creating standards for demand response transportation.
Roger's scope looks to be comprehensive to me. It appears to cover the sorts of data we would want in order to describe our services here at Ride Connection. Jeff's ideas for an API real-time scheduling sound great to me, as do Heather's reasons for expanding Google Transit.
I have some thoughts some of the broader themes that have come out:
Process -- I really appreciate Aaron's bringing up his questions about process. It really does matter, because in my mind we don't just want to produce a this one spec, we want to build capacity to address this kind of technical matter that concern our whole industry. That's not something we've had up to now. A spec itself is not a hard thing to produce. What's hard is getting people together to develop shared concepts for the problem and viable solutions. If we can develop the expertise, relationships, and infrastructure that will allow us to effectively respond to these new sorts of demands, we will have achieved something noteworthy.
In that spirit, I would support our moving towards an open process as soon as it's viable to do so. I would be very pleased to learn from Aaron and the precedents set by groups like the GTFS Fares Working Group. I don't have much (well any, really) experience working in open development processes like this, but since the whole point is have open communication between all our systems, an open process for achieving that makes sense.
I do think we would need some help getting that open approach going. While the Fares Working Group was a subgroup of the gtfs-changes list, I think most of us are GTFS newbies. I at least would need to bone up on the best practices for being successful in this kind of endeavor. Nonetheless, it strikes me as very doable.
That said, I think the group we have here is entirely legitimate to get things started. Maybe we can get some initial commitments from folks as what kind of time and energy they can bring to setting up a working group of our own. Then we would have some initial structure into which we can invite anyone who has interest. I would love to invite Ethan Nelson at LTD, Jeff Joll at ACCESS in Pittsburg, etc. etc. as soon as it makes sense to.
The Role of Google -- I'm delighted that Brian Ferris is game for working with us on this. That guy is simply amazing, and Google is lucky to have him. Google's participation in general would be a great boost and raises the possibility of Google Transit being an even better tool for the public. Even so, it's an open question for me as to whether they should be the lead in this project. Google's interests are not necessarily well aligned with the interests of transit providers. There's a strong chance that we won't even be privy to Google's intentions, since they may be understandably secretive when it comes to not letting competitors know their plans. If we want this spec to be part of our critical infrastructure for service discovery, it may not be wise to rely too heavily on a business that has a history of regular "spring cleanings" that involve ending services and initiatives that are no longer part of its corporate strategy. Even if we had a perfect alignment of interests, I don't think that would absolve us of the need to develop the our own capacity to respond to industry-wide challenges like this one. In any case, we'll need to stay very engaged if we want assurance that the spec evolves in a way that will work for us, particularly if there are requirements we have that don't serve Google's needs.
As I understand it, the GTFS got started when TriMet here in Portland reached out to Google and suggested to them that they include transit in Google Maps. The first version was more or less the same format as the data Google got from TriMet, which was a dump from TriMet's database of routes. I mention this because while they are an engineering powerhouse, they don't work in isolation. They would need continuous industry input to stay on track.
Finally, I'm not clear what applications would make use of these new extensions to the GTFS. My understanding from a conversation with Aaron in Phoenix is that formal extensions to the GTFS aren't generally accepted until there's actual working software that uses the new features. Speaking as a developer, this approach makes a lot of sense to me, as it prevents pie-in-the-sky additions that no one can ever actually implement.
For us, I think this means we'll need to take a look at what software projects will spearhead this process. Has Google committed to expanding Google Transit to include DRT in any way? If so, that's a big one. Ride Connection's clearinghouse can definitely be another, though it would probably need to be with additional funding, as our initial scope is set. There are a number of VTCLI projects that may also be candidates (Atlanta comes to mind). The sooner we get the word out about what we want to do, the better the possibility to getting projects that are in their early stages to add that to their scope.
Thanks all. Go team!
KC
Kevin Chambers
IT Project Manager
Ride Connection
"To link accessible, responsive transportation with community needs"
CONFIDENTIALITY: The information contained in this email is privileged and confidential. If you are not the intended recipient, or person responsible for delivering it to intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained in the transmission is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by return email and destroy this transmission along with any attachments. Thank you.
Kevin Chambers
This is one in a series of emails I'm forwarding to the new GTFS Flexible Transit Working Group. These emails make up the initial conversation that led to the creation of the working group. I'm sending them with permission of the original senders for archival purposes, allowing new participants to the conversation to get up to speed.
From: Barbeau, Sean [mailto:bar...@cutr.usf.edu]
Sent: Friday, April 12, 2013 9:13 AM
To: Kevin Chambers; Heather Menninger; 'Roger Teal'; 'Aaron Antrim'; 'Becker, Jeff'; 'Kevin Webb'
Subject: RE: Google Transit GTFS spec for DRT--first steps
Hi all,
I propose that we have a conference call to hammer out action items and our process going forward.
Proposed agenda:
1. Determine who will be a pilot producer of the data (seems like this is low-hanging fruit with Denver RTD already involved)
2. Determine if we are satisfied with the existing Google Doc contents (https://docs.google.com/document/d/1hB5ItKLWRtMQ4Iuap9wk9NwvzQRC7LQVPht_9oySO2M/edit?usp=sharing) for the scope of DRT additions to GTFS
3. Determine the next action item going forward (e.g., opening up process with online group, developing exact spec, etc.)
Does this sound reasonable to everyone?
If so, we can work on nailing down a date/time.
Sean