Block transfers

[Andrew Byrd]

Hello GTFS-changes group,

In a recent discussion on the transit-developers list (CC'ed), it has come to light that many people are having problems with block_id field. We need to represent two different but interrelated things:

1. From the transit operations point of view, the "work block” of consecutive trips served by a single vehicle.
2. From the passenger point of view, the possibility of staying in a vehicle when it passes from one GTFS trip to the next.

The first item is the conventional meaning of “block”, and many GTFS producers simply export these work block IDs from their scheduling software. However, the GTFS specification document indicates that officially block_id has the second meaning (which I’ll refer to as “block transfers”).

Both kinds of information are useful. Obviously passengers need to know when they can stay on a bus as it changes from one trip to another, but even when they can’t stay onboard the block information is important for interpretation of real-time delay data.

The consensus on the transit-developers list seems to be that block_id should be redefined to represent the block of trips served by a vehicle, whether or not passengers are allowed to stay on board. This should be augmented by another field that indicates when passengers are allowed to pass from one trip to the next (make a “block transfer”).

There are several ways of expressing interlining. The two I mentioned are:
1. A boolean field in trips.txt stating whether passengers may stay on the vehicle as it passes on to the next trip in the block.
2. A string field in trips.txt giving the trip_id of the following trip when passengers may stay on board; the field would be empty when they may not stay on board.

Looking back, I see that this issue was already raised in 2013 by Brian Ferris, and mentioned again by myself in July of 2015. We should really try to get this change implemented in a producer and a consumer. Does anyone have any arguments in favor of one or the other method?

I see from past messages that Thomas Koch in the Netherlands was in favor of block transfers to specific trip_ids. I also identified a problem where chaining trips based on block_id is ambiguous, when the same block_id is used on different service_ids but multiple service_ids are active on certain days.

For both of these reasons I’m inclined to prefer the second option, but I’m wondering if this will be too difficult for feed producers.

Thanks for any input you may have,
Andrew Byrd

[Stefan de Konink]

"For both of these reasons I’m inclined to prefer the second option,"

Are you refering to the stringfield as single linked list here?


Personally I feel more for extending transfers.txt with from_trip_id and
to_trip_id. This would give better control of the transfer behavior and it
is also more generic.

Stefan

[Andrew Byrd]

Yes, by “the second option”, in data structures terms I was referring to a singly linked list where each trip has a “pointer” to the next trip in the block from the passenger perspective.

But you’re right,  there are additional options here, including your suggestion to used full fledged transfer entries in transfers.txt. I over-simplified things by conflating Thomas’s preference for trip-specific block transfers with my suggestion for a single new field in trips.txt.

There is a mature proposal for a “route-to-route and trip-to-trip transfers” GTFS extension which would already allow specifying block transfers. Supplying the fields from_stop_id, to_stop_id, from_trip_id, to_trip_id, all we would need is a new transfer_type to express a free, in-seat block transfer.

https://support.google.com/transitpartners/answer/2450962?hl=en

My only concern is that many feed producers would find this prohibitively complex to output. If they don’t have sophisticated scheduling software or custom GTFS export modules they might not be able to generate all these specific transfers, while switching on a “block transfers allowed” flag on a route or trip basis would be pretty easy for anyone.

Even some operators with fairly sophisticated IT capabilities may find this prohibitive, in the sense that all they really keep track of is vehicle work blocks and which routes allow passengers to stay on board. I suppose they could just use an entry in transfers.txt that has transfer_type of “block transfer”, but specifies a from_route and to_route instead of from_trip and to_trip. 

That does make a lot of sense as a flexible, simple way to express block transfers.

Andrew

[Thomas]

That excludes the property block_id currently has, which allows block-transfers from 1 to trip to 0...n trips as long as each trip to block-transfer to is on a different service-day. Doing so would be a significant increase to the number of trips necessary to model all block-trips (in some use-cases).

Kind regards,

Thomas Koch

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/3c588747-98da-4691-85b2-2b7ce22c9249%40konink.de.

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

[Michael Smith]

Definitely true that block_ids can be ambiguous due to the complexity of service_ids. But I don't understand the need for specifying the next trip_id as a String instead of just using a boolean to indicate that passengers can stay on board for the next trip of the block. I thought that trips in the trips.txt file are unique because the service_id is provided. This would mean that the next trip for a service_id would be unique for a block_id and would not need to be specified.

Of course this assumes that block_ids are fully specified. If blocks are not defined then would need to use a String to indicate the next trip. So is your desired for choice #2 of supplying an id for the next trip due to the block_id info not always being defined?

By the way, my impression is that "interlining" commonly means a block assignment serves multiple routes, not that a passenger can stay on board at the end of a trip and continue on the next trip. Is your impression of how the term is used different?

Mike

--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.

[Andrew Byrd]

> On 05 Jan 2016, at 20:07, Michael Smith <msmith...@gmail.com> wrote:
> By the way, my impression is that "interlining" commonly means a block assignment serves multiple routes, not that a passenger can stay on board at the end of a trip and continue on the next trip. Is your impression of how the term is used different?

I may be using the term incorrectly because I’ve only used it informally in the context of passenger information systems. Come to think of it, we may have started out saying “interline transfer” and sloppily shortened that to “interlining” in casual usage. We can stick to the terminology “block transfer” from the original proposal if that’s more clear and correct.

Andrew

[Benoit Boissinot]

On Tue, Jan 5, 2016 at 1:04 PM, Andrew Byrd <and...@fastmail.net> wrote:

Hello GTFS-changes group,

In a recent discussion on the transit-developers list (CC'ed), it has come to light that many people are having problems with block_id field. We need to represent two different but interrelated things:

1. From the transit operations point of view, the "work block” of consecutive trips served by a single vehicle.
2. From the passenger point of view, the possibility of staying in a vehicle when it passes from one GTFS trip to the next.

The first item is the conventional meaning of “block”, and many GTFS producers simply export these work block IDs from their scheduling software. However, the GTFS specification document indicates that officially block_id has the second meaning (which I’ll refer to as “block transfers”).

Both kinds of information are useful. Obviously passengers need to know when they can stay on a bus as it changes from one trip to another, but even when they can’t stay onboard the block information is important for interpretation of real-time delay data.

For realtime data purpose, could it be simpler to have it in the realtime spec? For GTFS-RT you could "link" trips by specifying the same vehicle id and preannouncing the following trip early enough.

This would provide the same information, but be more flexible.

The consensus on the transit-developers list seems to be that block_id should be redefined to represent the block of trips served by a vehicle, whether or not passengers are allowed to stay on board. This should be augmented by another field that indicates when passengers are allowed to pass from one trip to the next (make a “block transfer”).

There are several ways of expressing interlining. The two I mentioned are:
1. A boolean field in trips.txt stating whether passengers may stay on the vehicle as it passes on to the next trip in the block.
2. A string field in trips.txt giving the trip_id of the following trip when passengers may stay on board; the field would be empty when they may not stay on board.

Looking back, I see that this issue was already raised in 2013 by Brian Ferris, and mentioned again by myself in July of 2015. We should really try to get this change implemented in a producer and a consumer. Does anyone have any arguments in favor of one or the other method?

I see from past messages that Thomas Koch in the Netherlands was in favor of block transfers to specific trip_ids. I also identified a problem where chaining trips based on block_id is ambiguous, when the same block_id is used on different service_ids but multiple service_ids are active on certain days.

For both of these reasons I’m inclined to prefer the second option, but I’m wondering if this will be too difficult for feed producers.

Thanks for any input you may have,
Andrew Byrd

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/649E3215-C83E-4EF3-8E2F-A36DC421235C%40fastmail.net.

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

--

:wq

[Andrew Byrd]

Hi Michael,

> On 05 Jan 2016, at 20:07, Michael Smith <msmith...@gmail.com> wrote:

> Definitely true that block_ids can be ambiguous due to the complexity of service_ids. But I don't understand the need for specifying the next trip_id as a String instead of just using a boolean to indicate that passengers can stay on board for the next trip of the block. I thought that trips in the trips.txt file are unique because the service_id is provided. This would mean that the next trip for a service_id would be unique for a block_id and would not need to be specified.

This would be true if it were possible for only a single service_id to be active on a given day, but GTFS allows several services to be active at once. The sequence of trips on each block could be apparent for a given set of active service_ids, simply based on first and last departure/arrival times of trips. However:

1. This assumes the GTFS data is clean, with no two trips on the same block_id and set of service_ids active at the same time. Data exports often contain errors, and an error here could require the consumer to guess the trip sequence using inexact heuristics. It is harder to detect errors when there is less redundant information and the consumer is reconstructing implicit details. It is harder for the producer to fix these details when they don’t know exactly how the consumer is inferring them.

2. The sequence of the trips for a particular block can be different on each day, even changing between two days when one of the same service_ids is active. This requires the GTFS consumer to determine every actually occurring combination of service_ids, reconstruct the chain of trip_ids for every block independently for each combination of service_ids, and retain each of those chains separately for each combination of service_ids. This seems like a lot of error-prone steps to reconstruct information that may already be present on the producer’s side but was collapsed down into only the block_id.

Adding a single “next trip_id in block” field to trips.txt (as I suggested) creates a one-to-one block transfer relationship (one trip to one other trip), which conflicts with #2 above. This is the point Thomas made: my suggestion does not allow block transfers to be one-to-many (one trip to multiple other trips, with the target trip changing from day to day). Adding a single boolean field is similarly problematic: just because a passenger may do a block transfer from trip A to the following trip on weekdays does not mean block transfers from trip A are allowed on weekends, when the same vehicle is serving a different trip after A.

I suspect that one-to-many block transfers will show up in real data sets, so this possibility should be preserved. Thomas and Stefan’s suggestion was to treat block transfers as normal transfers in transfers.txt, which would allow a large set of different rules with different specificities (trip level, route level, stop level). There would be no need for exhaustive reconstruction of blocks on different combinations of service_ids because the transfer entries would allow reconstruction of the chains on the fly, at runtime.

It is also worth noting that block transfers are not usually a characteristic of single trips. They are relationships between one large group of trips (usually all the trips on a route A) and another large group of trips (all the trips on a second route B) at a particular pair of stops (the end of route A and the beginning of route B). The transfers.txt solution allows more readable data through abstraction: we can make a rule that transferring from the last stop of route A to the first stop of route B is always a free, in-seat block transfer whenever that possibility arises on an actual day of service.

Considering all these points, I don’t see any viable, complete alternative to Stefan and Thomas’s transfers.txt solution.

The important deciding questions are:
1. Do one-to-many block transfer relationships occur in the wild?
2. Is it prohibitively difficult to implement any of these options for the producer? GTFS is supposed to encourage data sharing by being easy to implement.
3. Is it prohibitively difficult to implement any of these options for the consumer? Based on our past experience more specific transfers (trip-specific or route-specific) are not to bad to deal with.

Can anyone familiar with scheduling / run cutting software testify about export implementation challenges? What about the perspective of hand-rolled GTFS?

-Andrew Byrd
(By the way, after this message I’ll post only to GTFS-changes which I believe to be the proper forum for this discussion.)

[Stefan de Konink]

On Wed, 6 Jan 2016, Andrew Byrd wrote:

> The important deciding questions are:
> 1. Do one-to-many block transfer relationships occur in the wild?

Would https://en.wikipedia.org/wiki/Portion_working count?

Stefan

[Stefan de Konink]

Thomas also suggested that one-to-many do exist because of another reason:
different block validities dependent on service dates. The latter also
suggests that adding an optional service_id to transfers.txt for
route-to-route and trip-to-trip transfers might be required.

Joel suggested that the alternative is to see a different validity as a
different trip. Solving this problem without a calendar.

Stefan

[Andrew Byrd]

Yes, I think portion working could easily lead to this kind of data. Say train A runs every day of the week from city X to city Y, so it’s on service ID “every_day”. On weekdays it’s coupled to a service going from Y to city Z, and they proceed together as a unit; on weekends that service from Y to Z is less frequent with different timings. Therefore there are different trips from Y to Z on service_id weekday than on service_id weekend. However, one could argue that the first XY trip should just be represented as an XYZ trip. It’s a question of data compactness, ease of export, and clarity: combining the two into XYZ might go against the operator’s logical naming of trips and routes.

This situation could arise even without portion working if the same single, uncoupled train going from X to Y at the same time every day continued on to Z with different schedules on weekdays and weekends, with the segment from Y to Z being considered a separate logical route or trip by the operator.

If you can find real-world examples of this happening in e.g. the Netherlands train data, I think you have a strong argument in favor of your transfers.txt solution.

Andrew

[Stefan de Konink]

On Wed, 6 Jan 2016, Andrew Byrd wrote:

> If you can find real-world examples of this happening in e.g. the Netherlands train data, I think you have a strong argument in favor of your transfers.txt solution.

We have real world examples for Dutch Railways (NS) and Conexxion as bus
operator. Google eats the data already in this format.

Stefan

[Andrew Byrd]

Meaning Google consumes and uses the extended transfers.txt for what we’re calling block transfers? Have you defined another integer transfer type in transfers.txt representing a free block transfer?

Andrew

[Thomas]

What Stefan de Konink was meaning was that Google supports one-to-many (but one-to-one per serviceday) block-transfer using block_id and that this functionality is used within the Netherlands dataset occasionally. This functionality is supported by Google 

Transit as shown by what happens with the validation if two traps in the same block overlap on the same serviceday:

Block Trips with Overlapping Stop Times
Two trips were found in the trips.txt file with the same block_id value and overlapping stop times. Two trips in the same block should not have overlapping stop times if both trips are active on the same service date. Specifically, the last departure time of a trip in a block should be less than or equal to the first arrival time of the next trip in the block.
For more information, see The Transit Partners Help Center
Specific problem instances:

• Trip with id 33817673 (row 389608) with service id 28 and the trip with id 33833616 (row 373548) with service id 28. The first intersection of these services is 2016/01/04. (Block id 185873).

Kind regards,

Thomas Koch

Andrew

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/FAF86618-56FC-4336-9F60-3D7DA78A6043%40fastmail.net.

[Joris Wu]

transfers.txt operates on stops, not on trips or routes. So any service that has 'can stay onboard' at a given stop cannot be handled if the same stop is serviced by an unrelated service.

I vote for option 2, using strings as that reserves this field for the passenger view ( and journey planner ! )
The block_id can then be used for the operator view.

Otherwise, I would vote for extending transfers.txt to include a from_route_id and to_route_id (these can be equal) to specify what route change the entry applies to.

[Stefan de Konink]

On Thu, 7 Jan 2016, Joris Wu wrote:

> transfers.txt operates on stops, not on trips or routes.

Please review what is already active for Google Transit below.

https://support.google.com/transitpartners/answer/2450962


Stefan

[Joris Wu]

Reading on Google's own Best Practices document, it looks like block_id has been meant for 2, passenger point of view only.
Related, the description of 'route' mentions it should match the information provided to riders. Thus, in general, GTFS looks like meant to represent the passenger view of things. At least if the 'G' means Google, not General.

[Andrew Byrd]

Hello,

I discussed block transfers yesterday with TriMet. We are cooperating with them to implement the approach suggested by Stefan and Thomas (route-specific or trip-specific entries in transfers.txt) on both the data provider and consumer side. 

TriMet already supplies block IDs indicating a sequence of trips served by a vehicle. They generally allow riders to stay on board a vehicle (i.e. block transfers are usually allowed), but at a small number of locations all passengers must alight. Rather than exhaustively list every place where a block transfer is allowed, they will supply trip-specific transfers.txt entries for each of these occasions when a block transfer is not allowed. This reflects the way their source data is organized: there is no exhaustive list of block transfers, only per-trip block IDs and indications where block transfers are forbidden.

Either way (exhaustive list or exception list) we need some new transfer types in transfers.txt. Types 0-3 are already defined. I propose that we add types 4 and 5, defined as follows:

4: In-seat transfer between these two stops / routes / trips is allowed

5: In-seat block transfer not allowed (even if two trips on the same block ID can be chained end to end here, the passenger must alight and walk to transfer between them)

Our plan is to assume that if a feed producer supplies block IDs, block transfers must be possible within their network and only exceptions need be supplied in transfers.txt. A data producer could on the other hand choose not to supply block IDs, and instead list all allowed block transfers in transfers.txt for complete clarity.

Does anyone have any comments or criticism of this approach before we begin working on it?

Thanks,

Andrew Byrd

[Joris Wu]

The only issue I see is backward compatibility : feeds that currently populate a block_id will under this proposal get assumed passengers can stay aboard, whilst this is not always true. As feeds unfortunately do not mention what GTFs revision it follows, consumers do not know what the block_id is meant to signify if there is no indication in the feed whether the proposal is implemented.

Just realizing while writing that this is more general for any spec changes. Ideally, a feed should have a mandatory feed_info.txt containing the spec revision it implements.

If transfers.txt would contain both exceptions and the norm, then the mere presence of type 4 and 5 is conclusive. That would mean consumers can ignore block_id (as the meaning of this field in existing feeds is currently ambiguous) unless transfers.txt contains relevant info.

With exceptions only, one would need to assume that the mere presence of at least a single exception in transfers.txt signified this proposal is implemented. This means that if there are no exceptions, there is no way to conclude that by inspecting a feed.

I would be wary for retrofitting an interpretation on existing and older feeds, hence my view that feeds not implementing your proposed approach may have block_id's populated without knowing what it exactly means in terms of transfers.

In practice, a single type 4 entry would suffice to suggest the approach is implemented.

Joris

[Michael Smith]

My impression from working with a good number of agencies is that they typically don't allow passengers to remain on board during block transfers. Therefore assuming that passengers can stay onboard unless specifically disallowed via the transfers.txt file would most likely be wrong more often than correct. So it will work for Trimet but I think it will be a determinant for other agencies.

Mike

--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to transit-develop...@googlegroups.com.

[Andrew Byrd]

> On 16 Feb 2016, at 05:56, Michael Smith <msmith...@gmail.com> wrote:
> My impression from working with a good number of agencies is that they typically don't allow passengers to remain on board during block transfers.

The terminology we’re using hasn’t always been clear, but I think we’ve defined a block transfer as “a passenger staying on board a vehicle when it changes trips, and being allowed to do so”. To use that terminology, we could simply say that many or most agencies don’t allow block transfers.

> Therefore assuming that passengers can stay onboard unless specifically disallowed via the transfers.txt file would most likely be wrong more often than correct. So it will work for Trimet but I think it will be a determinant for other agencies.

The current GTFS spec says that the whole point of block IDs is to show when such a block transfer is allowed. If the agency didn’t allow block transfers, wouldn’t they just not include block IDs? I suppose they might want to include block IDs even when block transfers are forbidden to assist in real-time delay propagation across trip boundaries.


In that case maybe we just need a feed-wide variable to say whether there is a blanket policy allowing or disallowing block transfers.

Andrew

[Aaron Antrim]

On Tue, Feb 16, 2016 at 4:14 AM, Andrew Byrd <and...@fastmail.net> wrote:

> Therefore assuming that passengers can stay onboard unless specifically disallowed via the transfers.txt file would most likely be wrong more often than correct. So it will work for Trimet but I think it will be a determinant for other agencies.

The current GTFS spec says that the whole point of block IDs is to show when such a block transfer is allowed. If the agency didn’t allow block transfers, wouldn’t they just not include block IDs? I suppose they might want to include block IDs even when block transfers are forbidden to assist in real-time delay propagation across trip boundaries.

I'll speak to Trillium's practice here. Until recently, we generally included block_id values only in cases when an in-seat transfer was possible, in accordance with the Spec, "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." Essentially, the only consuming application type we considered was a trip planner. However, more recently, we have begun to provide block_id in a way that is useful for AVL/arrival estimates, only in a small but growing minority of feeds we publish.

It would certainly be useful to have a broader survey of practice to inform the decision of how to change the Spec to provide block transfers.

--

Aaron Antrim, Principal

Trillium Solutions, Inc.
www.trilliumtransit.com
Portland, Oregon
503.567.8422 ext. 3

[Dave Barker, MBTA]

The MBTA's public GTFS feed includes blocks for all our bus and subway service. Our developer community has expressed an interest in this data. It also may prove valuable in future AVL projects. We also have a separate GTFS feed, not publicly documented, that only includes the block_id's for trips on which "block transfers" are allowed. This version is used by a small number of feed consumers. 

Since it would allow us to eliminate a special-case GTFS feed, we would be a beneficiary if the spec was changed to address this issue. We would be able to support either option. Since option 1 (boolean) is easier for producers, and option 2 (trip_id of next trip) is easier for consumers, it's hard to choose between them. But option 2 more precisely represents the idea we are trying to capture. Also suppose that trips allowing block transfers are being represented in frequencies.txt; for example, route 1 runs every 5 minutes and you can always block transfer from the outbound trip to the inbound trip. This can be represented in option 2 but not in option 1. 

-Dave Barker, MBTA

[Devin Braun]

For San Diego's GTFS files, we had always used block_id in its scheduling sense as a group of trips operated by a vehicle. However, we were forced to change this field to in-seat transfers only as Google Maps was drawing deadhead links between two stops served by the same vehicle in the Transit layer, causing lines to criss-cross the map.

For any agencies who use the HASTUS scheduling system, the built-in GTFS export uses block_id for a vehicle's task, not to signify in-seat transfers, so switching block_id to this definition could be a benefit to many agencies who are probably unknowingly publishing their feeds this way.

[Mike Gilligan (TriMet)]

Until this became a bigger issue for TriMet, I had never read the `block_id` description in GTFS: https://developers.google.com/transit/gtfs/reference#trips_block_id_field. Google's description does not represent our original intent when we worked to develop the spec. I would suggest we change the spec language to match the industry standard and create an explicit agency controlled mechanism for defining passenger interlining.

+1 for the transfers.txt option here: https://groups.google.com/d/msg/gtfs-changes/PkNAWbN9wcs/LFEqHGemBAAJ

[Sean Barbeau]

On a related note, does anyone have statistics on how many feeds include block IDs

An aside, related to the previous discussion of best practices and GTFS feed registry - this is a perfect example of a question that a centralized feed registry could be capable of answering, which could help create data-driven best practices.  Transit.land is moving in this direction.

On Thursday, February 18, 2016 at 11:11:32 AM UTC-5, Ritesh Warade wrote:

+1 for changing the spec per Mike from TriMet’s email. Blocks mean something very specific for transit - the sequence of trips that a vehicle will perform - and do not mean passenger interlining.

 

---

Ritesh Warade, IBI Group

--

You received this message because you are subscribed to the Google Groups "Transit Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to transit-developers+unsub...@googlegroups.com.

[Ritesh Warade]

+1 for changing the spec per Mike from TriMet’s email. Blocks mean something very specific for transit - the sequence of trips that a vehicle will perform - and do not mean passenger interlining.

 

---

Ritesh Warade, IBI Group

 

From: transit-d...@googlegroups.com [mailto:transit-d...@googlegroups.com] On Behalf Of Mike Gilligan (TriMet)
Sent: Thursday, February 18, 2016 11:08 AM
To: General Transit Feed Spec Changes <gtfs-c...@googlegroups.com>
Cc: transit-d...@googlegroups.com
Subject: [transit-developers] Re: Block transfers

 

Until this became a bigger issue for TriMet, I had never read the `block_id` description in GTFS: https://developers.google.com/transit/gtfs/reference#trips_block_id_field. Google's description does not represent our original intent when we worked to develop the spec. I would suggest we change the spec language to match the industry standard and create an explicit agency controlled mechanism for defining passenger interlining.

--

You received this message because you are subscribed to the Google Groups "Transit Developers" group.

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

[Ritesh Warade]

@sean

http://transitfeeds.com/ might also have this info.

 

---

Ritesh Warade, IBI Group

 

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

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

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/c0ba71bc-4189-4233-87d9-95109c3ff0ff%40googlegroups.com.

[Frank]

+1 for changing the gtfs spec around block_id to match the industry standard definition.
     My reasons:
       a) as is, the spec is confusing by use of the word block_id.
       b) representing a block transfer with just block_id, in situations where not all trips thru-out the day allow a customer to "Stay on board" doesn't work.
       c) having block_id is very useful across all trips, regardless if they allow a customer to 'Stay on board' thru a block transfer or not.

+1 for hashing out and adopting Andrew's suggestions to thus specify block transfers via the transfers.txt file.

[Stefan de Konink]

On Thursday, February 18, 2016 8:24:04 PM CEST, Frank wrote:
> +1 for changing the gtfs spec around block_id to match the
> industry standard definition.
> My reasons:
> a) as is, the spec is confusing by use of the word block_id.
> b) representing a block transfer with just block_id, in
> situations where not all trips thru-out the day allow a customer
> to "Stay on board" doesn't work.
> c) having block_id is very useful across all trips,
> regardless if they allow a customer to 'Stay on board' thru a
> block transfer or not.
>
> +1 for hashing out and adopting Andrew's suggestions to thus
> specify block transfers via the transfers.txt file.

Which has been consumed in Google Transit for a while ;)

https://support.google.com/transitpartners/answer/2450962?hl=en


--
Stefan

[Frank]

Correct.  On the shoulders of giants.

[Andrew Byrd]

Hi Dave,

On 18 Feb 2016, at 16:31, Dave Barker, MBTA <dba...@mbta.com> wrote:

We also have a separate GTFS feed, not publicly documented, that only includes the block_id's for trips on which "block transfers" are allowed. This version is used by a small number of feed consumers. 

I can certainly see why you’d want to eliminate this double feed situation. A clear consensus seems to have emerged that the simple presence of block IDs in a GTFS feed does not imply that block transfers are allowed.

We would be able to support either option. Since option 1 (boolean) is easier for producers, and option 2 (trip_id of next trip) is easier for consumers, it's hard to choose between them.

These two proposals turned out to be inadequate because they cannot deal with a single trip A interlining to two different trips B and C on two different service IDs. For this reason (among others) Stefan and Thomas advocated the GTFS extension they use in the Netherlands: trip-specific and route-specific transfers, which are already understood and consumed by Google.

At this point they, Frank and others at TriMet, and I are all in favor of using the transfers.txt extension to allow or disallow specific block transfers. As mentioned in my email of Feb 15th, beginning with the "Route-to-route and trip-to-trip transfers” section of the existing transfers.txt extension (https://support.google.com/transitpartners/answer/2450962) we will need to add two new transfer types (https://groups.google.com/d/msg/gtfs-changes/PkNAWbN9wcs/LFEqHGemBAAJ).

This leaves one thing unsolved though: I know that TriMet does not want to exhaustively list all their block transfers since block transfers are usually allowed in their system, so their scheduling system only contains information about block transfers being disallowed. They want to use transfers.txt to force certain exceptional block transfers on or off. So we need some way to declare that block transfers are allowed by default and inferred from block_ids. This could be at the feed level, the agency level, the route level… Mike or Frank (or anyone else), at what level would it be appropriate to declare that block transfers are generally allowed?

-Andrew

[Mike Gilligan]

Andrew-

I could explicitly supply both allowed and disallowed passenger interlines in transfers.txt. Not a big deal for me. However, I think it would be good for consumers to have a `default` behavior based on the existing `block_id` field, if no transfers.txt values are present. I believe that default behavior would be "allow passengers to stay on board between trips if `block_id` is the same unless explicitly disallowed via transfer.txt".

-Mike Gilligan
TriMet

[Aaron Antrim]

On Thursday, February 18, 2016 at 1:40:21 PM UTC-8, Mike Gilligan wrote:

I think it would be good for consumers to have a `default` behavior based on the existing `block_id` field, if no transfers.txt values are present. I believe that default behavior would be "allow passengers to stay on board between trips if `block_id` is the same unless explicitly disallowed via transfer.txt".

+1 to Mike Gilligan's proposal above.

Trillium can begin providing feeds that follow this shortly.

[Sean Barbeau]

I believe that default behavior would be "allow passengers to stay on board between trips if `block_id` is the same unless explicitly disallowed via transfer.txt".

+1
 

[Andrew Byrd]

On Thursday, February 25, 2016 at 9:50:58 PM UTC+1, Aaron Antrim wrote:

On Thursday, February 18, 2016 at 1:40:21 PM UTC-8, Mike Gilligan wrote:

I think it would be good for consumers to have a `default` behavior based on the existing `block_id` field, if no transfers.txt values are present. I believe that default behavior would be "allow passengers to stay on board between trips if `block_id` is the same unless explicitly disallowed via transfer.txt".

While convenient, it seems to me that such a default would be ignoring two of the earlier conclusions of this conversation: most operators do not allow block transfers, and the mere presence of block IDs should not imply block transfers (since block IDs are also useful for interpreting realtime data).

Considering the support I saw for both of those statements, I'd say block transfer behavior should have to be switched on. I think the main question is where it is switched on: the whole feed, the agency, or the route.

-Andrew

[Aaron Antrim]

I propose that we revive this important discussion thread about block transfers. The last discussion was in March 2016. There was strong expressed support for the proposal from Andrew Byrd, developed in collaboration with TriMet and others: https://groups.google.com/d/msg/gtfs-changes/PkNAWbN9wcs/LFEqHGemBAAJ

We left off with the question of what the default interpretation of the presence of block_id should be when there are not records in transfers.txt that set in-seat transfer rules. Here is a summary of positions:

1.) When not set by transfers.txt, then block_id transfers should be assumed to be allowed, because that is what the Spec currently defines

2.) When not set by transfers.txt, then block_id transfers should be assumed to be disallowed, because most agencies do not intend that in-seat transfers are allowed between subsequent trips

Does everyone find this to be an accurate summary of where we left off? As GTFS is being used as an input for real-time prediction systems more, it is becoming more urgent to clarify and amend the Spec.

[Barbeau, Sean]

+1 for putting this into an official proposal via Github.

 

Sean

--
You received this message because you are subscribed to a topic in the Google Groups "General Transit Feed Spec Changes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gtfs-changes/PkNAWbN9wcs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gtfs-changes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/edf5f859-a5de-4df6-a1f2-167376e6194c%40googlegroups.com.

[Stefan de Konink]

While we are at it. Could we pretty please also have the combination of
route_id/trip_id + stop_id a valid pair for transfers.txt? Rationale: for
this trip never transfer at stop X.

Stefan

[Dave Barker, MBTA]

Aaron, 

Thank you for reviving this discussion. I'm enthusiastic about adding the ability to define, in transfers.txt, the route or trip pairs on which in-seat transfers are (or aren't) possible. 

Regarding the question of default behavior, could an agency set the default behavior for their own GTFS feed, either through a line in transfers.txt that sets in-seat transfers as on or off without specifying route or trip, or in a new feed_info field? I ask this because at an agency that allows very few in-seat transfers we would find it cumbersome to mark every combination of routes that might appear on the same block and for which an in-seat transfer must therefore be explicitly blocked; however for an agency that mostly allows them it would be just as cumbersome to list all the places where it could be done. 

I lean towards option 2 (assumed to be disallowed), partly because I do think it reflects the majority of agencies, and partly because in the event of ambiguity I think it's safer for a trip planner not to assume that in-seat transfers are possible. 

-Dave Barker, MBTA

[Aaron Antrim]

I created a pull request here: https://github.com/google/transit/pull/32

The pull request:

• brings in Google's GTFS extensions for route-to-route and trip-to-trip transfers:
  https://developers.google.com/transit/gtfs/reference/gtfs-extensions#TripToTripTransfers
• allows overrides to in-seat block transfers
  
• proposes a new field, agency.disallow_block_transfer

Let's move discussion over to the pull request.

[Aaron Antrim]

I'm anxiously anticipating comments on this pull request for new transfer types :). Crickets so far.

https://github.com/google/transit/pull/32

Do people think this proposal is viable & worthwhile? Should it be changed?

[Aaron Antrim]

Discussion to change the Spec with regard to "block [in-seat] transfers" has continued over here: https://github.com/google/transit/pull/32

Currently, everyone has proposed that we change the Spec so that block transfers are not assumed by default. This technically breaks backwards compatibility with the Specification as written, but may not actually break with most current practice.

Before proceeding, let's survey feed producers again:

Do you publish a GTFS feed? Do you assume that in-seat transfers are allowed or not allowed by default when block_id values are supplied? If you have not already commented, please post in GitHub here: https://github.com/google/transit/pull/32

[Devin Braun]

San Diego MTS - We do not assume that block transfers are allowed by default.  We use the field to signify a chain of trips operated by the same vehicle (a vehicle task). 

In most cases, block transfers are allowed, but there are some deadheads between trips with different routes where transfers/through riders aren't allowed.

--

You received this message because you are subscribed to a topic in the Google Groups "General Transit Feed Spec Changes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gtfs-changes/PkNAWbN9wcs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to gtfs-changes+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/8a0bcac5-a5bf-42f3-b81d-46f28448e208%40googlegroups.com.

[Aaron Antrim (Trillium)]

This discussion has been dormant for some time, but the unresolved issue means that it is not presently possible to specify blocks for all trips (useful for arrival prediction software) AND to precisely specify in-seat transfer availability.

I have had various discussions with feed producers and consumers, and have revived a proposal to preserve backward-compatibility with the current Spec, set agency-wide defaults for in-seat transfer rules, and specify overrides that reference stops, trips, and routes here: https://github.com/google/transit/pull/32#issuecomment-303248307

Your reaction and comments will help move this along. I've proposed we shoot for 2 weeks of discussion before moving to a vote. So, please bring any comments up here or on GitHub.

--

Aaron Antrim
Technical Lead, Interoperable Transit Data
Project of Rocky Mountain Institute's Mobility Transformation Program
www.rmi.org/ITD

Principal Consultant, Trillium
www.trilliumtransit.com/blog/

[Aaron Antrim (Trillium)]

I've called the vote on pull request #32. Voting closes next Tuesday, 6/13.

https://github.com/google/transit/pull/32

[Aaron Antrim (MobilityData)]

Discussion has resumed on pull request #32 - "transfer rules for routes and trips, and in-seat transfers".

https://github.com/google/transit/pull/32

We are exploring whether there is a path forward for implementation in software and spec amendment.

To recap, the proposal includes:

- elements from Google’s route-to-route and trip-to-trip transfers extension, with the introduction of transfer_type=4 [in-seat transfer; more discussion below].

- backwards compatible changes to provide block_id without also also implying the availability of in-seat transfer.

The previous proposal had appeared to reach consensus, but was stalled for lack of implementations.

If you represent a GTFS consumer or producer who would implement (or has objections), please comment on the GitHub thread!

https://github.com/google/transit/pull/32