-
Notifications
You must be signed in to change notification settings - Fork 5
Returning aggregate metrics #432
Description
Current implementation
The current implementation of the method allows to return traffic metrics of different kinds.
- Road-level metrics, describing the features per unit of time and per road (eg, the mean velocity and the cumulative number of the vehicles in a road in a time period);
- Trip-level metrics, describing quantities related to full vehicular trips (eg, the travel time and the mean speed of vehicles starting in a time period).
New zone-level metrics
I am interested in "zone-level" metrics, which describe the aggregated features of roads grouped inside a "zone".
The zone-level metrics of interest are the following. Let Z be a zone (a set of roads), and t a time period:
- Distinct vehicles in zone: number of distinct vehicles traveling on any road
r ∈ Zat timet - Trip origins in zone: number of distinct vehicles starting a trip on any road
r ∈ Zat timet - Zone entries: number of distinct vehicles that are on some road
r ∈ Zat timetand were on some roadr' ∉ Zat timet-1 - Peak road occupancy: maximum, over all roads
r ∈ Z, of the number of vehicles on r at timet - Mean zone speed: weighted average of the mean speed on each road
r ∈ Zat timet(possibly weighted)
The zonal aggregation occurs differently depending on the metric type:
- (weightedly) averaging the road-level feature (eg, when considering the mean speed)
- maximizing (or minimizing) the road-level feature (eg, the max congestion in a zone)
- starting from the raw data (eg, when computing the number of distinct vehicles in a zone)
I wonder if it would be possible to obtain either more granular information on the trips to compute the metrics above (e.g., the composition of each trip as a list of road segments and timestamps), or to obtain directly the aggregated metrics given the zonal grouping. Note that the granular trip data would only be used to re-aggregate at the zone level — I am not interested in individual travel patterns. Either approach would work for my use case — I'm open to whichever solution is easier to implement on your end.