Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#4645 closed defect (fixed)

gdal_translate fails on GRD grid

Reported by: mladen Owned by: warmerdam
Priority: normal Milestone: 1.9.1
Component: GDAL_Raster Version: 1.9.0
Severity: major Keywords: grd, vertical mapper, northwood, gdal_translate
Cc:

Description (last modified by mladen)

NOTE: This is probably not gdal_translate specific, but rather a bug in the Northwood Vertical Mapper .grd driver. However, I didn't want to jump to conclusions and so am describing exactly how I came across the issue, which was with gdal_translate.

Suppose we start with a large, mostly empty grid (45Mb zipped, ~4Gb unzipped): http://dl.dropbox.com/u/53500018/translateBug/original_30m_grid.zip

This grid has a resolution (pixel size) of 30m, and looks like this when I open it in a viewer: http://dl.dropbox.com/u/53500018/translateBug/original.png

However, if I try to translate it with "gdal_translate", with the following command:

gdal_translate -of png -b 1 -b 2 -b 3 -outsize 10% 10% "original30m.grd" resolution30.png

I get garbled, warped output near the bottom of the grid:
http://dl.dropbox.com/u/53500018/translateBug/resolution30.png

It is evident also that a large chunk of the grid has been cut off at the bottom.

This seems to be related to the large file size of the original grid, because I can downsample it to lower resolutions, and the lower the resolution, the better the output. For example:

Downsampled to 35m:
http://dl.dropbox.com/u/53500018/translateBug/resolution35.png

37m (notice that less is cut off at the bottom, but still warped):
http://dl.dropbox.com/u/53500018/translateBug/resolution37.png

By 45m, it looks OK, but I doubt that it would look OK if there were data near the bottom of the grid extent.
http://dl.dropbox.com/u/53500018/translateBug/resolution45.png

And by 60m, everything is clearly fine:
http://dl.dropbox.com/u/53500018/translateBug/resolution60.png

For convenience, here is the original grid downsampled to 60m resolution (22Mb zipped, ~1Gb unzipped):
http://dl.dropbox.com/u/53500018/translateBug/resized_60m_grid.zip

Rather than resizing, I can also cut the original grid in 2 halves, and get good output. Unfortunately, I can't do this in every case, since I'm using GDAL as part of an automated process.

So, obviously the wheels fall off somewhere around 2 Gb grid size, or 45m resolution in this case. The 30m is a good sample grid for the "bad" case, and the 60m is a good sample for the "good" case, but if more samples are needed let me know.

P.S. The aux.xml files for each of the PNGs above are available just by adding ".aux.xml" to the link (except original.png, which is a screen cap).

Change History (4)

comment:1 Changed 6 years ago by mladen

Description: modified (diff)

comment:2 Changed 6 years ago by mladen

Description: modified (diff)

comment:3 Changed 6 years ago by Even Rouault

Component: defaultGDAL_Raster
Milestone: 1.9.1
Resolution: fixed
Status: newclosed

r24355 /trunk/gdal/frmts/northwood/ (grcdataset.cpp grddataset.cpp): Northwood: fix wrong file offset computation over 2 GB (#4645)

r24356 /branches/1.9/gdal/frmts/northwood/ (grcdataset.cpp grddataset.cpp): Northwood: fix wrong file offset computation over 2 GB (#4645)

comment:4 Changed 6 years ago by mladen

Tested with the original data set and a few others, and it works. Thanks!

Note: See TracTickets for help on using tickets.