4

I am using GDAL 1.91 on a Windows 7 machine. I have been mosaicing large numbers of rasters together and most of the time this process works exactly as expected. However a very few of my mosaics look incomplete. It is as though GDAL_merge simply ignored some of my input files (see image - notice the top lefthand corner): incomplete mosaic

To try and eliminate this problem I have:

  • checked that the missing rasters are valid and exist in my file system (correct on both counts - they display individually without error)
  • checked my input string and that definitely includes the missing rasters.
  • made all the input rasters the same type (e.g. Float32)
  • explicitly specified the no_data value to ignore in the inputs
  • EDIT: all the inputs are also the same resolution and running with verbose output gives no clues of any errors either

The mosaic process involves joining a maximum of 395 rasters each of which is 980KB and the resultant files should be about 390MB. The process works very well most of the time, so this suggests that it is not a memory issue (I have 6GB of RAM and am using the 64 bit version of GDAL).

The error is not isolated to only one mosaic. I have seen this elsewhere before and with GDAL 1.8 (which is why I upgraded to 1.91). In this particular case, the result using GDAL 1.8 was almost the exact opposite (i.e. the top left hand corner of this area did have data and the bottom left was empty - thus proving my data are valid but mystifying me further as to what is going wrong).

Changing the order of my input files does sometimes make a difference but usually does not entirely solve the issue.

Is this a bug (this is my gut feeling at the moment)? Otherwise, does anybody have any suggestions for what might be going wrong and/or work arounds?

Many thanks!

UPDATE: I have been studying my rasters in QGIS looking for differences and the ONLY difference I can see is that, although all the rasters were created in exactly the same way and are all the same resolution, same projection and all geotiffs, QGIS quotes the driver as VRT/Virtual Raster for the ones which gdal_merge is failing. QGIS correctly quotes the driver as GeoTiff for the rest!?! Gdalinfo on the other hand, quotes the driver as GTiff/GeoTiff for all the files.

So - there is SOMETHING different about the tiles but what and why is not obvious... more digging to follow...

Improve this question
6
  • Have you checked if the spatial resolution of all your files is the same? I think gdalinfo reports it.
    – nickves
    Commented Oct 3, 2012 at 21:40
  • Yes they are all the same resolution
    – MappaGnosis
    Commented Oct 4, 2012 at 7:07
  • my gut tells me what is something wrong with the output file (detected) resolution. Have you tried with -pr piselsize_x pixelsize_y flag?
    – nickves
    Commented Oct 4, 2012 at 10:33
  • Just tried your suggestion and there is no improvement
    – MappaGnosis
    Commented Oct 4, 2012 at 11:23
  • I am begining to think that it is the infuriating GDAL issue where it makes some rasters upside down. That could explain why QGIS is treating some as VRTs and some as GTiffs. Though why some of the files rasterized the right way up and some upside down, I don't know.
    – MappaGnosis
    Commented Oct 4, 2012 at 12:37

1 Answer 1

Reset to default
3

I have a solution!

It IS because of the old and infuriating GDAL upside-down export to GeoTiff (see my comments above)! Before anybody tells me that this has been fixed - I agree it does appear to be fixed but I was using a mixture of data converted with a older version of GDAL about 4 years ago and data I converted with the latest version of GDAL about 3 weeks ago. The old stuff was partially upside down and the new stuff was all the right way up. So long as you don't mix the upside down and right-way up data, you are OK - which is partly why it took me so long to find the problem. Gdal_merge couldn't cope and QGIS only coped by making a virtual raster on the fly. That was my clue.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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