West Salem Connector

73 views
Skip to first unread message

Aaron Antrim

unread,
May 13, 2016, 1:57:10 PM5/13/16
to Matt Berggren, gtfs-fle...@googlegroups.com
Matt Berggren:
(cc: GTFS-flex working group)

I am working with ODOT and PSU to support developing prototype "GTFS-flex” datasets for demand-responsive transit services in Oregon. We have identified the West Salem Connector (http://www.cherriots.org/en/connector) as a service to reference in this effort.

To that end, could you please clarify/confirm aspects of the West Salem Connector for me? I am trying to figure out what would make sense to attempt to model in GTFS-flex.
  • Name for type of service:
    • Would this typically be called a "Checkpoint" service?
  • Glen Creek Transit Center is the only scheduled stop. Is there any default common order/schedule for serving the other stops, or is it entirely based on the stops that people call into request?
  • Travel times:
    • Average travel times?
    • Maximum travel times?
  • Reservations
    • Minimum time before reservation
    • Reservation URL?
Thank you so much for helping to support this effort, which should result in some new opportunities for information tools for DRT!

Thank you,
Aaron

--
Aaron Antrim, Principal
Trillium Solutions, Inc.
www.trilliumtransit.com
Portland, Oregon
503.567.8422 ext. 3

Matt Berggren

unread,
May 19, 2016, 2:38:00 PM5/19/16
to GTFS Flexible Transit Working Group, matt.b...@cherriots.org
Time Points
Besides Glen Creek TC, there's no scheduled order of serving other stops. It's entirely based on request (online or call-in). If there are no bookings, it will just wait at Glen Cree TC. We originally considered creating something more akin to deviated-fixed route, with at least a few scheduled stops in a loop...but we wanted to start with seeing if any patterns developed. It wouldn't be inconceivable for us to eventually create more scheduled stops throughout the system to try to match demand (aka students going to the high school in the morning and after school). The software we use, Mobility DR, is very flexible and it can handle everything from deviated-fixed route to completely demand responsive.

Additionally, it's worth noting people can book trips to and from Glen Creek TC even outside of the scheduled time, and that's where 85% of or trips are to and from. We've also considered at some point having two scheduled times an hour at Glen Creek TC and forcing all trips to happen at those times.

Vehicles
We currently only have one vehicle in use at a time based on our current demand. Putting a second vehicle on the road during peak times might eventually happen, though. 

Average Travel Times
The average time a person spends in a vehicle is 9.35 minutes. Every rider has a max trip time based on distance. I believe it's (direct travel time)*2.5+5 minutes. Aka if the vehicle would have taken 7 minutes to bring a rider directly from the pick-up point to the drop-off point, their max time would be 8*2.5+5=25 minutes. According to our software provider, the formula for the max vehicle ride time is the biggest limiting factor in how many passengers we can schedule at a time.

Request-to-Pickup Times
According to our reports, the average person books 10.56 hours in advance. Riders can book up to two weeks in advance for one-time trips (and I'm not sure if they average time includes recurring trips, which could on average be booked 1.5 months in advance).

Desired Boarding Time vs Actual Boarding Time
Our system doesn't currently allow for realtime reservations (although we're quickly headed in that direction). Currently we require riders to book 30 minutes in advance, and we encourage them to book further in advanced. Riders also have the ability to set up recurring trips for up to 3 months (aka I want to get picked up at 3:00p at this stop every M, W, and F for two weeks).

According to our report, for the months of February-April 2016, the average actual boarding time was just 2.65 minutes from the desired boarding time. I'm not sure if that compares their requested time to the pick-up window they received, or to the actual time the bus ended up arriving. I'll have to look into that. That number seems very low to me, but it would be great if it were accurate. Likely this is ignoring bookings that were abandoned...aka people who started to book, but couldn't find a time to they didn't ride at all.

Another metric we can look at is "trips denied." When someone request a pick-up time or drop-off time, the system tries to find a time as close as possible to what they want. If it cannot find something within an hour of the requested time, it will give them a trip denial and ask them to request another time. This happened 0 times in February, 5 times in March, and 7 times in April. This is compared to 955 trips, 1065 trips, and 1161 trips, respectively.

Salem-Keizer Transit
555 Court St NE, Suite 5230
Salem, OR 97301


Aaron Antrim

unread,
Jun 8, 2016, 10:10:02 PM6/8/16
to GTFS Flexible Transit Working Group, matt.b...@cherriots.org
Matt,

Thank you so much for this great information!

There are a few important aspects of this service that the draft GTFS-flex specification was unable to describe.

I have proposed changes to the working draft specification, specifically to add point deviation and DRT travel time and booking parameters. You can see these changes in github here:

And here's a readable version of the new proposed draft spec:

@Sean: I opened a pull request on this here: https://github.com/CUTR-at-USF/gtfs-flex/pull/3

@Others: Any comments on this? I'm particularly interested in feedback from Denver RTD, as I believe that you also use the same software and operate point deviation services -- is that correct?

-- 
Aaron Antrim, Principal
Trillium Solutions, Inc.
Portland, Oregon


Reply all
Reply to author
Forward
0 new messages