block_id in the GTFS

298 views
Skip to first unread message

Juan Borreguero

unread,
Jul 13, 2017, 10:59:55 AM7/13/17
to mtadeveloperresources
Hello,

The block_ids are not included in the trips.txt file of the GTFS for buses.

That information is returned by the Siri API though:
http://api.prod.obanyc.com/api/siri/vehicle-monitoring.json?key={......}&LineRef=B64

Would it be possible to include that information in the GTFS?

Thanks in advance.
Juan

Laidig, David

unread,
Jul 13, 2017, 11:22:11 AM7/13/17
to mtadeveloperresources

Juan,


The block_id concept in GTFS does not agree with existing nomenclature in the transit industry (see below). As such, we will not include it in the GTFS. Furthermore, the block_id exposed by the Bus Time API is sometimes generated as part of the schedule import process, and may not be an identifier that our scheduling system has access to. 


From TCRP Report 135 (1):


[Blocks] consist of a series of trips that are “hooked” together and assigned to a single vehicle. The vehicle trips that are linked together as part of the block may serve multiple routes and may be operated by multiple operators. The block refers to the work assignment for a single vehicle for a single service workday.

From the GTFS Spec (2):

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.


Since GTFS adds this quirk about passengers staying on a vehicle to the next trip, we cannot expose it and make sure that consumers will respect the industry-accepted definition.


(1) : https://www.nap.edu/read/14257/chapter/1

(2): https://developers.google.com/transit/gtfs/reference/trips-file





From: mtadevelop...@googlegroups.com <mtadevelop...@googlegroups.com> on behalf of Juan Borreguero <da...@thetransitapp.com>
Sent: Thursday, July 13, 2017 10:59:55 AM
To: mtadeveloperresources
Subject: [MTAdev] block_id in the GTFS
 
--
You received this message because you are subscribed to the Google Groups "mtadeveloperresources" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mtadeveloperreso...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Juan Borreguero

unread,
Jul 18, 2017, 4:29:05 PM7/18/17
to mtadeveloperresources
Thank you for the answer, Tony. We understand.

Other than the GTFS data, is there a way developers can have access to the blocks or, more generally speaking, to know which trip a vehicle is doing next? (through another dataset or api?)

Thanks in advance
Juan
To unsubscribe from this group and stop receiving emails from it, send an email to mtadeveloperresources+unsub...@googlegroups.com.

Michael Smith

unread,
Jul 19, 2017, 4:48:11 PM7/19/17
to mtadeveloperresources
The definition of block_id in the Google GTFS spec is indeed problematic in that it doesn't relate to what transit agencies consider a block. There is the problem that Tony pointed out in the GTFS spec wording "where a passenger can transfer from one trip to the next just by staying in the vehicle" since in-seat transfers is a completely separate issue. And there is an additional issue with "The block_id must be referenced by two or more trips" since in practice a block can consist of only a single trip.

There is currently an attempt to change how in-seat transfers are proposed to be handled that is part of gtfs.org . The GTFS spec has also been updated and can be found via gtfs.org to be at https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md . It includes the appropriate definition of block_id. The gtfs.org effort is being supported by agencies, Google, and vendors and I highly recommend that developers look at it since the Google version is still significantly behind.

Most large agencies I have worked with have not waited for the definition of block_id to be corrected. They have already added block_id info to the trips.txt by using the standard definition of blocks that Tony has provided and have simply ignored the in-seat transfer issue, which I think is the correct thing to do. This is great progress. I hope that the new definition of block_id will become the standard and that in the future NYC MTA will also provide the block_ids in their GTFS.

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

Darwin O'Connor

unread,
Jun 29, 2019, 7:30:25 PM6/29/19
to mtadeveloperresources
It seems in the years since this was originally posted, the definition of block_id has been revised so it is the continuous trip of a vehicle, not necessarily that the passenger can stay on.

Can this be added to the MTA GTFS data.

Reply all
Reply to author
Forward
0 new messages