Custom Query (2765 matches)

If we run following wcps query and check the nodata value of the output file value with gdalinfo, it show that the only integer part of the argument is taken, the decimal part is truncated. Also with scientific notation like 9.96921e+36, the nodata is set to 0.

Query:

for c in (mean_summer_airtemp)return
encode(c,"netcdf","nodata=-9.96921")

gdalinfo wcps

Output:

Driver: netCDF/Network Common Data Format
Files: wcps
Size is 886, 711
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]
Origin = (111.974999999999994,-8.975000000000000)
Pixel Size = (0.050000000000000,-0.050000000000000)
Metadata:
  Band1#_FillValue=-9
  Band1#_Unsigned=true
  Band1#grid_mapping=crs
  Band1#long_name=GDAL Band Number 1
  Band1#valid_range={0,255}
  crs#GeoTransform=111.975 0.05000000000000001 0 -8.975 0 -0.05 
  crs#grid_mapping_name=latitude_longitude
  crs#inverse_flattening=298.257223563
  crs#longitude_of_prime_meridian=0
  crs#semi_major_axis=6378137
  crs#spatial_ref=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]]
  lat#long_name=latitude
  lat#standard_name=latitude
  lat#units=degrees_north
  lon#long_name=longitude
  lon#standard_name=longitude
  lon#units=degrees_east
  NC_GLOBAL#Conventions=CF-1.5
  NC_GLOBAL#GDAL=GDAL 1.10.1, released 2013/08/26
  NC_GLOBAL#history=Thu Jul 31 15:58:58 2014: GDAL CreateCopy( /tmp/rasdaman-8fYFwI, ... )
Corner Coordinates:
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)
Band 1 Block=886x1 Type=Byte, ColorInterp=Undefined
  NoData Value=-9
  Metadata:
    _FillValue=-9
    _Unsigned=true
    grid_mapping=crs
    long_name=GDAL Band Number 1
    NETCDF_VARNAME=Band1
    valid_range={0,255}

This function work good in ​http://kahlua.eecs.jacobs-university.de/trac/wiki/ticket/59 when I can check to sort comments (by oldest or newest) but in rasdaman.org can not work (nothing happens).

It appears that the sdom function reports the bounds taken by tiles, irrelevant of whether they have real data, whereas it would be preferable if sdom reports only the domain that actual data covers.

This is a tough problem to solve however and requires either inspecting the tile contents, or recording some additional information at insert/update time. Neither option looks like a particularly good solution.