Discussion: deviated fixed route / flex routes / general service dial-a-ride
Aaron Antrim
frequently in my work recently, so I'm trying to get a conversation
started. Hopefully this is a useful jumping-off point.
NEED
- An increasing number of agencies that offer deviated fixed route or
flexible route service and/or a mixture of deviated with conventional
fixed routes are interested in participating in Google Transit.
- Some agencies have chosen not to participate in Google Transit
because they offer some deviated fixed-route service. Participating
without representing their deviated fixed-route service would mean
that passengers would receive accurate trip itineraries where
fixed-route service is the only available travel option, but would be
misled without seeing all available transportation options in cases
where deviated fixed-route service is available.
- At least two agencies I know of that currently participate in Google
Transit offer forms of deviated fixed-route or flexible service,
Dallas Area Rapid Transit and Rio Vista Delta Breeze. There are
likely more.
- Some areas offer general service dial-a-ride, which can be a useful
alternative mode for people evaluating transportation options on
Google Maps.
BACKGROUND / DEFINITIONS
- Deviated fixed route is service service that runs along an
established path, and arrives/departs timing points at preset times,
but which can deviate from the established path for door-to-door
pickups and drop-offs within specific defined areas or zones, and then
returns to the fixed route path. With these types of service, there
is frequently a tiered fare structure, with one fare for curb-to-curb
service (with both pickup & dropoff along the fixed route), and an
additional fare for door-to-door service (where the vehicle travels
off of the fixed route)
- Point-deviation services also keep to a timetable, however, vehicles
do not follow a specific route. Rather, vehicles will stop at
designated bus stops at scheduled times, but during the time between
two scheduled stops drivers will pick up and drop off passengers with
advanced reservations over a dispersed area. (from
http://tinyurl.com/d62smv)
- General service dial-a-ride is the most extreme form of flexible
service. In most areas, dial-a-ride service is only available to
eligible seniors or disabled citizens, but in some areas, these
services are available to the general public.
- For these types of service, advance reservations are usually required.
PREVIOUS DISCUSSION
Gregory J Feazell and Joe Hughes had a short discussion about this
issue in Sep 2008, http://tinyurl.com/czjk8p
IDEAS
GTFS additions/changes:
- Add a shape_id field to stops.txt. shape_id would reference a shape
in shapes.txt. Shapes referenced by a stops.txt record would be
treated as closed polygons that indicate the bounds of a service area
for dial-a-ride or flex route service. Referencing demand service
bounds through stops.txt would mean the existing zone_id field in
stops.txt could be used in defining fare_rules for travel between
demand response service, or fixed route service zones.
- shape_dist_traveled would be ignored for every stop_times.txt row
that references a stop which references a polygonal zone.
- modification of route_type field based on existing proposal
(http://tinyurl.com/dkz7by) with the addition of values for
dial-a-ride, deviated fixed route, and point deviation.
- addition of adv_reservation_secs field to routes.txt that indicates
how soon reservations must be made for travel on the service in
seconds.
- change meaning of value 2 for pickup_type and drop_off_type to
"Advance reservations required," rather than "Must phone agency…,"
because more agencies are looking into, or implementing web-based
reservation systems
- incorporate proposal similar to proposal for agency_ticket_url
(http://tinyurl.com/c547mk) to enable advance reservations for a
demand response trip through an agency's own web-based system
Representing common forms of service in GTFS:
- 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.
- A deviated fixed route trip could be described by stop_times.txt
rows that reference discrete stop locations interspersed with rows
that reference polygonal bounds.
Potential trip planner behaviors/display:
- Deviations within the service bounds would be indicated by arrows in
a similar fashion to Google Transit's walking indicator prior to the
introduction of beta walking directions (the "before" in this image:
http://tinyurl.com/d2m4dg). The fixed route of the vehicle for a
journey would be drawn as it usually is now, by drawing lines between
discrete stop locations referenced in a trip in stop_times.txt, or by
the segment of a trip traveled which is described in shapes.txt.
- For itineraries where advance reservations are required (involving
an origination or destination location where pickup_type or
drop_off_type is 2), a message will be displayed that says
"Reservations are required x hours x minutes in advance", or, for
agencies that use agency_ticket_url, the trip planner will provide a
link to a web-based reservations/ticketing system.
- It may be necessary to suppress exact times from being shown in an
itinerary for demand response services where travel time depends less
on traveler choice and more on agency scheduling and availability.
This behavior could be controlled with values in route_type.
Thoughts? Needs? Problems?
ro...@slevin.plus.com
Perhaps I can offer the following comments in relation to how the UK
standards deal with related issues, and also on what limitations I see
with any approach. This explanation relates to UK standards for regional
and national journey planners - from which two regions are now exporting
selected data to Google Transit. If we are to generate data for Google
related to flexible services we would need to the concepts to be broadly
the same.
In the UK we have the usual differences in flexible services.
We have Hail-and-Ride operations where a bus will stop anywhere along a
section of route (rather than having defined fixed stopping points).
Schedules of such services are fixed - but we have the concept of a stop
which has an anchor location, together with an entry location and an exit
location for the section of road that is Hail-and-Ride. We aim for each
section to be along only one named road - but on long roads we would break
the sections every half-mile or so ... in order that journey plans can be
reasonably precise. We also needed a notation on mapping to show what
segments of a route were hail-and-ride.
We then have dial-a-ride (demand responsive) services which range from
many-to-one through to full many-to- many operations - with or without a
published "schedule". Some are semi-fixed route (fixed route with some
deviations) ... others are completely flexibly routed. For all these
services there is an implicit conflict between journey planning which
relies on the certainty of a schedule, and the operation of a service
which by its very nature is uncertain in demand-responsive mode. What we
find we have to use comprises stop zones - similar to the Hail-and-Ride
stop in that it has an anchor point, but instead of it having an entry and
exit point, it instead has a polygon defined by multiple points that
contain the local area in which the service is available. To give some
certainty for journey planning times, we seek to limit the zones to
perhaps a 1 mile radius - but each location requires different treatment.
We then have a timetable which can be reasonably conventional if the route
is "fixed with deviations" ... albeit every time has to be commented that
it is approximate because of the effect of deviations along the way. But
for many-to-many operations the timetable is a work of fiction - and
contains unachievable times between points in the service area, simply
because most O/D pairs of zones would not be covered in any single vehicle
working. But what it does is to allow a journey plan to be offered with
the need to "pre-book - when more accurate times will be confirmed". The
skill is in creating the dummy timetable so that it works reasonably well
for most types of journey - and particularly the ones that are made most
often. And so that it creates good connections to trunk services - as
these types of demand-responsive services are often used in feeder mode to
longer distance services.
So from our experience with this suggests that we need to be able to
define different stop types "Hail-and-Ride" and "Flexible Service Zone" -
both of which have an anchor location, and then supplementary location
data (two for HAR stops for entry/exit and multiple points for FLX zones).
We do not use shape files in our offerings to Google so I have not thought
about how these arrangements would work with them.
And then there needs to be clear and clever guidance about how to specify
a timetable for such services - so that journey plans for the more
flexible demand responsive operations are credible without necessarily
being "accurate" until the journey is booked with the operator/agency.
I look forward to seeing other contribuitions to this discussion.
Best wishes
Roger
traveline south east, UK
Aaron Antrim
described in GTFS with something like my proposed extension.
For hail-a-ride service, it is possible to add a dense row of stops
along the street in a hail-a-ride zone. Not very clean GTFS data, but
maintaining this could be automated in a GTFS publishing tool.
Many-to-one (I think this means several passengers from different
locations all going to the same destination) service availability
could be indicated with a stop time that references a service area
(shape) and a later stop time at a discrete stop location.
Many-to-many service availability could be indicated by two (or more)
service boundaries (shapes) referenced in a trip.
Note that I don't think it will be possible to return maps and trip
itineraries that show how the vehicle will actually travel, because
this travel will depend on demand. Rather, the goal here is to
describe service availability and give enough information to send
passengers to the right place to reserve their travel.
How would you suggest representing the services you described in GTFS?
Joe Hughes
issues, Aaron!
A few quick thoughts on this:
* This one's going to need a great deal of testing; it would be very
helpful to have one or more sample feeds that we can iterate on for
the purposes of discussion.
* It's clear that we'd need some way to represent polygons for
flexible coverage areas. Rather than overloading shapes.txt (which
comes close to acting as a way to define route patterns), it'd
probably be better to add a new "polygons.txt" file for representing
closed regions/shapes.
* Is anyone in the group using existing software/databases to
represent this kind of information? We'll get the most benefit from
this proposal if we end up with a model that's compatible with
existing data. (Roger, thanks for your comments in this direction.)
Joe
Roger Slevin
I am very short of time to follow this up right now - but I can tell you
that my colleagues on traveline east midlands have many flexibly-routed
services in parts of their region - and data about these services is being
supplied already in the traveline east midlands feed to Google Transit.
I have not examined how we are handling this in detail ... but I suspect
that we are simply using the anchor point in each service zone (polygon) and
presenting each of these as if they were a conventional stop. That allows
journey planning to happen (but it probably misses the key information that
pre-booking is required) - and the transit "bubbles" likewise will show
indicative times without any indication that most of them are unlikely to
represent actual bus movements at that location (or even in that particular
service zone) as the timetable includes far more service zones than could
actually be served at any particular time ... each declared time at a
particular zone's anchor represents an "opportunity" for a service to run at
about that time.
I will try to get back to looking at this in more detail - but it is
unlikely to be until sometime next week that I will be able to do so.
Roger
Aaron Antrim
* It's clear that we'd need some way to represent polygons for
flexible coverage areas. Rather than overloading shapes.txt (which
comes close to acting as a way to define route patterns), it'd
probably be better to add a new "polygons.txt" file for representing
closed regions/shapes.
* This one's going to need a great deal of testing; it would be very
helpful to have one or more sample feeds that we can iterate on for
the purposes of discussion.
Joe Hughes
>> * It's clear that we'd need some way to represent polygons for
>> flexible coverage areas. Rather than overloading shapes.txt (which
>> comes close to acting as a way to define route patterns), it'd
>> probably be better to add a new "polygons.txt" file for representing
>> closed regions/shapes.
>
> Joe: I like this idea (polygons.txt). I think it may also be good to plan
> for open, as well as closed, shapes in this file. Roger mentioned
> "Hail-and-Ride" areas where a vehicle will stop at any section of a route,
> rather than at discrete, fixed locations.
For hail-and-ride sections along a fixed route, it seems like it would
be more efficient and easier to process to specify two points along
the existing trip shape (via shape_dist_traveled) than to try to match
a completely separate polyline.
>> * This one's going to need a great deal of testing; it would be very
>> helpful to have one or more sample feeds that we can iterate on for
>> the purposes of discussion.
>
>
> I have a few current and prospective clients that are interested in
> publishing information on flexible and dial-a-ride services. As soon as we
> develop a reasonable proposal, I can work with them to create or update
> feeds that take advantage of it.
Great! The other ingredient we'll need is a client that can use this
information; perhaps we can enlist one of the open-source routing
engine projects to help experiment with this functionality.
Joe
Nicholas Albion
http://en.wikipedia.org/wiki/Well-known_text
(Unfortunately, WKT is comma-paired, space delimited while KML is
space-paired, comma delimited)
Perhaps in the interest of keeping things simple for producers, the
geometry type could be assumed to be either LINESTRING or POLYGON
depending on the number of pairs of brackets and the start/end (but
this would make SQL import a little more complicated)
(3 4,10 50,20 25)
((1 1,5 1,5 5,1 5,1 1),(2 2, 3 2, 3 3, 2 3,2 2))
((3 4,10 50,20 25),(-5 -8,-10 -8,-15 -4))
(((1 1,5 1,5 5,1 5,1 1),(2 2, 3 2, 3 3, 2 3,2 2)),((3 3,6 2,6 4,3 3)))
Polygons/linear rings could also be used to describe
- fare zones
- agency/feed coverage
- city/state/country borders
If either WKT or KML was adapted for a row-per-shape format, the
"shapes.txt" could possibly also support the similar format as an
alternative to the current row-per-node convention (and indicated as
such in "feed_info.txt").
Once again, I think it would be very useful if feed producers were
encouraged (or even allowed, if not enforced) to provide extra
information in "shapes.txt":
-stop_id (would make route planning about 10-100 times faster)
-altitude (useful for mashing with bicycle planners, but probably too
much effort for most producers)
Roger Slevin
Traveline south east does not supply Google with shapes.txt data - we have
such a large network (it is the largest in Google Transit) and we have no
way of creating shapes without a lot of effort - and we would have
difficulties in avoiding infringing someone's IPR in so doing. So we rely
on stops to define the points which need to be connected.
In Great Britain the national data standard defines a Hail-and-Ride stop by
three pairs of coordinates ... the central "anchor" which we currently send
to Google (and therefore acts as a proxy for the Hail-and-Ride) ... and
associated records which currently do not go to Google, which comprise the
"entry" point to the Hail-and-Ride section, and the "exit" point from it.
For Demand Responsive Services which have "areas of service" then the
polygons are defined by a sequential series of paired coordinates ... the
first and last of which must be identical to complete the polygon (or you
could work with the implication that the last one always joins back to the
first one in the list).
I think these requirements need to be flagged separately ... because a
Hail-and-Ride route might well be defined in such a way that would create a
legitimate triangular polygon that could be a demand-responsive service
area.
I don't think I have a particular preference for format - I am not
technically involved in the production of the GTDF export. My assumption is
that the format would be consistent with current position records - but if
there is an alternative that is more helpful, I imagine we would have few
problems in using one of the formats you mention.
Roger
-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of Nicholas Albion
Sent: 08 April 2009 00:21
To: Google Transit Feed Spec Changes
Subject: [gtfs-changes] Re: Discussion: deviated fixed route / flex routes /
general service dial-a-ride
