Project

General

Profile

Actions

Bug #2273

closed

Problem with Hydro1K Flow Accumulation data

Added by Dan Higgins about 19 years ago. Updated over 18 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
actors
Target version:
Start date:
11/15/2005
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
2273

Description

Hydro1K Flow Accumulation data is somehow not getting processed correctly. It
should range from small numbers to numbers in the millions at the mouths of
large rivers. The *.bil files look reasonable but when read and reprojected
using GDAL actors, the output is a region with uniform values of 0.0! This may
be related to the fact that this is the only Hydro1K data set where NBIT=32
(NBITS=16 in all the other sets.)

Actions #1

Updated by Dan Higgins almost 19 years ago

This appears to be a GDAL problem. GDAL tries to read the data in a 32 bit bil
file as a 32 bit float when it is (apparently) a 32 bit INT. (Dan Higgins)

Actions #2

Updated by Dan Higgins almost 19 years ago

This looks like a GDAL problem - see comments below from Dave Vieglais

Hi Dan,

from gdal-1.3.1/frmts/raw/ehdrdataset.cpp :

else if( EQUAL(papszTokens[0],"NBITS") )
{
if( atoi(papszTokens[1]) == 16 )
eDataType = GDT_Int16;
else if( atoi(papszTokens[1]) == 32 )
eDataType = GDT_Float32;
else if( atoi(papszTokens[1]) == 64 )
eDataType = GDT_Float64;
}

http://www.esri.com/library/whitepapers/pdfs/eximgav.pdf implies INT, and also
indicates a variety of sizes that are not covered by GDAL (notably 1 and 4
bits not in gdal, 64 bit formats are not specified in the esri doc):

"nbits—The number of bits per pixel per band. Acceptable values are 1, 4, 8,
16, and 32. The default value is eight bits per pixel per band. For a true
color image with three bands (R, G, B) stored using eight bits for each pixel
in each band, nbits equals eight and nbands equals three, for a total of
twenty-four bits per pixel. For an image with nbits equal to one, nbands must
also equal one. "

Other docs around the place indicate BIL in floating point format, or integer.
Basically there is no mechanism in BIL to specify the type of data, just the
size. Apart from tweaking GDAL, there doesn't seem to be any simple fix for
this - you could try something like reading the data into an im memory raster,
casting to INT32 as you read the pixels, then do the transform on the in
memory raster. But that doesn't seem like something to do in Kepler.

I would suggest converting the files with another product to GeoTiff, which is
a much more robust format.

Dave V.

Dan Higgins wrote:

Kevin,
The docs I have found for gdal_translate have an output format but I
cannot find an input format. Do you have a reference or example for how
to specify the input?

Dan

Kevin Ruland wrote:

Dan,

I'll look into this in the morning.

gdal_translate lets you specify input and output formats including
representation.

Kevin

Dan Higgins wrote:

Hi All,

Any GIS/GDAL experts out there?

As part of the ENM/GARP workflows, we need to read and re-project
some *.bil raster files. We are using some GDAL code in actors to do
this. The problem is that one of the *.bil input files is specified with
NBITS=32 in the *.hdr file. GDAL apparently assumes that NBITS=32
corresponds to 32-bit floating point data, but some other applications
assume it is 32 bit INT data!

The data is apparently 32 bit INTs. Is *.bil data always INT data?
(It allows 8 and 16 bit data which are integers; I see no way of
specifying what 32 bit data represents.) Is there any way in GDAL (eg
GDALWARP) to set the assumed input datatype? (i.e. tell GDAL to assume
INT rather than FLOAT?)

Dan

Actions #3

Updated by Dan Higgins over 18 years ago

Fixing this would require changes in the gdal code. Also, the Accumulation data is apparently not considered vital. Thus, dropping plans to fix, at least in the near term.

Actions #4

Updated by Redmine Admin over 11 years ago

Original Bugzilla ID was 2273

Actions

Also available in: Atom PDF