CAMARA Population Density Data API - Follow-up meeting #4 - 2024-03-20

March 20th, 2024

Attendees

Population Density Data API minutes: https://wiki.camaraproject.org/display/CAM/Population+Density+Data+API+Minutes

Agenda

• Approval of previous meeting minutes #3 and meeting agenda
• Open issues and PRs
  • PRs: #5
  • Issues: #6 #7 #10
• Initial algorithm proposal review
• Timeline and next steps
• AoB

Open Issues & PRs

Approval of previous meeting minutes & documentation (1)

Meeting Minutes #3

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 proposed for handling both situations:

  • Partial response, if only some areas are not included in the response due to the
  • Empty response, if no area is managed by operator and, therefore, no information can be provided.

  Proposed values (to be agreed):

  → Values for status (initial proposal): "enum": ["OK_SUPPORTED_AREA" → "AREA_SUPPORTED", "PART_OF_ AREA_NOT_SUPPORTED", "AREA_NOT_SUPPORTED"] 

  
  

  Agreed WF

→ offline discussion on partial responses. 

→ agreed on the values for the status parameter

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

  • Close time frame limits in t=0 (min) and reduce max to t=(3)months (max) with data prediction algorithm in all the timeframe. That covers current use case.
  • Document in the API yaml that response will include equal-sized cells, focusing on the geohash cells format.
  • 1 week (7 days) is proposed as maximum time frame length.
  • Maintain 1 hour as the time granularity for the response.
  • Default value on level 7 (150m x 150m) (TBC). Open Discussion, please provide feedback.
  • 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.

Agreed WF

 → Open discussion on maintaining the default geohash level in 7, but include an optional parameter in the request for the consumer to select a different value. "Not supported" error to be analyzed on those cases

• 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.

Agreed WF

→ Gregory: 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.

→ Keep discussion in the issue offline.

Initial algorithm proposal (3)

Population Density API - Algorithm.pdf

Feedback:

Agreed WF

→ Issue to be opened to keep the discussion offline.

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 10th, 2024