Opened 12 years ago
Closed 9 years ago
#4672 closed defect (fixed)
HDF4 read incorrectly
| Reported by: | cmutel | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | GDAL_Raster | Version: | 1.9.0 |
| Severity: | normal | Keywords: | hdf4 |
| Cc: | etourigny |
Description
GDAL reads some HDF4 subdatasets incorrectly (which other utilities such as HDFlook can process without problems).
GDAL interprets the bottom third of the image correctly, the next upper half is filled with the nodata value, and then a different selection from the image is repeated four times across the top fifth of the image (see attached). Sample dataset which shows this problem is also attached; other similar datasets can be downloaded at ftp://ftp.ntsg.umt.edu/pub/MODIS/Mirror/MOD16/MOD16A2_MONTHLY.MERRA_GMAO_1kmALB/Y2000/M01/ (data from MODIS on evapotranspiration).
Problem seen with Mac (10.6) 64-bit and Linux 64-bit with GDAL 1.9.0.
Attachments (2)
Change History (6)
by , 12 years ago
| Attachment: | MOD16A2.A2000M01.h14v02.105.2010357183410.hdf added |
|---|
comment:1 by , 12 years ago
| Cc: | added |
|---|---|
| Component: | default → GDAL_Raster |
| Status: | new → assigned |
The problem is the HDF4 grid code using the tile API when it isn't working on tile sized chunks. It isn't clear how far back things have been broken.
I have made a fix for this in trunk (r24447) and 1.9 branch (r24448). It may be though that the logic for picking a block size ought to be more tile-size-friendly.
Unfortunately the fix will not likely be in 1.9.1.
comment:2 by , 12 years ago
comment:3 by , 12 years ago
That was fast! I noticed that when passed to the netcdf driver, the values are ok but there is no projection.
The fix works for me (trunk). Any workaround that could work, as it probably won't make it to 1.9.1?
comment:4 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Looks like the issue was solved
Dataset read incorrectly