CAMARA Population Density Data API - Follow-up meeting #7 - 2024-05-28

May 08th, 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 #6 and meeting agenda

• Open issues and PRs
  
  

  • Issues: #7 #12 #13 #14 #15 #16 #20

  • PR #19 #21

• Initial algorithm proposal review

• Timeline and next steps

• AoB

Open Issues & PRs

Approval of previous meeting minutes & documentation (1)

Meeting Minutes #6

→ Approved

API proposal review (2)

Different discussions raised during the API review:

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

Issue#13

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

Issue#14

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

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

•  

  •  

    • Or to change the API name to count

    • Or to change the response unit from people/cell to people/km2

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

to be closed, including proper density value (people/km2). To continue in #23 and discussion for the definitions of the parameters.

Issue#15

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

Issue#16

Orange: Align location area format with other APIs of CAMARA

Issue#20

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

Discussion: 2 proposals of resolution:

•  

  • Callback URL/ webhook: More complex approach for the developer, but more suitable for unexpected response delays.

    • To include also a failure response for the callback in case the process cannot be completed. → done

    • Also to be included an error for the sync response → done

  • GET endpoint and requestID: easier to implement, more suitable for fast response APIs or APIs which response is expected in a specific delay. In longer responses, developer should poll the get endpoint.

PR#19

Solving Issue#15

PR#21

Solves #6 #7 #10 #13 & #15. #20 still open about details, also to be aligned with async/subscription mechanism in commonalities

Initial algorithm proposal (3)

Issue#12

Population Density API - Algorithm.pdf

→ To provide feedback

Question: how to proceed?

PR to be opened for further discussion on documentation.

AoB (4)

Authentication/security discussion opened around the usage of 2-3 legged access tokens for this API(s). Discussion to be opened in #24

Discussion Summary

Next steps

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

2. Close async mechanism #8

3. Parameter definitions #8

4. RC API spec agreement → Follow-up meeting #8

• Next call will be May 22th, 2024