Petascope_Recheck the shift intervals with "dataBound" option in wcst_import general_coverage recipe

[Bang Pham Huu]

in UpdateCoverageHandle.java there is a method "getShiftDomain" which returns the intervals for Rasql shift intervals.

It worked before, but with the new ingredient in wcst_import ("dataBound": false), this will make this function work wrong.

e.g: axis orders in ingredient (time@4326@forecast@ensemble) which create a 5D cube from multiple 4D files.

"OGC/0/AnsiDate@EPSG/0/4326@OGC/0/Index1D?axis-label=\"forecast\"@OGC/0/Index1D?axis-label=\"ensemble\""

as AnsiDate axis is not from the file (netcdfFile has 4 axes (lat, long, forecast, ensemble), then it need to set "dataBound":"false", as it should not be included in shift intervals, but this function still uses this axis for shifting.

[Dimitar Misev]

default, all axis is set to True, but in case, axis is not belonged to file (such as Time) from file name then this property must set to false

Can you try to write a bit better documentation, the above is confusing. I understand what it means mostly, but I'm not sure why is it called dataBound?

[Bang Pham Huu]

Replying to dmisev:

default, all axis is set to True, but in case, axis is not belonged to file (such as Time) from file name then this property must set to false

Can you try to write a bit better documentation, the above is confusing. I understand what it means mostly, but I'm not sure why is it called dataBound?

actually it was hidden from the wcst_import guide as well, I found it after making a similar option named "slice_axis", then I removed it and add in ​http://rasdaman.org/wiki/WCSTImportGuide/GeneralRecipe

the dataBound basically by default is set to true and in case the axis is not from the file then it has to set to false for Petascope know it should not calculate the shift intervals with this axis.

[Dimitar Misev]

'dataBound' doesn't sound very good choice for that case. Perhaps 'externalAxis'? But how does it know which one is external? I don't think you can control that with true/false, what if there are multiple additional axes?

[Bang Pham Huu]

Replying to dmisev:

'dataBound' doesn't sound very good choice for that case. Perhaps 'externalAxis'? But how does it know which one is external? I don't think you can control that with true/false, what if there are multiple additional axes?

as I see from the code, it works like this, each axis can add this option to false and it is external.

[Dimitar Misev]

Ah ok, I didn't notice it's part of an axis config block.

Fix the documentation to this:

// set to False if axis does not belong to the file (e.g. date derived from the file name)

[Dimitar Misev]

Does this affect the specific regular/irregular timeseries? I think by default they would consider time to be dataBound:false, whereas here all axes are dataBound:true by default.

[Bang Pham Huu]

as I tested it with other wcst_import using regular/irregular recipes, it seems does not need this option set to false. Your suggestion is good but I think this general recipe is supposed to work for > 2D which mostly has the time axis ( not sure but guess ).

[Alex Dumitru]

Hi, the dataBound property refers to an axis that is not defined in the data slice (a data slice can be a file, a grib message, a netcdf variable etc). as well. For example on a 3-D coverage (Lat, Long, ansi) formed from 2D slices (Lat Long) the Lat and Long axis are data bound while the ansi one is not data bound as it is not an axis that is present in the data slices.

This option is present in the python code model of the coverage. We do not expose it in map_mosaic, or the timeseries ingredients as there it is clear what the intent is (2D files → 3D coverage for example). In the general coverage we cannot deduce the intent of the user and we allow him to set this in the ingredients.

Furthermore, this option does not influence petascope in any way, just the way WCSTImport generates the coverages to be used in the update operations. Not sure I understand from the ticket why this would be a bug, it seems it's the intended behavior.

[Dimitar Misev]

Ok it's clear. It needs to be reflected in the getShiftDomain in petascope as Bang has discovered, which doesn't seem to produce the correct shift domains (with right dimensionality) when dataBound is false. The axis which is not dataBound should not be in the shift domain at all, because it is sliced in the update domain. Example:

update cov as m set m[0,*:*,*:*] assign shift($1, [0,0])

The first axis is dataBound so it's sliced in m[0,*:*,*:*], accordingly the shift domain must be 2D, but now it's 3D. If I remember correctly.

[Bang Pham Huu]

This ticket was fixed in ticket:1442 thanks to Vlad.