new Endpoint: calculate indicator with given data

[joker234]

Implement a possibility/endpoint to request one indicator with given data. The data to calculate the indicator comes through the request and not from the ohsome API.

Data that needs to be given:

• indicator name: {"name": "name"}
• input data:
  • {"data": {"value": "1", "timestamp": "iso"}}
• layer
  • {layer: {"name": "name", "description": "description}}
• geometry
  • {"bpolys": GeojsonObject}

[matthiasschaub]

Each Indicator object needs as input a geometry (GeoJSON Feature) and a layer which defines the attributes and aggregations on which to compute.

At the moment the layer class (LayerDefinition) consists of attributes name and description AND the ohsome API endpoint and filter parameters with which to retrive the data.

• Indicator Input
  • Layer
    • name AND description
    • ohsome API endpoint and filter -> data
  • Geom

This issue suggest to provide the data on which to compute directly. Should the data stand for itself as input or be part of the Layer object.

Either:

• Indicator Input
  • Layer
    • name AND description
  • Geom
  • Data

Or:

• Indicator Input
  • Layer
    • name AND description
    • Data
  • Geom

Is it conceptually wrong that a layer has data attached to it?

Regarding the implementation of those two options in code. The first one would mean additional logic in each indicator.py (checking if data is present or not). The second one would mean the logic could be outsourced to ohsome/client.py (checking if given layer object has data attached to it?)

[Hagellach37]

I think that I prefer option 1, where data is not part of the layer.

For each indicator data does not always come from ohsome, but can also come from our DB directly, e.g. population. So I would try to avoid having several data objects in different places.

From my understanding the new endpoint would allow us to replace the data attributes that would normally be generated. For mapping saturation I can provide the timestamps and the values. But for other indicators I could in theory provide the population count and building density.

For each indicator we then check which data attributes are provided in the request and would get the missing one e.g. from ohsome or from the DB. So from my side it sounds okay to add a logic to indicator.py.

[Hagellach37]

sorry for the confusion I mean option 1. :)

[joker234]

Discussion result:

• output data has to be renamed, data.… is confusing
• input data are following option 2, but only ohsome API / OSM data related to “layer” definitions are allowed as input data
• other input data are still only available through other data sources