Proposal for adding Polygons to GTFS

[Ross Peterson]

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

[Brian Ferris]

Would you rather we make comments on the mailing list or in the proposal doc?

--
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.

[Ross Peterson]

Please make substantive comments in the google doc.

Thanks,

Ross

[Brian Ferris]

Could you please give us permissions to add comments to the doc then? ; )

[Brian Ferris]

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:

[Ross Peterson]

Yes your comments in the doc reflect a better grasp for how to model the data.  Of course, please offer a counter proposal.  It would be useful and much appreciated.

Thanks,

Ross

[Roger Teal]

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

[Kevin Chambers]

In his final notes, Ross explicitly excludes pure demand-responsive services, since it would break the spec by having omitting the required arrival_time and departure_time fields in the (also required) stop_times.txt file. Also, each stop_times.txt row needs to reference a stop from stops.txt even though there would be none.

 

But since I feel that what Ross and Brian have proposed gets *so* close to being able to describe pure DR, I'd like to get a feel from folks about whether we can do a little creative repurposing.

 

What if we did something like this:

·         Added a value option to location_type in stops.txt, where the value 2 means "service area"

·         When location_type equals 2, enter the service area centroid in stop_lat and stop_lon (allowing us to meet the requirement that these fields have data in them)

·         Also when location_type equals 2, reference areas.txt in stops.txt as a new optional field (instead of putting it in stop_times.txt as Brian suggested). Having areas referenced in stops.txt keeps location information closer together and also gives us a good reason to reference a stop_id in stop_times.txt, which is valuable since stop_id is required in stop_times.txt.

·         Add an optional stop_time_type field to stop_times.txt, where 0 defaults to the current meaning of a stop and 1 changes the meaning of arrival_time and departure_time to represent a time range for service (e.g., 8 am to 5 pm). This meets the requirement that these fields have data in them. In a scenario where a trip has only a portion that is flexible, I'd propose that stop_time_type would be 0 and the arrival_time and departure_time fields would represent entry into and exit from the area referenced in stops.txt.

 

It seems like these changes would handle scenarios where there is one or more fixed stops in a trip, as well as when there are none.

                           

Have I missed anything? What do folks think of the idea of repurposing the stop_lat, stop_lon, arrival_time and departure_time fields in this manner?

 

KC

[Brian Ferris]

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).

 Flexible Public Transportation Services in GTFS

There is plenty of potential room for improvement in this proposal, so I'm definitely interested in your thoughts.

Thanks,

Brian

[Kevin Chambers]

I really like how comprehensive this is. The "Intermediate Stops Within Zones" case drove home to me the value of having start_service_area_id and end_service_area_id vs a single service_area_id. Serve start and end times are handled well under this proposal too.

The only thing I feel weird about it is the ambiguous role that stop_id plays in stop_times.txt in these cases. Can't think of a solution to that at the moment, though.

I'm curious to hear what Aaron and Roger think of this, since they've probably seen a variety of services that have different types of deviation.

KC

---

From: Brian Ferris [bdfe...@google.com]
Sent: Wednesday, November 20, 2013 10:27 PM
To: Roger Teal
Cc: Ross Peterson; Kevin Chambers; gtfs-fle...@googlegroups.com

[Ross Peterson]

Brian, thanks for your work on this. This is a more elegant solution.

From my perspective, I think the next step in development is to test this (Brian's proposal) with some real data and a real application.  I'm encouraging my colleagues on several of the FTA funded one-click projects to experiment with this spec.  So far, I think everyone has been quite busy so things have gone quiet for the moment. However, I'll be face to face with some developers this week and hope to stimulate further progress.

Stay tuned.

Ross

[Becker, Jeff]

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