Provide clear error message when WCPS query exceeds coverage bounds

[Dirk Daems]

When a user forgets to specify CRS:1 in the query below, a vague error is returned: “Runtime error while processing request: For input string: i_i[0]”.

for c in (mean_summer_airtemp)
  return condense +
  over $x x(500:600),
       $y y(500:600)
  where (max(c[x($x:$x),y($y:$y)]) < 100)
  using c[x($x),y($y)]

[abeccati]

Thanks Dirk for your report, would you please also provide the query that generates no error, this will help ticket consistency and speed up investigation.

Meanwhile tentatively assigning for further evaluation.

[Dirk Daems]

The WCPS query that works:

for c in (mean_summer_airtemp)
  return condense +
  over $x x(500:600),
       $y y(500:600)
  where (max(c[x:"CRS:1"($x:$x),y:"CRS:1"($y:$y)]) < 100)
  using c[x:"CRS:1"($x),y:"CRS:1"($y)]

[swingit]

The fix is simple "per se". The easiest way to fix that was to catch the java.lang.NumberFormat exception and wrap it into a WCPSException containing all necessary information describing the error.

Something like that (except for necessary additions to utils.WCPSConstants)

            // Fixing bug #394 [author Swing:It]
            // axisLo = Integer.parseInt(axis.getLoCellCoord());
            // axisHi = Integer.parseInt(axis.getHiCellCoord());
            // Start fix
            boolean phase = false;
            try {
                 log.trace("  " + WCPSConstants.MSG_AXIS + ": Getting coordinates.");
                 axisLo = Integer.parseInt(axis.getLoCellCoord());
                 .... omissis ...
                 axisHi = Integer.parseInt(axis.getHiCellCoord());
            } catch (NumberFormatException e) {
                    String errmsg = ... omissis... ;
                    log.error(errmsg + ": " + axis.getAxisName());
                    throw new WCPSException(errmsg + ": " + axis.getAxisName()
                            + "[" + e.getMessage() + "]");
            }
            // End fix #394

Unfortunately, the exception thrown there is first caught and rethrown twice in CoverageExpr.java
where fortunately the information containt survives and it is finally caught in ScalarExpr.java:85
where thaks to the following catch clause

        // NumericScalarExprType
        if (child == null) {
            if (NumericScalarExpr.NODE_NAMES.contains(n)) {
                try {
                  ...
                } catch (WCPSException e) {
                    child = null;
                }
            }
        }

every information is lost.

The solution is now twofold:

• either fixing this code to make the e.message survive
• or producing a different Exception which cannot neither inherit from WCPSException (this I don't like)

We'll looking for a solution to this.

[swingit]

A new patch, including a test was uploaded to patch manager few days ago.

[Dirk Daems]

Now I don't get an errormessage anymore when executing the query listed above. Is this expected behaviour as the default CRS is EPSG:4326?
Actually this ticket was meant for collecting several WCPS error handling improvements. Closing it gives the wrong impression that WCPS error handling has improved. That's why I suggest to change the ticket summary.

[Dimitar Misev]

Somehow it works and gives the same output irrelevant of whether you put explicitly "CRS:1" or not. The current query is

for c in (mean_summer_airtemp)
  return condense +
  over $x x(500:600),
       $y y(500:600)
  where (max(c[Long($x:$x),Lat($y:$y)]) < 100)
  using c[Long($x),Lat($y)]

Piero do you know how this works? Shouldn't it use EPSG:4326 when native CRS is assumed in the query?

[Piero Campalani]

Yes, native CRS is the default for subsettings.

Now no error is returned, while the query is transmitted to rasdaman, which does not raise errors if bounds exceed the domain (but returns zeros instead):

 for c in (mean_summer_airtemp)
   return condense +
   over $x x(5000:5002),
        $y y(5000:5002)
A) where (max(c[Long:"CRS:1"($x:$x),Lat:"CRS:1"($y:$y)]) < 100)
B) where (max(c[Long($x:$x),Lat($y:$y)]) < 100)
   using c[Long($x),Lat($y)]
------
0

There is no mention in the ​WCPS standard about how to behave on out-of-bound subsets.

WCS specifies to return an InvalidSubsetting exception, and so Petascope does:
​http://localhost:8090/rasdaman/ows//wcs2?service=WCS&version=2.0.0&request=GetCoverage&coverageid=mean_summer_airtemp&subset=Long(5000,5000).

Dirk any opinion on the desired behavior of WCPS?
I personally think is more convenient to return an error, in line with out-of-bound slicings:

for c in (mean_summer_airtemp)
return encode(c[Long(5000)], "csv")
--------
WCPS Error: Long axis: subset (5000.0:5000.0) is out of bounds.

I know there is an upcoming patch for WCPS: Alex/Vlad can you check this on the new implementation then? thx.

[Bang Pham Huu]

I've tested with cases out bounds, in bounds, near by,… and it throw exception like

http://localhost:8088/rasdaman/ows?service=WCS&version=2.0.1&request=ProcessCoverages&query=for%20c%20in%20(eobstest)%20return%20encode(c[t(%221950-01-03T13:00:00%22),%20Lat(-40.9:-40.7)],%20%22png%22)

returns

<ows:ExceptionText>Lat axis: subset (-40.9:-40.7) is out of bounds.</ows:ExceptionText>

so I think this ticket can be closed here as it was fixed.

[Dimitar Misev]

Can you add the tests you did to the wcps systemtest?