Opened 10 years ago
Closed 5 years ago
#5502 closed defect (wontfix)
gdalwarp is unable to output a geotiff with units=seconds correctly
Reported by: | kornm | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | closed_because_of_github_migration |
Component: | Utilities | Version: | 1.11.0 |
Severity: | major | Keywords: | NON STANDARD UNITS |
Cc: |
Description (last modified by )
We use geotiff with units=seconds quite a lot. I found that running: gdalwarp -t_srs <srs-def> <input path> <output path>
- If target srs-def is a ESRI 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. This means the the transformation works OK from seconds to degrees.
- If target srs-def is 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. Which means that the transformations works incorrectly from degrees to seconds. In order to reproduce the problem I prepared the following:
- Two ESRI prj files for EPSG 4236, one with units = seconds and the
other with units = degrees, to be used as -t_srs.
- a geotiff with units = seconds named WGS84 SEC FIRST.tif and a
polygon that "sits" on the contour.
- also the result (reproducible) of the first gdalwarp from seconds
to degrees, named WGS84 DEG from SEC.tif.
- also the output of the second gdalwarp from degrees to seconds
(with the incorrect header)named WGS84 SEC from DEG.tif.
- a directory with GDALINFO listing for the geotiffs (3 files).
In order to correct the last output file I used ArcCatalog and set the units to seconds. After the correction the file (and the header) was OK. It also seems thar reading of the input geotiff is correct, including cases when the units = seconds. This may hint that the correction could be relatively simple,since the calculations and almost all the geotiff header writing seem OK.
Summary: I assume there is a general problem with cases in which the units of the geotiff are not the DEFAULT units that appear in GCS.csv or PCS.csv. For example the same problem will happen when using radians instead of degrees for a GCS or feet instead of meters for PCS.
Additional notes:
- ArcGIS has a problem displaying correctly vectors and rasters
with units = seconds. To get the distances correct in the display - reload the GCS for the Data Frame.
- The ESRI prj to be used SHOULD contain the EPSG code, otherwise
ArcMAP my read the geotiff file as "custom".
- ArcGIS 10.2 is not able to output "normal" geotiffs because of
a serious problem with Data>Export Data.
The attached material: a rar file containing all the files required and also my results.
I hope some one will help us since all my programmers are experienced in C# and have no practical experience with GDAL internals.
Attachments (1)
Change History (6)
comment:1 by , 10 years ago
by , 10 years ago
Attachment: | ESRI Bugs 1MB.rar added |
---|
I created a new set of files less than the 1MB limit.
comment:2 by , 10 years ago
Description: | modified (diff) |
---|
comment:3 by , 9 years ago
Priority: | high → normal |
---|
All those tickets have more than one year and nobody has acted on it, so the priority is not so high
comment:5 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.
I was not aware of the limitation of attachments size, there fore I will attach only the minimum required and not the results.