1

I have experienced that gdal shifts rasters. The outputs of gdal_warp are often skewed, have different pixel sizes and so forth. A known error which has also been discussed here.

But now, I had to realize, that gdal_merge also shifts rasters! Well it is only some mm of whole MODIS tiles (pixel size 250m), but I can't imagine what is the reason for it, all layers have the same extent, the same coordinate system and so forth. Why should gdal_merge shift inputlayers and not simply merge or stack them?

[code example:

gdal_merge -separate -of GTiff -o D:/MODIS_TIF_NDVI_RECTCLIP_YEARLY_STACK/2005_PARAMETERS_NDVI_STACK.tif D:/MODIS_TIF_NDVI_RECTCLIP_SEASONAL_PARAMETERS/2005_SOS_s1 .....]

enter image description here

  • You should make a zip file which could be used for reproducing the error. It would be interesting to know more about the know gdalwarp errors as well, including test data. – user30184 Aug 7 '15 at 22:36
  • Thanks for the interest. Unfortunately, I am very very busy with my data and can hardly spare some time to do small example datasets. But I will try as soon as I get a chance. Meanwhile: Here and in several Qgis forums, you will find the warp problem discussed ;) – Konrad Aug 14 '15 at 14:40
  • 1
    I use gdalwarp from command line frequently and I haven't noticed any problems lately but I have had to learn the parameters which suit for my data. I believe that there are problems and the only effective way to start analyzing them is to get all that is needed for reproducing the issue. Links to older discussions which contain exact commands and links to data are good, as well as links to GDAL tickets. These open tickets deal with gdalwarp, do you mean some of those trac.osgeo.org/gdal/… ? – user30184 Aug 14 '15 at 14:52
  • Maybe i did something wrong. I used the GUI of QGIS quite often and it is reported to be also problematic: trac.osgeo.org/gdal/ticket/4344 I find a lot of people writing that GdalWarp can not guarantee a kept input resolution which I find very odd! – Konrad Aug 15 '15 at 7:57
  • By default gdalwarp does not even try to keep the native resolution but you can always use -tr and define explicitly the output resolution. If that does not work I would call it as a bug. Keeping the native resolution is not always possible (e.g. reprojecting from degree units to meters) and very often would lead to extra resampling which would mean quality loss. I think that the current behavior is better as a default and easy to override with -tr, possibly used together with -tap. But probably documentation of gdalwarp should be improved, and QGIS may not expose all the gdalwarp options. – user30184 Aug 15 '15 at 11:32

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.