WCPS - change coverage's axis type to grid CRS after subsetting by "CRS:1"

[Bang Pham Huu]

This query has problem:

for c in (test_irr_cube_2)

return encode(
        c[ansi:"CRS:1"(0:0), E:"CRS:1"(0:62), N:"CRS:1"(0:35)] -
        
          coverage meanTime
          over $T t(imageCrsDomain(c[ansi("2008-01-01T02:01:20.000Z":"2008-01-01T02:01:20.000Z")], ansi)),
          $X x(imageCrsDomain(c, E)),
          $Y y(imageCrsDomain(c, N)) 
values c[ansi($T), E($X), N($Y)] , "json")

Axes of coverages 'test_irr_cube_2' and 'meanTime' are not compatible. Reason: Axis type is different, given first coverage's axis with name 'ansi', 

type 't' and second coverage's axis with name 'x', type 'x'

[Dimitar Misev]

It should work automatically without needing this CRS:1 conversion in c[ansi:"CRS:1"(0:0), E:"CRS:1"(0:62), N:"CRS:1"(0:35)], i.e. here I should be able to subset in geo bounds, and the binary operation should work as long as the grid axis extents match.

[Bang Pham Huu]

No, this is a hard requirement. When you want to work on grid coverages, then you convert them to all grid CRSs.

Try to think: if you have 2 coverages in EPSG:4326.

covA: Lat and Long (resolution: 1)
covB: Lat and Long (resolution: 10)

What is the result of covA + covB (if they have same grid domains for lat and long)?

[Dimitar Misev]

We are talking about geo+grid cov in this ticket, not geo+geo. I think it is fine to implicitly convert the geo cov to grid in this case.

[Peter Baumann]

agreed that there can be more convenience functionality, but in the first place it is not part of the standard. And the workaround, getting both into grid CRS, seems natural and available.

[Dimitar Misev]

It's a defect, currently the "workaround" does not work.