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

I could maybe help here but, good god, it's been a long time since I've
worked on the Java bindings and I remember almost nothing. Maybe if I
inspect the Java bindings code I will remember some stuff. Naively, the
function signature looks pretty simple to translate.

On Thu, Aug 13, 2026 at 6:53 AM Even Rouault via gdal-dev <
[email protected]> wrote:

> 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 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 [email protected]://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
>

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