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]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 >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
