Opened 20 months ago

Closed 5 weeks ago

#974 closed defect (fixed)

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

Reported by: dmisev Owned by: bphamhuu
Priority: major Milestone: 9.4
Component: petascope Version: development
Keywords: Cc: vmerticariu
Complexity: Medium

Description

.. 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

Change History (6)

comment:1 Changed 13 months ago by bphamhuu

  • Milestone changed from 9.1.x to 10.0
  • Summary changed from induced aggregation in WCPS doesn't preserve axis names to WCPS1.5_induced aggregation in WCPS doesn't preserve axis names

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.

comment:2 Changed 9 months ago by bphamhuu

  • Resolution set to invalid
  • Status changed from new to closed
  • Summary changed from WCPS1.5_induced aggregation in WCPS doesn't preserve axis names to WCPS 2_induced aggregation in WCPS doesn't preserve axis names

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.

comment:3 Changed 5 weeks ago by dmisev

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

comment:4 Changed 5 weeks ago by dmisev

Implemented in #907

comment:5 Changed 5 weeks ago by dmisev

  • Owner changed from mdumitru to bphamhuu
  • Status changed from reopened to assigned

comment:6 Changed 5 weeks ago by bphamhuu

  • Milestone changed from 10.0 to 9.4
  • Resolution set to fixed
  • Status changed from assigned to closed

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

Note: See TracTickets for help on using tickets.