--
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.
--
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.
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
--
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.
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).
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.
--
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.
> 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.
On a related note, does anyone have statistics on how many feeds include block IDs
+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.
+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.
@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.
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.
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.
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".
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".
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 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.
--
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.