add runtime_build_point to stop_times.txt

[BTollison]

In conjunction with adding runtimes.txt from issue #42 to enable runtimes to move from between platforms, it is necessary to add a way to distinguish where running time should be distributed from within a trip. This proposal seeks to add runtime_build_point as a boolean value to stop_times.txt to enable this.

runtime_build_point
0 = runtimes for the trip are not built from a particular point, but should be distributed from beginning of the trip forward.
1 = This is the point where running time should be built from. This can only be used when runtime_style = 1 in runtimes.txt

[skyqrose]

I don't get it. Can you describe what ambiguity this resolves, and can you give an example of the data?

So far, I think ODS has been trying to avoid making changes to GTFS files.

[safrazier17]

So far, I think ODS has been trying to avoid making changes to GTFS files.

I would go so far as to say that it is an implicit requirement. Changes to GTFS have to be made via a separate path and are handled by way of that community's guidelines. We have avoided making any change requests to GTFS and should continue to do so. In this case, could we not handle the proposed functionality here, assuming it is needed, in the same way that we handle for example runs_pieces.start_trip_position? That is, could we not have a field in runtimes.txt that refers to stop_times.stop_sequence or ops_locations.location_sequence?

[BTollison]

@safrazier17 okay to avoid modifying GTFS it may then be useful to do something like you suggest but also include a trip_id because it could be different for every trip.

@skyqrose it's to manage situations like this:

runtimes.txt
start_time	end_time	from	to	runtime
6:00	6:29:59	a	b	5
6:00	6:29:59	b	c	5
6:00	6:29:59	c	d	5
6:30	6:59:59	a	b	6
6:30	6:59:59	b	c	6
6:30	6:59:59	c	d	6

<style type="text/css"></style>

stop_times.txt where runtime_build_point has a value
stop_sequence	stop_id	arrival_time	departure_time	runtime_build_point
1	a	6:20:00	6:20:00
2	b	6:26:00	6:26:00
3	c	6:32:00	6:32:00	1
4	d	6:38:00	6:38:00

<style type="text/css"></style>

stop_times.txt where runtime_build_point is null
stop_sequence	stop_id	arrival_time	departure_time	runtime_build_point
1	a	6:20:00	6:20:00
2	b	6:25:00	6:25:00
3	c	6:30:00	6:30:00
4	d	6:36:00	6:36:00

Notice how when runtime_build_point = 1 that all runtimes are now 6 minutes because the software builds the trip from C. Since it's after 6:30, it will build all points from the period 6:30 - 6:59:59. To be totally honest, this sort of functionality makes little sense to me but it exists in the software so I have to assume it is used somewhere.

[skyqrose]

This seems like an internal detail of the scheduling application that wouldn't need to be published to other applications once the scheduling system has chosen the times. ODS so far has been about publishing completed schedules. I guess runtimes.txt could be useful as a standardized input into the scheduling system, but at that point, stop_times.txt doesn't exist. What's the benefit to publishing in ODS/GTFS the rules for how to generate stop_times, when the finished stop_times are already there?

[BTollison]

We see this as a way to help allow the smooth transfer of data between 2 systems when network planners use one system and a scheduler uses another, and then allowing them to iterate their ideas quickly.

A good example is if we have Hastus for scheduling, but the network planners prefer to use something like Remix, we need a way to send information back and forth without triggering lots of data entry. Especially in a tender scenario where time is highly constrained.

In our case, even if trip times exist, the network planner often modifies trips to sync with new requirements from the government, "must meet these vehicles at X bus station, must meet Y trains at this station." We also modify timetables when there is road closures, so modifying existing timetables for us is quite common. So it's important to have runtime information so that trips are created realistically.

[skyqrose]

That makes sense. But this still a detail about how the schedule is generated, rather than trying to accurately describe service. The real-world time between stops a and b depends on what time the bus is driving between a and b, not what time the bus reaches c. I understand why a scheduling system would want to make the simplification of generating the runtimes based on a single time of day, even if it's not quite realistic. But modifying the standard so that two different systems can match each other on that implementation detail is still enshrining an implementation detail in the standard, when the standard is supposed to be for describing real-world service.

An alternative suggestion, as long as you control enough of the two systems to adjust how they load data: Could you write this data for your use case in a non-standard way? This would not break other GTFS consumers, because the spec says to ignore unrecognized fields/files.

• You could add it in stop_times.txt as proposed here.
• You could add a nonstandard column runtime_build_point that contains a stop_id to trips.txt
• You could add a new nonstandard file in GTFS with three columns: service_id, trip_id, and runtime_build_point (a stop_id)
• You could load this data into both systems separate from GTFS/ODS.

[skyqrose]

The stop_times_supplement.txt file proposed in #55 would make this change much easier, and removes the main objection that it would require modifying a GTFS file.

I still think it doesn't fit ODS's main goals because it's an internal implementation detail rather than describing service, but now that there's an obvious way to write the spec that doesn't make the spec more complicated, and because it doesn't affect me, I only have a very weak objection.

One detail of #55 that hasn't been resolved yet is the use of nonstandard columns (asked as Q3 here). Assuming it's okay to add columns that aren't officially supported to _supplement files, and that consumers should just ignore columns they don't recognize, then it'd be straightforward to implement this whether or not it's an official part of ODS. You'd just have to make sure producer and consumer both agree on the column.

[skyqrose]

Another thought: Does this belong in stop_time_supplement.txt or trip_supplement.txt? A column in trip_supplement.txt could list the stop_sequence of the reference stop, which might be easier to check than reading through all the stop_times on a trip. I guess whether that's better or not might depend on what software you're using.

[BTollison]

I believe we should put this in a stop_time_supplement.txt for ODS 2.0 compliance. Since a build point is at the stop level (timepoint), it would be better there than at the trip level.

For me, I think it fits ODS in that it helps transfer data but also to ensure that when brought in to another system, that data is properly preserved. Without this, trips would could "shift" to the segment distribution style if they are not frozen on import.