WCPS1.5_Wrong upper bound of geo-axis when translating to Rasql (Need to update oracle)

[Bang Pham Huu]

test_wcps "82-timestamp_in_subset.test" with WCPS:

for c in (eobstest) return encode(
  (c[
    t("1950-01-02"),
    Long(20:35),
    Lat(10:15)]),
"tiff", "nodata=0")

with WCPS 2.0 will translate to:

SELECT encode( ( c[1,-10:19,121:130] ),..)

instead of like WCPS 1.0 will translate to:

select encode(   c[1,-10:20,121:131],...)

It should be [-10:20] and [121:131], e.g with Long axis interval is (25, 75.5) with 75.5 - 25 = 50.5 and grid interval is (0, 100) with 100 - 0 = 100, then each point of geo-axis ~ 2 points ( 100 / 50.5 = 1.9) in grid axis. So, 35 - 25 = 10 * 2 = 20 instead of 19.

[Vlad Merticariu]

This is not so straight forward: if resolution is 1, from 10 to 15 there are 5 points in geo coords (10 to 11 is the first, 11 to 12 second and so on). In array coordinates, from 10 to 15 there are 6 points (10 is the first, 11 the second and so on).

So the difference is that in geo, a point is an interval, while in cartesian a point is a single value.

I am not sure which is the correct one here, can you attach the coverage description so I can see the resolution on each axis?

Thanks!

[Dimitar Misev]

Perhaps one of WCPS 1 or WCPS 2 uses better precision floating point and that's why we see this difference?

[Bang Pham Huu]

Vlad, here is the description ​https://www.diffchecker.com/6hkrykqf and here the code why it is lower than WCPS 1.0 (not sure why you wanted to subtract to 1 ?), thanks.

 returnUpperLimit = (long)
 Math.ceil(BigDecimalUtil.divide(BigDecimal.valueOf(numericSubset.getUpperLimit()).subtract(domMin), cellWidth).doubleValue()) - 1 + pxMin;

[Vlad Merticariu]

Let's take the longitude subset: Long(25:35)

Longitude axis is defined from 25 to 75.5 in geo coordinates, with a resolution of 0.5.
In Cartesian coordinates, it corresponds to 0:100, so 101 cells. And this corresponds indeed to ( 75.5 - 25 ) / 0.5 = 101 intervals of length 0.5 each.

The origin on Longitude is 25.25. This implies the following mapping:

• Long 25:25.5 is first pixel (origin is in the middle of first pixel) → pixel 0 in rasdaman
• Long 25.5:26 is second pixel → pixel 1 in rasdaman
• …
• Long 34.5:35 is 20th pixel → pixel 19 in rasdaman

So a subset of Long(25:35) will be translated into [0:19] in rasdaman.

That seems right to me. Between 25 and 35 there are 20 intervals of length 0.5, so 20 pixels should be returned.

If you select Long(25:35.1), then there are 20.2 intervals of length 0.5, but since we can not return less than 1 pixel, we return 21 pixels.

So I think the calculation is correct in WCPS 2, and incorrect in WCPS 1.

[Dimitar Misev]

Off topic: try to break code like in several statements instead or in a separate method, otherwise it's harder to understand when it's all in one line.

Replying to bphamhuu:

 returnUpperLimit = (long)
 Math.ceil(BigDecimalUtil.divide(BigDecimal.valueOf(numericSubset.getUpperLimit()).subtract(domMin), cellWidth).doubleValue()) - 1 + pxMin;

[Bang Pham Huu]

Vlad, you are right, 20 is the position of pixel in sequence but it is [0:19] then WCPS 2.0 is correct, thanks.

From Dimitar, yes, actually it is very hard for me to debug code as it is all methods which is input to other methods.

Replying to dmisev:

Off topic: try to break code like this into several statements instead or in a separate method, otherwise it's harder to understand when it's all in one line.

Replying to bphamhuu:

 returnUpperLimit = (long)
 Math.ceil(BigDecimalUtil.divide(BigDecimal.valueOf(numericSubset.getUpperLimit()).subtract(domMin), cellWidth).doubleValue()) - 1 + pxMin;

[Bang Pham Huu]

this ticket also need to update oracle as consider is fixed correctly in WCPS 2.0.

[Bang Pham Huu]

the patch was accepted, close ticket, thanks.