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 <mailto:kshan...@fs.fed.us>
# ============================
On Thu, Oct 28, 2010 at 12:35 PM, Joaquim Luis <jl...@ualg.pt
<mailto: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 <mailto:kshan...@fs.fed.us>
# ============================
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev
