2025-12-17 Population Density Data - Meeting Minutes

2025-12-17 Population Density Data - Meeting Minutes

CAMARA Population Density Data API - Follow-up meeting #26 - 2025-12-17

December 17th, 2025

Attendees

Name

Company

Name

Company

@Ludovic Robert

Orange

@Violeta González

TEF

@Alberto Ramos Monaga

TEF

@Sachin Kumar

VOD

 

 

 

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: Fall26 meta-release scope

  • Timeline and next steps

  • AoB

Open Issues & PRs

#

Company

Summary

#

Company

Summary

PR#104

TEF

Draft until next meta-release: Delete additional text for RFC date time format

#105 & PR#106

TEF

Issue (Release Management) - Align asynchronous response with CloudEvents format to ensure compliance with Commonalities r3.3

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 - No new updates

#108 & PR#108

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 - No new updates (ready to include in new version)

#109

Population Density Data Group

Scope for Fall26 release (in preparation): Please add your proposals in the comments and open issues if needed.

#110

Orange

Provide a list of GeoHashes in the API request: Add support for GEOHASHLIST as a new areaType, allowing developers to send a list of geohashes (precision 7) in the request.

Goal: Improve request precision and predict response volume.

Note: This would complement, not replace, the current area definition method.

Solved - TEF will implement the changes in the next PR agreed with the discussion

#111

Governance

Reset API and test code version information in main branch to wip

The main branch of this repository contains API definitions and/or test files with version references that are not yet reset to wip. According to CAMARA guidelines, all version fields on the main branch must use work-in-progress (wip) versions between releases.

Can be close after merge PR#108

API proposal review (2)

Clarifications for asynchronous response in callback #533 - No new changes since last meeting

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

Captura de pantalla 2025-10-29 a las 10.09.58.png
  • 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.

  • Which version are we going to use for the next meta-release? v0.4 or v1.0?

    • Checklist - v1.0 - Go/No-Go

      • User Stories complete and stored in the repo - ❌ (create an issue)

      • README / MAINTAINERS / CODEOWNERS updated (≥3 maintainers from ≥3 companies) - ✅️ (TEF, Vodafone & Verizon)

      • API Description (Marketing page) published - ✅️

      • OAS 3.0.3 valid and fully aligned with CAMARA Design Guidelines, Commonalities, ICM - ✅️

      • Linting passes with no open violations - ✅️

      • Full Gherkin test suite (sunny + rainy day) - ✅️

      • Enhanced test documentation (mapping tests → behaviours) - ⚠️ (under review by the group)

      • Test Result Statement: at least one member has executed the repo’s tests successfully on a real implementation - ⚠️

      • Previous public version is certified (mandatory for publishing a new stable) - ⚠️ (inform release management)

  • Decision: solved this remaining points (⚠️) for next meeting 21th Jaunary

AoB (4)

N/A

Discussion Summary

#

Summary

Status/conclusion

#

Summary

Status/conclusion

 N/A

N/A 

 N/A

Next steps

N/A

Action Points

  • User Stories complete and stored in the repo - ❌ (create an issue)

  • Enhanced test documentation (mapping tests → behaviours) - ⚠️ (under review by the group - create an issue)

  • Test Result Statement: at least one member has executed the repo’s tests successfully on a real implementation - ⚠️

  • Previous public version is certified (mandatory for publishing a new stable) - ⚠️ (inform release management)

  • Send a recap email for the group.

    • Deadline: 21th Jaunary