I am working with the v2.3.3 NuGet of GDAL by Tamas Szekeres for the .NET environment, and can successfully open the etopo1_ice_g_f4.flt raster to cut basic tiles.

The problem I am having is that even when I apply the -r bilinear option to my translation options, the generated image remains pixelated.

Specifically, I make the following calls in code to get the initial raster (simplifying the file names for this example):


var etopoPath = @"F:\testing\etopo1_ice_g_f4.flt";
var colorPath = @"F:\testing\color.txt";
var pngPath = @"F:\testing\tile.png";
var tifPath = @"F:\testing\tile.tif";

var raster = Gdal.Open(etopoPath, Access.GA_ReadOnly);

I then set the appropriate projection extents, which will produce a 256x256 tile (in OpenMaps, it would be tile x = 306, tile y = 389, zoom = 10):

// shows us tile 306 389 z10
const double lonWest = -72.42;
const double lonEast = -72.02;
const double latNorth = 39.64;
const double latSouth = 39.24;

I set up the gdal_translate options to include bilinear interpolation:

var translateOptions = new[] {
    "-of", "GTiff",
    "-projwin", $"{lonWest}", $"{latNorth}", $"{lonEast}", $"{latSouth}",
    "-outsize", "256 256",
    "-r", "bilinear",

Gdal.wrapper_GDALTranslate(tifPath, raster, new GDALTranslateOptions(translateOptions), null, null);

And finally, process the GeoTIFF as a color-relief tile:

var demOptions = new[] {
    "-of", "PNG",

var tifRaster = Gdal.Open(tifPath, Access.GA_ReadOnly);
Gdal.wrapper_GDALDEMProcessing(pngPath, tifRaster, "color-relief", colorPath, new GDALDEMProcessingOptions(demOptions), null, null);

And it works, producing the following PNG image:

Pixelated tile

Now, the problem is that this does not seem to have been interpolated. The same image is produced even when -r bilinear is removed from the options.

Using the same elevation data (etopo1), and doing my own bilinear interpolation processing, I get this image:

Smooth tile

I would like to not have to get the raw elevation data and do my own bilinear interpolation... I'd rather have the image properly interpolated coming out of gdal_translate.

So, am I missing something?

  • The difference between bilinear and nearest (by default, if you don't use the -r option) is not in the pixelated or not of the output. But in the value of each pixel. This will be interpolated bilinearly between the pixel values covered or will it assume the value of the nearest input pixel. Your output image appears to be 25 x 25 pixels, not 256 x 256. Feb 16 '19 at 0:25
  • I have checked the image file properties, and it is indeed 256x256, which is as expected from the -outsize option. Etopo1 has a resolution of 1 arc-minute, so only about 1 in 10 pixels at zoom 10 will have an actual elevation value in a 256x256 grid. The others should get their values by interpolation, as in my second image, but as you noticed, it appears that a single elevation value is being shared by 10x10 clusters of pixels. I thought using the “-r bilinear” option would produce an image whose pixel values were interpolated from the sparse data values. Feb 16 '19 at 6:27
  • 1
    I thought you were downsampling the raster. But if you are translating 0.4 degrees (24 minutes) to 256 pixels, you are upsampling it. gdal_translate tool (I'm used OSGeo4W binaries) perform the upsampling just how you want, with smoother results for cubic, cubicspline and lanczos methods. You can try another rather than bilinear. Seems to be a problem with that library? Feb 16 '19 at 7:08
  • Thanks for the suggestions, @GabrielDeLuca. I tried again using the different options for the -r switch, and the same PNG was produced in all cases. I am also using the OSGeo libraries, with the .NET wrapper classes (e.g., gdal_csharp) provided by Szekeres. I will try contacting him directly. Feb 19 '19 at 15:43
  • 1
    I have just also tried processing the same source (ETOPO1) with the OSGeo4W package, and get the same results (i.e., same PNG produced whether or not "-r bilinear" is used), so I suspect it is something to do with the etopo source data. I notice that the intermediary GeoTiff file is "all black" when opened in an image viewer. Feb 19 '19 at 16:42

I sorted out the issue. The etopo1 FLT file did not have a defined datum, so the GDAL interpolation failed. Fully answered here, in my second question on this topic.

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.