Discussion on API spec - Cell's format in the response

[jgarciahospital]

During meeting held on 7th february, open questions were raised:

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. *Same solution as in Location Retrieval API

• Geohash Cells: The Coordinates of the cell are representad 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.\

(Note that optionality in one side implies obligatory for the other, in this case forcing developers to support both options)

Participants are invited to provide their view about this issue →

[sachinvodafone]

I believe , it is good idea to offer some flexibility to API providers by allowing them to choose one of these cell format that aligns with its network elements's capabilities (or limitations) . API providers should have the autonomy to decide how information will be shared with users—whether through 'Boundary Cells,' 'Geohash Cells,' or a combination of both.

Either users can specify their preferred cell format using the optional parameter ( example : '?cellFormat=boundary’ or '?cellFormat=geohash’ or '?cellFormat=default’ ) otherwise it can be defined using two scopes - one allowing "geohash" parameters to be returned and another allowing only "boundary" parameters to be returned

• population-density-data:retrieve:read:geohash
• population-density-data:retrieve:read:boundary

Now it is upto provider whether they are offering both scope or only one scope.

[gregory1g]

It is not very clear how exactly "Boundary Cells" grid looks like and who decides this. Unlike "Location Retrieval" Ppl density deals with a grid and data aggregation and therefore one should be careful moving "Location Retrieval" approach here.

Using a global grid system like geohash allows to avoid many issues one need to deal with otherwise.

[jgarciahospital]

@sachinvodafone agree on the flexibility, but that provides complexity on the provider, and also when aligning solutions among them for providing a common harmonized service to developers. We've been analyzing internally and believe that homogenizing the format is more valuable than flexibility.

@gregory1g Agree, boundary cell proposal was targeted for allowing some more flexibility but after giving it a second though, we believe that using an standard global grid will facilitate the life of developers and also implementations, ensuring that operators provide homogeneous responses.

Proposed WF: Focusing on standard global geohash cells and eliminate the option of boundary cells, at least in this first version.

Please share your feedback about this.

[greuff]

Dimetor input: our Aviation customers so far were not interested in a rasterized output format. Instead, they wanted to process GeoJSON, and that's what we implemented too. They naturally think in "volumes of airspace" where something significant happens, like danger zones or restricted zones, and thus their management systems are built with this in mind. An Airspace can be any arbitrarily shaped 3D polygon.

Now for Population Density they were so far interested in such 3D polygons as well, formatted as GeoJSON. They would send to our API the maximum population density they are able to accept in a certain area, and they would get back a GeoJSON containing such volumes (there could be more than one) where that condition is not met, i.e., where are too many people. They would then process this like any other restricted airspace where the flight is not able to be conducted.

[jgarciahospital]

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 to be closed, if no further comments are raised before next meeting.

[jgarciahospital]

Decision taken, focusing on geohash in first version