Update Occupancy Percent formula

[jlarsonOmahaNE]

Is your feature request related to a problem? Please describe.

The current Occupancy Percent is modeled by sum[dwell time] / total duration . In a parking study, occupancy is calculated by active sessions over the total amount of spaces per area or zone for a specific time period. Optimal occupancy is usually around 80% and seeing x% over could give you insights into availability or payment issues.

Describe the solution you'd like

I would like to propose to change the model for Occupancy Percent to use the calculation count[sessions] / total spaces for a specific time period.

Is this a breaking change

• No, not breaking. I believe this is not breaking because only the formula is updated and the required fields/naming stays the same (ie. Aggregate).

Impacted Spec

• Metrics

[schnuerle]

I believe this would be a breaking change if we change the formula.

If instead we make a new metric with a different name, then it could be added and therefore nob-breaking.

[LaurentG-AMD]

What @jlarsonOmahaNE is proposing is an instantaneous occupancy, which kind of goes against the definition of an Aggeregate as (italic mine):

Aggregates are historic pre-computed counts and metrics of Events occurring in curb places, aggregated to the hour

However, I agree that in practice, this is not always helpful since there's often to many data to parse to be able to meaningfuly draw a conclusion. I would also argue that linking aggregates to places is too restrictive.

Basically, occupancy can be defined over different timespans or geographic units and these aggregates serve different purposes. In our studies here, we regurlarly use hourly occupancy over a whole street (which would combine many zones on almost any streets in the city), hourly occupancy over multiple streets, multi hour occupancy (e.g 9h00 am - 12h00 pm) over a single street or over a set of streets. It really depends what the aggregate is used for.

[schnuerle]

@jlarsonOmahaNE do you align with @LaurentG-AMD's comments here, that you are looking for instantaneous occupancy?

@LaurentG-AMD the reason we do 'linking aggregates to places' like a zone is that currently Metrics comes directly from a reduction and summation of fields from Events, which require Zone connections, and that makes the Metrics clear and easy to calculate per Zone. Do you think it's cumbersome to try and calculate these Metrics across many Zones in a street block? If we do want a metric for a block instead in Metrics, then we may have to add a new field about the block name or ID in the Zone object in order to know how the Zones are connected to each other in this way.

[jacobmalleau]

I feel like this type of metric becomes more involved because we would have to add the space count into the Metrics attribute table (or otherwise pull it from Curbs).

I think for now this should be left as a future item, potentially under "advanced metrics" that combine Curbs and Events/Metrics data to calculate unique metrics.

Obviously, individual users can make these calculations themselves in the mean time.