Opened 9 years ago

Last modified 8 years ago

#1318 closed defect

Petacope_CRS_Extension extract 2D CRS from compound CRS (3D, 4D,...) — at Version 8

Reported by: Bang Pham Huu Owned by:
Priority: major Milestone: 9.3
Component: petascope Version: development
Keywords: Cc: Dimitar Misev
Complexity: Medium

Description (last modified by 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().


The coverage is 3D and slicing in Time axis to 2D and native CRS is 4326, it is valid to project to output 3857. However, in handle class, such as GeotiffFormatExtension.java. What it was done is:

// First, transform possible non-native CRS subsets
CRSExtension crsExtension = (CRSExtension) ExtensionsRegistry.getExtension(ExtensionsRegistry.CRS_IDENTIFIER);
crsExtension.handle(request, m, meta);

//Handle the range subset feature
RangeSubsettingExtension rsubExt = (RangeSubsettingExtension) ExtensionsRegistry.getExtension(ExtensionsRegistry.RANGE_SUBSETTING_IDENTIFIER);
rsubExt.handle(request, m);

So it needs the 2D CRS (4326) from the coverage before the coverage is sliced from 3D to 2D. Then in CrsExtension.java, it will throw error due to the compound CRS like this is not valid

http://localhost:8080/def/crs-compound?1=http://localhost:8080/def/crs/EPSG/0/3857&2=http://localhost:8080/def/crs/OGC/0/AnsiDate"

for GeoTools.JTS library to transform (this library works well, before I had a mistake with parameters then it is transformed to wrong coordiniates).

So, what need to change here:

+ Get the right grid/geo CRS (4326) in compound CRS (it is tricky as the order in compoundCRS is not consistent, e.g: 1=time&2=4326 or 1=4326&2=time)

or

+ Handle the coverage first to make it 2D and in GetCoverageMetadata (somehow it is handled correctly to get only 2D axis (4326)). Then it is input for the CRSExtension class.

Change History (8)

comment:1 by Bang Pham Huu, 9 years ago

Description: modified (diff)

comment:2 by Dimitar Misev, 9 years ago

Description: modified (diff)

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 reply to:  2 comment:3 by Bang Pham Huu, 9 years ago

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.

comment:4 by Dimitar Misev, 9 years ago

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.

in reply to:  4 comment:5 by Bang Pham Huu, 9 years ago

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.

comment:6 by Dimitar Misev, 9 years ago

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

comment:7 by Bang Pham Huu, 9 years ago

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).

comment:8 by Bang Pham Huu, 9 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.