...
Open Issues & PRs
| N# | Company | Summary |
|---|---|---|
| PR#5 | Telefonica | Initial contribution of the Population Density API spec |
| Issue#6 | Telefonica | Information in water zones discussion → to be closed |
| Issue#7 | Telefonica | Default and limit values for the API Characteristics |
| Issue#10 | Telefonica | Management of "big" responses → to be closed |
| Issue#12 | Telefonica | Discussion on API algorithm - Initial proposal |
| Issue#13 | Ericsson | API time format |
| Issue#14 | Ericsson | Exposed data - Population vs density |
| Issue#15 | Ericsson | Including redoc and swagger editor link in readme |
| Issue#16 | Orange | Area format alignement |
| Issue#20 | Orange | Async operation proposal |
| PR#19 | Telefonica | Modification of readme |
| PR#21 | Telefonica | Solves #6 #7 (partial) #10(partial) #13 #15 #20 (open) |
...
Let max area size open (technically) to a reasonable use case management, each operator can of course launch an error in case the size is not supported.
Issue to be closed after "bigger area than supported" error is included in the code
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.
...
Decision: Support async endpoint for bigger and smaller areas, also needing to define a size limitation (area, duration and granularity) (TBD in issue #7). In any case, the response will be part of the API response body. Only identified limitation is on the calculation time, not in the response size.
Issue #10 to be closedclosed
Ericsson: Time format alignment with commonalities, supporting RFC instead of ISO
...