Names in the raster

[maelle]

@annakrystalli please ignore #122 for now as I've stumbled upon an issue with how we find which band to apply a correction to.

It made me wonder whether emodnet.wcs should fix the names in the raster so that the names could be useful:

library(emodnet.wcs)
#> Loading ISO 19139 XML schemas...
#> Loading ISO 19115-3 XML schemas...
#> Loading ISO 19139 codelists...
wcs <- emdn_init_wcs_client(service = "biology")
#> ✔ WCS client created succesfully
#> ℹ Service: <https://geo.vliz.be/geoserver/Emodnetbio/wcs>
#> ℹ Service: "2.0.1"
coverage_id <- "Emodnetbio__cal_fin_19582016_L1_err"
# Subset using a bounding box
cov <- emdn_get_coverage(wcs,
  coverage_id = coverage_id,
  bbox = c(
    xmin = 0, ymin = 40,
    xmax = 5, ymax = 45
  )
)
#> Loading required package: sf
#> Linking to GEOS 3.12.2, GDAL 3.10.3, PROJ 9.4.1; sf_use_s2() is FALSE
#> No encoding supplied: defaulting to UTF-8.
#> ── Downloading coverage "Emodnetbio__cal_fin_19582016_L1_err" ──────────────────
#> <GMLEnvelope>
#> ....|-- lowerCorner: 40 0 "1958-02-16T01:00:00"
#> ....|-- upperCorner: 45 5 "2016-11-16T01:00:00"
#> ✔ Coverage "Emodnetbio__cal_fin_19582016_L1_err" downloaded succesfully as a
#>        terra <SpatRaster>
cov
#> class       : SpatRaster 
#> size        : 50, 50, 2  (nrow, ncol, nlyr)
#> resolution  : 0.1, 0.1  (x, y)
#> extent      : 0.05, 5.05, 39.95, 44.95  (xmin, xmax, ymin, ymax)
#> coord. ref. : lon/lat WGS 84 (EPSG:4326) 
#> source      : Emodnetbio__cal_fin_19582016_L1_err_2016-11-16T01_00_00_40,0,45,5.tif 
#> names       : Emodnetbio__cal~_00_40,0,45,5_1, Emodnetbio__cal~_00_40,0,45,5_2
names(cov)
#> [1] "Emodnetbio__cal_fin_19582016_L1_err_2016-11-16T01_00_00_40,0,45,5_1"
#> [2] "Emodnetbio__cal_fin_19582016_L1_err_2016-11-16T01_00_00_40,0,45,5_2"

# should emodnet.wcs set those names to rangesubset values?

cov2 <- emdn_get_coverage(wcs,
  coverage_id = coverage_id,
  bbox = c(
    xmin = 0, ymin = 40,
    xmax = 5, ymax = 45
  ),
  time = c(
    "2012-11-16T01:00:00",
    "2016-05-16T02:00:00"
  )
)
#> ── Downloading coverage "Emodnetbio__cal_fin_19582016_L1_err" ──────────────────
#> <GMLEnvelope>
#> ....|-- lowerCorner: 40 0 "1958-02-16T01:00:00"
#> ....|-- upperCorner: 45 5 "2016-11-16T01:00:00"<GMLEnvelope>
#> ....|-- lowerCorner: 40 0 "1958-02-16T01:00:00"
#> ....|-- upperCorner: 45 5 "2016-11-16T01:00:00"
#> ✔ Coverage "Emodnetbio__cal_fin_19582016_L1_err" downloaded succesfully as a
#>        terra <SpatRaster> Stack
cov2
#> class       : SpatRaster 
#> size        : 50, 50, 4  (nrow, ncol, nlyr)
#> resolution  : 0.1, 0.1  (x, y)
#> extent      : 0.05, 5.05, 39.95, 44.95  (xmin, xmax, ymin, ymax)
#> coord. ref. : lon/lat WGS 84 (EPSG:4326) 
#> sources     : Emodnetbio__cal_fin_19582016_L1_err_2012-11-16T01_00_00_40,0,45,5.tif  (2 layers) 
#>               Emodnetbio__cal_fin_19582016_L1_err_2016-05-16T02_00_00_40,0,45,5.tif  (2 layers) 
#> names       : Emodnet~,45,5_1, Emodnet~,45,5_2, Emodnet~,45,5_1, Emodnet~,45,5_2
names(cov2)
#> [1] "Emodnetbio__cal_fin_19582016_L1_err_2012-11-16T01_00_00_40,0,45,5_1"
#> [2] "Emodnetbio__cal_fin_19582016_L1_err_2012-11-16T01_00_00_40,0,45,5_2"
#> [3] "Emodnetbio__cal_fin_19582016_L1_err_2016-05-16T02_00_00_40,0,45,5_1"
#> [4] "Emodnetbio__cal_fin_19582016_L1_err_2016-05-16T02_00_00_40,0,45,5_2"

# should emodnet.wcs set those names to
# time1 - band 1
# time1 - band 2
# time2 - band 1
# time1 - band 2

^{Created on 2026-01-09 with reprex v2.1.1}

So currently we have these not useful names, wouldn't it be nice if looking at the names of the SpatRaster, one knew which time/depth/band they corresponded to?

[maelle]

• If there's no time nor elevation, it's easy: the names are the rangesubset values i.e. the bands.
• If there's time, the elements are ordered by time and within each time by band.
• If there's elevation, no idea. We'd need an example (which we need for test coverage too). https://github.com/eblondel/ows4R/blob/02467ed5ec727db0d779195b37ea3ea34cd8d784/R/WCSCoverageSummary.R#L694

[maelle]

@pepijn-devries Happy to get your input too! And Happy New Year!!

[maelle]

eblondel/ows4R#159

[pepijn-devries]

Hi @maelle,

Happy new year to you too from snowy Holland.

I must admit that I'm not that familiar with the SpatRaster class from the terra package. It seems that these named items are actually slices from specific dimensions. So it makes sense to translate the names to more concrete properties, such that the user can extract / subset data at specific locations, heights, times, bands, etc.

Is the naming logic documented anywhere? Is there even a standardized logic? Maybe check with the people at EMODnet?

Cheers,

Pepijn

[maelle]

eblondel/ows4R#161

[maelle]

When we are able to query by subset, we could simply split the query by subset and add the names from our side? I'm still puzzled as to why using the band/range subset in the name is a missing feature in ows4R, I might be missing something obvious.

[maelle]

anyway I'll use a workaround for now. something, probably raster, adds _1, _2 to the layers and this corresponds to bands... hopefully they are in the correct order.

[pepijn-devries]

When we are able to query by subset, we could simply split the query by subset and add the names from our side? I'm still puzzled as to why using the band/range subset in the name is a missing feature in ows4R, I might be missing something obvious.

If there is some sort of ows standardisation in place, it would make sense to address it in the ows4R package. If this is emodnet-specific, we should address it here. The thing is, I don't know 😳 . I would have to look into it...

[maelle]

Thank you @pepijn-devries! There's more activity in eblondel/ows4R#160 so I'm hopeful it could happen on the ows4R side (I think it could be useful beyond emodnet.wcs). I'll come back to this at the end of next week.

[annakrystalli]

Personally I don't think this is something we should even attempt to handle here as I suspect it has the potential to open us up to a whole world of pain. Time especially is a formal dimensions whose values can be accessed through utility functions and formally subset

[maelle]

@annakrystalli I'll see what happens in ows4R. We do need to know which layer corresponds to which band to use the data, and also to be able to apply the correct nil value.

Once #79 is fixed (GeoTools/ows4R) then we could split the requests then merge the layers, and we'd know which is which 😸 But that's not my favorite solution, compared to getting the information (which band is in which layer) from ows4R.

Hope that makes sense.

[annakrystalli]

Thanks @maelle. I agree the current band names are not user friendly and I can see how this creates friction. However, after some digging, I don't think this is something ows4R should be handling, nor something we should take on in emodnet.wcs. Here's my reasoning:

This is standard WCS/GeoServer behaviour

The WCS specification separates coverage description (via DescribeCoverage, which includes the rangeType with band names) from coverage delivery (via GetCoverage). The GeoTIFF Coverage Encoding Profile (OGC 12-100r1, Section 6.3.2) states:

Requirement 10 /req/geotiff-coverage/range-ordering:
A GeoTIFF encoded coverage instance with more than one component in the rangeType
shall order the components of the coverage's rangeType in the same order as given in the
gml:rangeType element's document order.

so it only specifies that bands in the output must be ordered consistently with the rangeType document order, but does not require that band names be embedded in the GeoTIFF metadata.

GeoServer returns GeoTIFFs with generic band naming. This may be a known limitation: the same question was raised by another user in 2022 and appears to have gone unanswered.

The filenames do include timestamps (as we can see: Emodnetbio__cal_fin_19582016_L1_err_2012-11-16T01_00_00_40,0,45,5_1), and the _1, _2 suffixes correspond to band order from the rangeType, with bands ordered by time then by band within each timepoint.

What we already provide

Users can get band names via our existing metadata utilities (emdn_get_coverage_info() etc.). This information is available, it's just not embedded in the downloaded raster.

Why I'm hesitant to handle this in emodnet.wcs

Renaming bands in emdn_get_coverage() would require an additional DescribeCoverage call for every download, adding latency. More importantly, it couples two previously independent operations. A transient failure or malformed response from DescribeCoverage would now break downloads that would otherwise succeed. Any upstream quirks in metadata structure become our problem to handle and debug during download.

For now, I'd suggest we improve documentation to explain the naming convention and point users to the metadata utilities for getting band names when they need them.

[maelle]

but to apply the nil value, we need to know which is which?