Use of block_id together with required arrival_time and departure_time makes contradictory information too easy

[bradyhunsaker]

Introduce yourself

I have previously contributed some code changes to the GTFS validator; I'm not associated with any particular feed.

Ask a question

I recently noticed contradictory data creating a poor display with the feed for Park City Transit as displayed by Transit App. I believe other feeds that use block_id may do the same thing.
https://mobilitydatabase.org/feeds/gtfs/tld-1325

Transit App displays two arrivals with different headsigns and sometimes different times (within a few minutes) when in reality there is a single vehicle. I attached a screenshot showing the situation. This is a bad user experience, of course, since it's not clear which headsign is correct or which time is correct.

I first describe the technical issue and then mention two possible ways to improve the situation.

Technical issue:
The feed uses block_id for vehicles, both at end stations and at a significant transit station where they have trips starting and ending but to some passengers is just an intermediate stop.

The arrival_time and departure_time for the last stop of trip A do not match the arrival_time and departure_time for the first stop of trip B.

Example: Vehicle arrives at 9:00 and departs at 9:02.
Feed shows:
trip A and trip B in the same block
trip A final stop: stop alpha, arrive 9:00, depart 9:00
trip B first stop: stop alpha, arrive 9:02, depart 9:02

Since arrival_time and departure_time are both required, even at starting and ending stops, the feed uses the recommended approach of using the same time for both. But this creates contradictory data.

Transit App shows a departure at 9:00 using the headsign for trip A and a departure at 9:02 using the headsign for trip B.

Ideas to improve the situation; either one or both would help, I think:

• Require that arrival_time and departure_time both match (or are omitted, if the second suggestion is adopted) for trips connected by a block_id. We can add a check in the validator tool to help feeds avoid the inconsistent data.

• Do not require a departure_time on the final stop of a trip or an arrival time for the first stop of a trip. Encourage feeds to omit these times unless they are meaningful. Why are they required when they are generally meaningless?

[miklcct]

There is no problem here. It indicates that trip A will stop service at 09:00, while trip B will start service at 09:02. There are 2 minutes of downtime where the vehicle is at rest. My suggestion to modify the spec is to not require a departure_time at the final stop and not require an arrival_time at the first stop.

The frontend I am working omits the time from departure boards if it is the final stop of a trip.

[felixguendling]

trip A and trip B in the same block
trip A final stop: stop alpha, arrive 9:00, depart 9:00
trip B first stop: stop alpha, arrive 9:02, depart 9:02

Since departure at the last stop and arrival at the first stop are redundant, it should be easy to omit them from departure/arrival boards as @miklcct described. In MOTIS we ignore this information completely as it's not required for trip planning nor for any kind of departure/arrival boards and can only lead to inconsistencies.

[miklcct]

Shall we make a proposal to make these fields optional?

[felixguendling]

I guess we've reached the topic of backward compatibility / versioning once more.

As current software (GTFS parsers) might rely on these fields being present/populated everywhere, it could mean that a software that's 100% conforming to the current GTFS-standard right now might not be able to parse a GTFS compliant dataset in the future due to missing (optional) values for arrival_time and departure_time. In my interpretation this change would therefore not be backward compatible.

Since backward compatibility came up already for the cars_allowed discussion, and will probably come up more and more, I think it would make sense to have a general discussion about the evolution of the GTFS standard (including GTFS-RT, see ADDED). Even if this discussion leads to the consensus that GTFS will never have (semantic?) versioning and we can't make any changes that are not backward compatible, this would still be valuable to know as it would hopefully come with a clear definition of which changes are allowed and which changes are not allowed.

Anyway, I would support making arrival_time of the first departure and departure_time for the last arrival optional.

[gcamp]

One issue we've seen is that some agencies use block_id to link multiple trips that don't end start at the same location. In this case, we would want to show a departure from the end stop from the first trip. Admittedly, it doesn't look right because it's in the same stop.

I'm not against making arrival/departure time optional in the right context, but should we also enforce the first/last stop of a in-seat transfer be exactly the same?

Right now, block_id don't enforce anything and in-seat transfer via trip to trip transfer has a lax requirement The last stop of from_trip_id SHOULD be geographically close to the first stop of to_trip_id.

[felixguendling]

but should we also enforce the first/last stop of a in-seat transfer be exactly the same?

+1

[miklcct]

but should we also enforce the first/last stop of a in-seat transfer be exactly the same?

+1

When we do interlining, how do we deal with drop_off_type and pickup_type? How should we represent the case where the incoming trip drops off passengers at an alighting only stop, then a new trip is started on another route with 2-minutes changeover time, the vehicle moves forward to a boarding only stop to pick up passengers?

[bradyhunsaker]

OK. I hadn't realized the flexibility around using block_id.
I can imagine an example:

• A vehicle completes a trip at stop A, the end of the route, arriving and departing at 9:00.
• It goes to some nearby waiting area for a while. Riders cannot stay on the vehicle.
• Then it comes back and starts a new return trip at stop A, arriving and departing at 9:30.

In this example it would be correct to have the same stop and correct to have different times.

This indicates that my first suggestion of requiring that arriving and departing times match wouldn't be correct in every case.

So the real problems with the feed above are:

• It should use transfers.txt to indicate which of these connected trips allow in-seat transfers.
• Less important: It should put accurate arrive and depart times for the stops at transit stations, though correct use of transfers.txt would probably make this less important.

I think we can close this issue as working-as-intended.

I'll think about whether there's a way the validator could detect this "omission of transfers.txt" and create a warning. If I can think of a reasonable approach I'll create a separate issue proposing that.

[felixguendling]

When we do interlining, how do we deal with drop_off_type and pickup_type? How should we represent the case where the incoming trip drops off passengers at an alighting only stop, then a new trip is started on another route with 2-minutes changeover time, the vehicle moves forward to a boarding only stop to pick up passengers?

I see two options (in case last stop + first stop have to match):

• If passengers are allowed to stay seated, the part where if moves forward can just be assigned to the first trip (or to the next trip). This probably does not mirror the operational view on those trips and is hard to achieve if the GTFS timetable is a stripped down dump from the operational data. But from a customer / routing perspective this change would do the job.
• If passengers are not allowed to stay seated, it's just two separate trips and no case for block_id or transfer_type=4.

[leonardehrenfried]

A bit off-topic but there is a complication to this: agencies put block_id into their feeds (for operational reasons, presumably) but it's unclear whether this means that it's a stay-seated transfer or not, because the spec is silent on this topic. You could reasonably assume that it just means that the same bus services multiple trips, nothing else.

HOWEVER, Google does treat block_id as stay-seated: https://developers.google.com/transit/gtfs/examples/block-transfer-example

This is a very unfortunate situation that is quite confusing and I cannot see a good way out. For that reason we (OTP) allow you to configure whether block_id means a stay-seated or not.

[felixguendling]

IMO the fact that it's the same bus is an operational detail and quoting from the front page of gtfs.org, GTFS is a "standard for rider-facing transit information". So any operational detail not relevant for riders (stay seated = relevant, same vehicle without stay seated = not relevant for riders) should be omitted as there are other standards for this purpose. Some might say that this information is required to propagate delays. However, this is not the job of a GTFS-RT consumer. A proper delay prediction requires way more information than just that and should be done on the GTFS-RT producer side. So again, there's no need to have the "same vehicle" information in GTFS unless it's a stay-seated transfer. My proposal would be to standardize the Google Maps approach of interpreting block_id as stay-seated (also because the majority of feeds are tailored to Google Maps anyway and I think this won't change for a long time).

[gcamp]

I don't think we can get out of the problematic interpretation of block_id until everyone moves to trip to trip transfers (which is probably never!). Even inside the same feed, some block_id are used as in-seats and others are just vehicle without in-seat transfer. I don't know the details, but I think Google maps also has some heuristics too (or internal configuration?) because some block_id are not shown as in-seat.

We mentioned it in the original PR but it was a bit hidden : we have a open source GTFS-blocks-to-transfers tool that allows you to convert block_id to trip to trip transfers with good heuristics and optional configuration.