Scheduled reinforcement trips about transit HOT 18 OPEN

I'm trying to understand why it's important to have a schedule component here when it's effectively only useful in real time for the user? What's the purpose of knowing there might be a reinforcement trip if it's not to be displayed until it's confirmed in real time.

from transit.

Is this information that is useful for operators/staff only or would it also be shown to passengers? If so, how would it look like?

from transit.

Is this information that is useful for operators/staff only or would it also be shown to passengers? If so, how would it look like?

The information will be available as 'regular trips' trips after acknowlegement. This may happen hours or minutes before the trip starts.

from transit.

Can you not have them marked as 'Cancelled' on the days they are not used?

How do you handle this within the CAD-AVL, I'm assuming if a trip is not serviced then it needs to be reflected accordingly in your internal systems from a reporting standpoint.

from transit.

Can you not have them marked as 'Cancelled' on the days they are not used?

The problem with this, is that it will appear as cancelled. This is not what we want service providers to show. And it would also depend if a service provider implemented GTFS-RT. In addition, it would only work on that day, not all the others.

How do you handle this within the CAD-AVL, I'm assuming if a trip is not serviced then it needs to be reflected accordingly in your internal systems from a reporting standpoint.

I'll ask the operator how this is handled.

from transit.

interesting, how often do you generate your static GTFS files;

from transit.

interesting, how often do you generate your static GTFS files;

As aggregator, virtually daily ;-) this operator about every two weeks. https://data.ndovloket.nl/netex/qbuzz/

from transit.

Depending on if you want those trips to be shown in the schedule before they are confirmed I would either

• Add them to the GTFS and mark them as DELETED in GTFS-rt if they are not confirmed as @bijustrada360 mentionned. DELETED trips should not be marked as cancelled.
• Or add them dynamically to via DUPLICATED in GTFS-rt (assuming those reinforcement trips have the same stop pattern).

Would that fulfill your needs?

from transit.

@gcamp the problem I have with the first option that it would depend on an GTFS-RT implementation, hence wrong information if GTFS-RT is not implemented. DUPLICATED could work too (iff they share the same pattern).

from transit.

How do you handle this within the CAD-AVL, I'm assuming if a trip is not serviced then it needs to be reflected accordingly in your internal systems from a reporting standpoint.

It seems to be implemented quite naive and simple. Every trip that does not sign on (it isn't selected in vehicle) does not produce data. In that respect, for the driver, it is nothing different from a regular trip. So the trip is scheduled in CAD-AVL.

from transit.

I was going to take back my question; you said the decision is made on service day so it really doesn't matter how often you generate your static files.

As an aggregator we have an agency that has somewhat a similar but not quite the same scenario as yours.

They have empty scheduled blocks with operator duties assigned that go out every day, they are called those blocks as extras. The trips would be part of 'dummy' blocks in the scheduling / CAD system and would not be outputted during the GTFS schedule export but rather only available in CAD and the on-board systems on the vehicle. And for quite the same reason as you specified as well as others like special events where its hard to gauge how many transit users there could be, they would re-assign these trips to the blocks called extras. When the trips get assigned, they show up as 'Added trip' on the RT feed. Off course this requires the consumer to be handling RT.

But since you want to handle it via the static files, I would say I do see value in having a field in the trips.txt called trip_type which could be an enum value with one being what you suggested. I do already see other values that could be added like 'School Trip' or 'Priority' trip just as an example. I say this because most Scheduling and CAD system do have the concept of a trip type.
As a rule of thumb I'd like to follow, any solution that we propose should be generic that can extended over time so an enum would make sense rather than a boolean flag.

from transit.

@bijustrada360 thanks for this elaborate reply. I think I also want to clear something up. From my point of view the data that an agency provides should be available for the users of our data products as transparently as possible. Sure it may be in a different standard, but if this party wants to do the integration their selves they should have all the context available. The "lets put it in realtime" feels to me to hide the original context, regardless if it actually depends on the same stop pattern.

from transit.

How do you handle this within the CAD-AVL, I'm assuming if a trip is not serviced then it needs to be reflected accordingly in your internal systems from a reporting standpoint.

It seems to be implemented quite naive and simple. Every trip that does not sign on (it isn't selected in vehicle) does not produce data. In that respect, for the driver, it is nothing different from a regular trip. So the trip is scheduled in CAD-AVL.

Honestly what you have is a Scheduling / CAD issue and you're trying to solve it using a customer information system like GTFS/RT.

To your comment:

The "lets put it in realtime" feels to me to hide the original context, regardless if it actually depends on the same stop pattern.

I have to respectfully disagree here. Any changes on the day off service should be reflected via RT, and it is important that consumers handle it to truly reflect dynamic changes to the schedule else it defeats the purpose of having a standardised specification as it is designed.

from transit.

Honestly what you have is a Scheduling / CAD issue and you're trying to solve it using a customer information system like GTFS/RT.

I don't see how you come to that conclusion. NeTEx offers the ability to add attributes to trips (ServiceJourney) if they should be printed and shown on realtime displays. These trips are print=False, and dynamic=onlyIfSignedOn.

from transit.

Honestly what you have is a Scheduling / CAD issue and you're trying to solve it using a customer information system like GTFS/RT.

I don't see how you come to that conclusion. NeTEx offers the ability to add attributes to trips (ServiceJourney) if they should be printed and shown on realtime displays. These trips are print=False, and dynamic=onlyIfSignedOn.

If a trip is scheduled in the scheduling software the intent should be to service it. If there is any change on service day then CAD should handle it as a cancelled trip.

And as I mentioned before most scheduling / dispatching software will handle trip type attributes, but there is no standardised list of these attribute values. dynamic=onlyifSignedOn seems to be specific to the NeTEx solution.

from transit.

I'm trying to understand why it's important to have a schedule component here when it's effectively only useful in real time for the user? What's the purpose of knowing there might be a reinforcement trip if it's not to be displayed until it's confirmed in real time.

There are at least two 'users'. The end-user of a journey planner and an app, and a system integrator using GTFS between systems.

from transit.

Trips should only appear in the schedule if the TA intends to run them. At the TA I am most familiar with, there is a performance metric that captures the percentage of scheduled trips that are actually run. The goal is to run all scheduled trips. CAD/AVL software allows users to create supplemental trips on any route as required. The CAD software I am most familiar with allows you to create these new trips, and only when the new trip is assigned to a block does it get inserted into the headway...at which point it is treated the same as any other scheduled trip. These new trips report scheduled time as well as real time, but only after they are assigned to a block as I said.
I don't see any value in scheduling trips, and then remove them from public view. You would be better off not scheduling them and adding the supplements in CAD, or just having a bus sign into these trips since you aren't publishing the scheduled times.
Just my two cents. :)

from transit.

@huntrob I think you too miss the point that the Block and Duty part must be organised. That typically happens before it is loaded in CAD/AVL, especially if an optimisation engine from vendor A is used, and CAD/AVL from vendor B.

from transit.