GTFS - Flexible Services
Becker, Jeff
Brian –
I sent this a while back and wonder if we want to rekindle this activity. The international conference I referred to below in Monterey, CA will feature a session on data standards among flexible transit service providers. Perhaps this effort could have something to contribute. - JB
3/7/2014
Our apologies for taking so long to review Flexible Public Transit Services in GTFS.
Comments by Jonathan Wade and Jeff Becker
These comments are in reference to how these specifications address flexible services in Denver’s Regional Transportation District (RTD); there are currently 22 such services which are named Call-n-Ride (http://www.rtd-denver.com/callNRide.shtml). These services generally operate in demand-responsive mode in low-moderate density settings, providing many-to-many/few and many-to-one connector to fixed-route service within a bounded geographic area. Customers reserve trips by phone or web booking and can also board spontaneously without a reservation by arriving at a checkpoint stop before a scheduled time.
We thoroughly went through the proposed additional fields and explanations to the current GTFS tables and feel that it works well for modeling RTD’s flexible service areas. Following are specific scenarios and comments for which we request your confirmation. Sorry if we seem a bit dull.
1. You state that using the term “area” may be confused with fare “zone,” thus area will be used. However you continue to use both words, which is indeed confusing. We use the word “area” as well, and one reason is that we also have sub-areas that we call zones which serve as catchments (specified as a radius or polygon) for specific stops within the flexible service area. These catchments are important in the Call-n-Ride scheduling system to direct customers for pickup or drop-off, but we are not sure if they are relevant to GTFS-Flex.
2. Must a flex service area be associated with a fixed route? RTD has Call-n-Rides that provide service to areas that may or may not also have routes in them and which have no route/trip/stop connection. Can the GTFS-Flex accommodate such areas as available to customers whose trips fall within them? While these areas are mostly reservation only, they may also have scheduled stops (that we call checkpoints). Which of your defined, flexible service types would this fall in?
Do we need to create a fictional route_id, service_id, stop_id and trip_id or could route_type in the route.text table have a type 8 Flex? The other likely fields that could be used in this table would be block_id, wheelchair_accessible, and bikes_allowed.
3. RTD’s service areas cannot be completely defined by a single, continuous polygon. For example, there are exclaves not contiguous to the main service area, but are associated with the same, uniquely named flexible service area. How can these be accommodated?
4. Will it be easy to convert an ESRI shapefile or kml file into the fields needed in the area.txt table?
5. Could you help us with some additional example flex service areas operating 5:30 – 20:00 that have demand-responsive service throughout plus one of the following:
a. There is a regularly scheduled transfer connection, say every 30 minutes, 6:00 – 9:00 and 15:00 – 18:00 at stop A.
b. There are stops (checkpoints not a bus stop) B and C that have two AM and two PM scheduled times each.
c. A flex-route “corridor” that has a transfer connection stop D scheduled every 15 minutes from 15:00 to 18:00. The corridor (route) is defined as operating along a “path” (streets?) along which are two stops (checkpoints not a bus stop) E and F scheduled every 15 minutes.
d. Is it correct that we can implement any combination of these configurations in a single service area?
6. We would need for each service area: a service area name, URL(s) and telephone number(s) fields to provide proper customer service. Fare info would be nice also.
Brian –
The TRB Paratransit Committee is sponsoring an international conference this October and we feel that data exchange is an important topic regarding open and integrated DRT services. Roger will be sending you an invitation—call for abstracts—very soon; sponsorships are also available. I was glad to meet you at last fall’s GIS in Transit Conference and did make it to the GTFS for the Rest of Us meeting after the January TRB Annual Meeting. - JB
A. Jeff Becker | Senior Manager of Service Development | Regional Transportation District | 303-299-2148
From: gtfs-fle...@googlegroups.com [mailto:gtfs-fle...@googlegroups.com] On Behalf Of Brian Ferris
Sent: Wednesday, November 20, 2013 11:28 PM
To: Roger Teal
Cc: Ross Peterson; kcha...@rideconnection.org; gtfs-fle...@googlegroups.com
Subject: Re: Proposal for adding Polygons to GTFS
My apologies that it took some time to write up, but here are my thoughts on a possible alternative proposal for modeling flexible service areas. As a bonus, I also describe support for flag stops as well (based on the proposal developed at the GTFS For the Rest of Us Workshop).
There is plenty of potential room for improvement in this proposal, so I'm definitely interested in your thoughts.
Thanks,
Brian
On Tue, Nov 19, 2013 at 9:11 AM, Roger Teal <Roger...@demandtrans.com> wrote:
Brian:
I read through your comments on Ross’ proposal, and in them you had at least one counter-proposal for a specific proposal of his. Have you developed a more complete counter-proposal and posted that somewhere? If so, can you provide the link or the location? I like your concept of an areas.txt file which could be further linked to the stops.txt and stop_times.txt files, this would seem to handle many of the real life situations we need to model in Denver (probably 20 of the 23 service areas have some stops in them if only a single cycle point), but Kevin has raised a good point about how to configure the data to indicate a purely demand responsive service and to handle services that only have a start of day and end of day service times.
Roger
From: gtfs-fle...@googlegroups.com [mailto:gtfs-fle...@googlegroups.com] On Behalf Of Brian Ferris
Sent: Monday, November 18, 2013 11:39 AM
To: Ross Peterson
Cc: gtfs-fle...@googlegroups.com
Subject: Re: Proposal for adding Polygons to GTFS
So I have some fairly substantive differences-of-opinion. If you think it'd be useful, I'd be willing to write up a counter-proposal that summarizes my ideas.
Brian
On Mon, Nov 18, 2013 at 9:02 AM, Ross Peterson <rpete...@gmail.com> wrote:
Many thanks to the organizers of the GTFS for the rest of us meeting last week. While much of the meeting focused on international paratransit (jeepnies, microbuses and so forth), the meeting also helped catalyze thoughts on how to begin representing North American paratransit services (flex-routes, point-deviation, and dial-a-ride). This thread is intended to continue the discussion regarding these other flexible transit services.
I'll post a note to https://groups.google.com/forum/#!forum/transit-developers and https://groups.google.com/forum/#!forum/making-gtfs-work-for-the-rest-of-the-world, to stimulate discussion but will try to keep the discussion here for the time being.
This is a formative proposal for adding a polygon to GTFS. The objective is to allow trip planning applications that consume GTFS to recognize origins and destinations that fall within the service area polygon of a demand responsive transit provider so that those demand response services can be offered as part of an itinerary.
This would be a helpful function for many trip planning applications currently under development as part of the Veteran's Transportation and Community Living Initiative (VTCLI) - including the open source One-Click effort underway in several cities around the U.S. As such, this proposal can be advanced alongside projects that will 1) supply data in the proposed format and 2) create tools that consume the proposed feed - thus meeting a core requirement for modifying GTFS.
The proposal is HERE in a google doc.
Proposed Next Steps:
1) Review the proposal
2) See if your data can be described using the proposed spec
3) Adapt your trip planning tools to consume it and see if it works.
4) Recommend changes to the proposal
For now, I think this proposal should be vetted by folks who will use it, before we put it forward for adoption into GTFS. Ideally, we should have multiple data sets in the proposed format (once it has been adapted to work properly) as well as at least one application that consumes it before we suggest the change on https://groups.google.com/forum/#!forum/gtfs-changes.
I look forward to hearing your constructive feedback.
Ross
--
You received this message because you are subscribed to the Google Groups "GTFS Flexible Transit Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-flexible-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "GTFS Flexible Transit Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-flexible-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "GTFS Flexible Transit Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-flexible-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Aaron Antrim
On Tuesday, June 3, 2014 at 2:48:31 PM UTC-7, Becker, Jeff wrote:
Brian –
I sent this a while back and wonder if we want to rekindle this activity. The international conference I referred to below in Monterey, CA will feature a session on data standards among flexible transit service providers. Perhaps this effort could have something to contribute. - JB
3/7/2014
Our apologies for taking so long to review Flexible Public Transit Services in GTFS.
Comments by Jonathan Wade and Jeff Becker
These comments are in reference to how these specifications address flexible services in Denver’s Regional Transportation District (RTD); there are currently 22 such services which are named Call-n-Ride (http://www.rtd-denver.com/callNRide.shtml). These services generally operate in demand-responsive mode in low-moderate density settings, providing many-to-many/few and many-to-one connector to fixed-route service within a bounded geographic area. Customers reserve trips by phone or web booking and can also board spontaneously without a reservation by arriving at a checkpoint stop before a scheduled time.
We thoroughly went through the proposed additional fields and explanations to the current GTFS tables and feel that it works well for modeling RTD’s flexible service areas. Following are specific scenarios and comments for which we request your confirmation. Sorry if we seem a bit dull.
1. You state that using the term “area” may be confused with fare “zone,” thus area will be used. However you continue to use both words, which is indeed confusing. We use the word “area” as well, and one reason is that we also have sub-areas that we call zones which serve as catchments (specified as a radius or polygon) for specific stops within the flexible service area. These catchments are important in the Call-n-Ride scheduling system to direct customers for pickup or drop-off, but we are not sure if they are relevant to GTFS-Flex.
2. Must a flex service area be associated with a fixed route? RTD has Call-n-Rides that provide service to areas that may or may not also have routes in them and which have no route/trip/stop connection. Can the GTFS-Flex accommodate such areas as available to customers whose trips fall within them? While these areas are mostly reservation only, they may also have scheduled stops (that we call checkpoints). Which of your defined, flexible service types would this fall in?
Do we need to create a fictional route_id, service_id, stop_id and trip_id or could route_type in the route.text table have a type 8 Flex?
The other likely fields that could be used in this table would be block_id, wheelchair_accessible, and bikes_allowed.
3. RTD’s service areas cannot be completely defined by a single, continuous polygon. For example, there are exclaves not contiguous to the main service area, but are associated with the same, uniquely named flexible service area. How can these be accommodated?
start_service_area_id | AreaX | |
end_service_area_id | AreaX |
start_service_area_id | AreaX | |
end_service_area_id | AreaY |
start_service_area_id | AreaY | |
end_service_area_id | AreaX |
4. Will it be easy to convert an ESRI shapefile or kml file into the fields needed in the area.txt table?
5. Could you help us with some additional example flex service areas operating 5:30 – 20:00 that have demand-responsive service throughout plus one of the following:
a. There is a regularly scheduled transfer connection, say every 30 minutes, 6:00 – 9:00 and 15:00 – 18:00 at stop A.
b. There are stops (checkpoints not a bus stop) B and C that have two AM and two PM scheduled times each.
c. A flex-route “corridor” that has a transfer connection stop D scheduled every 15 minutes from 15:00 to 18:00. The corridor (route) is defined as operating along a “path” (streets?) along which are two stops (checkpoints not a bus stop) E and F scheduled every 15 minutes.
d. Is it correct that we can implement any combination of these configurations in a single service area?
Aaron Antrim
- 5.A.: Your scenario A
- 5.C.: Your scenario C
- Green Mountain (RTD) service: http://www.rtd-denver.com/callNRide.shtml#greenmountain
- South JeffCo: not complete yet
Aaron –
I have tried to combine and clean things up a bit below, and you will see our latest comments in red. RTD would be able to supply these GTFS-Flex data for testing, but we do not have the capability to develop an extended application. I have not sent this to the googlegroups. How shall we proceed to restart this? Thanks. - JB
A. Jeff Becker | Senior Manager of Service Development | Regional Transportation District | 303-299-2148
Comments by Jonathan Wade and Jeff Becker
Comments by Aaron Antrim
Comments by Jonathan and Jeff
These comments are in reference to how these specifications address flexible services in Denver’s Regional Transportation District (RTD); there are currently 22 such services which are named Call-n-Ride (http://www.rtd-denver.com/callNRide.shtml). These services generally operate in demand-responsive mode in low-moderate density settings, providing many-to-many/few and many-to-one connector to fixed-route service within a bounded geographic area. Customers reserve trips by phone or web booking and can also board spontaneously without a reservation by arriving at a checkpoint stop before a scheduled time.
We thoroughly went through the proposed additional fields and explanations to the current GTFS tables and feel that it works well for modeling RTD’s flexible service areas. Following are specific scenarios and comments for which we request your confirmation. Sorry if we seem a bit dull.
1. You state that using the term “area” may be confused with fare “zone,” thus area will be used. However you continue to use both words, which is indeed confusing. We use the word “area” as well, and one reason is that we also have sub-areas that we call zones which serve as catchments (specified as a radius or polygon) for specific stops within the flexible service area. These catchments are important in the Call-n-Ride scheduling system to direct customers for pickup or drop-off, but we are not sure if they are relevant to GTFS-Flex.
2. Must a flex service area be associated with a fixed route? RTD has Call-n-Rides that provide service to areas that may or may not also have routes in them and which have no route/trip/stop connection. Can the GTFS-Flex accommodate such areas as available to customers whose trips fall within them? While these areas are mostly reservation only, they may also have scheduled stops (that we call checkpoints). Which of your defined, flexible service types would this fall in?
My read is that this falls in the category of a "Zone Route" in Bryan's document.
We’re okay with that, but we would like to see more examples as in item 5 below.
Do we need to create a fictional route_id, service_id, stop_id and trip_id or could route_type in the route.text table have a type 8 Flex?
My read is that, to fit within the existing GTFS, the "zone route" would need to be set up with route_id and service_id. I would suggest against creating a "Flex" route type, as ideally this information would be expressed in stop_times.txt. There may be an appropriate designation to use or add here: https://support.google.com/transitpartners/answer/3520902?hl=en&ref_topic=1095593
So, would we use 1501 Communal Taxi Service which is supported in stop_times.txt?
The other likely fields that could be used in this table would be block_id, wheelchair_accessible, and bikes_allowed.
3. RTD’s service areas cannot be completely defined by a single, continuous polygon. For example, there are exclaves not contiguous to the main service area, but are associated with the same, uniquely named flexible service area. How can these be accommodated?
Good question. By my read, it would be possible to define travel availability between various areas with separate rows in stop_times, e.g.
start_service_area_id
AreaX
end_service_area_id
AreaX
start_service_area_id
AreaX
end_service_area_id
AreaY
start_service_area_id
AreaY
end_service_area_id
AreaX
Since this just expresses availability of service, it does not imply anything about the number of vehicles operating.
This is not intuitively obvious, but we can try it.
4. Will it be easy to convert an ESRI shapefile or kml file into the fields needed in the area.txt table?
This is just a Spec proposal. If this gains traction, anyone can write software or develop methods to perform data conversion between GTFS flexible data and other formats.
Now that we understand more about this, we don’t think this is a problem.
5. Could you help us with some additional example flex service areas operating 5:30 – 20:00 that have demand-responsive service throughout plus one of the following:
a. There is a regularly scheduled transfer connection, say every 30 minutes, 6:00 – 9:00 and 15:00 – 18:00 at stop A.
b. There are stops (checkpoints not a bus stop) B and C that have two AM and two PM scheduled times each.
c. A flex-route “corridor” that has a transfer connection stop D scheduled every 15 minutes from 15:00 to 18:00. The corridor (route) is defined as operating along a “path” (streets?) along which are two stops (checkpoints not a bus stop) E and F scheduled every 15 minutes.
d. Is it correct that we can implement any combination of these configurations in a single service area?
I'll return to the above tomorrow.
In order to move this along, I would like to propose changes to the "Flexible Transportation Services in GTFS Proposal". Does anyone have preferences for, or alternatives to the earlier ideas for fields to add to stop_times (below)?
· Split continuous_stops into two fields: continuous_stops_drop_off and continuous_stops_pickup. Values of digits 0-3 would indicate the same meaning as for the existing drop_off_type and pickup_type fields (https://developers.google.com/transit/gtfs/reference#stop_times_fields).
· Just add one field, continuous_stops, but define additional possible values. e.g. "32" indicates the passenger must request drop-off from the driver and that one must phone the agency for pickup. "31" indicates the passenger must coordinate with the driver for drop-off but that there is no pickup available.
Bullet 1 seems to be easier to understand and adequate to our needs, but is not a strong preference. As stated above, more examples regarding item 5 would be helpful, especially for combined configurations.