Ah, I see your issue. I honestly don't know what to do about that. The
only option I see is issuing a warning and continuing. I don't think
unscaling that data is an option without a user explicitly asking for it to
be unscaled. I am still not sure if this is even a gdal issue. The caller
just
Kyle,
Yes, that is much better but (sorry for one other 'but') what about
formats that do not know anything about scale/offset?
(Surfer format is one comes right to my mind)
In those cases conversion would definitively go wrong. Issue a
screaming warning in than?
Joaquim
Joaquim,
With my
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
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 (g
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
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 metho
