Opened 20 years ago

Last modified 20 years ago

#533 closed defect (fixed)

problems loading ESRI GRID data with r.in.gdal (LandScan dataset)

Reported by: geoffreyfw@… Owned by: warmerdam
Priority: high Milestone:
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords:
Cc:

Description

Copy of original posting to GDAL-DEV and grass user list:
**********************************************************

I have been working with r.in.gdal in Grass5 and am
having an odd problem:

I am working with the LandScan dataset
(http://www.ornl.gov/sci/gist/landscan/) , and all
sections have been loading fine with r.in.gdal, with
the exception of part of India, where I get a "rip"
across part of the data. Specifically, a rectangle
roughly from 76:00 East to 78:08 East and from 28:40
North to 28:36 North loads as null (since the LandScan
data is at 30''x30'' this is about 8 by 256 squares by
my count). 

I get an error message when r.in.gdal is loading the
LandScan data set:
"Warning 1: Unsupported Arc/Info Binary Grid tile of
type 0x20 encountered. This and subsequent unsupported
tile types set to no data value"

I am in contact with Oak Ridge (who prepare the
LandScan data set). They are being very helpful, but
they have no trouble loading it and have never heard
of this problem.

I sent an earlier version of this message to the Grass
users mailing list and was advised to use hexdump to
look through the file for "20"s.  I've tried that, but
the overall Asia file has nearly 100,000  instances of
"20" (I get this using grep -c).  

Is there some way to distinguish which of the "20"s is
causing the trouble? Perhaps some of them are
coordinates and some of them are data? Is there any
way to either hand edit the file to remove the
offending tiles or alternatively, is there some way to
tell r.in.gdal to accept the data?

Additional information from working with ORNL:
***********************************************

ORNL has made available to me several versions of the problem area, none of
which help to load it properly. Handediting of the affected section for 0x20's
only seems to substitue random values for the entire affected area.

I have copies of the ORNL files of the affected area that I can share with
anybody  working on this problem.

Attachments (3)

williams4.zip (23.7 KB ) - added by geoffreyfw@… 20 years ago.
ESRI GRID data set for part of problem area described in bug report
williams3.zip (12.6 KB ) - added by geoffreyfw@… 20 years ago.
ESRI GRID data of problem area described in bug report in zip format
williams.zip (171.5 KB ) - added by geoffreyfw@… 20 years ago.
ESRI GRID data of problem area described in bug report (including large areas that loaded without problem)

Download all attachments as: .zip

Change History (4)

by geoffreyfw@…, 20 years ago

Attachment: williams4.zip added

ESRI GRID data set for part of problem area described in bug report

by geoffreyfw@…, 20 years ago

Attachment: williams3.zip added

ESRI GRID data of problem area described in bug report in zip format

by geoffreyfw@…, 20 years ago

Attachment: williams.zip added

ESRI GRID data of problem area described in bug report (including large areas that loaded without problem)

comment:1 by warmerdam, 20 years ago

Problem fixed. 

0x20 blocks are 32bit integer raw data blocks. 

The code change has been committed, and I have tested successfully with two of
the attached files.  The easiest way to get the fix is likely to fetch a nightly
snapshot tomorrow from:


  ftp://ftp.remotesensing.org/gdal/daily/


Note: See TracTickets for help on using tickets.