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