Opened 11 years ago
Closed 11 years ago
Last modified 11 years ago
#4607 closed defect (fixed)
EPSG authority code is not preserved
|Reported by:||ilucena||Owned by:||warmerdam|
|Severity:||normal||Keywords:||EPSG code GTiff|
|Cc:||ilucena, rprinceley, gaopeng, esrixz|
The file has PCS code compatible with EPSG but the driver doesn't show it as it was discussed in this thread:
I am going to give a copy of that file to Frank so he can take a look.
Change History (10)
comment:1 by , 11 years ago
|Component:||default → GDAL_Raster|
|Status:||new → assigned|
by , 11 years ago
Small Geotiff file demonstrating the problem.
comment:2 by , 11 years ago
The problem is that the CheckCitationKeyForStatePlaneUTM() method is setting the SRS based on a matching state plane PCS name and circumventing the normal setting based on EPSG logic.
At the very least we need to add the EPSG authority codes when appropriate.
But I don't really understand why we are going through this code path when we have perfectly good EPSG WKT we can use. Is the goal of this function to establish an SRS based on a name matching a PE string when we don't otherwise have a full definition? Or is it intended to ensure we use PE names for the projected SRS so PE recognising the SRS? It seems like the function is doing a lot of things and some of the cases might not make sense to apply outside of ESRI but I'm not sure which.
Robin / Gao - could someone from ESRI comment on what you guys need in this situation?
comment:3 by , 11 years ago
I believe this mostly for dealing with legacy Esri/ERDAS style citation strings. We should be able to handle EPSG WKT if present and fallback to PE - I'm not sure if there is a need to provide exact citation names to PE (we aren't doing so for other cases).
Xiuguang should be able to provide concrete details.
comment:4 by , 11 years ago
Is that any update on that issue folks?
comment:5 by , 11 years ago
I mean "Is *there* ..." Thanks.
comment:6 by , 11 years ago
I would like to point out that if we add the EPGS code 26943 to the regression test script http://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/tiff_srs.py#L88 that will fail.
That means that this problem is independent from data sample.
Note that by removing all the esri_* files from the GDAL_DATA folder the problem disappears.
Gao, would that be the case that those esri_* files are only useful on ESRI software? If that is true we could change GDAL's "make install" to avoid copying those files to the data folder and add an "make install-esri" that does. Does it looks like a solution?
Frank, may I go ahead and add the code 26943 to the regression test? That would help us to trac that issue in the future.
comment:7 by , 11 years ago
Ivan, please do. I'm also hoping to work on this bug this afternoon.
comment:8 by , 11 years ago
|Status:||assigned → closed|
comment:9 by , 11 years ago
Frank, it seems to be working fine now. Thanks.
For reference the file in question has this listgeo report:
and this gdalinfo SRS:
It is not clear why the authority node is not present.