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
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
