- the first notebook runs the tactical-forecasts command
- the second notebook describes the tactical demand forecasting process
+ demand aggregation on a per-pixel level
+ time series generation: horizontal, vertical, and real-time time series
+ STL decomposition into seasonal, trend, and residual components
+ choosing the most promising forecasting model
+ predicting demand with various models
- fix where to re-start the forecasting process after it was interrupted
- enable the heuristic for choosing the most promising model
to also work for 7 training weeks
- the two notebook files are helpful in visualizing all relevant
pickup (red) or delivery (blue) locations from the point of view
of either e restaurant or a customer
- add notebook that runs the plotting code
- add three visualizations per city:
+ all addresses, colored by zip code
+ all restaurants, incl. the number of received orders
+ all restaurants on a grid with pixel side length of 1000m
- the model applies a simple moving average on horizontal time series
- refactor `db.Forecast.from_dataframe()` to correctly convert
`float('NaN')` values into `None`; otherwise, SQLAlchemy complains
- the method implements a heuristic from the first research paper
that chooses the most promising forecasting `*Model` based on
the average daily demand in a `Pixel` for a given `train_horizon`
- adjust the test scenario => `LONG_TRAIN_HORIZON` becomes `8`
as that is part of the rule implemented in the heuristic
- `*Model`s use the `methods.*.predict()` functions to predict demand
given an order time series generated by `timify.OrderHistory`
- `models.base.ForecastingModelABC` unifies how all `*Model`s work
and implements a caching strategy
- implement three `*Model`s for tactical forecasting, based on the
hets, varima, and rtarima models described in the first research paper
- add overall documentation for `urban_meal_delivery.forecasts` package
- move the fixtures in `tests.forecasts.timify.conftest` to
`tests.forecasts.conftest` and adjust the horizon of the test horizon
from two to three weeks
- the function implements a forecasting "method" similar to the
seasonal naive method
=> instead of simply taking the last observation given a seasonal lag,
it linearly extrapolates all observations of the same seasonal lag
from the past into the future; conceptually, it is like the
seasonal naive method with built-in smoothing
- the function is tested just like the `arima.predict()` and
`ets.predict()` functions
+ rename the `tests.forecasts.methods.test_ts_methods` module
into `tests.forecasts.methods.test_predictions`
- re-organize some constants in the `tests` package
- streamline some docstrings
- move the module
- unify the corresponding tests in `tests.forecasts.methods` sub-package
- make all `predict()` and the `stl()` function round results
- streamline documentation
- ensure a `Restaurant` only has one unique `Order.pickup_address`
- rework `Grid.gridify()` so that only pickup addresses are assigned
into `Pixel`s
- include database migrations to ensure the data adhere to these
tighter constraints
- add `.low80`, `.high80`, `.low95`, and `.high95` columns
- add check contraints for the confidence intervals
- rename the `.method` column into `.model` for consistency
- add a Jupyter notebook that allows to install all project-external
dependencies regarding R and R packages
- adjust the GitHub Action workflow to also install R and the R packages
used within the project
- add a `init_r` module that initializes all R packages globally
once the `urban_meal_delivery` package is imported
- the main purpose of this class is to manage querying the order totals
from the database and slice various kinds of time series out of the
data
- the class holds the former `aggregate_orders()` function as a method
- modularize the corresponding tests
- add `tests.config` with globals used when testing to provide a
single source of truth for various settings
