GTFS-Occupancies (part 2)

[sccmcca]

Due to GitHub workflow and CLA issues, this pull request is a continuation of discussions at #240.

GTFS-Occupancies is an extension proposal to describe usual or expected vehicle occupancy levels in GTFS Schedule.

As occupancies can currently be described in GTFS Realtime using occupancy_status and occupancy_percentage, GTFS-Occupancies aims to complement the availability of crowdedness information by providing static predictions for future trips based on historical trends, which can help riders plan trips based on their crowdedness preferences and comfortability.

To be resolved:

• Officializing an occupancy indicator in GTFS Realtime: Currently, both OccupancyStatus and occupancy_percentage are experimental. Ideally, we want consistency between static and realtime occupancy indicators. Whichever becomes official in GTFS Realtime will be the one used here.
• Elaborate GTFS-Occupancies to support frequency-based service. Some thinking on this here.

TfNSW has published a dataset: #240 (comment).

[skinkie]

I think we still have to discuss the start_time / end_time for frequency based trips.

[sccmcca]

The definition we have for start_time is:

First stop departure time for a given vehicle on a trip using frequencies.txt.

Must be some multiple (including zero) of frequencies.headway_secs plus frequencies.start_time for the corresponding time period.

Conditionally Required:
- Required for trips using frequencies.txt.
- Forbidden otherwise.

Correct me if I'm wrong, but should this be rephrased to refer to the first departure time of the stop specified by trip_id and stop_sequence? If no stop_sequence is defined, the first stop of the trip will be assumed. The wording now suggests start_time applies to the departure time of the first stop in a trip, which I don't think is completely right if want to be defining time ranges.

I propose the following reword to occupancies.start_time:

Start time in a range that a vehicle occupancy state applies to a stop on a trip using frequencies.txt.

If frequencies.exact_times=0, this field must be populated to define an estimated range start time.

If frequencies.exact_times=1, this field must be some multiple (including zero) of frequencies.headway_secs plus frequencies.start_time for the corresponding time period.

Conditionally Required:
- Required for trips using frequencies.txt.
- Forbidden otherwise.

Following this, here is a proposal for defining occupancies.end_time:

End time in a range that a vehicle occupancy state applies to a stop on a trip using frequencies.txt.

If frequencies.exact_times=0, this field must be populated to define an estimated range end time.

If frequencies.exact_times=1, this field must be some multiple (including zero) of frequencies.headway_secs plus frequencies.start_time for the corresponding time period.

Conditionally Required:
- Required for trips using frequencies.txt.
- Forbidden otherwise.

Does this work?

[barbeau]

Thanks @scmcca - yes, I believe that works. One option here to make sure is to wait to adopt the start_time and end_time fields until we have producers/consuemers for those specific fields (i.e., frequencies data).

[sccmcca]

@barbeau I added them for now but agree that they aren't necessary for initial adoption

[skinkie]

I do have a bigger question. Does the standard currently state anything regarding a requirement that the files must be bundled as a single zip archive? In our case we would like to add the latest predictions we receive but forcing hundreds of megabytes of unchanged data data just does not make sense.

[paulswartz]

I do have a bigger question. Does the standard currently state anything regarding a requirement that the files must be bundled as a single zip archive? In our case we would like to add the latest predictions we receive but forcing hundreds of megabytes of unchanged data data just does not make sense.

@skinkie we were also thinking about this @mbta. We might include it in our GTFS (which updates a few times a week) as well as a standalone file (updated as frequently as necessary).

[skinkie]

@skinkie we were also thinking about this @mbta. We might include it in our GTFS (which updates a few times a week) as well as a standalone file (updated as frequently as necessary).

That is probably going to be our approach as well, but I think generically we should state something about bundling.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This pull request has been closed due to inactivity. Pull requests can always be reopened after they have been closed. See the Specification Amendment Process.