Opened 4 years ago

Closed 14 months ago

Last modified 14 months ago

#394 closed enhancement (fixed)

Provide clear error message when WCPS query exceeds coverage bounds

Reported by: dirk.daems@… Owned by: mdumitru
Priority: major Milestone: 9.0.x
Component: petascope Version: 8.4
Keywords: wcps out bounds Cc: pcampalani, vmerticariu, mdumitru
Complexity: Medium

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

Change History (11)

comment:1 Changed 4 years ago by abeccati

  • Owner changed from abeccati to swingit
  • Status changed from new to assigned

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.

comment:2 Changed 4 years ago by 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)]

comment:3 Changed 4 years ago by swingit

  • Status changed from assigned to accepted

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.

comment:4 Changed 4 years ago by swingit

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

Last edited 4 years ago by swingit (previous) (diff)

comment:5 Changed 3 years ago by dmisev

  • Resolution set to fixed
  • Status changed from accepted to closed

comment:6 Changed 3 years ago by dirk.daems@…

  • Description modified (diff)
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Summary changed from WCPS query error handling to Provide clear error message when WCPS query exceeds coverage bounds

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.

comment:7 Changed 3 years ago by dmisev

  • Cc pcampalani added
  • Milestone set to 9.0

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?

comment:8 Changed 3 years ago by pcampalani

  • Cc vmerticariu mdumitru added
  • Keywords wcps out bounds added
  • Owner changed from swingit to pcampalani
  • Status changed from reopened to assigned

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.

comment:9 Changed 16 months ago by dmisev

  • Owner changed from pcampalani to mdumitru

comment:10 Changed 14 months ago by bphamhuu

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

comment:11 Changed 14 months ago by dmisev

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

Note: See TracTickets for help on using tickets.