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

May 08th, 2024

Attendees

Population Density Data API minutes: https://wiki.camaraproject.org/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 Closed

Issue#13

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

Issue Closed

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 Closed and PR merged

Issue#16

Orange: Align location area format with other APIs of CAMARA

Issue Closed

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.

Discussion: Not clear about best option. Current one, specified in #21, is focused on callback mechanism. To be confirmed offline

AP: Confirm strategy on the proposal to first focus on current callback mechanism for this version, adapted to any modification of Commonalities Subscription mechanism.

PR#19

Solving Issue#15

PR closed

PR#21

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

To be merged when closing Issue#20

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