Indicator data input

[matthiasschaub]

Description

An Indicator consists of a Layer and a Feature.

This PR introduces a new Layer baseclass. Now a Layer object can be either an instance of a "Layer Definition" class (with information how to retrieve the data for the layer) or of a "Layer Data" class (with data already attached to itself). This way it is possible to compute an Indicator for given data. At the moment this is restricted to the MappingSaturation Indicator.

In particular the PR adds:

• New Layer base-class and Layer sub-classes
• New API parameter layer (containing name, description and data) to the endpoint indicator (POST)

Below is an example of the request body for a POST request to the /indicator endpoint.

{
  "name": "MappingSaturation",
  "bpolys": {
    "type": "Feature",
    "geometry": {
      "type": "Polygon",
      "coordinates": [
        [
          [
            8.674092292785645,
            49.40427147224242
          ],
          [
            8.695850372314453,
            49.40427147224242
          ],
          [
            8.695850372314453,
            49.415552187316095
          ],
          [
            8.674092292785645,
            49.415552187316095
          ],
          [
            8.674092292785645,
            49.40427147224242
          ]
        ]
      ]
    }
  },
  "layer": {
    "name": "",
    "description": "",
    "data": {
      "result": [
        {
          "value": 1,
          "timestamp": "2020-03-20T01:30:08.180856"
        },
        {
          "value": 56,
          "timestamp": "2020-03-20T01:30:08.180856"
        },
        {
          "value": 5581,
          "timestamp": "2020-03-20T01:30:08.180856"
        },
      ]
    }
  }
}

Corresponding issue

Closes #233

Checklist

• I have updated my branch to main (e.g. through git rebase main)
• My code follows the style guide and was checked with pre-commit before committing
• I have commented my code
• I have added sufficient unit and integration tests
• I have updated the CHANGELOG.md
• Waiting for Utilize singledispatch for create_indicator() func of the oqt.py module #239
• Add ohsome API result schema validation to the Mapping Saturation Indicator
• Check TODOs in code
• Update PR description
• Move schema from dev-dependency to depedency

[joker234]

First overview looks pretty good, but one question we have to clarify before it makes sense to review in more detail: Does it make sense to name the new parameter layer? I would assume it means the layer name and not layer data you can give the endpoint for calculation.

[joker234]

I'm generally not really of using **_kargs or *_args, especially if you don't use them. Isn't there a better solution?

[matthiasschaub]

I'm generally not really of using **_kargs or *_args, especially if you don't use them. Isn't there a better solution?

Those are used because of flags like the force flag which is an argument to some of the overloaded functions and not to others. I wanted to signal that this is the case.

E.g. Notice the different second arguments:

@create_indicator_as_geojson.register(IndicatorBpolys)
@create_indicator_as_geojson.register(IndicatorData)
async def _create_indicator_as_geojson(
    parameters: Union[IndicatorBpolys, IndicatorData],
    size_restriction: bool = False,
    **_kargs,
):
    pass


@create_indicator_as_geojson.register
async def _create_indicator_as_geojson(
    parameters: IndicatorDatabase,
    force: bool = False,
    **_kargs,
):
    pass

I am totally open for another solution.

PS: The caller of the function create_indicator_as_geojson always passes down the force flag. Even in the case where it is not needed.

[joker234]

Thanks for the changes. Made only a few comments. If you want you can have a look at SonarCloud: https://sonarcloud.io/summary/new_code?id=ohsome-quality-analyst&pullRequest=245