No data available for Occupancy data in GTFS-RT

111 views
Skip to first unread message

ROCS PREDICTOR

unread,
Oct 19, 2020, 9:16:52 AM10/19/20
to GTFS-realtime
Hello,

As a producer we currently using GTFS-RT with v2.0 which includes 7 enums for Occupancy data. Unfortunately, there are situations that occupancy data will not be available. How do you indicate that in GTFS-RT v2.0? If a Enum is left empty, will the consumers receive a default value?

  Do you know who is accepting the following Proposal: Support multi-car crowding in GTFS-RT (#237) ?

Thanks in advance,
Javier

Sean Barbeau

unread,
Oct 20, 2020, 3:52:41 PM10/20/20
to GTFS-realtime
Javier,
I believe the current best practice for producers of GTFS-RT with the 7 enum values for OccupancyStatus is that if you don't have any data for VehiclePosition.occupancy_percentage and VehiclePosition.occupancy_status just leave them empty (don't set them) when publishing a feed. 

Consumers are then responsible for checking if the value is populated using methods in the consumer protocol buffer bindings library such as " hasOccupancyStatus()" before reading the value. So the pseudocode on the consumer side should look something like:

if (vehiclePosition.hasOccupancyStatus()) {
    // Do something with OccupancyStatus
    print(vehiclePosition.getOccupancyStatus());
} else {
    // No occupancy data - do nothing
}

There is a known issue with some protocol buffer bindings libraries not generating these "hasOccupancyStatus()" methods (in particular .NET/C#), in which case the current default values defined in gtfs-realtime.proto of EMPTY and 0 would be read from VehiclePosition.occupancy_status and VehiclePosition. occupancy_percentage, respectively:

I'm working on updating the gtfs-realtime.proto with new default values for VehiclePosition.occupancy_status and VehiclePosition. occupancy_percentage of NO_DATA_AVAILABLE and -1, respectively, which would give a clear indication that there are no values for these fields, even for binding libraries that don't generate the "hasOccupancyStatus()" methods:

This requires some testing for backwards compatibility to make sure we don't break anything in the process.

An aside - you may notice that the multi-car crowding proposal already defined these defaults for CarriageDetails.occupancy_status and CarriageDetails.occupancy_percentage, so the same issue doesn't arise there.

As for consumers of the multi-car crowding experimental feature, I would suggest commenting on the proposal pull request asking who is currently consuming, and if you're interested in producing I would mention this too:

We need at least one consumer and one producer to advance the multi-car crowding out of the experimental stage and into "official" status.

Sean

Sean Barbeau
Center for Urban Transportation Research
University of South Florida

ROCS PREDICTOR

unread,
Jan 21, 2021, 10:32:42 PMJan 21
to GTFS-realtime
Hello Sean,

I would like to thank you for the great answers provided and an excellent job supporting the specification.

We have successfully publish Occupancy Data using enum values from 0 to 6. Unfortunately,   multi-car crowding proposal   was consider but  ruled out due to lack of acceptance by our consumers.

Even that we are able to support  Occupancy Data using enum values from 0 to 6, our data mainly contains the following values MANY_SEATS_AVAILABLE ,  FEW_SEATS_AVAILABLE  and  FULL.

Thanks again for the support provided,
Javier

Reply all
Reply to author
Forward
0 new messages