2024-12-18 Population Density Data - Meeting Minutes

CAMARA Population Density Data API - Follow-up meeting #18 - 2024-12-18

December 18th, 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 #17 and meeting agenda

• Open issues and PRs

  • Issues: #40 #48 #50 #51 #56 #58 #61 #62

  • PR #59 #60

• Timeline and next steps

• AoB

Open Issues & PRs

Approval of previous meeting minutes & documentation (1)

Meeting Minutes #17

→ Approved

API proposal review (2)

Issue#40

Issue opened in commonalities for the alignment on how to define the area types along all the APIs in CAMARA.

AP: provide direct feedback on the commonalities issue Issue #242. Groups is ok to create a homogeneous definition of the area types, as long as each API can later select granularly which types apply (and not getting obligation to support all the types, or getting involved in a complex data model).

Status: Commonalities closed for circle and polygon, enough for PDD.

AP: Check if format in commonalities is aligned with current PDD and align if needed

Issue#48

Propose new scope for next release.

Included so far:

• Issue#40 on area type formar

• (new) Issue#50 on async response mechanism

• Issue#61 request ID in async response

• Issue#62 error for async processing

Status: Alpha release of commonalities getting ready, we’ll adapt API accordingly

Issue#50

Include alignment with commonalities for the async response mechanism (and any)

Status: Commonalities closed Analysis+of+Commonalities+0.5.0-alpha.1+changes#Analysis. To start with current alpha1 version and wait for any additional change if needed

AP:

Issue#51

Support time window for past time frames, historical data.

AP: include use cases in the API scope (readme) and yaml/testplan to ensure API is also aligned

Status:

PR#60

Issue#56

Easing code parameters and polymorphic formats

Status:

• The polymorphic patter use on line 576-578 is not developer-friendly as it require a manual processing with code generator. It will be better to use same name for the enum value and the corresponding class.

  • → Just align naming in classes and enum, maintaining polymorphic

• There is probably unnecessary complexity with all the classes defined in the yaml. We can merge CellPopulationDensityData and PopulationDensityData in one class and avoid one unnecessary level that will make the API sipler

  • → Check if this change breaks or not the polymorphic

  • Proposal to maintain at level of cellPopulationDensityData, merge PopulationDensityData in one big class including both curren geohash and the rest of parameters now included inside cellPopulationDensityData:

"cellPopulationDensityData": [

        {

          "geohash": "u09tsm9",

            "dataType": "DENSITY_ESTIMATION",

            "maxPplDensity": 25737.0,

            "minPplDensity": 12704.0,

            "pplDensity": 24273.0

          }

• The class DensityEstimationPopulationDensityData has probably too many Density but this point is linked to my first point.

• → solved by point 1

Issue#58

Value format (double/integer) for density data

Status: move to integer format

Issue#61

Include ID in notification to track request-response

Status: create PR with this new parameter, aligned with QoD sessionID mechanism

Issue#62

Include error status for callback response if area cannot be processed

Status: Align with geofencing when processing the are (in that case area subscription), in case this is covered there in the callback (and not only in the post response)

AP: check with geofencing, also around the 400/422 in the sync mechanism

PR#59

Solving 56 & 58

Status: to be merged by the end of the day

PR#60

Solving 51

Status: to be reviewed and merged, leaving historical age restriction open for the moment

AoB (4)

Next steps:

• Close current PRs to freeze API content

• Align commonalities as expected

• Release tracker created for 0.2.0, RC to be created before 15/01 (next meeting)

Discussion Summary

Next steps

1. Scope for next release → #17

• Next call will be TBD