Opened 12 years ago
Closed 11 years ago
#407 closed defect (fixed)
WCPS parsing error with scalar * coverage expression
Reported by: | Marcus Sen | Owned by: | Alireza |
---|---|---|---|
Priority: | major | Milestone: | 9.0 |
Component: | petascope | Version: | 8.4 |
Keywords: | Cc: | Peter Baumann, Piero Campalani | |
Complexity: | Medium |
Description
If I post the WCPS expression below to petascope I get the image expected back:
for v1 in (NIR) return encode ( (char) scale ((v1.red > 150) * 250 , { x:"CRS:1"(0:99), y:"CRS:1"(0:99) }, {}) , "png")
However, if I make the seemingly innocuous change swapping the order of the multiplied elements as below:
for v1 in (NIR) return encode ( (char) scale ( 250 * (v1.red > 150), { x:"CRS:1"(0:99), y:"CRS:1"(0:99) }, {}) , "png")
I get the error response:
<ows:ExceptionReport version="2.0.0" xsd:schemaLocation="http://www.opengis.net/ows/2.0 http://schemas.opengis.net/ows/2.0/owsExceptionReport.xsd"><ows:Exception exceptionCode="InternalComponentError"><ows:ExceptionText>Invalid coverage Expression, next node: cast - failed to match SubsetOperation: cast</ows:ExceptionText></ows:Exception></ows:ExceptionReport>
The Tomcat log is attached.
Attachments (1)
Change History (10)
by , 12 years ago
Attachment: | buglog.txt added |
---|
comment:1 by , 11 years ago
Cc: | added |
---|---|
Component: | undecided → petascope |
Owner: | changed from | to
Status: | new → assigned |
I think Alireza was already working on a ticket for the same bug.
comment:2 by , 11 years ago
It seems the problem has been resolved in petascope 9, I added test 96 to wcps_tests to examine this:
for c in ( rgb ) return encode(255 * (c.red > 150) + (c.red > 150)*255 , "png" )
follow-up: 4 comment:3 by , 11 years ago
Alireza can you add the test in the ticket, should be like this for rgb:
for v1 in (rgb) return encode ( (char) scale ( 250 * (v1.red > 150), { x:"CRS:1"(0:99), y:"CRS:1"(0:99) }, {} ) , "png")
comment:4 by , 11 years ago
Should be:
--- { x:"CRS:1"(0:99), y:"CRS:1"(0:99) }, +++ { i:"CRS:1"(0:99), j:"CRS:1"(0:99) },
btw, looking at the queries in the description, I think the issue is on the ScalarExpr * BooleanExpr
which is not commutative. The ScaleExpr
is noise in this case. Isn't it?
comment:5 by , 11 years ago
This query also pass (axis labels should be i and j):
for v1 in (rgb) return encode (
(char) scale ( 250 * (v1.red > 150), { i:"CRS:1"(0:99), j:"CRS:1"(0:99) }, {}) , "png")
The reason for creating the test as such is that if you look in the ticket description the two queries only differs in the way the multiplication operands are used.
comment:6 by , 11 years ago
Ok if that test passes too (comment:4) I think we can close this ticket?
comment:8 by , 11 years ago
I guess we should test in on rasdaman 8.5 release and either close it or fix it.
comment:9 by , 11 years ago
Milestone: | 8.4.4 → 9.0 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Tomcat log