`ows4R` classes not available to methods on objects created using `ows4R::` ( i.e. with package not loaded)

[Anna Krystalli]

When using ows4R methods after calling ows4R::WCSClient (i.e using :: rather than loading package as is required practice in package development), required classes are not available unless the package is loaded.

wcs <- ows4R::WCSClient$new(url = "https://ows.emodnet-humanactivities.eu/wcs",
                     serviceVersion = "2.0.1")
#> Loading ISO 19139 XML schemas...
#> Loading ISO 19115 codelists...
#> Loading IANA mime types...
#> No encoding supplied: defaulting to UTF-8.

coverage <- "emodnet__2017_01_st_00"
wcs$describeCoverage(coverage)
#> Error in eval(parse(text = self$getClassName())): object 'WCSCoverageDescription' not found
summary <- wcs$getCapabilities()$findCoverageSummaryById(coverage)
summary$getDescription()
#> Error in eval(parse(text = self$getClassName())): object 'WCSCoverageDescription' not found
library(ows4R)
#> Loading required package: geometa
#> Loading required package: keyring
wcs$describeCoverage(coverage)
#> Loading required package: sf
#> Linking to GEOS 3.9.1, GDAL 3.4.0, PROJ 8.1.1; sf_use_s2() is TRUE
#> <WCSCoverageDescription>
#> ....|-- boundedBy <GMLEnvelope>
#> ........|-- lowerCorner: -622999.999999999 604000.000000006
#> ........|-- upperCorner: 6885000 7035000.00000001
#> ....|-- domainSet <GMLRectifiedGrid>
#> ........|-- limits <GMLElement>
#> ............|-- GridEnvelope <GMLElement>
#> ................|-- low <GMLElement>
#> ....................|-- value: 0 0
#> ................|-- high <GMLElement>
#> ....................|-- value: 7507 6430
#> ........|-- axisLabels <GMLElement>
#> ............|-- value: i j
#> ........|-- origin <GMLPoint>
#> ............|-- pos: -622499.999999999 7034500.00000001
#> ........|-- offsetVector <GMLElement>
#> ............|-- value: 1000.0 0.0
#> ........|-- offsetVector <GMLElement>
#> ............|-- value: 0.0 -1000.0
#> ....|-- coverageFunction <GMLGridFunction>
#> ........|-- sequenceRule <GMLElement>
#> ............|-- value: Linear
#> ........|-- startPoint <GMLElement>
#> ............|-- value: 0 0
#> ....|-- rangeType <GMLElement>
#> ........|-- DataRecord <GMLElement>
#> ............|-- field <GMLElement>
#> ................|-- Quantity <GMLElement>
#> ....................|-- description <GMLElement>
#> ........................|-- value: GRAY_INDEX
#> ....................|-- nilValues <GMLElement>
#> ........................|-- NilValues <GMLElement>
#> ............................|-- nilValue <GMLElement>
#> ................................|-- value: -9999.0
#> ....................|-- uom <GMLElement>
#> ....................|-- constraint <GMLElement>
#> ........................|-- AllowedValues <GMLElement>
#> ............................|-- interval <GMLElement>
#> ................................|-- value: -3.4028235E38 3.4028235E38
#> ....|-- metadata <GMLCOVExtension>
#> ........|-- Keywords <ISOElementSequence>
#> ............|-- Keyword: GeoTIFF
#> ........|-- Metadata[xlink:type=simple,xlink:href=https://www.emodnet.eu/geonetwork/emodnet/eng/csw?service=CSW&version=2.0.2&request=GetRecordById&elementsetname=full&id=ccc4cd96-a838-4368-8a7f-9e2637a8b3ef&outputschema=http://www.isotc211.org/2005/gmd]
#> ....|-- CoverageId <GMLElement>
#> ........|-- value: emodnet__2017_01_st_00
#> ....|-- ServiceParameters <ISOElementSequence>
#> ........|-- CoverageSubtype: RectifiedGridCoverage
#> ........|-- nativeFormat: image/tiff

^{Created on 2022-08-17 by the reprex package (v2.0.1)}

This causes problems when using ows4R internally in other packages as loading the whole package is not recommended while loading individual classes is cumbersome and feels unnecessary. Should the required classes not be imported by the methods requiring them in ows4R? Interestingly I had not come across this problem with EMODnetWFS

[Emmanuel Blondel]

In context of ows4R, that's a complex issue, it deals with geometa that I will tackle asap. For the timebeing, you have to import the package, and can't rely on the namespace approach. This said, using ows4R, you depend on geometa, so it's still valid approach to consider an import. In the case of WCS, as I said in another ticket, the Coverage description is directly handled by the GML COV specification which is managed by geometa. To avoid any binding issue, you will need to have all geometa classes loaded. You don't have the issue in WFS, because WFS feature type description are managed by the OGC WFS standard, not any base binding managed by geometa.

[Anna Krystalli]

I've included a workaround for this (i.e. loading the package on loading of EMODnetWCS) P.S. I had to load ows4R not geometa for it to work so the class appears to be internal to ows4R.

[Emmanuel Blondel]

@annakrystalli can you please re-install geometa and ows4R, and retry the above code? The problem is related to the fact that WCSCoverageDescription inherits from a specific GML binding that is managed in geometa. Because it's part of geometa package, with the ows4R:: approach, ows4R decoding (which approach consist in loading the appropriate binding from XML elements, at decoding time) was unable to understand WCSCoverageDescription parent class is actually part of geometa and not ows4R; which is not straightfoward in R to implement with the R6 class model. I found a way to make sure this inheritance works, and ows4R auto-discovers the corresponding GML binding in geometa.

Let me know if it works for you

[Anna Krystalli]

Thanks @eblondel , this works now.