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)?

[Stuart Heinrich]

I think the proper way to represent "interlined" trips in GTFS is to make them as 1 trip

--
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.

[Brian Ferris]

I believe King County Metro is a good example of such a feed.  They have a ton of interlined routes that switch from one route to another as they enter downtown.  To pick just one example:

trip_id,arrival_time,departure_time,stop_id,stop_sequence
18086473,11:28:24,11:28:24,558,100856928
18086474,11:30:19,11:30:19,578,100856929

The trips really do belong to two separately branded routes, but riders really do stay on-board across the interlined-transfer.

I think there are other examples in other feeds if you need more.

Brian

[Aaron Antrim]

On 13 Sep 2012, at 9:03 AM, Stuart Heinrich <sbhe...@gmail.com> wrote:

I think the proper way to represent "interlined" trips in GTFS is to make them as 1 trip

Stuart- I disagree.  If the vehicle is presented as a different route for different sections of the work block, then two trips with one block_id is the best way to do this.  Otherwise, timetable generation software wouldn't have any good data to present these trips on the right timetable.  And, trip planners won't accurately represent the parts of the service.

[Wojciech Kulesza]

David,
we have the same, especially including d), where by "different" we understand same location but different stop_id.
usually, passengers are not allowed to stay in the vehicle, but (what's very common especially with small operators) they do stay in the bus.

Regards,
Wojciech

[T Sobota]

Our agency feed has a block with 19 minutes and roughly 5.2 miles of distance between the last revenue stop of one trip, and the first revenue stop of the next trip.  A trip plan from a stop earlier on that first trip, to a stop along the second trip, does not return a result using this same vehicle block with a stay-in-seat transfer (over the 5.2 mile distance between the two trip ends) - it forces significant walking to alternate routes and multiple transfers to complete as much.

[David Turner]

That's on Google Transit?

They are probably using a heuristic to decide which blocks to trust,
since some agencies use the operator definition of block instead of the
GTFS definition.

> --
> You received this message because you are subscribed to the Google
> Groups "General Transit Feed Spec Changes" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/gtfs-changes/-/7U2-PLnleBYJ.

> To post to this group, send email to gtfs-c...@googlegroups.com.
> To unsubscribe from this group, send email to gtfs-changes

> +unsub...@googlegroups.com.

[T Sobota]

The agency feed I cited (19 min/5.2 mile gap) was as queried through Google Transit.  Our trip data is also defined with each vehicle's block of service, not an operator's run/work assignment.

[Andrew Byrd]

Hello, 

I just received feedback from an OTP user on this subject. They expect a trip planner to tell a passenger to stay on an interlined vehicle only where the final stoptime of the first trip is identical to the initial stoptime of the second trip. The user's expectation comes from the fact that "Google [transit] uses the Block ID and the end /start trip times to link trips together. If there is a mismatch then the block is not linked." They can remove non-passenger-carrying trips, keeping the block ids for the remaining trips the same, and Google Transit does not tell passengers to stay on the vehicle.

Is this indeed the heuristic that Google uses? If so then Google Transit sees the block id as a sort of vehicle identifier that only implies continuous service under specific conditions. However, the GTFS spec says: "The block_id field identifies the block to which the trip belongs. A block consists of two or more sequential trips made using the same vehicle, where a passenger can transfer from one trip to the next just by staying in the vehicle. The block_id must be referenced by two or more trips in trips.txt." (https://developers.google.com/transit/gtfs/reference#trips_fields)

What is the proper interpretation, and should the spec be updated to reflect how this field is actually used in practice?

Thanks,

Andrew

[Brian Ferris]

It's true that historically, Google Transit only applied a block transfer when the last stop-time of the incoming trip and the first stop-time of the outgoing trip shared the same stop (but not necessarily the same arrival/departure time).  I'm not sure where the "same stop" heuristic came from, since it's not mentioned in the spec, so I've been working to get rid of that restriction in our code (though there may still be some bugs around that).

In general, I'd agree that block transfers aren't defined as clearly as they could be in the spec.  I take a pretty liberal view of block transfers: if two trips have the same block_id and the end of the incoming trip is sufficiently near in time to the start time of the outgoing trip, then they should be linked.  I think Google currently defines "near in time" as anything up to 4 hours.  Note that two trips don't have to share the same service_id, or even the same service date, to be considered for linking (eg. trip ends at 23:50 on previous date and and next trip starts at 00:05 on the next date).  When you combine block_ids and frequency-based trips, things get even weirder.

Either way, I'm all for trying to lock this down based on current usage and updating the spec.

Brian

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.

To post to this group, send email to gtfs-c...@googlegroups.com.

Visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andrew Byrd]

Questions for Brian or the rest of the list:

On 05/08/2013 12:56 AM, Brian Ferris wrote:
> I take a pretty liberal view of block
> transfers: if two trips have the same block_id and the end of the
> incoming trip is sufficiently near in time to the start time of the
> outgoing trip, then they should be linked.

Is this independent of proximity? For example, do two trips with the
same block ID, but where the end of the first trip and the beginning of
the second trip are separated by 2 hours and 50km allow a block
transfer? This example case would almost certainly be a mistake, and you
might want to detect it in a feed validator, but any accept/reject
heuristics we apply would be pretty arbitrary.

If a feed provider uses block IDs internally to indicate all trips made
by the same vehicle (i.e. to help with real-time position systems), but
they sometimes have dead runs which passengers are not allowed to use in
block transfers, it is the feed provider's responsibility to change the
block ID after a dead run that is skipped in the feed export?

-Andrew

[Brian Ferris]

We do not take proximity into account.  So in your case, yes we really would link the trips.  In practice, I'm not aware of many feeds that have this property but I agree it could come up.  You can imagine some sanity checks here, but I agree at some point the thresholds are indeed a bit arbitrary.  Yet we do have a threshold for time (4 hours).  I'm not sure of the historical context behind that number but I assume it must have come up at some point.  I could probably go back and try to generate some stats about block transfers in practice if you are interested.

Regarding the use of block_ids to indicate same-vehicle, I'd actually rather keep this property of the feed and find some way for an agency to specifically enable / disable block transfers for a particular trip.  I'd want to keep the same-vehicle block_id information because it allows consumers of the GTFS feed to potentially do their own real-time delay propagation (irrespective of whether passengers are allowed to stay on the vehicle).

I'd propose a new field like "block_transfer" in trips.txt with the following semantics:

0 - a block transfer is not possible from this trip

1 - a block transfer is possible from this trip

empty - a block transfer is possible from this trip (aka maintain the existing behavior of the spec)

This field could be used by agencies to control if block transfers are possible from a particular trip to the next trip in the block sequence.

[T Sobota]

Is there another mechanism possible, that might extend the transfers.txt file instead?

Something along the lines of allowing/barring a block transfer between an (arrival) stop_id and subsequent trip (depart) stop_id?

This would seem to vehicle "deadhead" trips (either revenue, or non-revenue, in practice) between true revenue trips - where the revenue trips end at one stop_id and resume at a different stop_id.

[RTC_Québec]

 

Hi everyone

 

Is there some news about the Brian's proposal

 

Thank you

[Andrew Byrd]

Hello,

I've run into some ambiguity while working on interlining (block transfers) and I'd like to revive this proposal from Brian Ferris.

On Thursday, May 9, 2013 at 12:13:38 AM UTC+2, Brian Ferris wrote:

Regarding the use of block_ids to indicate same-vehicle, I'd actually rather keep this property of the feed and find some way for an agency to specifically enable / disable block transfers for a particular trip.  I'd want to keep the same-vehicle block_id information because it allows consumers of the GTFS feed to potentially do their own real-time delay propagation (irrespective of whether passengers are allowed to stay on the vehicle).

The TriMet feed, for example, is already structured this way: block_id is in fact a vehicle ID. This raises the need for a new field:

I'd propose a new field like "block_transfer" in trips.txt with the following semantics:

0 - a block transfer is not possible from this trip

1 - a block transfer is possible from this trip

empty - a block transfer is possible from this trip (aka maintain the existing behavior of the spec)

This field could be used by agencies to control if block transfers are possible from a particular trip to the next trip in the block sequence.

TriMet currently uses the pick-up flag on the final stop of each trip as a stopgap replacement, but this is less than ideal.

I am in favor of this new field. However, when using block_id as vehicle_id, another issue arises which I have run into in practice in the TriMet data. There can be many trips with the same block_id that overlap in time and do not neatly chain together because they occur on different services. That is, the physical vehicle is used for different series of trips on different service_ids. The case where such trips do not chain neatly is actually less problematic because we can use heuristics to spot which sequences of trips can chain together cleanly. It becomes more difficult to judge when same-block trips have well-aligned timings on different service_ids.

OpenTripPlanner currently handles this by grouping trips by (service_id, block_id) but this is not a general solution, because more than one service ID can be active at once, and different combinations of service IDs can occur on different days. And of course grouping by a compound (service_id, block_id) is not sanctioned anywhere in the spec.

The semantics of block IDs and block transfers in the spec are vague. Let's use the new revision process to make these more clear.

Andrew