0

If I use gdalwarp to convert a simple ArcInfo ASCII grid with a compound projection (Geographic horizontal/meters vertical) to a GeoTIFF, I get an error message. Here's the input raster (asc_h84deg_vm.asc):

ncols         2
nrows         2
xllcorner     -112
yllcorner     38
cellsize      1
nodata_value  -999
78 -999
-999 -999

Here's the input projection (asc_h84deg_vm.prj):

COMPD_CS["WGS_1984,NAVD88",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.0174532925199433,AUTHORITY["EPSG","9122"]],AXIS["Latitude",NORTH],AXIS["Longitude",EAST],AUTHORITY["EPSG","4326"]],VERT_CS["National Geodetic Vertical Datum of 1929",VERT_DATUM["North American Vertical Datum 1988",2005,AUTHORITY["EPSG","5103"]],UNIT["m",1.0],AXIS["Gravity-related height",UP],AUTHORITY["EPSG","5703"]]]

I use the following gdalwarp command:

gdalwarp -of GTiff -ts 2 2 asc_h84deg_vm.asc -overwrite asc_h84deg_vm_exported.tif -ot Float32
ERROR 1: Too many points (441 out of 441) failed to transform, unable to compute output bounds.

Note that if I use gdal_translate to convert the ASCII grid, it succeeds:

gdal_translate -of GTiff -outsize 2 2 asc_h84deg_vm.asc asc_h84deg_vm_exported.tif -ot Float32
Input file size is 2, 2
0...10...20...30...40...50...60...70...80...90...100 - done.

I have tried gdalwarp with other compound projections where the horizontal projection is a projected coordinate system instead of a geographic and it works fine.

Any ideas how to get gdalwarp to work with a compound projection where the horizontal part is a geographic projection? Note that reprojection works fine if I try to do a gdaltransform operation on some coordinates that are within the range of my raster:

gdaltransform -s_srs asc_h84deg_vm.prj -t_srs EPSG:32612+5702
Enter X Y [Z [T]] values separated by space, and press Return.
-113 38 87
324396.629208543 4207702.36747255 285.4325
1
  • It seems gdalwarp has trouble with compound projections where the horizontal projection is in geographic coordinates. I could never get gdalwarp to work with these kinds of rasters. My workaround was to remove the vertical projection from the raster and just call gdalwarp on rasters with a horizontal projection if the horizontal projection is in geographic coordinates and the raster has a compound projection.
    – Burrow
    Commented Jun 6, 2022 at 17:32

1 Answer 1

2

You have a somewhat unrealistic use case with an image having only 4 pixels and using gdalwarp for a conversion where no warping will happen because source srs is the same as the target srs. Therefore gdal_translate can do the same job.

If you definitely want to use gdalwarp I would pay attention to the error message

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

Gdalwarp seems to have problems with output bounds and obviously it is trying to do some analysis on a larger area because it tries to transform 441 points even the source and target rasters have only 4 pixels.

I made a test by helping gdalwarp with the target extent by giving that as a parameter -te and at least it created an output despite throwing some errors.

gdalwarp -of GTiff -ts 2 2 asc_h84deg_vm.asc -overwrite asc_h84deg_vm_exported.tif -ot Float32 -te -112 38 -110 40
Creating output file that is 2P x 2L.
Processing asc_h84deg_vm.asc [1/1] : 0Using internal nodata values (e.g. -999) for image asc_h84deg_vm.asc.
Copying nodata values from source asc_h84deg_vm.asc to destination asc_h84deg_vm_exported.tif.
ERROR 1: Too many points (529 out of 529) failed to transform, unable to compute output bounds.
Warning 1: Unable to compute source region for output window 0,0,2,2, skipping.
...10...20...30...40...50...60...70...80...90...100 - done.
2
  • OK this seems to point me in the right direction anyway. I'm just trying to update to the latest GDAL with my software and this unrealistic test case was used in one of our automated tests. I'll think a little more about this issue and if there's a better case I could use to test this functionality. Maybe I'll use a real ascii grid file instead of one that has been contrived.
    – Burrow
    Commented Jun 3, 2022 at 5:43
  • Are you aware of the automated tests that GDAL is running github.com/OSGeo/gdal/tree/master/autotest? Test for gdalwarp is github.com/OSGeo/gdal/blob/master/autotest/utilities/…. Maybe you can find some useful hints.
    – user30184
    Commented Jun 3, 2022 at 8:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.