2025-11-19 Population Density Data - Meeting Minutes
CAMARA Population Density Data API - Follow-up meeting #26 - 2025-11-19
November 19th, 2025
Attendees
Name | Company |
|---|---|
@Alberto Ramos Monaga | TEF |
@Violeta González | TEF |
@Sachin Kumar | Vodafone |
@Rafal Artych | DT |
@istván andrás horváth | Ericsson |
Approval of previous meeting minutes & documentation (1)
Meeting minutes: OK
Agenda
Approval of previous meeting minutes and meeting agenda
Open issues and PRs
Agenda 1: Clarifications for asynchronous response in callback #533
Agenda 2: Fall26 meta-release scope
Timeline and next steps
AoB
Open Issues & PRs
# | Company | Summary |
|---|---|---|
TEF | Draft until next meta-release: Delete additional text for RFC date time format | |
TEF | Issue (Release Management): The asynchronous response in PredictiveConnectivityData and Population Density Data does not comply with Commonalities r3.3 (uses application/json instead of CloudEvents). Status: An issue (#533) has been created in the commonalities group to address this issue. Once a decision has been made, it will be applied to this issue. | |
Orange | Some model names use SNAKE_CASE in place of CamelCase: NO_DATA, LOW_DENSITY, and DENSITY_ESTIMATION models do not respect naming conventions defined in Commonalities | |
Population Density Data Group | Scope for Fall26 release (in preparation): Please add your proposals in the comments and open issues if needed. | |
Orange | Provide a list of GeoHashes in the API request: Add support for Goal: Improve request precision and predict response volume. Note: This would complement, not replace, the current area definition method. |
API proposal review (2)
Agenda 1: Clarifications for asynchronous response in callback #533
Problem description
Some APIs such as Population Density and Predictive Connectivity Data support asynchronous responses for large or time-consuming requests by allowing a sink (callback URL).
Current CAMARA guidelines define two subscription types — instance-based (implicit) and resource-based (explicit) — and specify that event notifications use CloudEvents.
The open question is whether asynchronous responses (triggered once per request) should also adopt the CloudEvents structure, or remain simple JSON payloads.
Discussion summary
Patrice Conil and Pedro Diez both argued that an asynchronous response is not an event but rather a deferred response, which happens once and whose value lies in the payload, not in the occurrence of the event itself. Therefore, using CloudEvents adds unnecessary overhead and does not conceptually fit this case.
The group agreed that the key question is whether CAMARA should mandate CloudEvents as the default envelope for asynchronous responses, or allow plain JSON responses for simplicity.
Next step
→ The group will discuss and reach a consensus on this topic in an upcoming meeting before applying any decision or documentation update.
Agenda 2: Fall26 meta-release scope - Issue created: #109
Note: APIs are recommended to target the Fall26 Meta-release, but some exceptions can be discussed.
For these exception, the concerned APIs should be aware that the Spring26 schedule is very tight.
Recommended to skip Spring26, but exception may exist e.g. for APIs that dropped from the Fall25 meta-release.
Requests for Spring26 participation are to be done through a GitHub issue in Release Management
AoB (4)
N/A
Discussion Summary
# | Summary | Status/conclusion |
|---|---|---|
N/A | N/A | N/A |
Next steps
N/A