- show an example order's path from the restaurant to the customer's
  delivery address as it is travelled by a courier
- explain how to use the Google Maps API directly
- show how the API is integrated into the data model

- `Order.draw()` plots a `Courier`'s path from the
  `Order.pickup_address` to the `Order.delivery_address`
- `Path.draw()` plots a `Courier`'s path between any two
  `Address` objects

Special case of `Path.from_addresses()` to create a single
`Path` object from an `Order.restaurant` to the `Customer`.

- a `Path` is a better description for an instance of the model
- the `Location`s en route are renamed into `.waypoints`
- generic `assoc` is renamed into `path` in the test suite

Adapt code to prevent new warnings and errors (as of SQLAlchemy 1.4):
- Overlapping foreign key columns could be set in a conflicting way
  => This is prevented by the application logic
  => Ignore the warning by setting a `overlaps` flag
- Transaction already rolled back
  => This only happens when tests cause an `IntegrityError` on purpose
  => Filter away the corresponding warning in the fixture
- Query returns `Row` objects and not scalars
  => Add genexpr to pull out `primary_id`

... from the dev dependencies.

Longer queries in SQLAlchemy get flagged even though they are not
complicated. Other expressions are generally not that complicated.

- as of September 2021, PyCharm is used to write some of the code
- PyCharm's built-in code styler, linter, and type checker issued
  some warnings that are resolved in this commit
  + spelling mistakes
  + all instance attributes must be specified explicitly
    in a class's __init__() method
    => use `functools.cached_property` for caching
  + make `tuple`s explicit with `(...)`
  + one test failed randomly although everything is ok
    => adjust the fixture's return value (stub for Google Directions API)
  + reformulate SQL so that PyCharm can understand the symbols

... after upgrading:
- alembic
- geopy
- googlemaps
- psycopg2
- rpy2
- dev dependencies
  + coverage       + darglint      + flake8      + flake8-annotations
  + flake8-black   + flake8-comprehensions       + flake8-docstrings
  + flake8-pytest-style            + pre-commit  + pytest
  + pytest-cov     + pytest-mock   + sphinx      + sphinx-autodoc-typehints
- research dependencies
  + jupyterlab     + matplotlib    + numpy       + pandas
- transient dependencies
  + argcomplete    + argon2-cffi   + attrs       + babel
  + bleach         + certifi       + cffi        + cfgv
  + chardset-normalizer            + colorlog    + debugpy
  + decorator      + defusedxml    + distlib     + geographiclib
  + gitdb          + gitpython     + greenlet    + identify
  + idna           + importlib-resources         + ipykernel
  + ipython        + jinja2        + json5       + jupyter-client
  + kiwisolver     + mako          + markupsafe
  + nbclient       + nbconvert     + nbformat    + nodeenv
  + notebook       + parso         + pathspec    + pbr
  + pillow         + platformdirs  + pluggy      + prometheus-client
  + prompt-toolkit + pycodestyle   + pydocstyle  + pyflakes
  + pygments       + pyristent     + python-dateutil
  + pywin32        + pywinpty      + pyzmq       + regex
  + requests       + scipy         + send2trash  + six
  + smmap          + sphinxcontrib-htmlhelp
  + sphinxcontrib-serializinghtml  + stevedore   + terminado
  + textfixtures   + testpath      + traitlets   + typed-ast
  + typing-extensions              + tzdata      + tzlocal
  + urllib3        + virtualenv    + zipp

The newly introduced "P023" error code must be disabled explicitly.

- problem: because of the randomization of test cases, every once in a
  while, the schema holding the test db already exists and cannot be
  created a second time (background: we run all tests against a db
  created with `metadate.create_all()` by SQLAlchemy at once and
  a db created by running all incremental Alchemy migration scripts)
- quick fix: possible, we could find a way to run all tests against
  one of the two test db's in random order and then against the other
  => in the interest of time, we simply do not randomize the test cases

- `DistanceMatrix.from_addresses()` takes a variable number of
  `Address` objects and creates distance matrix entries for them
- as a base measure, the air distance between two `Address`
  objects is calculated
- in addition, an integration with the Google Maps Directions API is
  implemented that provides a more realistic measure of the distance
  and duration a rider on a bicycle would need to travel between two
  `Address` objects
- add a `Location.lat_lng` convenience property that provides the
  `.latitude` and `.longitude` of an `Address` as a 2-`tuple`

- the class stores the data of a distance matrix between all addresses
  + air distances
  + bicycle distances
- in addition, the "path" returned by the Google Directions API are
  also stored as a JSON serialized sequence of latitude-longitude pairs
- we assume a symmetric graph

- 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

... after upgrading:
- alembic
- matplotlib
- pandas
- rpy2
- sqlalchemy
- statsmodels
- dev dependencies
  + coverage     + factory-boy    + faker                 + nox
  + packaging    + pre-commit     + flake8-annotations    + pytest
  + pytest-cov   + sphinx
- research dependencies
  + numpy        + pyty
- transient dependencies
  + astpretty    + atomicwrites   + bleach                + chardet
  + colorlog     + darglint       + flake8-comprehensions + gitpython
  + identify     + ipykernel      + ipython               + jedi
  + jinja2       + jupyter-client + jupyter-core          + mako
  + nbformat     + nest-asyncio   + notebook              + parso
  + pluggy       + prompt-toolkit + ptyprocess            + pygments
  + pyyaml       + pyzmq          + requests              + smmap
  + terminado    + textfixtures   + snowballstemmer       + typed-ast
  + urllib3      + virtualenv

- fix SQL statements written in raw text

- use the `HorizontalSMAModel` for low demand
- use the `TrivialModel` for no demand

- we use that shorter name in `urban_meal_delivery.forecasts.*`
  and want to be consistent in the ORM layer as well

- the trivial model simply predicts `0` demand for all time steps

- 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

- when running tests marked with "r" we still must not run tests
  marked with "db" on the CI server