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

→

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, to align

AP:

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#51 historical information

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?

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: move to integer format

Issue#62

Include error status for callback response if area cannot be processed

Status: move to integer format

PR#59

Solving 56 & 58

Status: to be merged

PR#60

Solving 51

Status: to be reviewed

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

Discussion Summary

Next steps

1. Scope for next release → #17

• Next call will be TBD