No data available for Occupancy data in GTFS-RT

[ROCS PREDICTOR]

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]

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:

https://github.com/google/transit/issues/247

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:

https://github.com/google/transit/pull/248

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:

https://github.com/google/transit/pull/237

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]

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