[gdal-dev] problems with gdal_merge.py

[Volker Wichmann]

Thanks for your help Frank,
seems I stumbled across a bug in the GDAL Import/Export Module of SAGA 
GIS. Using OpenEV the file gets interpreted as reported by gdalinfo ...

sorry for the mess,
Volker


Frank Warmerdam wrote:
> 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,