Petacope_CRS_Extension extract 2D CRS from compound CRS (3D, 4D,...)

[Bang Pham Huu]

Currently, in Petascope, with WCS request and CRS_Extension like

localhost:8080/rasdaman/ows?service=WCS&version=2.0.1&request=GetCoverage&
coverageId=eobstest&format=image/tiff&
subset=t(0)&outputCrs=http://www.opengis.net/def/crs/EPSG/0/3857

Update For the purpose of this ticket, CoverageMetdata object can extract correctly the URIs in crsUris property.

with irr_cube_2 it can returns from CompoundCRS:

http://localhost:8080/def/crs/EPSG/0/32633
and
http://localhost:8080/def/crs/OGC/0/AnsiDate

so try to adapt these metadata correctly in WCS subsettingCrs, outputCrs and WCPS crsTransform().

---

E.g: WCS on a coverage which has compoundCRS

service=WCS&version=2.0.1&request=GetCoverage&coverageId=eobstest&
subset=Lat(45,60)&subset=Long(25,30)&subset=t(0)&format=image/tiff&
outputCrs=http://localhost:8080/def/crs/EPSG/0/4269

will return a Rasql with error in CRS of projection()

select encode(
project( c[0,0:10,31:61], "25.0,45.0,30.0,60.0", "EPSG:4326", ":" ),
 "GTiff", "xmin=25.0;xmax=30.0;ymin=45.0;ymax=60.0;crs=EPSG:4326") 
from eobstest AS c where oid(c)=1537

[Dimitar Misev]

So this needs to be properly transformed to WCPS internally, instead of having some special code to transform non-native subsets. Otherwise it's just duplicating code for doing the same thing.

wcs	wcps
subsetCrs	axis:crs
outputCrs	crsTransform

[Bang Pham Huu]

Replying to dmisev:

So this needs to be properly transformed to WCPS internally, instead of having some special code to transform non-native subsets. Otherwise it's just duplicating code for doing the same thing.

wcs	wcps
subsetCrs	axis:crs
outputCrs	crsTransform

In this case, WCS should use the class handle in WCPS as it works the same behavior as Dimitar has pointed out. The CRSExtension in wcs2.extensions can be removed if no need to handle these parameters (outputCrs, subsettingCrs) anymore.

[Dimitar Misev]

I don't think it should be removed completely, as it has the extension identifier and parsing of the parameters. Just the coordinate transformation should be removed.

[Bang Pham Huu]

Replying to dmisev:

I don't think it should be removed completely, as it has the extension identifier and parsing of the parameters. Just the coordinate transformation should be removed.

Almost of this class is to deal with coordinate transformation, and parsing subsettingCrs, outputCrs to get CRS if it is available is very tiny.

[Dimitar Misev]

Yes, I just meant the class should not be removed completely.

[Bang Pham Huu]

I think even in WCPS crsTransform() the CRSCompound is not handled correctly.

for c in (irr_cube_2)
return encode(crsTransform(c[ansi(148654)],
 { E:"http://www.opengis.net/def/crs/EPSG/0/3542", N:"http://www.opengis.net/def/crs/EPSG/0/3542"}, {}), "netcdf")

Error: Error evaluating rasdaman query: 'select encode(project( (c) [*:*,*:*,0],
 "75042.72735943,5094865.5579385,705042.72735943,5454865.5579385",
 "OGC:AnsiDate", "EPSG:3542" ), "netCDF", "xmin=75042.72735943;xmax=705042.72735943;
ymin=5094865.5579385;ymax=5454865.5579385;crs=OGC:AnsiDate") 
from irr_cube_2 AS c where oid(c)=4609

Here it tried to use "OGC:AnsiDate" as source CRS which is wrong (it should use 32633 from native CRS of irr_cube_2).

[Bang Pham Huu]

It is fixed in the patch ticket 1188, WCPS 1.5, close ticket.

SELECT encode(project( c[0,0:9,31:60], "25,45,30,60", "EPSG:4326", "EPSG:4269" ),
"GTiff" ,
"xmin=25;
ymin=45.000000000943231270866817794740200042724609375;
xmax=29.999999999999996447286321199499070644378662109375;
ymax=60.00000000081617912428555428050458431243896484375;
crs=EPSG:4269") FROM eobstest AS c