CAMARA Population Density Data API - Follow-up meeting #2 - 2024-02-21

February 21st, 2024

Attendees

Population Density Data API minutes: https://wiki.camaraproject.org/display/CAM/Population+Density+Data+API+Minutes

Agenda

• Approval of previous meeting minutes #1 and meeting agenda
• Open issues and PRs
  • PRs: #5 #9
  • Issues: #6 #7 #8
• Timeline and next steps
• AoB

Open Issues & PRs

Approval of previous meeting minutes & documentation (1)

Meeting Minutes #1

API proposal review (2)

Different discussions raised during the API review:

• Issue#8 Cell's format in the response: Currently, API support two different formats of defining the cells in which the requested area is divided for providing the information in the response:

  • Boundary Cells: The cell is defined by a polygon, composed by the internal area bounded by 4 geo positions. *Similar solution as in Location Retrieval API

  • Geohash Cells: The Coordinates of the cell are represented as a string using the Geohash system. The value length, and thus the cell granularity, is determined by the implementation.

  Discussion on which mechanisms to restrict, or how to allow developers to select one of them if multiple are supported.

  Proposed WF (discussed in the meeting and based on offline discussions):
  • To focus on standard global geohash cells and eliminate the option of boundary cells, at least in this first version. New version may consider GEOJSON in the output, as suggested by Dimetor, due to the current support and preference of certain customers.

• 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 -->
  • 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
    • Cells for the complete request zone with no density value --> 
  • To open again discussion focusing on geohash format. Feedback required previous to next meeting.

  
  

• 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.

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

• • Close time frame limits in t=0 (min) and reduce max to t=(3-6)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.
  • 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.

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:

Discussion

Next steps

1. Review and close open points PDD → Follow-up meeting #3
2. Propose initial draft of algorithm → Follow-up meeting #3
3. RC API spec agreement → Follow-up meeting #3

• Next call will be March 06th, 2024