1

I am using the OSGeo4W Shell with the ETOPO1, 1 arc-minute global bathymetric data (etopo1_ice_g_f4.flt).

I am cutting 256x256 pixel slippy map tiles, and am having a problem with getting smooth-appearing PNG files out of the GDAL process. For example, the tile at zoom level 10, x = 306, y = 389 represents a 24 arc-minute span, from 39.24 N to 39.64 N, and 72.42 W to 72.02 W.

So, to produce the GeoTIFF I apply:

gdal_translate -of GTiff -projwin -72.42 39.64 -72.02 39.24
-outsize 256 256 -r bilinear
F:\test\etopo1_ice_g_f4.flt F:\test\z10x306y389.tif

Then, to get the color relief tile, I apply:

gdaldem color-relief 
F:\test\z10x306y389.tif F:\test\colors.txt F:\test\z10x306y389.png 
-of PNG

The problem is that the resulting PNG file does not appear to have been properly interpolated. Instead, it is pixelated:

Pixelated

I have asked a similar question, thinking that the problem was because I was using a .NET wrapper for the GDAL libraries, but here I am using OSGeo4W Shell, and the results are the same: a pixelated image. So, this question is more about upsampling ETOPO1 data.

The pixelation remains the same regardless of the type of resampling method I choose (e.g., bilinear, cubic, lanczos, etc.), so I wonder if this is an issue with the ETOPO1 data source?

The intermediary TIFF file (z10x306y389.tif in my example) opens as "all black" in various image editors (e.g, Paint).

And the gdaldem hillshade option results in a simply terrible graphic:

Hillshade

Has anyone else had issues when upsampling ETOPO1 elevation data? Is there a way to check the "correctness" of the steps I am using, or the integrity of the intermediary GeoTIFF file?

1 Answer 1

1

I sorted out the issue.

The etopo1_ice_g_f4.flt file does not have a datum defined (as discovered through gdalinfo), and so GDAL's interpolation techniques fail.

No coordinate system

I corrected the problem by applying gdal_translate -a_srs EPSG:4326 F:\test\etopo1_ice_g_f4.flt F:\test\etopo1_f4.tif to the FLT file.

The resulting GeoTIFF has the appropriate datum (WGS84), and the -r bilinear option now produces the expected smooth results.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.