Re: [gdal-dev] ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds.
Am 17.09.2014 04:59, schrieb Love: Hi, Thanks! But it is workig only for some while for some hdf's, error still appears. I assigned one uniform target extent for all the files since this was what I specified before I downloaded the files from the oceancolor nasa. The extent of the hdf file(s) is different than the rectangular extent you ordered. You have to run gdalinfo on each hdf file to get the information. Look out for something like: geospatial_lat_max=24.78230858 geospatial_lat_min=5.343300343 geospatial_lat_units=degrees_north geospatial_lon_max=139.3295746 geospatial_lon_min=126.3987579 geospatial_lon_units=degrees_east HTH, André Joost ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds.
I just recall seeing similar output from gdal info where it listed the meta data but still showed Coordinate System is `' for the main line. When I added the s_srs it fixed itself. However I will admit it was a long while ago and I could be remembering slightly off. On Sep 15, 2014 11:21 AM, Andre Joost andre+jo...@nurfuerspam.de wrote: Am 15.09.2014 17:02, schrieb Simon Shak: I have had this error message show up if the s_srs is not correctly auto detected or not present in the input file. I have used a combination of looking through other nonstandard meta data files present with the image sets or using a program like global mapper which has a good chance at guessing the correct s_srs and then specifying it with the -s_srs option. For the hdf files mentioned above, the SRS is EPSG:4326, so that is not the problem. It is rather the extent of the raster. The raster is not aligned to latitudes or longitudes, but rather a parallelogram. The coordinates of each cell are stored in additional bands. Re-transforming only works if GDAL knows the correct extent of the data in degrees. Greetings, André Joost ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds.
Am 15.09.2014 04:22, schrieb Love: Thanks andre, will try this as soon as I can and will give you a update. I just want to ask if will it be possible to batch process my hdf files and gdalwarp everything if I'm going to specify the -te of each files? I am not sure if the -te coordinates follow a certain pattern. It should be possible to read the metadata information with gdalinfo, and extract the coordinate information with a python script that can build the gdalwarp command from it. But I am not a python expert. HTH, André Joost ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds.
I have had this error message show up if the s_srs is not correctly auto detected or not present in the input file. I have used a combination of looking through other nonstandard meta data files present with the image sets or using a program like global mapper which has a good chance at guessing the correct s_srs and then specifying it with the -s_srs option. On Sep 12, 2014 11:19 AM, Andre Joost andre+jo...@nurfuerspam.de wrote: Am 12.09.2014 04:54, schrieb Love: Hi, The gdalinfo in my post is the gdalinfo of the subdataset 37. I have also tried gdal_translate but when I tried to use gdalwarp using the gdal_translate output, it has error. I really need to use gdalwarp so that I could project the image into epsg:4326(+prj=longlat). If I'm going to use the gdal_translate I am ask to indicate the gcp which is not good in my case because I have many hdf files in my local directory and maybe they have different gcp and I need to batch process them later using the gdalwarp with the +proj=longlat command. What could be the solution? gdalwarp needs the -geoloc switch, and the target extent with -te. See also http://osgeo-org.1560.x6.nabble.com/gdal-dev- Geolocation-Arrays-td4372909.html There does not seen to be any progress on this issue. The values for -te can be found with gdalinfo on the subdataset. HTH, André Joost ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds.
Am 15.09.2014 17:02, schrieb Simon Shak: I have had this error message show up if the s_srs is not correctly auto detected or not present in the input file. I have used a combination of looking through other nonstandard meta data files present with the image sets or using a program like global mapper which has a good chance at guessing the correct s_srs and then specifying it with the -s_srs option. For the hdf files mentioned above, the SRS is EPSG:4326, so that is not the problem. It is rather the extent of the raster. The raster is not aligned to latitudes or longitudes, but rather a parallelogram. The coordinates of each cell are stored in additional bands. Re-transforming only works if GDAL knows the correct extent of the data in degrees. Greetings, André Joost ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds.
Am 12.09.2014 04:54, schrieb Love: Hi, The gdalinfo in my post is the gdalinfo of the subdataset 37. I have also tried gdal_translate but when I tried to use gdalwarp using the gdal_translate output, it has error. I really need to use gdalwarp so that I could project the image into epsg:4326(+prj=longlat). If I'm going to use the gdal_translate I am ask to indicate the gcp which is not good in my case because I have many hdf files in my local directory and maybe they have different gcp and I need to batch process them later using the gdalwarp with the +proj=longlat command. What could be the solution? gdalwarp needs the -geoloc switch, and the target extent with -te. See also http://osgeo-org.1560.x6.nabble.com/gdal-dev-Geolocation-Arrays-td4372909.html There does not seen to be any progress on this issue. The values for -te can be found with gdalinfo on the subdataset. HTH, André Joost ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds.
I know I'm not the first to post this topic and encountered this problem. But I've search and read some posts related to this and tried their solutions but no luck. I really can't figure out what is causing this problem. How am I going to solve it? Badly need help! I have tried gdalwarp -wo SOURCE_EXTRA=100 -wo SAMPLE_GRID=YES and still no luck. Here are the info: gdalwarp -t_srs +proj=longlat +datum=WGS84 HDF4_SDS:UNKNOWN:A2014042042000.L2_LAC.SeAHABS.hdf:37 hdf.tif Creating output file that is 783P x 697L. Processing input file HDF4_SDS:UNKNOWN:A2014042042000.L2_LAC.SeAHABS.hdf:37. ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds. Warning 1: Unable to compute source region for output window 0,0,783,697, skipping. 0...10...20...30...40...50...60...70...80...90...100 - done. *GDALINFO:* Driver: HDF4Image/HDF4 Dataset Files: A2014042042000.L2_LAC.SeAHABS.hdf Size is 563, 880 Coordinate System is `' Metadata: bad_value_scaled=-32767 bad_value_unscaled=-32767 Calibration Data=A2014042042000.L1A_LAC.eAHAB.hdf, MYD02_Reflective_LUTs.V6.1.17.19_OC.hdf, MYD02_Emissive_LUTs.V6.1.1 7.19_OC.hdf, MYD02_QA_LUTs.V6.1.17.19_OC.hdf cdm_data_type=swath Conventions=CF-1.6 creator email=d...@oceancolor.gsfc.nasa.gov creator name=NASA/GSFC/OBPG creator url=http://oceandata.sci.gsfc.nasa.gov date_created=20140211T064516Z Day or Night=Day Earth-Sun Distance Correction=1.02664971351624 Easternmost Longitude=136.7005615 End Center Latitude=11.01664448 End Center Longitude=131.961853 End Day=42 End Millisec=15905744 End Node=Ascending End Time=2014042042505744 End Year=2014 Flag Percentages=0, 1.770345688, 0, 52.53552246, 57.10398483, 8.07766819, 0.434966892, 0, 29.46895599, 64.5276947, 0.0 002018407686, 0.4016631842, 0, 0, 2.331059217, 0.0367350243, 0, 0, 0, 0.4466736615, 77.9515152, 0, 1.508356214, 0, 0, 1. 087921858, 0, 72.44247437, 1.770345688, 6.767116547, 90.6432724, 0 geospatial_lat_max=11.47631836 geospatial_lat_min=2.273697615 geospatial_lat_units=degrees_north geospatial_lon_max=136.7005615 geospatial_lon_min=125.5854034 geospatial_lon_units=degrees_east Latitude Units=degrees North license= http://science.nasa.gov/earth-science/earth-science-data/data-information-policy/ long_name=Chlorophyll Concentration, OC3 Algorithm Longitude Units=degrees East Lower Left Latitude=11.47631836 Lower Left Longitude=135.0154266 Lower Right Latitude=9.963588715 Lower Right Longitude=125.5854034 Mask Names=ATMFAIL,LAND,CLDICE,HILT naming_authority=gov.nasa.gsfc.sci.oceandata Node Crossing Time=33400 Northernmost Latitude=11.47631836 Number of Bands=16 Number of Pixel Control Points=563 Number of Scan Control Points=880 Number of Scan Lines=880 Orbit Node Longitude=-999 Orbit Number=-1 Pixels per Scan Line=563 Scene Center Latitude=7.185176849 Scene Center Longitude=132.8315887 Scene Center Scan Line=440 Scene Center Solar Zenith=26.0915 Scene Center Time=2014042042403706 Sensor Name=HMODISA Upper Left Latitude=3.718107462 Upper Left Longitude=136.7005615 Upper Right Latitude=2.273697615 Upper Right Longitude=127.4018173 Westernmost Longitude=125.5854034 Geolocation: LINE_OFFSET=0 LINE_STEP=1 PIXEL_OFFSET=0 PIXEL_STEP=1 SRS=GEOGCS[WGS 84,DATUM[WGS_1984,SPHEROID[WGS 84,6378137,298.257223563,AUTHORITY[EPSG,7030]],TOWGS84[0,0,0,0 ,0,0,0],AUTHORITY[EPSG,6326]],PRIMEM[Greenwich,0,AUTHORITY[EPSG,8901]],UNIT[degree,0.0174532925199433,AUTHOR ITY[EPSG,9108]],AUTHORITY[EPSG,4326]] X_BAND=1 X_DATASET=HDF4_SDS:UNKNOWN:A2014042042000.L2_LAC.SeAHABS.hdf:11 Y_BAND=1 Y_DATASET=HDF4_SDS:UNKNOWN:A2014042042000.L2_LAC.SeAHABS.hdf:12 Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 880.0) Upper Right ( 563.0,0.0) Lower Right ( 563.0, 880.0) Center ( 281.5, 440.0) Band 1 Block=563x880 Type=Float32, ColorInterp=Gray ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds.
Am 11.09.2014 10:45, schrieb Love: I know I'm not the first to post this topic and encountered this problem. But I've search and read some posts related to this and tried their solutions but no luck. I really can't figure out what is causing this problem. How am I going to solve it? Badly need help! I have tried gdalwarp -wo SOURCE_EXTRA=100 -wo SAMPLE_GRID=YES and still no luck. Here are the info: gdalwarp -t_srs +proj=longlat +datum=WGS84 HDF4_SDS:UNKNOWN:A2014042042000.L2_LAC.SeAHABS.hdf:37 hdf.tif maybe source crs is missing. *GDALINFO:* Driver: HDF4Image/HDF4 Dataset Files: A2014042042000.L2_LAC.SeAHABS.hdf Size is 563, 880 Coordinate System is `' That is for the whole dataset. Try gdalinfo on the subdataset 37 you want. I was successful with extracting the subdatset using gdal_translate, and work on with that: gdal_translate -a_srs EPSG:4326 -a_ullr -180 -90 180 90 -of Gtiff HDF4_SDS:UNKOWN:LISOTD_HRFC_V2.3.2013.hdf:0 test.tif In your case, a_ullr might be different. HTH, André Joost ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds.
I know I'm not the first to post this topic and encountered this problem. But I've search and read some posts related to this and tried their solutions but no luck. I really can't figure out what is causing this problem. How am I going to solve it? I have tried gdalwarp -wo SOURCE_EXTRA=100 -wo SAMPLE_GRID=YES and still no luck. Here are the info: gdalwarp -t_srs +proj=longlat +datum=WGS84 HDF4_SDS:UNKNOWN:A2014042042000.L2_LAC.SeAHABS.hdf:37 hdf.tif Creating output file that is 783P x 697L. Processing input file HDF4_SDS:UNKNOWN:A2014042042000.L2_LAC.SeAHABS.hdf:37. ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds. Warning 1: Unable to compute source region for output window 0,0,783,697, skipping. 0...10...20...30...40...50...60...70...80...90...100 - done. *GDALINFO:* Driver: HDF4Image/HDF4 Dataset Files: A2014042042000.L2_LAC.SeAHABS.hdf Size is 563, 880 Coordinate System is `' Metadata: bad_value_scaled=-32767 bad_value_unscaled=-32767 Calibration Data=A2014042042000.L1A_LAC.eAHAB.hdf, MYD02_Reflective_LUTs.V6.1.17.19_OC.hdf, MYD02_Emissive_LUTs.V6.1.1 7.19_OC.hdf, MYD02_QA_LUTs.V6.1.17.19_OC.hdf cdm_data_type=swath Conventions=CF-1.6 creator email=d...@oceancolor.gsfc.nasa.gov creator name=NASA/GSFC/OBPG creator url=http://oceandata.sci.gsfc.nasa.gov date_created=20140211T064516Z Day or Night=Day Earth-Sun Distance Correction=1.02664971351624 Easternmost Longitude=136.7005615 End Center Latitude=11.01664448 End Center Longitude=131.961853 End Day=42 End Millisec=15905744 End Node=Ascending End Time=2014042042505744 End Year=2014 Flag Percentages=0, 1.770345688, 0, 52.53552246, 57.10398483, 8.07766819, 0.434966892, 0, 29.46895599, 64.5276947, 0.0 002018407686, 0.4016631842, 0, 0, 2.331059217, 0.0367350243, 0, 0, 0, 0.4466736615, 77.9515152, 0, 1.508356214, 0, 0, 1. 087921858, 0, 72.44247437, 1.770345688, 6.767116547, 90.6432724, 0 geospatial_lat_max=11.47631836 geospatial_lat_min=2.273697615 geospatial_lat_units=degrees_north geospatial_lon_max=136.7005615 geospatial_lon_min=125.5854034 geospatial_lon_units=degrees_east Latitude Units=degrees North license=http://science.nasa.gov/earth-science/earth-science-data/data-information-policy/ long_name=Chlorophyll Concentration, OC3 Algorithm Longitude Units=degrees East Lower Left Latitude=11.47631836 Lower Left Longitude=135.0154266 Lower Right Latitude=9.963588715 Lower Right Longitude=125.5854034 Mask Names=ATMFAIL,LAND,CLDICE,HILT naming_authority=gov.nasa.gsfc.sci.oceandata Node Crossing Time=33400 Northernmost Latitude=11.47631836 Number of Bands=16 Number of Pixel Control Points=563 Number of Scan Control Points=880 Number of Scan Lines=880 Orbit Node Longitude=-999 Orbit Number=-1 Pixels per Scan Line=563 Scene Center Latitude=7.185176849 Scene Center Longitude=132.8315887 Scene Center Scan Line=440 Scene Center Solar Zenith=26.0915 Scene Center Time=2014042042403706 Sensor Name=HMODISA Upper Left Latitude=3.718107462 Upper Left Longitude=136.7005615 Upper Right Latitude=2.273697615 Upper Right Longitude=127.4018173 Westernmost Longitude=125.5854034 Geolocation: LINE_OFFSET=0 LINE_STEP=1 PIXEL_OFFSET=0 PIXEL_STEP=1 SRS=GEOGCS[WGS 84,DATUM[WGS_1984,SPHEROID[WGS 84,6378137,298.257223563,AUTHORITY[EPSG,7030]],TOWGS84[0,0,0,0 ,0,0,0],AUTHORITY[EPSG,6326]],PRIMEM[Greenwich,0,AUTHORITY[EPSG,8901]],UNIT[degree,0.0174532925199433,AUTHOR ITY[EPSG,9108]],AUTHORITY[EPSG,4326]] X_BAND=1 X_DATASET=HDF4_SDS:UNKNOWN:A2014042042000.L2_LAC.SeAHABS.hdf:11 Y_BAND=1 Y_DATASET=HDF4_SDS:UNKNOWN:A2014042042000.L2_LAC.SeAHABS.hdf:12 Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 880.0) Upper Right ( 563.0,0.0) Lower Right ( 563.0, 880.0) Center ( 281.5, 440.0) Band 1 Block=563x880 Type=Float32, ColorInterp=Gray -- View this message in context: http://osgeo-org.1560.x6.nabble.com/ERROR-1-Too-many-points-440-out-of-441-failed-to-transform-unable-to-compute-output-bounds-tp5161212.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds.
My GDAL package version: GDAL 1.9dev, released 2011/01/18 My input file is a NETCDF file which contains global average temperatures. This is the gdalinfo spew: Driver: netCDF/Network Common Data Format Files: gfdl_cm2_1-sresa2-tas-run1-2041-2070.nc Size is 144, 88 Coordinate System is `' Origin = (0.000,88.988767426589433) Pixel Size = (2.500,-2.022471986967942) Metadata: NC_GLOBAL#title=GFDL CM2.1, SRESA2 (run1) SRES A2 experiment output for IPCC AR4 and US CCSP NC_GLOBAL#institution=NOAA GFDL (US Dept of Commerce / NOAA / Geophysical Fluid Dynamics Laboratory, Princeton, NJ, USA) NC_GLOBAL#source=GFDL_CM2.1 (2004): atmosphere: AM2.1 (am2p13fv, M45L24); ocean: OM3.1 (mom4p1p7_om3p5, tripolar360x200L50); sea ice: SIS; land: LM2; infrastructure: FMS preK release NC_GLOBAL#contact=gfdl.climate.model.i...@noaa.gov NC_GLOBAL#project_id=IPCC Fourth Assessment and US CCSP Projects NC_GLOBAL#table_id=Table A1 (20 September 2004) NC_GLOBAL#experiment_id=SRES A2 experiment NC_GLOBAL#realization=1 NC_GLOBAL#cmor_version=9.60e-01 NC_GLOBAL#Conventions=CF-1.0 NC_GLOBAL#history=Wed Feb 9 15:43:49 2011: ncks -d lat,1,88 gfdl_cm2_1-sresa2-tas-run1-2041-2070.nc gfdl_cm2_1-sresa2-tas-run1-2041-2070.nc input/atmos.200101-210012.t_ref.nc At 10:21:57 on 01/28/2005, CMOR rewrote data to comply with CF standards and IPCC Fourth Assessment and US CCSP Projects requirements NC_GLOBAL#references=The GFDL Data Portal (http://nomads.gfdl.noaa.gov/) provides access to NOAA/GFDL's publicly available model input and output data sets. From this web site one can view and download data sets and documentation, including those related to the GFDL CM2.1 model experiments run for the IPCC's 4th Assessment Report and the US CCSP. NC_GLOBAL#comment=GFDL experiment name = CM2.1U-H2_SresA2_W1. PCMDI experiment name = SRESA2 (run1). Initial conditions for this experiment were taken from 1 January 2001 of the climate of the 20th century experiment named CM2.1U-D4_1860-2000-AllForc_H2. Several time varying forcing agents used during the first 100 years of this CM2.1U-H2_SresA2_W1 experiment were based on output of the MOZART global atmospheric chemistry climate model when driven with the SRES A2 emission scenarios. For the CM2.1U-H2_SresA2_W1 experiment volcanic aerosols were zero, land surface cover types were time invariant, and solar irradiance varied seasonally based upon late 20th century averages but with no interannual variation. NC_GLOBAL#gfdl_experiment_name=CM2.1U-H2_SresA2_W1 NC_GLOBAL#NCO=20110209 tas#standard_name=air_temperature tas#long_name=Surface Air Temperature tas#units=K tas#cell_methods=time: mean tas#coordinates=height tas#original_name=t_ref lat#standard_name=latitude lat#long_name=latitude lat#units=degrees_north lat#axis=Y lat#bounds=lat_bnds lon#standard_name=longitude lon#long_name=longitude lon#units=degrees_east lon#axis=X lon#bounds=lon_bnds Corner Coordinates: Upper Left ( 0.000, 88.9887674) Lower Left ( 0.000, -88.9887674) Upper Right ( 360.000, 88.989) Lower Right ( 360.000, -88.989) Center ( 180.000, -0.000) Band 1 Block=144x1 Type=Float32, ColorInterp=Undefined NoData Value=9.96920996838686905e+36 Metadata: NETCDF_VARNAME=tas NETCDF_DIMENSION_timeofyear=1 this is the command I am trying to perform: gdalwarp -s_srs +proj=longlat -t_srs +proj=somerc +lat_0=47.5 +lon_0=-97.0 +y_0=315.0 +x_0=390.0 +a=6371229 +b=6371229 -tr 5 -5 -te 575000.000 575000.000 7275000.000 5775000.000 -srcnodata 1e20 -dstnodata 1e20 -r bilinear -overwrite NETCDF:gfdl_cm2_1-sresa2-tas-run1-2041-2070.nc:tas test.tif as per this thread: http://tinyurl.com/4enmf2o* *I have also tried: gdalwarp --config CENTER_LONG 180 -s_srs +proj=longlat -t_srs +proj=somerc +lat_0=47.5 +lon_0=-97.0 +y_0=315.0 +x_0=390.0 +a=6371229 +b=6371229 -tr 5 -5 -te 575000.000 575000.000 7275000.000 5775000.000 -srcnodata 1e20 -dstnodata 1e20 -r bilinear -overwrite NETCDF:gfdl_cm2_1-sresa2-tas-run1-2041-2070.nc:tas test.tif and with a negative center_long gdalwarp --config CENTER_LONG -180 -s_srs +proj=longlat -t_srs +proj=somerc +lat_0=47.5 +lon_0=-97.0 +y_0=315.0 +x_0=390.0 +a=6371229 +b=6371229 -tr 5 -5 -te 575000.000 575000.000 7275000.000 5775000.000 -srcnodata 1e20 -dstnodata 1e20 -r bilinear -overwrite NETCDF:gfdl_cm2_1-sresa2-tas-run1-2041-2070.nc:tas test.tif But the stays the same: ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds. I am not sure if it makes a different, but I have slightly altered the input file by removing the top 2 rows of latitude using the command: ncks -d lat,1,88 gfdl_cm2_1-sresa2-tas-run1-2041-2070.nc Any help with this error would be very appreciated, Hailey ___ gdal-dev mailing list gdal-dev@lists.osgeo.org
Re: [gdal-dev] ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds.
On 11-02-10 01:43 PM, Hailey Eckstrand wrote: But the stays the same: ERROR 1: Too many points (440 out of 441) failed to transform, unable to compute output bounds. Hailey, I tried with your file and with debugging on and saw the following message: WARP: Recompute out extent with CHECK_WITH_INVERT_PROJ=TRUE I read through the code in gdalwarp.cpp and it seems this is something added, perhaps by Even, to check that the output area selected is appropriate and can be effectively reprojected. I tested a few points between the somerc projection and WGS84 with the PROJ.4 cs2cs command and found there was often poor fidelity - likely indicating that points were being transformed that are far outside the well defined area for the projection. I did successfully run your gdalwarp command by adding: --config CHECK_WITH_INVERT_PROJ FALSE on the commandline, but I'm not convinced that the results are actually very accurate or meaningful. I'd suggest you reconsider whether you really want to try and warp nearly the whole world to a swiss oblique mercator projection. Possibly Even could consider improving the error reporting in this case if the issue is really that the transformation is not round tripping well. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
