Population Density Data API minutes: https://lf-camaraproject.atlassian.net/wiki/display/CAM/Population+Density+Data+API+Minutes

Agenda

Open Issues & PRs

Approval of previous meeting minutes & documentation (1)

Meeting Minutes #5

→ Approved

API proposal review (2)

Different discussions raised during the API review:

Status parameter is used for handling both situations:

Gregory/Tim: Include all the cells in the partial case, since the impact of including the empty cell is not big enough to lose the developer will expect as a full response.

Jorge: Calculating the cells, with no real value to developer, is costly for the CSP.

Decision: Move on with the most supported option. Empty cell in partial responses will be provided.

Issue #6 to be closed

Decision: Support a input parameter for the developer to select level (opt, default ==7), and create a "level nor supported" error. To consider in future release the analysis of other global grids.

Let max area size open (technically) to a reasonable use case management, each operator can of course launch an error in case the size is not supported.

Issue to be closed after "bigger area than supported" error is included in the code

Following the discussion on maximum time frame and area to cover, we've been analyzing the management of valid/useful requests and the corresponding response. Considering the size of a common request, of 1 week and common areas of around 10Km2, the size of the response's content may be too big for being handled directly in the API REST body.

Proposal to analyse

Proposal is to analyze the implementation a unique asynchronous mechanisms for being able to handle both kind of scenarios, small scenarios where response will reach soon but also time and resource consuming scenarios where it may take even minutes to calculate the response.

→ to analyze limiting the size of the request to avoid complexity in the response, at least to consider response size that can fit properly in a HTTP response.

Decision: Support async endpoint for bigger and smaller areas, also needing to define a size limitation (area, duration and granularity) (TBD in issue #7). In any case, the response will be part of the API response body. Only identified limitation is on the calculation time, not in the response size.

Issue #10 to be closed 

Ericsson: Time format alignment with commonalities, supporting RFC instead of ISO

Decision: Agreed and solved in PR#21

Ericsson: Response content should follow the expected as in the API name, it is, density instead of population count

Decision: Analyze offline to make sure that API response is aligned with API name

AP: to define what max and min means in the calculated forecast. Also reconsider average as a forecast response, maybe just "expected"/"forecasted" population value

Ericsson: adding redoc and swagger editor links in API readme.

TEF: Mainly used in stable versions when a release is launched, in any case it's proposed in PR#19

Decision: Agreed and solved in PR#19

Orange: Align location area format with other APIs of CAMARA

Decision: Agreed and solved in PR#21

Orange: Proposal and alternative for implementation of async mechanism in the API response

Decision: 2 proposals of resolution:

Initial algorithm proposal (3)

Population Density API - Algorithm.pdf

→ To provide feedback