Wrong substitution for variables labels in a WCPS trimming operation

[Piero Campalani]

When an over clause is used to define custom axes, the variable labels which are then used in the following clause (over or using, depending whether it is a coverage constructor or a condense operation) are badly translated (to 0s) when used inside a trimming operation.

E.g.

for c in (mean_summer_airtemp)
  return encode(
     coverage mincov
     over     $px x (100:101)
     values   min(c[x:"CRS:1"($px:$px + 1), y:"CRS:1"(300)]
     )
  ), "csv")

Translates to the following RasQL query

SELECT csv(marray i_i in [100:101] values min_cells((c) [0:0,300])) 
FROM   mean_summer_airtemp AS c

which instead should look like this:

SELECT csv(marray i_i in [100:101] values min_cells((c) [i_i[0]:i_i[1],300])) 
FROM   mean_summer_airtemp AS c

The same holds for a condense operation, e.g.:

for c in (mean_summer_airtemp)
  return encode(
     condense +
     over     $px x (100:101)
     using    min(c[x:"CRS:1"($px:$px+1), y:"CRS:1"(300:300)]
     )
  ), "csv")

[Piero Campalani]

Closing this as it seems a duplicate of #335.

[Piero Campalani]

Re-opening since this does not work on a temporal dimension now:

for c in (eobstest) return encode (
     coverage averaged_pixel_history
     over     $t t(0:1)
a)   values   max(c[Lat(0), Long(51), t:"CRS:1"($t:$t)])
b)   values   max(c[Lat(0), Long(51), t:"CRS:1"($t:$t+1)])
c)   values   max(c[Lat(0), Long(51), t:"CRS:1"($t:1+$t)])

Stack trace:

java.lang.NumberFormatException: For input string: "i_i[0]"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Integer.parseInt(Integer.java:492)
	at java.lang.Integer.parseInt(Integer.java:527)
	at petascope.util.WcsUtil.toInt(WcsUtil.java:571)
	at petascope.util.WcsUtil.min(WcsUtil.java:536)
	at petascope.wcps.server.core.TrimCoverageExpr.computeRasQL(TrimCoverageExpr.java:174)
...

It works on spatial ones, but not when then variable is first operand and the operator is not preceded by a white space:

for c in (eobstest) return encode (
   coverage averaged_pixel_history
   over     $t x (0:1)
   values   max(c[Lat(0:1), Long:"CRS:1"($t:$t)])     -> OK
   values   max(c[Lat(0:1), Long:"CRS:1"($t:1+$t)])   -> OK
   values   max(c[Lat(0:1), Long:"CRS:1"($t:$t + 1)]) -> OK
   values   max(c[Lat(0:1), Long:"CRS:1"($t:$t+1)])   -> ERROR
, "csv" )
}}]

[Piero Campalani]

Apparently, this is somehow not related to the type of dimension, but to the variable name. e.g. using $x instead of $t as name gives error:

for c in (eobscov) return encode (
   coverage averaged_pixel_history
   over     $x x (0:2)
   values   max(c[Long:"CRS:1"($x:$x), Lat(0)])
, "csv")

Error: For input string: "i_i[0]"

The same error message returned by the queries reported in comment:3.

[Dimitar Misev]

Is Alan the right owner of this?

[Bang Pham Huu]

The patch was accepted, close here, thanks.