Crosspost/Forward: Paratransit (demand response) addition to trip planning engine?
T Sobota
Group to cross-post here.
---------- Forwarded message ----------
From: T Sobota <tsob...@cityofmadison.com>
Date: Apr 1, 4:12 pm
Subject: Paratransit (demand response) addition to trip planning
engine?
To: Google Transit Trip Planner
Thought open for further discussion:
Under the regulations of the United States Amercians with Disabilities
Act, transit operators must provide users unable to use fixed route
modes of transportation complimentary service in a demand response
(paratransit) environment. These guidelines broadly include items
like picking up and dropping off riders at points within 3/4 of a mile
of fixed route modes of transit providing "regular" service, while
allowing latitude to require things like advanced booking, schedule/
travel time flexibility and fare premiums.
Presently, Google maps can generate travel itineraries for a user by
foot (walking), transit (fixed route, regularly scheduled modes), and
driving (personal vehicle). I can envision a fourth, albeit limited,
option which would be "paratransit", with the itinerary not being
timed as much as stating "eligible" or "ineligible" based on the
service parameters of the transit operator. There would seem to be
some relatively basic additions that could be made to a transit feed
database, that could inform this "eligibility" value of Google maps'
itinerary planning engine - given the traditonal user inputs of origin
point, destination point, date and time. Due to the dynamic nature of
paratransit service, I can't envision a "third party" trip planner
being able to deliver an accurately timed itinerary (typically the
user calls in advance to a request a trip at a desired time, then the
trip is subsequently booked with perhaps an offset for efficiency
reasons, and then the trip is open to further fluctuations at the time
of actual journey).
Upon inital thought, there would need to be geographic definitions of
polygons and attribute data (days and times of paratransit
eligibility), fare information (to the extent it differs from fixed
route modes), and perhaps service parameter rule text (users must call
transit operator by a certain time, or x hours in advance of trip
request).
While a paratransit rider may be able to derive an eligibility
estimate by modeling a fixed route trip (does such an itinerary exist
using fixed route modes from a point within 3/4 of a mile of their
origin to a point within 3/4 of their destination at their request
date and time of travel), limitations on the service area of
paratransit trips like jurisdictional boundaries or ineligible
"commuter" modes of fixed routes may obscure an accurate assessment in
this manner.
Tim Sobota
Transit Planner
Metro Transit, City of Madison (WI)
Aaron Antrim
Last month, a discussion began on how to represent non-fixed route services in GTFS:
http://groups.google.com/group/gtfs-changes/browse_frm/thread/cc186121791e77b8
So far, discussion has been oriented around representing general service flexible and dial-a-ride service, not paratransit/ADA services. However, many questions are shared: how to represent geographic boundaries, costs, service hours / days, etc.
Your comments on any additional needs or problems that you see with the (very rough draft / discussion purposes only) proposal would be useful and appreciated.
Aaron
T Sobota
I have been following the related discussion on what I was
perceiving was fixed-route side DR itinerary planning. I was seeing
what I understood to be goals of representing actual itinerary
results, which I could envision based on the nature of fixed-route DR
services (a vehicle is "scheduled" to be serving an area on a day-in
day-out basis at specific times, typically with a minimum number of
fixed nodes where passengers might even be able to board without
advance notice to provider, etc.).
I had started a new thread to target the ADA complimentary
paratransit style of demand response service. In my experience, this
is much more of an ad hoc operation, indeed trips are frequently
subcontracted to private taxi providers by the fixed route operator.
While some paratransit riders obviously have daily travel patterns,
and it could happen that a series of such passengers may be served by
the same vehicle plying the same routing on a daily basis, that
vehicle still does not have a "daily" schedule that fits into a trip
planning model. Rather, ride requests are typically batched together
on a nightly basis - then dispatched the following morning to the
operating fleet, and through the course of the day rides may be added/
deleted/modified per conditions.
In sum, my paratransit concept was ignoring entirely a goal of
producing an actual itinerary for a user... but rather just returning
an initial analysis of whether their requested origin and destination
point, at their requested date and time of travel, fell within the
eligibility guidelines of the paratransit service area of the
provider. From a provider persepective, this could result in some
decrease in call volumes to the ride bookers/customer service staff,
freeing call takers to book and confirm rides rather than determining
eligibility.
On Apr 5, 3:44 pm, Aaron Antrim <aa...@arcatacommunity.org> wrote:
> Hi Tim,
>
> Last month, a discussion began on how to represent non-fixed route services
>
> - Show quoted text -
Edward Vielmetti
there are at least three or four here in Ann Arbor, include
one fueled by waste oil from fryers at a restaurant that uses
it as a "burrito bus", and getting those routes or even contact
and region areas into Google Transit would be a huge win
for late night and weekend transit here where the fixed route
operators cut back on traffic.
thanks
Ed
ps I have a SMART (metro Detroit) GTFS data set for the asking -
if you asked once ask again please, I got it via FOIA.
Edward Vielmetti
Ann Arbor, MI
+1 734 330 2465
Aaron Antrim
Fixed route demand response service can already be described in GTFS. This looks like a trip where all pickup_type and drop_off_type for all stop times is 2. Currently, however, these services do not show up in the Google Transit trip planner (only scheduled service with drop_off_type or pickup_type of 0 or 3, regularly scheduled, or must coordinate with driver, is returned).
However, non fixed-route service availability cannot currently be described.
Representing general service dial-a-ride or flexible service and paratransit dial-a-ride or flexible service would require identical GTFS capabilities to describe the time/day and area bounds of available service. For paratransit/ADA service, individual elderly/disabled, etc. eligibility requirements would also need to be included.
Seeing this overlap, I suggest we work together for to develop one proposal for a GTFS modification to enable describing day / time and service area bounds for dial-a-ride and flex route services. The proposal could include the capability to describe elegibility requirements for paratransit services, or that could be added later.
My original post suggested a way to describe dial-a-ride.
A general dial-a-ride service could be described by a trip with only
two stop times, both of which reference stop locations that include a
shape_id for polygonal bounds. A row in frequency.txt would indicate
the bounds of service hours.
However, your point that service availability, rather a set schedule, needs to be described is key. Do you have any suggestions on how to best do this? Other thoughts / suggestions?
Aaron
