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

March 06st, 2024

Attendees

Population Density Data API minutes: https://wiki.camaraproject.org/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.

Agreed WF

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

Following the discussion on maximum time frame and area to cover, we've been analyzing the management of valid/useful requests and the corresponding response. Considering the size of a common request, of 1 week and common areas of around 10Km2, the size of the response's content may be too big for being handled directly in the API REST body.

Proposal to analyse

Include a second option for a developer to be able to request a big area, that will receive as response containing a file link instead of a direct content response. That will allow developers to better manage big responses (<1MB) when asking for data of big areas or long time frame. To discuss the best approach on how to manage both flexibility and speed of a direct response, with more complete data in a filed response.

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

Proposed WF: it makes sense to consider a time vector (primary key) with each cells included in each timeslot, so only cell information (small in geohash) is repeated. To formalize in the code

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