OccupancyStatus vs. occupancy_percentage

[barbeau]

In GTFS-RT, we now have two experimental fields that can contain real-time vehicle occupancy information:

• OccupancyStatus - A enum of 7 values added to the spec 6 years ago. We know of 3 producers of this data - see this pull request for details.
• occupancy_percentage - A percentage value representing the degree of passenger occupancy of the vehicle. Just adopted as an experimental field ~30 days ago in this pull request

Unless there is a specific use case to have both fields in the spec, we should try to narrow down to one.

Producers and consumers - if you were to pick one of the two, which would you pick and why?

For producers - is one field easier to produce than the other? Would adoption be faster with one field in particular?

[skinkie]

If it would be one or the other; To be compatible with SIRI I would pick the enumeration. In in addition, it is the least commercial sensitive information to be shared.

[darylweinberg]

At Capital Metro we are working to produce OccupanyStatus by August. It will not have a percentage value at this time.

[stevenmwhite]

occupancy_percentage would be the pick.

• Lends itself better to situational adjustments (for example during the COVIC crisis, 100% could represent a policy-related limit rather than a physical limit). It makes sense as "per agency regulations (whatever they may be at a given time), the vehicle is X percent of its limit. The scale of 100% can change as needed.
• It is less open to interpretation (what is many, what is few?) by different agencies and different consumers.
• It does not claim precession that may not be accurate (when status says a bus is standing room only, it may not necessarily be... depending on whether passengers have chosen to take all available seats before standing. It's not uncommon to be on a crowded transit vehicle with many people standing and still have some open seats.)
• It is easier to produce and I believe adoption would be faster as a result.
• Gives consumers more flexibility in how they display it, rather than attempting to map the enums to approximate percentage levels.

What it doesn't do is give any sort of accessibility information. While occupancyStatus can be unclear, the mention of "seats" can be helpful to riders if it is accurate, and a pure percentage doesn't give that.

[mike-swiftly]

I don't believe these fields are mutually exclusive. Both would be optional, so clients will be able to handle data being available in none, one, or both of the fields. I expect that more agencies will be able to handle the enumeration because it is less information. But really don't want to preclude applications that can use more detail, like occupancy percentage.

[stevenmwhite]

I don't believe these fields are mutually exclusive. Both would be optional, so clients will be able to handle data being available in none, one, or both of the fields.

I agree. I wouldn't necessarily advocate for deprecating one. My comments above should be taken in the context of if we had to pick one or the other.

[mcossette1]

I don't believe these fields are mutually exclusive. Both would be optional, so clients will be able to handle data being available in none, one, or both of the fields.

I agree. I wouldn't necessarily advocate for deprecating one. My comments above should be taken in the context of if we had to pick one or the other.

I agree too.

[BodoMinea]

I agree with most of the points above. While this is probably not the outcome desired by feed spec maintainers, as I understand that simplicity is key, I think that both of these fields could be of use to some.

While the enumeration is simplified enough to not give away data of commercial value, for some agencies that are just starting to implement this system, a percentage may be easier to implement, by averaging the data from sensors for example - vehicle cabin weight scales or volumetric cameras.

I also think that applications that consume data may have interest in having both fields exposed - the enumeration is easy to implement as a simple color highlight/people icon, the percentage may be easier to manipulate in a mathematics formula for weighting routing options and also for presenting more exact data to the user.

I would be fine with both of them being optional and given the available resources at a client, I would do my best to provide both.

[antrim]

If we keep both of these fields, it might create opportunities for confusion or unnecessary spec bloat. I worry we’d take a situation with existing ambiguity and just layer in more ambiguity and complexity:

• How should a consumer interpret a feed where occupancy_percentage is 90 and occupancy_status is FULL?
• Should there be a consistent mapping applied between occupancy_status and occupancy_percentage?
• If so, why not just have one field?

As part of this exercise, I ask what would be lost (if anything) by just having one field?

[skinkie]

@antrim I really liked how @gcamp has defined the percentage based on the safety limit of the vehicle. For me the enumeration would be just the textual description, presented to as translatable text to the end user. It would obviously be nice to have a ballpark as mapping to have a GTFS-RT validator to invalidate 10% to FULL.

Our percentage / enum approach is mainly targeting busses and taxi's. But for a train with different compartments the values greatly variate. We have not modeled that yet. Neither did we do the mobility impaired space, which is even deeper level of detail than the current two approaches. I think after the VehicleTypes GTFS stuff, more questions will come done. Some train builders are already able to tell exact numbers of free seats. Similar to the number of people in the standing space.

[juanborre]

Another point for the enum is that it is the only way a producer can specify if a passenger is likely to find a seat. The mapping between percentage and enum will greatly depend on the vehicle and its seating capacity.

Getting rid of that field would remove that functionality.

However, if the only reason for the enum was to add information about seating, it could be replaced with another field to address that need in particular.

[caywood]

@barbeau I'm not trying to derail the discussion, but there doesn't seem to be clear agreement. Perhaps because we're too tied to history and not adjusting the spec enough to address today's crisis. Given there are few actual implementations of the spec we should choose whatever serves today's needs best.

Within GTFS-RT VehiclePositions:

• passenger_count_estimate
• seating_capacity
• max_capacity

passenger_count_estimate recognizes that this is a noisy measurement - in addition, agencies can use a discrete set of values or add random noise if especially privacy sensitive.

seating_capacity is a physical property of the vehicle. (I expect any producers currently producing OccupancyStatus must already know this).

max_capacity is a policy decision - normally max_capacity >= seating_capacity but in COVID, max_capacity is whatever the agency says it is.

This would allow consumers to reconstruct any OccupancyStatus or occupancy_percentage they care to represent, with greater precision if needed.

(seating_capacity and max_capacity are part of GTFS-vehicles full but I don't expect that will be implemented on the relevant timeline for the current problem - we need a solution within GTFS-RT VehiclePositions).

Apologies if you've already considered alternatives like this - I'm just processing all of this after joining last week's call.

[skinkie]

@caywood I agree on the passenger_count_estimate (and relevant mobility impaired information) but having static data in a realtime data stream, because we fail to standardise the static data is a direction I don't wish to follow either.