"Open" qualifier for intervals (collections)

[jerstlouis]

Mathematically an open interval is an interval that stops before a specific point, but does not include it, e.g (0, 10] means greater than 0, but less or equal to 10, and is called "left-open".
Requirement 11 uses "open" meaning "open-ended" for what is probably more appropriately called an infinite interval.

https://mathworld.wolfram.com/OpenInterval.html
https://en.wikipedia.org/wiki/Interval_(mathematics)
http://www.mathquickeasy.com/types_of_intervals.html

Related: Requirement 17 D should probably be moved to Requirement 16 B as it talks about the query parameter (16), rather than the response (17)?

It should also be clarified where ".." and null are valid to mean "infinite", e.g. in datetime value, vs. in temporal extent definitions. My undertanding is that ".." is expected for the query parameter, but extent definitions should use null for the same meaning, and that is easy to confuse. We have seen implementations mixing this up, so it should probably be made clearer.

[cmheazel]

@jerstlouis Requirements 16 and 17 match requirements 24 and 25 in API-Features. I don't believe we can re-define the semantics of the datetime parameter at this point.
Requirement 15 (old 16) defines the structure of the parameter. Validation is performed against the request URI.
Requirement 16 (old 17) defines how the parameter shall be processed and the results of that processing. Validation is performed against the response.
The parts of requirements 16 and 17 have been allocated based on this scoping.
Note: EBNF in Requirement 15 has been updated to match the approved version of API-Features. (this corrects an error in R15)

[jerstlouis]

@cmheazel This issue was not about re-defining the semantics, but clarifying it:

1. Open vs. Bounded -- proper terminology
2. ".." and null for query parameters and for within extent interval -- which is used/allowed in which context

[cportele]

I agree that the use of "open interval" or "open range" was not a good idea and, while the meaning is clear from the context, I also support an update to the wording in the Features standard to the terminology that is in common use. I will work on a PR for Features and let this group know, too, when it is ready for review.

[jerstlouis]

@cportele Cool, thank you!

While in the Features spec PRs, could you also please take a look at the multi-part extent clarification, which I don't think is saying the right thing:

Clients only interested in the overall spatial extent will only need to access the first item in each array.

I rephrased that in Coverages as:

Clients only interested in the overall extent will only need to access the first item (a pair of lower and upper bound values).

https://github.com/opengeospatial/ogcapi-features/blob/master/core/openapi/schemas/extent.yaml#L104
https://github.com/opengeospatial/ogcapi-features/blob/master/core/openapi/schemas/extent.yaml#L28

The "each" is misleading, as what we want to say is that the client only needs to access the single first item of either the bbox or the interval, which itself is an array.

All of that is already done in Coverages, so perhaps that could be useful as a basis for your other PR as well:

https://github.com/opengeospatial/ogcapi-coverages/blob/master/standard/openapi/schemas/coverages-core/envelope.yaml#L15

[cmheazel]

Updated API-Common Part 2 to align with the mods made in API-Features through issue 650