2

The image below shows part of a peninsula on the Australian island of Tasmania. The black pixels are 9" climate data with GDA94 (EPSG:4283) SRS, projected by QGIS on the fly to Australian Albers (EPSG:3577). The purple (pink?) and blue pixels are the same data projected to a 250 m grid in Australian Albers with gdalwarp, using "cubicspline" and "cubic" resampling methods, respectively, e.g. with:

gdalwarp -multi -tr 250 250 -s_srs "EPSG:4283" -t_srs "EPSG:3577" -r "cubicspline" -dstnodata "-9999" in.flt out.tif

I've used GDAL 1.11.1 for the above.

enter image description here

Why do the data resampled with "cubicspline" extend beyond the cells of the original data, and is there a way to make the behaviour consistent with that of "cubic"?

Comments on which approach is more appropriate when resampling climate data are also welcome.

  • 1
    A spline needs both ends to interpolate, where there's a null value there's nothing to pin it to so it uses the last valid pixel and the cell gets omitted so you should always loose one cell when resampling using this method, for cubic a couple of adjacent values are all it needs to approximate the pixel. Try filling in your nodata areas with a valid value (0 perhaps?) or use the Cubic method rather than the spline. – Michael Stimson Sep 17 '15 at 3:40
  • Thanks @MichaelMiles-Stimson. I'm reluctant to treat nodata as zero - wouldn't that pull the spline down (or up) towards zero inappropriately at the coastal boundary? I'd planned on using cubic spline as it "is the best method for representing ... phenomena such as temperature" (ref) - though I'm open to being told otherwise. At any rate, I'm not losing cells but gaining them - the pink/purple layer is the cubic spline result, which stretches out a number of cells into nodata territory. Have I misunderstood you? – jbaums Sep 17 '15 at 3:56
  • 2
    Perhaps it's extending the spline which is kinda dangerous, that is my understanding of how the maths operates. If there isn't a sensible value to use in your nodata areas then try to extend your data (download more) such that shrink/growth occurs outside your project area... it's not good working to the edge of a raster if it can be avoided. Normally I'd stick with bilinear for natural/continuous rasters like elevation models but I work with very large rasters and want to get them done reasonably quickly not worrying about the decimal places too much. – Michael Stimson Sep 17 '15 at 4:02
  • 1
    I understand that the computation of cubicspline bleeds and creates values on bordering nodata pixels, but I would say that as a final step of writing the result out nodata should be written back. I wonder what happens if your source images had alpha band instead of nodata. I would also try if using -srcnodata is changing anything. As a workaround you could save the nodata areas as vector polygons and post-process the result image with gdal_rasterize gdal.org/gdal_rasterize.html. That way you could burn nodata back to where it belongs. – user30184 Sep 17 '15 at 5:02
  • 1
    Not necessarily, I'd be happy to have a closer look at your workflow - which btw I think your question really needs specifics so we can reproduce the issue. I don't think there's any easy answer! Is this a pretty localized part of the grid, or is it most of it? (Ah I see Freycinet now). – mdsumner Sep 17 '15 at 12:41

Your Answer

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

Browse other questions tagged or ask your own question.