On Thu, 27 Aug 2009, Roger Bivand wrote:
On Mon, 24 Aug 2009, Frank Warmerdam wrote:
Roger Bivand wrote:
(reverting to list)
Correction, the user reported that:
Apparently, gdalinfo retrieves the correct min, max, and statistics,
despite the use of GDT_Int16.
on his Windows platform. The different GDAL versions ought to explain why
his gdalinfo says Int16 but gives statistics from UInt16.
...
On the trunk, GDT_Int16 is used too, so how does gdalinfo detect that it
is actually UInt16?
Roger,
I believe the min/max is actually being read from the file header in trunk
and is handled without regard to the actual imagery or it's type.
I skimmed the changelog for this driver and I didn't notice any obvious
changes in metadata / statistics handling so I'm surprised at this result.
Best regards,
Frank,
Having at last got the data and a current 1.7.0dev, I have to report that on
x86 Linux, I cannot reproduce the reading of Int16 as UInt16 reported by the
original questioner - I get Int16 and a negative minimum with gdalinfo, and
in rgdal using the same *.so. How the difference arose is unclear, I can
download FWTools and check on Windows.
Checked, same results. In the output sent by the original questioner,
gdalinfo named two files:
C:\Program Files\FWTools2.4.2>gdalinfo stand_bm.gis
Driver: LAN/Erdas .LAN/.GIS
Files: c:\landis\harvest_problem\FTT-N_MinT-N\stand_bm.gis
c:\landis\harvest_problem\FTT-N_MinT-N\stand_bm.gsw
Size is 1758, 839
...
so I think that the statistics are coming from stand_bm.gsw. He hasn't
responded to my request for this file.
I've submitted a fresh rgdal to CRAN for release, but without any
"guessing" about which type is "right". I've exposed by band what
GetMinimum(), GetMaximum(), and GetRasterDataType() return, so that the
user can investigate further, and documented that min/max may just be the
range of the type, not of the band, unless given by pre-calculated sources
(such as a header file).
I guess that there is no programmatic way for drivers to report what
(internal) types they are putting into the GDTs, right?
With regard to LAN/GIS, I don't think that there are clear authorities for
changing anything, but a slight change to the documentation, adding:
"4bit and 8bit data are read unsigned, 16bit data are read signed."
after the second sentence in the first paragraph.
Best wishes,
Roger
I would argue for replacing Int16 by UInt16 in the LAN/GIS driver based on
PCI and ESRI references to the data types as unsigned, but am open to other
arguments.
Best wishes,
Roger
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: roger.biv...@nhh.no
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
