Joaquim, With my code I wrote today, the offset and scale are set on the GDALRasterBand itself. If I do the following:
gdal_translate lixo.grd lixo.tif gdalinfo lixo.tif -mm I get: Driver: GTiff/GeoTIFF Files: lixo.tif lixo.tif.aux.xml Size is 21, 21 Coordinate System is `' Origin = (-10.500000000000000,10.500000000000000) Pixel Size = (1.000000000000000,-1.000000000000000) Metadata: NC_GLOBAL#Conventions=COARDS/CF-1.0 NC_GLOBAL#title=lixo.grd NC_GLOBAL#history=grdmath -R-10/10/-10/10 -I1 X Y MUL = lixo.grd NC_GLOBAL#GMT_version=4.5.4 z#long_name=z z#_FillValue=nan z#actual_range=-1, 1 z#scale_factor=0.01 x#long_name=x x#actual_range=-10, 10 y#long_name=y y#actual_range=-10, 10 Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( -10.5000000, 10.5000000) Lower Left ( -10.5000000, -10.5000000) Upper Right ( 10.5000000, 10.5000000) Lower Right ( 10.5000000, -10.5000000) Center ( 0.0000000, 0.0000000) Band 1 Block=21x21 Type=Float32, ColorInterp=Gray Computed Min/Max=-100.000,100.000 NoData Value=nan Offset: 0, Scale:0.01 Metadata: NETCDF_VARNAME=z where you can see the offset and scale reported at the band level. This is not just metadata anymore, it belongs to GDALRasterBand. if I run: gdal_translate -unscale lixo.grd lixo_uscale.tif gdalinfo -mm lixo_unscale.tif Files: lixo_uscale.tif lixo_uscale.tif.aux.xml Size is 21, 21 Coordinate System is `' Origin = (-10.500000000000000,10.500000000000000) Pixel Size = (1.000000000000000,-1.000000000000000) Metadata: NC_GLOBAL#Conventions=COARDS/CF-1.0 NC_GLOBAL#title=lixo.grd NC_GLOBAL#history=grdmath -R-10/10/-10/10 -I1 X Y MUL = lixo.grd NC_GLOBAL#GMT_version=4.5.4 z#long_name=z z#_FillValue=nan z#actual_range=-1, 1 z#scale_factor=0.01 x#long_name=x x#actual_range=-10, 10 y#long_name=y y#actual_range=-10, 10 Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( -10.5000000, 10.5000000) Lower Left ( -10.5000000, -10.5000000) Upper Right ( 10.5000000, 10.5000000) Lower Right ( 10.5000000, -10.5000000) Center ( 0.0000000, 0.0000000) Band 1 Block=21x21 Type=Float32, ColorInterp=Gray Computed Min/Max=-1.000,1.000 NoData Value=nan Metadata: NETCDF_VARNAME=z The data in the tif is unscaled or unpacked. I don't know if this is clear, I apologize for all the snippets. I, like Even, have no strong feelings for gdalinfo reporting scaled/unscaled data. kss # ============================ Kyle Shannon Physical Science Technician RMRS Fire Sciences Lab Fire, Fuels & Smoke - RWU 4405 5775 Highway 10 W. Missoula, MT 59808 (406)829-6954 kshan...@fs.fed.us # ============================ On Thu, Oct 28, 2010 at 12:35 PM, Joaquim Luis <jl...@ualg.pt> wrote: > Even > > Thanks for pointing into this that I was not aware of as it would be the > main point of my answer to Kyle's question. > But still, as it is referred in the ticket (sorry for lousy formatting but > I never learn how to do it better) the main issue occurred in the conversion > to another format (geotiff for that matter). So though an option exists > ('unscale') to account for offset/scale the natural expectancy is that the > conversion does not change the data values. > > Redoing the tickets example we can see (not shown than because I thought > it of lesser interest) > > C:\SVN\mironeWC\src_C\t>gdalinfo lixo.tiff -mm > Driver: GTiff/GeoTIFF > Files: lixo.tiff > Size is 21, 21 > Coordinate System is `' > Origin = (-10.500000000000000,10.500000000000000) > Pixel Size = (1.000000000000000,-1.000000000000000) > Metadata: > NC_GLOBAL#Conventions=COARDS/CF-1.0 > NC_GLOBAL#title=lixo.grd > NC_GLOBAL#history=grdmath -R-10/10/-10/10 -I1 X Y MUL = lixo.grd > NC_GLOBAL#GMT_version=4.5.4 > z#long_name=z > z#_FillValue=1.#QNAN0e+000 > z#actual_range=-1, 1 > z#scale_factor=0.01 > x#long_name=x > x#actual_range=-10, 10 > y#long_name=y > y#actual_range=-10, 10 > Image Structure Metadata: > INTERLEAVE=BAND > Corner Coordinates: > Upper Left ( -10.5000000, 10.5000000) > Lower Left ( -10.5000000, -10.5000000) > Upper Right ( 10.5000000, 10.5000000) > Lower Right ( 10.5000000, -10.5000000) > Center ( 0.0000000, 0.0000000) > Band 1 Block=21x21 Type=Float32, ColorInterp=Gray > Computed Min/Max=-100.000,100.000 > > > It's true that we can still see a trace of the previous info about the > scale > > z#actual_range=-1, 1 > z#scale_factor=0.01 > > but a user would need to be very very attentive to realize that and to know > that the data values were off by an 0.01 factor. > > I think that in these situations the scale factor would better be applied > by default (like with the gdal_info example) > > Joaquim > > Kyle, >> >> Frank added in GDAL 1.7 a '-unscale' option to gdal_translate, so people >> can >> always use gdal_translate -unscale to apply the offset and scale (they can >> even >> do that do a VRT file to save disk space), and then use gdalinfo on the >> result. >> >> Extract from the gdal_translate man page: >> >> "-unscale : Apply the scale/offset metadata for the bands to convert >> scaled >> values to unscaled values. It is also often necessary to reset the output >> datatype with the -ot switch." >> >> Is there a need for such an option in gdalinfo ? I have no strong opinion >> about this. An issue I see is that usually -stats record the computed >> stats in >> a .aux.xml file for later retrieval. The interaction with a -unscale >> option >> would be tricky... What happens if the user computes with -unscale and >> then do >> gdalinfo without it... Or the other way round. >> >> Le jeudi 28 octobre 2010 19:58:55, Kyle Shannon a écrit : >> >> >>> Hello, >>> I have been working on ticket #3797. In the example given, gdalinfo is >>> the calling the netcdf driver. I agree with Frank's opinion on this in >>> ticket #1660: >>> >>> Note that GDALRasterBand has methods to get the offset and scale. The >>> normal >>> >>> >>> >>>> GDAL practice would be to return them via those methods - not to apply >>>> them on the fly. Then it is up to the caller to do so if they wish. >>>> >>>> >>> gdal shouldn't be in charge of scaling the data to what may be a >>> different >>> data type, or unpacking it. But in this case, gdalinfo is the caller. >>> Should the functionality of the scaling be added to gdalinfo? Maybe >>> optionally reporting the stats as scaled data? Any thoughts? >>> >>> # ============================ >>> Kyle Shannon >>> Physical Science Technician >>> RMRS Fire Sciences Lab >>> Fire, Fuels& Smoke - RWU 4405 >>> 5775 Highway 10 W. >>> Missoula, MT 59808 >>> (406)829-6954 >>> kshan...@fs.fed.us >>> # ============================ >>> >>> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> >> >> >> > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev