Opened 6 years ago

Closed 6 years ago

#1767 closed defect (fixed)

Rasql_project() sdom of grid bounds should be shifted by -1

Reported by: Bang Pham Huu Owned by: Dimitar Misev
Priority: major Milestone: 9.7
Component: rasql Version: development
Keywords: Cc: Vlad Merticariu
Complexity: Medium

Description

test_mean_summer_airtemp is 2D coverage with grid and geo domains

Size is 886, 711

Upper Left  ( 111.9750000,  -8.9750000) 
Lower Left  ( 111.9750000, -44.5250000) 
Upper Right ( 156.2750000,  -8.9750000) 
Lower Right ( 156.2750000, -44.5250000) 
Center      ( 134.1250000, -26.7500000)

with sdom(project()), the lower bounds should be 0 instead of 1.

rasql -q 'SELECT sdom(
project( c, "111.975,-44.525,156.275,-8.975", "EPSG:4326", "EPSG:4326" )
) FROM test_mean_summer_airtemp AS c' --out string
rasql: rasdaman query tool v1.0, rasdaman 9.6.0.
Opening database RASBASE at localhost:7001... ok.
Executing retrieval query... ok.
Query result collection has 1 element(s):
  Result element 1: [********1:886,1:711***********]

The output of project() with tiff encoding is correct for grid and geo domains

rasql -q 'SELECT encode(project( c, "111.975,-44.525,156.275,-8.975", "EPSG:4326", "EPSG:4326" ),
 "image/tiff" , 
"{\"geoReference\":{\"crs\":\"EPSG:4326\",
\"bbox\":{\"xmin\":111.974999999999994315658113919198513031005859375,\"ymin\":-44.52499999999999857891452847979962825775146484375,\"xmax\":156.275000000000005684341886080801486968994140625,\"ymax\":-8.9749999999999996447286321199499070644378662109375}}}")
 FROM test_mean_summer_airtemp AS c' --out file


gdalinfo rasql_1.tif 
Driver: GTiff/GeoTIFF
Files: rasql_1.tif
Size is 886, 711

Upper Left  ( 111.9750000,  -8.9750000) (111d58'30.00"E,  8d58'30.00"S)
Lower Left  ( 111.9750000, -44.5250000) (111d58'30.00"E, 44d31'30.00"S)
Upper Right ( 156.2750000,  -8.9750000) (156d16'30.00"E,  8d58'30.00"S)
Lower Right ( 156.2750000, -44.5250000) (156d16'30.00"E, 44d31'30.00"S)
Center      ( 134.1250000, -26.7500000) (134d 7'30.00"E, 26d45' 0.00"S)

Change History (3)

comment:1 by Dimitar Misev, 6 years ago

Well technically [1:886, 1:711] isn't incorrect.

But putting it at origin [0,0] might be better for consistency indeed.

comment:2 by Dimitar Misev, 6 years ago

I submitted a patch.

comment:3 by Dimitar Misev, 6 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.