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: | 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)
Change History (4)
by , 20 years ago
Attachment: | williams4.zip added |
---|
by , 20 years ago
Attachment: | williams3.zip added |
---|
ESRI GRID data of problem area described in bug report in zip format
by , 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 , 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.
ESRI GRID data set for part of problem area described in bug report