Closed billdirks closed 5 years ago
I've been working through the refactor design issues on this ticket and have made some progress. My proposal is the following:
--days
flag that lets mobility-metrics know how many days of data to include before the specified report day (--day
)I'm still working on a PR for this, so let me know if there are objections or other ideas for how this should be designed. I will have a testable branch out early next week.
Addressed in v4.0 release. I changed the initial designs here a bit. The --day flag was deprecated in favor of:
Additionally, you can now add a "lost" property to your config specifying a number of days before a vehicle is considered lost in action, so that it will no longer affect availability or onstreet metrics after going silent. The raw data cache will use the lost property to pull data from before your aggregation window, but this data will not factor into metrics, other than detecting deployed vehicles. Defaults to 2 days.
We've spoken to cities who are interested in the generated maps (Trip Volumes, Flow, Availability, etc) for longer term planning objectives. Currently the maps are generated for a days worth of data at a time. For the planning use case, it would be great if the data could be visualized over an arbitrary number of days. This would allow it to produce maps for the length of pilot program, a month, or some other time interval of interest.
One workaround for the time being (please correct me if there is an issue with this approach) is to run the mobility-metrics aggregator for each day in the interval of interest with the
privacyMinimum
set to 0, combine the data, and then apply a privacy minimum.