[gdal-dev] problems with gdal_merge.py

[Frank Warmerdam]

Volker Wichmann wrote:
> Frank Warmerdam wrote:
>> Volker,
>>
>> You will need to file a ticket on this, and provide as much supporting
>> information (ie. .HDR files) as you can.
>>
>> I'm pretty sure we have already gone through several iterations on this
>> so there is clearly something that isn't being properly understood.  I'm
>> not going to take your fix on faith, I need to know I'm actually fixing
>> things, not just stirring the pot again.
>>
> Frank,
> 
> I will do so, and started to build up a test case. But first of all I 
> may need some advice, I'm a little surprised by my first tests.
> I build a simple 4 by 4 grid, geotiff format. Running gdalinfo on the 
> file I get:
...
> The Origin / Upper Left matches with what I expected (the grid BOUNDARY 
> is: N 14  S 10  W 10  E 14). I'm not sure to understand the values 
> reported for the Lower Right - isn't this off by 1 cell in x and -1 cell 
> in y??
> I don't think it makes sense to go on before I get this ...

Volker,

I think I would need to see a listgeo report on the file to comment.
I suspect it is using PixelAsPoint and assuming that a pixel/line value
of 0,0 refers to the center of the top left pixel.

There is an outstanding dispute on how PixelAsPoint GeoTIFF files ought
to be interpreted.  There is an open ticket on the issue, if you cared
to dig for it.  Suffice it to say that you are best off avoiding
ambiguity by working with pixel-as-area files when possible.

>>> Other issues I'd like to see mentioned on the gdal_merge.py page 
>>> (http://www.gdal.org/gdal_merge.html):
>>> - if the output file is already existing, the behaviour of the module 
>>> is indetermined as it tries to append to the file (?)
>>
>> I don't know why you say this. If the output already exists, then the
>> script attempts to mosaic into it.
>>
> ok, I see it's a feature. But I think it should be mentioned in the docs

I have modified the -o switch docs to read:

<dt> <b>-o</b> <i>out_filename</i>:</dt><dd> The name of the output file,
which will be created if it does not already exist (defaults to "out.tif").</dd>

>>> - the -ul_lr arguments reference the cell CENTERS
>>
>> The -ul_lr arguments are (to the best of my knowledge) outer pixel edges,
>> not cell centers.
 >
> not for me, but as written above: first of all I need to get that right 
> to build a proper test case.

I tried creating a file with gdal_merge.py and confirmed my understanding:

  gdal_merge.py -o out.tif utm.tif -ul_lr 5 10 10 5 -ps 1 1

gdalinfo out.tif
...
Corner Coordinates:
Upper Left  (   5.0000000,  10.0000000) (121d29'19.14"W,  0d 0'0.32"N)
Lower Left  (   5.0000000,   5.0000000) (121d29'19.14"W,  0d 0'0.16"N)
Upper Right (  10.0000000,  10.0000000) (121d29'18.98"W,  0d 0'0.32"N)
Lower Right (  10.0000000,   5.0000000) (121d29'18.98"W,  0d 0'0.16"N)
Center      (   7.5000000,   7.5000000) (121d29'19.06"W,  0d 0'0.24"N)
...

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org