Docs for `emdn_get_vertical_extent()` & `emdn_get_temporal_extent()`

[maelle]

[maelle]

@annakrystalli any opinion? https://emodnet.github.io/emodnet.wcs/articles/metadata.html#get-range-of-band-values

If I remembered correctly I had to change the use case because of a problem with the former one. f2ff3a0

[annakrystalli]

Sorry! I'm not sure what the question is?

[maelle]

Does that range at the link https://emodnet.github.io/emodnet.wcs/articles/metadata.html#get-range-of-band-values look ok to you?

[annakrystalli]

Yeah, it looks ok. There should be min and max of values contained in each band which is what that looks like

[maelle]

Thank you! They just seemed so big to me. 😅

[annakrystalli]

Ah, I see what you mean.

I dug into this a bit deeper and I think I’ve completely misunderstood what I was looking at when writing the function! 🙈 The huge numeric range (-3.402823e+38 to 3.402823e+38) comes from:

x$constraint$AllowedValues$interval$value

but this does not represent the actual min/max values in the coverage. According to the OGC Web Coverage Service standards (Coverage constraints are defined under the OWS “Operations Metadata” model), Constraint → AllowedValues describes the valid domain of request parameters, not statistics of the underlying coverage data.

In other words, the service is telling us:

“This field is a Float32, so any Float32 value is allowed,”

not:

“These are the smallest and largest values present in the dataset.”

This makes the range we saw (the full Float32 domain) expected behaviour at the metadata level.

From what I can tell, WCS services generally do not expose real data min/max in CoverageSummary or Constraints. So the only reliable way to obtain meaningful ranges is to download the coverage (or a subset) and compute statistics (which obviously we don't want to do at the summary stage).

This means our helper function that surfaces these summary constraints is still useful but for a different purpose: it helps users understand what kinds of values are valid in requests, not the actual value range of the data. We should document this clearly to avoid misinterpretation.

Confirmation from the service maintainers that this is the intended meaning of Constraint → AllowedValues, might be useful to help us document the behaviour correctly in the wrapper.

[maelle]

@hyperman3 does the comment above by @annakrystalli make sense, given you know more about the services than @annakrystalli and I? 😸

[hyperman3]

Yes. It's not even a geoserver specific number, its part of how floats work. See e.g. https://en.wikipedia.org/wiki/Single-precision_floating-point_format :

an IEEE 754 32-bit base-2 floating-point variable has a maximum value of (2 − 2−23) × 2127 ≈ 3.4028235 × 1038. 

Basicaly, geoserver is telling you every non-infinite float32 is allowed.

[maelle]

Rephrased in 3577d3b

Are the values returned by the following functions also informative:

• emdn_get_vertical_extent()
• emdn_get_temporal_extent()

[maelle]

@hyperman3 reminder about my question above: #88 (comment)