[gdal-dev] Gdalwarp is unable to output a geotiff with units = seconds correctly

[Marcel Korn]

We use geotif with units=seconds quite a lot.

I found that running :
gdalwarp -t_srs <srs-def> <input path> <output path>

1. If target srs_def is a prj file with EPSG code for GCS WGS84 and units=
degree and my input file is a geotiff with GCS WGS84 and units= Seconds -
the output file is a "normal" geotiff with GCS WGS84 and units= degree.
2. If target srs_def in a prj file with EPSG code for GCS WGS84 and units=
SECONDS and my input file is a geotiff with GCS WGS84 and units= degree  -
the output is a geotiff with the units undetected correctly.
In order to correct the output file I used ArcCatalog and set the units to
seconds.
After the correction the file (and the header was ok).
Note: the prj must include authority = EPSG and the code (in this case
4326) otherwise the geotiff is produced as Custom CS and it may or may not
be identified correctly and fully by apps.
Also note that with default units you can run gdalwarp with EPSG:4326
instead of the prj file.

It seems like there is a functional program bug since GDAL reads
non-default units OK but cannot produce a geotiff with seconds. Something
similar will probable happen with UTM PCSs if the target is feet instead of
meter (the default).

I would like to know if somebody else found this problem and how he solved
it.
Of course, I wait to get confirmation it is a bug or maybe I did something
wrong.
If it is a "new bug" I woułd like to know what can I do to advance the
solution for it.

This bug reminds me of a very old ArcMap bug that manifests itself when you
open a polygon or a raster with non-default units like second. If this is
the first item you open, the units are not read correctly until you reload
the GCS into the Data Frame. And than you get Degrees...the logic (or the
lack of it) is similar.

Best regards,
Moty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140527/50b953bd/attachment.html>