WCPS 2_induced aggregation in WCPS doesn't preserve axis names

[Dimitar Misev]

.. so scale over an induced aggregated coverage doesn't work, e.g. this fails

for c in (AGDC_NAT) return
encode(

 scale((
   condense min
   over     $ts t( imageCrsDomain(c[ansi:"CRS:1"(0:6)], ansi) )
   using    (c.red)[Long(148.8:149.4), Lat(-35.6:-35.0), ansi($ts)]
 ) / 6, { Long:"CRS:1"(0:255), Lat:"CRS:1"(0:255) })

, "png")

with

WCPS Error: Coverage 'scalarExpr' is not served by this server

[Bang Pham Huu]

This ticket needs to be fixed in WCPS1.5. However, the current code of WCPS1.5 has a bug with

scale ( coverage, { intervals } )

in CrsComputer/getPixelIndices [1]

 DomainElement dom = coverage.getCoverageInfo().getDomainByName(axisName);

this will only correct if coverage is an existing coverage, i.e with coverage variable name 'c'

scale('''c'''[Lat(0:20), Long(26:30)], { Lat:"CRS:1"(0:200), Long:"CRS:1"(0:250) })

then without this variable name, [1] will return NULL due to coverageInfo is NULL. This will need to discuss how to handle this later (as I think some WCPS syntaxes are not consistent).

For example, in this case, suppose ​http://rasdaman.org/ticket/1258 is accepted, then in {intervals} can use directly geo-referenced axis Long, Lat, instead of grid-axis Long:"CRS:1", Lat:"CRS:1".

here is the query in WCPS test example will return the same error as Dimitar's in WCPS 1.0

for c in (eobstest) return 
     encode( scale(
          (condense min 
           over  $ts t (0:5) 
           using c[Long(28.8:29), Lat(-35.6:-34.0), t($ts)]) / 6 , 
           { Long:"CRS:1"(25:30), Lat:"CRS:1"(0:20) } ) , "csv")

if I modify this query to query from another coverage like mean_summer_airtemp (2D geo-referenced) with different resolution with eobstest,

i.e: eobstest:Lat(0:20) → (60:70) in grid axis whilst mean_summer_airtemp:Lat(0:20) → (100:160) in grid axis.

then I will have the query

for c in (eobstest), d in (mean_summer_airtemp) return 
     encode( scale(
          (condense min 
           over  $ts t (0:5) 
           using c[Long(28.8:29), Lat(-35.6:-34.0), t($ts)]) / '''d[Long(20), Lat(20)]''', 
           [2] { Long(25:30), Lat(0:20) } ) , "csv")

then in [2], there is ambiguous to know which Long axis belonged to eobstest or mean_summer_airtemp should be used to scale.

[Bang Pham Huu]

This ticket could not be fixed with the current WCPS 1.5 as the coverage for (condense min ….) is only 1D and it does not have the axes name (Lat, Long) to scale in scale(condense …, {Lat, Long}).

Even if this can be handled in WCPS, the output in Rasql will have error, as it cannot scale a sclar value in intervals.

rasql -q 'SELECT encode(SCALE(6, [25:30,0:20]), "csv" ) FROM eobstest AS c'
rasql: rasdaman query tool v1.0, rasdaman v9.2.1-g86fa176 -- generated on 28.06.2016 15:57:29.
opening database RASBASE at localhost:7001...ok
Executing retrieval query...rasdaman error 416: 
Execution error 416 in line 1, column 15, near token 
SCALE: First operand of scale function must be of type MDD.
aborting transaction...ok
rasql done.

I will close as invalid until Dimitar has other idea.

[Dimitar Misev]

This is the induced condenser, out of a 3D coverage it produces a 2D coverage. So the axes should be fixed. The rasql query you have given above is not a correct translation of the WCPS query I gave in the ticket description.

[Dimitar Misev]

Implemented in #907

[Bang Pham Huu]

thanks to Dimitar which show the wrong rasql, this problem was fixed in recent WCPS 1.5.