[gdal-dev] ERROR 1: Too many points (441 out of 441) failed to transform, , unable to compute output bounds.

[Stephen Woodbridge]

Even,

Excellent! this fixed the problem and I can split the image if I need to 
do that.

So does --config CENTER_LONG 180 impact processing of files that are in 
other UTM Zones? ie: can I just always use this or will if mess up other 
files in some way?

Thanks,
   -Steve

Even Rouault wrote:
> Stephen,
> 
> Obviously when dealing with UTM zone 1 or 60, you can expect some issues :-)
> 
> The spatial extent of your source file is the following :
> 
> Upper Left  (  116009.250,  276735.000) (179d32'52.82"E,  2d29'56.85"N)
> Lower Left  (  116009.250,    -997.500) (179d33'4.57"E,  0d 0'32.43"S)
> Upper Right (  883970.250,  276735.000) (173d32'53.48"W,  2d29'56.85"N)
> Lower Right (  883970.250,    -997.500) (173d33'5.24"W,  0d 0'32.43"S)
> Center      (  499989.750,  137868.750) (177d 0'0.33"W,  1d14'50.42"N)
> 
> Which means its crossing the dateline meridian, a never ending source of 
> problems, in particular for gdalwarp...
> 
> There's luckily a workaround. You can give a hint to the warping algorithm by 
> specifying the center longitude of the area of interest.
> 
> Try this : gdalwarp --config CENTER_LONG 180 -s_srs EPSG:36001 -t_srs 
> EPSG:4326 source_dataset out.tif
> 
> The longitude extent of the out.tif will be approx. between 179.55 and 186.44, 
> which might cause issues in number of applications that would expect the 
> longitude to be in the [-180,180] range. In that case, you'd likely need to 
> cut it into 2 pieces, at the west and east of longitude 180 with 
> gdal_translate.
> 
> (You could also try with CENTER_LONG set at -180, which would leave to simular 
> results, but with extent centered around -180 ...)
> 
> Best regards,
> 
> Even