[gtfs-changes] Interlining / blocks

[David Turner]

Does anyone know of a case where:

(a) The same physical vehicle is used for two back-to-back trips (in the
GTFS trips.txt sense)
(b) These trips have the same block ID
(c) A passenger can stay on the vehicle between the trips, and
(d) The last stop on the earlier trip is *different* from the first stop
on the later trip?

The complication is, of course, (d).

Also, what rule does Google use to determine if two trips are interlined
(that is, a passenger can stay on the vehicle)?





--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To post to this group, send email to gtfs-c...@googlegroups.com.
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

[Louis Leskoviansky]

I think this can happen if the bus is at a "transfer center" where there is a group of stops and the bus basically moves up to a stop that's just a few feet forward along the road for the in-seat transfer. 

The Ann Arbor Transportation Authority has 3 of these transfer centers where it offers guaranteed transfers to a whole series of routes at regular intervals. 

Unfortunately, which is really only unfortunate in my case, OTP almost always favors walking to another nearby stop rather than suggesting the rider stay on the bus for the in-seat transfer that happens just a few minutes later. For the rider, the in-seat transfer is beneficial because it offers shelter during the harsh Michigan winters and would almost always be favorable over walking down the street during certain times of the year. 

I don't see a way of adjusting the /plan API parameters to increase the favor toward interlining trips. I'd be curious to know how this is represented in the GTFS as well...and how it might be possible to influence the trip planner to yield results in favor of interlining. 

-Lou

[David Turner]

Can you give an example trip plan, and describe what plan you would
prefer?

[Louis Leskoviansky]

I have two different examples...but it doesn't seem appropriate for this topic so I'll start a new one for it. 

In the spirit of the topic of GTFS changes, and going along the same lines as the issue I mentioned in my previous reply, I'm thinking it would be very handy to be able to differentiate between sheltered and non-sheltered stops. If there's a high chance of rain or it's really cold out or snowing, there is a high potential that the rider will have a preference toward these stops, especially for the inexperienced rider. Except for maybe extrapolating on the "location_type" field of the stops.txt file (where the location_type equals 1) I don't see a way to do that with GTFS currently. It would be very handy for the stops.txt file to have a boolean field defining whether or not the stop had shelter or even a seating area (maybe even a list of stop amenities...the "wheelchair_boarding" field could even be merged into an "amenities" field where "wheelchairAccessible" is an amenity). Food for thought.

[David Turner]

Yep, this is a great idea and one that we have considered. I'm not sure
if there's an official proposal on GTFS-changes yet. I haven't had a
chance to implement it yet, but it would be a pretty easy thing to do.

[MikeN]

I like this idea also - I have an OSM file full of the attributes shelter, bench, etc, but no place to use them yet.

[garth....@sa.gov.au]

In our system we have in the GTFS a block ID, I'm going to call it X, and a series of trips.

Block ID X  contains Trip ID A: 10:10am - 10:30, Trip ID B: 10:30 - 11:10, Trip ID C: 11:10 - 11:30.

The error we are seeing is that Trip B is a repositioning of the vehicle to the depo ( so the trip isn't public) and this is excluded from the feed, but if it is a public trip then we include them.

Garth.

[Garth Walker]

To update you all. Were processing our trips differently to generate block ids where vehicles change headsign. I suggested to Andrew that the Gtfs definition is slightly different to how otp implements blocks, so there is a change request there. We have also realized this has an impact to the output of transfers in the otp plan.