Custom Query (2765 matches)

Our rasdaman setup contains 3D coverages with different spatial domains and also a number of coverages that are used as masks. We can't create a new mask for every 3D coverage to match the spatial domain, so it seems that the use of the 'scale' expression in WCPS is the solution.

This is an example query that uses the scale function:

for c in (TAMSAT_RFE), m in (GAUL_Africa_1), l in (GLC2000_Africa)
return encode(
  coverage averagesOverTime
  over $T t(0:1060)
  values ((1/(count(((((c[x(26.8033:29.0793),y(-13.9166:-12.2299)])[t($T)] >=0) * ( scale(((m[x(26.8033:29.0793),y(-13.9166:-12.2299)]) =35535),{x:"CRS:1"(0:61), y:"CRS:1"(0:45)}) ) * scale(((l[x(26.8033:29.0793),y(-13.9166:-12.2299)]) = 13 )  ,{x:"CRS:1"(0:61), y:"CRS:1"(0:45)})  )) > 0))
         * add(
                (
                (c[x(26.8033:29.0793),y(-13.9166:-12.2299)])[t($T)]
                * ((c[x(26.8033:29.0793),y(-13.9166:-12.2299)])[t($T)] >=0)
                * ( scale(((m[x(26.8033:29.0793),y(-13.9166:-12.2299)]) =35535),{x:"CRS:1"(0:61), y:"CRS:1"(0:45)}) )
                * scale(((l[x(26.8033:29.0793),y(-13.9166:-12.2299)]) = 13 )  ,{x:"CRS:1"(0:61), y:"CRS:1"(0:45)})
                 ))
         )),
 "csv")

While this query works, there are major issues:

• Computing the scaling parameters requires a calculation that takes coverage metadata and the bounding box as input. It can not be done easily by someone who is writing the query by hand.
• The computation of the scaling parameters x:"CRS:1"(0:61), y:"CRS:1"(0:45) is subject to rounding errors.

The problem is that the input parameters are usually decimals such as the coordinates of the bounding box, and the output are integers. This means that using different hardware or a different programming language may result in an integer that is wrong by one. When sending such 'incorrectly' rounded parameters to rasdaman, it responds with an exception about spatial domains that do not match. This check is a bit strange because it implies that Rasdaman is able to compute these parameters itself, so why does the user have to compute them in the first place?

• If the bounding box crosses the border of the coverage, the scaling parameters have to be adapted accordingly. This is again something that is very hard for a user to do.

Preferrably, Rasdaman should provide a solution so that the user does not need to provide this kind of parameter at all, as the bounding boxes already provide sufficient information.

Finally, I'm also uncertain about the code that computes the scaling parameters: it seems to assume that there is a linear relation between the lon/lat coordinates of the bounding box, and the pixel coordinates of the coverage, while in most coordinate reference systems, this is not the case at all.

This is a critical issue because it makes it very hard for end-users to write their own Rasdaman/WCPS queries.

SECORE should keep the parametrized URL when reporting the CRSs the compose a compound CRS, otherwise the parametrization is lost and the raw target CRS is pointed.

E.g. AUTO(1.3):42001 targets EPSG:4326:

​http://localhost:8090/def/crs-compound?

1=​http://localhost:8090/def/crs?authority=AUTO%26version=1.3%26code=42001%26lon=10& 2=​http://localhost:8090/def/crs?authority=EPSG%26version=0%26code=5715

but the default EPSG:4326 definition is reported in the response (see //componentReferenceSystem/@xlink:href):

<CompoundCRS ... >
  <metaDataProperty>
    <epsg:CommonMetaData>
      <epsg:type>compound</epsg:type>
    </epsg:CommonMetaData>
  </metaDataProperty>
  <scope>not known</scope>
  <identifier codeSpace="OGC">
http://localhost:8090/def/crs-compound?1=http://localhost:8090/def/crs?authority=AUTO%26version=1.3%26code=42001%26lon=10%262=http://localhost:8090/def/crs?authority=EPSG%26version=0%26code=5715
  </identifier>
  <name>WGS 84 / msl depth</name>
  <componentReferenceSystem xlink:href="http://www.opengis.net/def/crs/EPSG/0/4326"/>
  <componentReferenceSystem xlink:href="http://www.opengis.net/def/crs/EPSG/0/5715"/>
</CompoundCRS>

This is bug probably introduced by the p2p patch changeset:90fa2688a862f227e7f52b0423041c185f1eed34

Seems to happen when the countdown/timeout is run out and a rasserver is to be restarted. To test run source:systemtest/testcases_petascope/test_wcps it will fail around the 48/49th test if the rasmgr.conf is with default countdown parameters.

Workaround: set countdown and timeout in rasmgr.conf to some large numbers.

Segfault stack trace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000423811 in MasterComm::askOutpeer (this=0x6c1b80 <masterCommunicator>, peer=1,
    outmsg=0x7fff64b70a40 "POST peerrequest HTTP/1.1\r\nAccept: text/plain\r\nUserAgent: RasMGR/1.0\r\nAuthorization: ras  ras rasguest:8e70a429be359b6dace8b5b2500dedb0\r\nContent-length: 47\r\n\r\nhifi RASBASE RNP ro 2130706689:1369740188"...) at rasmgr_master_nb.cc:877
877        struct hostent *hostinfo = gethostbyname(config.outpeers[peer]);
(gdb) bt
#0  0x0000000000423811 in MasterComm::askOutpeer (this=0x6c1b80 <masterCommunicator>, peer=1,
    outmsg=0x7fff64b70a40 "POST peerrequest HTTP/1.1\r\nAccept: text/plain\r\nUserAgent: RasMGR/1.0\r\nAuthorization: ras  ras rasguest:8e70a429be359b6dace8b5b2500dedb0\r\nContent-length: 47\r\n\r\nhifi RASBASE RNP ro 2130706689:1369740188"...) at rasmgr_master_nb.cc:877
#1  0x00000000004231fd in MasterComm::getFreeServer (this=0x6c1b80 <masterCommunicator>, fake=false, frompeer=false) at rasmgr_master_nb.cc:802
#2  0x000000000042178f in MasterComm::processRequest (this=0x6c1b80 <masterCommunicator>, currentJob=...) at rasmgr_master_nb.cc:482
#3  0x00000000004206e2 in MasterComm::processJob (this=0x6c1b80 <masterCommunicator>, currentJob=...) at rasmgr_master_nb.cc:214
#4  0x00000000004200ce in MasterComm::Run (this=0x6c1b80 <masterCommunicator>) at rasmgr_master_nb.cc:165
#5  0x000000000040d066 in main (argc=1, argv=0x7fff64b71548, envp=0x7fff64b71558) at rasmgr_main.cc:172