disallow null as extent boundary value

[pebau]

In the OAPI-Common extent definition null values are allowed (although only by way of an informal comment in the description). For a coverage this means that the domain extent in a direction containing an "unbounded" is undefined. This will break coverage applications.

It has been discussed that this describes the potential extent, but then this acts more like a "coverage type definition", which is different from the concrete instance's extent. The extent property as it stands in any case defines the concrete extent.

Therefore, OAPI-Coverages should contain a restricting requirement that in a coverage view (or context, whatever it will be called) a null extent value is not admitted.

PS: On a side note, if "null" wants to express "unbounded" then this is a hack, the corresponding value should be "unbounded".

[jerstlouis]

Concerns discussed in the call today (2021-07-28):

• An OGC API collection may be available using multiple mechanisms, including e.g. Features and Coverages. It would then be problematic for Coverages restrictions which would be extended to Features as well.
• null time interval bounds are inherited by Common from Features which says:

The temporal extent may use null values to indicate an open time interval.

• In an OGC API - Coverages implementation, a domainset resource as defined by CIS is always separately available. I have also encountered null values there in implementations. Restrictions there would not affect other access mechanisms. However, according to the CIS JSON schema, it seems that null is currently allowed. When encountered, it was also used with the meaning of an open time interval.

The hope is that this extent/envelope definition, including description of dimensions beyond the 2-3 spatial and 1 temporal, be a conformance class defined in OGC API - Common - Part 2: Geospatial data (see opengeospatial/ogcapi-common#91, opengeospatial/ogcapi-common#167, opengeospatial/ogcapi-common#274). Perhaps a recommendation to avoid null values would satisfy the concerns? We could perhaps also avoid null values for the additional dimensions, since Features seems to only allow null values specifically for the temporal dimension already.

See also opengeospatial/ogcapi-common#196 .

[pebau]

is there anywhere an exact specification of what such a null value means for the concrete object? How does it behave on subsetting? on bbox search? etc.

[jerstlouis]

@pebau

For Features / Common, there is only this where it just says that it means "an open interval". However as I highlighted in opengeospatial/ogcapi-common#196, what is meant is probably an infinite interval, since an open interval has a different meaning in mathematic. The example in Features is the end time being set to null, presumably because the features are live data which are constantly updated and thefore constantly retrieving the collection description to update the upper bound would be impractical.

In CIS, I just found out section 17.4 pertaining to the coverage-partitioning class where it says in 17.4 Domain set constraints:

The sub-coverage domain sets, as well as single direct positions, must be non-overlapping (considering all axes plus the range components) and properly contained in the super-cover­age; missing boundary values are represented as a null value.
Such null values can be used whenever the actual extent of the super-coverage is not known in the super-coverage itself, such as in timeseries where further timeslices can be appended at any time. The representation of such a null value is defined in the concrete encodings.

That CIS meaning actually seems fully consistent with the use of null in the extent / envelope.

It should probably not be limited to the coverage-partitioning class, since implementations can internally have a concept of scenes/images, without exposing the coverage as a partioned coverage.

[jerstlouis]

SWG 2022-02-16: Closing this issue because the definition of the Collection extent is defined by OGC API - Common - Part 2: Geospatial data. There is also already an example where null is used with the same meaning in CIS for coverage-partitioning, and the interpretation is clear, therefore this should not cause any issues for OGC API - Coverages. It also does not affect in any way the CIS specification/encoding.