Re: AutoIdentifyEPSG() fails on standard ESRI-dialect NAD83/UTM .prj (proj_identify succeeds); FindMatches() also missing from Java bindings

Tom,

yes FindMatches() is what is needed for your use case and it is not 
currently available in the Java bindings. That would require someone to 
write the appropriate typemap(s) to map the C types to Java types.

Even

Le 13/08/2026 à 13:15, Tom Moore via gdal-dev a écrit :
> 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 
> <http://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

-- 
http://www.spatialys.com
My software is free, but my time generally not.
LLMs contribute to global warming and brain rot.
Let's guillotine them! "Ah ! ça ira, ça ira, ça ira !"

_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev