[gdal-dev] ERROR 1: Too many points (441 out of 441) failed to
transform, , unable to compute output bounds.
Brent Fraser
bfraser at geoanalytic.com
Mon Jul 5 11:51:16 EDT 2010
Stephan,
Even though the tiles are South of the equator, they are in the UTM North
coordinate system. Try
-a_srs EPSG:32601
instead of 32701, for Zone 1.
Brent
Stephen Woodbridge wrote:
> 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
>>
>>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
More information about the gdal-dev
mailing list