[gdal-dev] ERROR 1: Too many points (441 out of 441) failed to
transform, , unable to compute output bounds.
Stephen Woodbridge
woodbri at swoodbridge.com
Sun Jul 4 23:21:14 EDT 2010
Even or anyone,
I have made some progress, I think, in that all of the northern
hemisphere files have been translated without error, but until I can get
it working in mapserver to assess the results, I wont be sure.
But all of the southern hemisphere files now generate this error
regardless of using --config CENTER_LONG 180 or not.
So what is the "standard" if there is one way of assessing how to deal
with files like this. I have 882 .sid files 286 in the south and 596 in
the north. I can script the conversion, but I'm not sure what I need to
look for and what I need to do for any random file, like setting
--config CENTER_LONG 180 or doing something else.
It seems like having a tool like this would make sense and be useful to
others.
So here is the info on the first of the southern files:
+ rm -f /geotiff/GeoCover2000TIF//s-01-00.tif
+ gdal_translate -a_srs EPSG:32701 -of VRT
/geotiff/GeoCover2000/s-01-00.sid -b 1 -b 2 -b 3
/geotiff/GeoCover2000TIF/tmp.vrt
Input file size is 26981, 38945
+ gdalwarp -srcnodata 0 -dstnodata 0 -s_srs EPSG:32701 -t_srs EPSG:4326
-rb -wm 250 --config GDAL_CACHEMAX 250 --config GDAL_ONE_BIG_READ ON -co
TILED=YES /geotiff/GeoCover2000TIF/tmp.vrt
/geotiff/GeoCover2000TIF//s-01-00.tif
ERROR 1: Too many points (440 out of 441) failed to transform,
unable to compute output bounds.
gdalinfo /geotiff/GeoCover2000TIF/tmp.vrt
Driver: VRT/Virtual Raster
Files: /geotiff/GeoCover2000TIF/tmp.vrt
/geotiff/GeoCover2000/s-01-00.sid
Size is 26981, 38945
Coordinate System is:
PROJCS["WGS 84 / UTM zone 1S",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.01745329251994328,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-177],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",10000000],
AUTHORITY["EPSG","32701"],
AXIS["Easting",EAST],
AXIS["Northing",NORTH]]
Origin = (499498.125000000000000,1011.750000000000000)
Pixel Size = (14.250000000000000,-14.250000000000000)
Metadata:
IMAGE__INPUT_NAME=/dbuy/l7/outputs/mosaics742/S-01-0/locals/S-01-00_lr_742_2000.tif,
/dbuy/l7/outputs/mosaics742/S-01-0/locals/S-01-00_ur_742_2000.tif
IMAGE__INPUT_FILE_SIZE=3164295044.000000
IMAGE__COMPRESSION_VERSION=1,6,3
IMAGE__TARGET_COMPRESSION_RATIO=29.999998
IMAGE__COMPRESSION_NLEV=8
IMAGE__COMPRESSION_WEIGHT=2.000000
IMAGE__COMPRESSION_GAMMA=1.000000
IMAGE__COMPRESSION_BLOCK_SIZE=4096
IMAGE__CREATION_DATE=Mon Sep 22 13:29:44 2003
VERSION=MG2
Corner Coordinates:
Upper Left ( 499498.125, 1011.750) (177d 0'0.00"W, 90d 0'0.00"S)
Lower Left ( 499498.125, -553954.500) (177d 0'0.00"W, 90d 0'0.00"S)
Upper Right ( 883977.375, 1011.750) (177d 0'0.00"W, 90d 0'0.00"S)
Lower Right ( 883977.375, -553954.500) (177d 0'0.00"W, 90d 0'0.00"S)
Center ( 691737.750, -276471.375) (177d 0'0.00"W, 90d 0'0.00"S)
Band 1 Block=128x128 Type=Byte, ColorInterp=Red
Band 2 Block=128x128 Type=Byte, ColorInterp=Green
Band 3 Block=128x128 Type=Byte, ColorInterp=Blue
Thanks,
-Steve
Even Rouault wrote:
>> 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
>
>
More information about the gdal-dev
mailing list