CAMARA Population Density Data API - Follow-up meeting #4 - 2024-03-20
March 20th, 2024
Attendees
Thomas Wana (Dimetor) |
Rafal Artych (DT) |
Violeta Gonzalez Fernandez (Telefonica) |
Sachin Kumar (Vodafone) |
Jorge Garcia Hospital (Telefonica) |
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
ITEM | WHO | DESCRIPTION |
---|---|---|
PR#5 | Telefonica | Initial contribution of the Population Density API spec |
Issue#6 | Telefonica | Information in water zones discussion |
Issue#7 | Telefonica | Default and limit values for the API Characteristics |
Issue#10 | Telefonica | Management of "big" responses |
Approval of previous meeting minutes & documentation (1)
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
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
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
Initial algorithm proposal (3)
Population Density API - Algorithm.pdf
Feedback:
Agreed WF
Discussion
Item | Discussion |
---|---|
PR#5 | Initial contribution of the Population Density API spec → |
Issue#6 | Information in water zones discussion → |
Issue#7 | Default and limit values for the API Characteristics → |
Issue#10 | Management of "big" responses → |
AoB | - |
Next steps
- Feedback on algorithm proposal→ Follow-up meeting #4
- Feedback on the big responses management #4
- RC API spec agreement → Follow-up meeting #5
- Next call will be April 03rd, 2024