[Gdal-dev] Fixing projections with GDAL_TRANSLATE vs. GDALWARP

[Rich Signell]

Matt,

> Are you using windows?

I'm having the problem with FWTOOLS 1.3.6 on Windows and FWTOOLS 1.3.4
on Linux.

> On windows with gdal installed via fwtools 1.07 (or later),
> gdalwarp seems to omit reading the source projection, i.e. you
> must use both -s_srs and -t_srs. When I do that with your source image,
> the results are the same as 1-step-with-gdalwarp result (see attached).

To me this is the same as doing the 1 step gdalwarp, because the only
thing the gdal_translate step was supposed to do was specify the
coordinate projection correctly, and now you are overriding that in
2nd gdalwarp step with the -s_srs command.

I think the real problem is that the gdal_translate step did not end
up specifying the coordinate system correctly, so the file "merc.tif"
still is not correct, therefore the gdalwarp command to convert it to
geo doesn't work correctly.

Yet it's odd that the very same specification of coordinate system, if
given to gdal_warp via the -s_crs argument, works correctly.   It's
almost like the -s_crs argument works but -t_crs is not working, or
else the Merc_1 info is being interpreted correctly when specified on
the command linke, but written incorrectly written to or read from a
GeoTIFF file.


> This bug is filed as http://trac.osgeo.org/gdal/ticket/1471 - gdalwarp
> should keep georeferencing info

According to my reasoning, I think this is not a problem of gdalwarp
not keeping the georeferencing info.   It could be a problem of not
being able to correctly read/write merc 1_sp info into the geotiff
correctly.

-Rich

P.S. Should this type of discussion take place here, or in trac ticket comments?
-- 
Dr. Richard P. Signell   (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598