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

[Even Rouault]

>
> 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?

No, I'd advise against always using --config CENTER_LONG 180 if you want to be 
able to deal with what lies at the west of the Greenwich meridian... (That 
would probably work but the longitudes would not fit in the [-180,180] 
interval as expected)

Here's why (ogr/ogrct.cpp) :

                    if( x[i] < dfTargetWrapLong - 180.0 )
                        x[i] += 360.0;
                    else if( x[i] > dfTargetWrapLong + 180 )
                        x[i] -= 360.0;
                }

So, if the coordinates are too far (more than 180 deg) from the center 
longitude, 360 is added or substracted. That helps when you're warping from 
UTM 1 to EPSG:4326 as part of the target coordinates are > 179 and part  
< -179. The +360 will correct the ones < -179 so that they end up being at 
the east of the ones > 179. 

I imagine that some heuristics could be added to gdalwarp to detect your 
situation and automatically add the --config CENTER_LONG 180, but there's 
always the risk to break other working use cases, and anyway people should be 
aware that there's probably some post-processing needed to deal with the fact 
that the result doesn't fit in the [-180,180] interval.

>
> 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