proposal: add travel types
bad...@gmail.com
Add files and fields to express the capacity of a vehicle to handle
different kids of passengers (wheelchair, bicycle, cars on ferries,
etc).
Motivation:
The ability of a transit vehicle to pick up or drop off a passenger
frequently depends on the state of the passenger. For example: a bus
may pick up bicycles for part of it's trip, but not for other parts
(as in Seattle's ride-free zone). Sometimes a bus will pick up _only_
bicycles, as is the case with dead-heading vehicles crossing Seattle's
floating bridges. Some stops are accessible by wheelchair, and some
stops are not; and some vehicles of a fleet may not have wheelchair
lifts while others do. Washington State ferry schedules are littered
with notes about which ports-of-call accept cars on which trips and
days, &c. A trip planner needs to be able to express these abilities
and limitations. The ability to accessible trips is particularly
important for many transit agencies.
Proposal:
Add one optional file "travel_types.txt" with the fields:
travel_type_id - Unique identifier for travel type. e.g. - "L"
travel_type_description - Description of travel type - "Limited
Accessibility"
travel_type_default - Whether this travel mode is supported by default
for all trips. 1 for yes, 0 for no.
Add a second file "travel_type_exception.txt" which serves as a many-
to-many join table between the stop_times.txt file and the
travel_types.txt file. It has the fields:
st_trip_id - Together with st_trip_id uniquely identifies a stop_time.
st_stop_sequence - Together with st_trip_id uniquely identifies a
stop_time.
travel_type - References an entry in the travel_type file
pick_up - Indicates whether this travel type can be picked up. 1 for
yes, 0 for no.
drop_off - Indicates whether this travel type can be dropped off. 1
for yes, 0 for no.
notes (optional) - Something a rider with this passenger type should
know.
-Brandon
Joe Hughes
Thanks for the proposal. It seems quite flexible and powerful--is it
based on functionality that you've prototyped in Graphserver? Frank,
can you think of how you'd use this information in TimeTablePublisher?
Agency folks, do you have data of this sort that you'd like to
publish?
On 5/26/07, bad...@gmail.com <bad...@gmail.com> wrote:
> Proposal:
> Add one optional file "travel_types.txt" with the fields:
>
> travel_type_id - Unique identifier for travel type. e.g. - "L"
> travel_type_description - Description of travel type - "Limited
> Accessibility"
Since these are open-ended definitions (they don't have any fixed
meaning), the text in travel_type_description would have to be
integrated directly into the UI of a trip planning application (as
radio-button/checkbox/drop-down options), and it would be hard to plan
trips across data from different feeds. Perhaps it's worth
considering having some fixed IDs for common boarding types. (The
current proposal would probably work fine for generating timetables,
though.)
> travel_type_default - Whether this travel mode is supported by default
> for all trips. 1 for yes, 0 for no.
I wonder whether it would make sense to be able to set the defaults
per route, since (as a proxy for vehicle type), that generally makes
the biggest difference in which kinds of boardings are allowed. Maybe
it would add more complexity than it would save, though.
> Add a second file "travel_type_exception.txt" which serves as a many-
> to-many join table between the stop_times.txt file and the
> travel_types.txt file. It has the fields:
>
> st_trip_id - Together with st_trip_id uniquely identifies a stop_time.
This line is confusing. I think you probably meant "Together with
st_stop_sequence..."
> st_stop_sequence - Together with st_trip_id uniquely identifies a
> stop_time.
> travel_type - References an entry in the travel_type file
This should probably be travel_type_id to match the field it
references in travel_types.txt
> pick_up - Indicates whether this travel type can be picked up. 1 for
> yes, 0 for no.
> drop_off - Indicates whether this travel type can be dropped off. 1
> for yes, 0 for no.
> notes (optional) - Something a rider with this passenger type should
> know.
It would be nice to field-test this (as an optional GTFS extension) to
see how it feels in practice.
Joe Hughes
Google Transit