petascope relies on opengis CRS URIs

[Dimitar Misev]

Even when the configured resolver is localhost, the CRS definitions in it could contain opengis URIs. If the opengis resolver is down petascope takes some defaults I assume, which breaks down the systemtest. E.g. UoM should be degree, but something else is extracted here as ​http://www.opengis.net/def/uom/EPSG/0/9122 is unresolvable:

 DEBUG [10:57:50] CrsUtil@567: Extracted name of the UoM from http://www.opengis.net/def/uom/EPSG/0/9122 is 9122.
 DEBUG [10:57:50] CrsUtil@471: Axis element found: Lat[9122]
 DEBUG [10:58:00] CrsUtil@567: Extracted name of the UoM from http://www.opengis.net/def/uom/EPSG/0/9122 is 9122.
 DEBUG [10:58:00] CrsUtil@471: Axis element found: Long[9122]

Probably the best way to fix this would be for petascope to retry with the resolver configured in the petascope.properties

[Dimitar Misev]

patch submitted.

[Bang Pham Huu]

Hi Dimitar,

I think the opengis has change the link to CRS, at least with the 2D

In this link ​http://rasdaman.org/wiki/WCSTImportGuide (the opengis 2D is not available) in the ingredient file. (map_mosaic.json).

the old one is: "default_crs": "​http://opengis.net/def/OGC/0/Index2D",
the new one is: ​http://opengis.net/def/crs/OGC/0/Index2D

And the result is when I run the wcst_import map_mosaic.json it notice that the CRS link is not available.

I don't know this problem is updated in your new patch? If it has already, please just see it is a report that you already know.

Thanks.

[Peter Baumann]

OGC up to now has not found a stable maintenance procedure for their URIs, despite manifold requests and proposal for support. Bottom line: don't rely on the OGC resolver to be available. Disclaimer: Currently.