I have submitted a pull request for my draft solutions.
https://github.com/OSGeo/gdal/pull/15033
It is probably a good idea to switch the discussion of this issue to github.
Tom
On Thu, Aug 13, 2026, at 7:53 AM, Even Rouault 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 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
