2024-11-20 Population Density Data - Meeting Minutes

CAMARA Population Density Data API - Follow-up meeting #17 - 2024-11-20

November 20th, 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 #15 and meeting agenda

• Open issues and PRs

  • Issues: #40 #48 #50 #51 #54 #56 #58

  • PR #55

• Timeline and next steps

• AoB

Open Issues & PRs

Approval of previous meeting minutes & documentation (1)

Meeting Minutes #16

→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:

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.

Status:

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:

Question whether historical data includes predictions or actual data → estimations

Issue#54

Include linting rules to the API repo, and adapt required actions to clean-up code (both included in https://github.com/camaraproject/PopulationDensityData/pull/55 )

Status:

To be validated and merged

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

AoB (4)

Next steps:

Discussion Summary

Next steps

1. Scope for next release → #17

• Next call will be TBD