Hi all,
I'm running into a case where SpatialReference.AutoIdentifyEPSG() fails on a
completely standard, well-formed ESRI-dialect .prj file, even though the
underlying PROJ identification machinery (proj_identify(), as exercised via
"projinfo --identify") resolves it correctly with 100% confidence. I'd like to
know whether this is a known limitation, and whether there's a recommended
workaround for Java bindings users specifically, since FindMatches() isn't
exposed there.
Environment:
- GDAL 3.11.1 (Windows build)
- PROJ 9.6.2
- Java bindings (org.gdal.osr / SWIG)
Input WKT (contents of a shapefile .prj, ESRI dialect):
PROJCS["NAD_1983_UTM_Zone_11N",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-117.0],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]
QGIS correctly identifies this as EPSG:26911.
What I tried (Java):
SpatialReference srs = new SpatialReference();
srs.ImportFromESRI(lines); // also tried plain ImportFromWkt() but got
the same result
srs.SetAxisMappingStrategy(osrConstants.OAMS_TRADITIONAL_GIS_ORDER);
try {
srs.AutoIdentifyEPSG();
} catch (Exception ex) {
System.out.println("Exception: " + ex.getMessage());
}
System.out.println("code = " + srs.GetAuthorityCode(null));
Result:
Exception: OGR Error: Unsupported SRS
code = null
gdal.GetLastErrorType() / GetLastErrorMsg() are empty. No additional
diagnostic detail is surfaced beyond the generic exception.
I ruled out several things before suspecting this is a AutoIdentifyEPSG()
limitation rather than an environment/config issue on my end:
1. proj.db itself is correct. Confirmed by mounting the exact same proj.db
(from the PROJ 9 data directory used by my JAva app) into a clean
ghcr.io/osgeo/gdal:ubuntu-small-latest container and running `gdalsrsinfo -e`
against the same .prj file. It resolved to EPSG:26911 correctly, full WKT2 with
all authority IDs.
2. PROJ_LIB / PROJ_DATA environment variables are set correctly and confirmed
using System.getenv() to be visible to the process
3. Tried MorphFromESRI() (both via ImportFromESRI() alone, and combined with an
explicit MorphFromESRI() call) - no change.
4. Tried explicit SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER) before
calling AutoIdentifyEPSG() - no change.
5. Ran the projinfo.exe from the gdal build that I am using with the Java app
directly against the same .prj file:
projinfo.exe --identify fmu.prj
...
Identification match count: 1
EPSG:26911: 100 %
So proj_identify() / FindMatches()-equivalent logic resolves this WKT perfectly
in the exact same native build, but AutoIdentifyEPSG() fails on it.
This looks consistent with a few things I found in the tracker/mailing list
archives while investigating:
- https://trac.osgeo.org/gdal/ticket/6188 -- maintainer comment noting
AutoIdentifyEPSG() has "very limited capabilities" and would need fuzzy
matching to handle inexact datum/ellipsoid names, "especially when dealing with
WKT coming from ESRI."
- https://github.com/OSGeo/gdal/issues/4038 -- near-identical repro WKT
(ESRI-dialect UTM), with a maintainer noting AutoIdentifyEPSG() can return
OGRERR_UNSUPPORTED_SRS while having still injected partial AUTHORITY tags into
sub-nodes. This matches what I see when printing the WKT after the failed call
(DATUM gets EPSG:6269, but the top-level PROJCS never gets an ID).
- https://github.com/OSGeo/gdal/issues/2303 -- shows the standard Python
workaround (fall back to FindMatches() when AutoIdentifyEPSG() fails), which
leads to my second question below.
Questions:
1. Is AutoIdentifyEPSG() failing on this ESRI-dialect NAD83/UTM WKT a known
limitation, or does this look like a genuine regression/bug worth filing?
2. FindMatches() does not appear to be exposed in the Java SWIG bindings
(org.gdal.osr.SpatialReference). Is that correct, or am I missing something?
If it's genuinely absent, is there any appetite for adding it, given it's the
documented fallback for exactly this situation in other language bindings?
3. Short of shelling out to "projinfo --identify" as a subprocess, is there a
recommended in-process approach for Java bindings users to reach the same
identification logic?
Happy to provide a minimal reproducible test case / file a tracker issue if
that's useful, but I wanted to check here first in case this is already
understood behavior.
Thanks,
Tom
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
