CAMARA Population Density Data API - Follow-up meeting #3 - 2024-03-06

March 06st, 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 #2 and meeting agenda

• Open issues and PRs

  • PRs: #5 #11

  • Issues: #6 #7 #8 #10

• Initial algorithm proposal review

• Timeline and next steps

• AoB

Open Issues & PRs

Approval of previous meeting minutes & documentation (1)

Meeting Minutes #2

API proposal review (2)

Different discussions raised during the API review:

• Issue#8 Cell's format in the response → (Issue closed)

• Issue#6 Information in water zones: Operators and therefore API can only provide data of those zones where it is operating. Water zones are not considered and current implementation will provive an error in case the requested zone includes a water zone. Dimetor proposes to only provide "nonData" or null response for those specific cells, but not a complete error, conscious of the multiple cases where flights will indeed consider water zones due to the expected low population density.

  Proposed WF (discussed in the meeting and based on offline discussions):

  • For request containing areas totally outside of the operator's reach, response should be:

    • Empty response/array --> Dimetor, Telefonica

    • Error -->

    • Vodafone's comment: "how will developers know about the reason of empty array? Status parameter to be added." → agreed WF

  • For mixed areas, including cells with a value available and other with no data (outside the operator's reach):

    • Only cells for the zones with a real value --> Telefonica

    • WF: Only cells for the zones with a real value, with a status parameter specifying that issue → Vodafone, Dimetor, Telefonica. → agreed WF

    • Cells for the complete request zone with no density value --> Vodafone

  → Values for status (innitial proposal): "enum": ["OK_SUPPORTED_AREA", "PART_OF_ AREA_NOT_SUPPORTED ", "AREA_NOT_SUPPORTED"] 

   

• Issue#7 Open discussion on default and limit values for the API characteristics:

  • Minimum and maximum date minimum and maximum date allowed as requested time range. Currently, 15 minutes is set as the minimum (soonest time target the request can consider), and 1 year for maximum (longer date with information to extrapolate). 

  • Time interval in the request: Maximum (and minimum) length of the time range requested in the API. 

  • Time granularity in the response: Length of the information pieces in which the time interval is subdivided in the response. Default value is proposed in 1hour, so the response will include density information of each 1 hour range that can be included in the requested interval. E.g. If request interval is 15 minutes to 1 hour, 1 only result will be provided, if 3 hours and 45 minutes are requested, 4 results will be provided (from 0-1, 1-2, 2-3, 3-3:45).

  • Cell size/granularity in the response: Currently both cell definition systems allow to implement different size of cells. 

  • New topic: max size of the requested area.

•  

  • Close time frame limits in t=0 (min) and reduce max to t=(3)months (max) with data prediction algorithm in all the timeframe. That covers current use case.

  • Document in the API yaml that response will include equal-sized cells, focusing on the geohash cells format.

  • Default value on level 7 (150m x 150m). (TBC)

  • 1 week (7 days) is proposed as maximum time frame length.

  • Maintain 1 hour as the time granularity for the response.

  • Open discussion on maximum requested area size, need to consider a feasible maximum response size jointly with the maximum length of the timeframe.

• Issue#10

• Additional: (comment from Sachin) format of the response in terms of which parameter (time or space) is used a primary key in the response chain. Analysis need to be performed based on geohash format, which format is more optimal in that case. With GeoHash format, cells will be equal and stable in the complete response, so having a vector of cells with the information of the timeline per each of them can work properly. 

Initial algorithm proposal (3)

Population Density API - Algorithm.pdf

Discussion

Next steps

1. Review and close open points PDD → Follow-up meeting #4

2. Close discussion on formats→ Follow-up meeting #3

3. Feedback on algorithm proposal→ Follow-up meeting #4

4. Feedback on the big responses management #4

5. RC API spec agreement → Follow-up meeting #5

• Next call will be March 19th, 2024