CAMARA Population Density Data API - Follow-up meeting #5 - 2024-04-10

April 10th, 2024

Attendees

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

Agenda

• Approval of previous meeting minutes #4 and meeting agenda

• Open issues and PRs

  • PRs: #5

  • Issues: #6 #7 #10 #12

• Initial algorithm proposal review

• Timeline and next steps

• AoB

Open Issues & PRs

Approval of previous meeting minutes & documentation (1)

Meeting Minutes #4

Approved

API proposal review (2)

Different discussions raised during the API review:

• Issue#6 Information in water zones: Operators and therefore API can only provide data of those zones where it is operating. Full water or hybrid scenarios to be covered.

  Status parameter is used for handling both situations:

  • Partial response, only some areas can be handled in the response. To discuss whether not-supported areas are to be included in the response.

  • Empty response, if no area is managed by operator and, therefore, no information can be provided.

•  

  • "noData" value to be added in those cells

• Issue#7 Open discussion on default and limit values for the API characteristics:

  • Default value on level 7 (150m x 150m) (TBC). Open Discussion, please provide feedback

  Include input parameter where developer can chose among a list of levels. Also, to align on other global grid options in the future.

  •  

    •  

      Option1: only support 6-7

•  

  •  

    • Option2: support any level, including a not-supported option. → Sachin, Tim, Jorge

•  

  • Maximum requested area size, need to consider a feasible maximum response size jointly with the maximum length of the timeframe. Dependency with Discussion on API spec - how to handle big areas/time in the response #10 Open Discussion, please provide feedback.

• Issue#10

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.

• PR#5

Merged last commit with the already taken decisions up to now. From now on, let's work on separate PRs of the WIP version.

Initial algorithm proposal (3)

• Issue#12

Population Density API - Algorithm.pdf

→ To provide feedback 

Discussion

Next steps

1. Feedback on algorithm proposal→ Follow-up meeting #5

2. Feedback on the big responses management #5

3. RC API spec agreement → Follow-up meeting #6

• Next call will be April 24th, 2024