<!DOCTYPE html><html><head><title></title></head><body><div>Hi all,</div><div><br></div><div>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.</div><div><br></div><div>Environment:</div><div>- GDAL 3.11.1 (Windows build)</div><div>- PROJ 9.6.2</div><div>- Java bindings (org.gdal.osr / SWIG)</div><div><br></div><div>Input WKT (contents of a shapefile .prj, ESRI dialect):</div><div><br></div><div>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]]</div><div><br></div><div>QGIS correctly identifies this as EPSG:26911.</div><div><br></div><div>What I tried (Java):</div><div><br></div><div> SpatialReference srs = new SpatialReference();</div><div> srs.ImportFromESRI(lines); // also tried plain ImportFromWkt() but got the same result</div><div> srs.SetAxisMappingStrategy(osrConstants.OAMS_TRADITIONAL_GIS_ORDER);</div><div><br></div><div> try {</div><div> srs.AutoIdentifyEPSG();</div><div> } catch (Exception ex) {</div><div> System.out.println("Exception: " + ex.getMessage());</div><div> }</div><div> System.out.println("code = " + srs.GetAuthorityCode(null));</div><div><br></div><div>Result:</div><div><br></div><div> Exception: OGR Error: Unsupported SRS</div><div> code = null</div><div><br></div><div>gdal.GetLastErrorType() / GetLastErrorMsg() are empty. No additional diagnostic detail is surfaced beyond the generic exception.</div><div><br></div><div>I ruled out several things before suspecting this is a AutoIdentifyEPSG() limitation rather than an environment/config issue on my end:</div><div><br></div><div>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 <a href="http://ghcr.io/osgeo/gdal:ubuntu-small-latest">ghcr.io/osgeo/gdal:ubuntu-small-latest</a> container and running `gdalsrsinfo -e` against the same .prj file. It resolved to EPSG:26911 correctly, full WKT2 with all authority IDs.</div><div>2. PROJ_LIB / PROJ_DATA environment variables are set correctly and confirmed using System.getenv() to be visible to the process</div><div>3. Tried MorphFromESRI() (both via ImportFromESRI() alone, and combined with an explicit MorphFromESRI() call) - no change.</div><div>4. Tried explicit SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER) before calling AutoIdentifyEPSG() - no change.</div><div>5. Ran the projinfo.exe from the gdal build that I am using with the Java app directly against the same .prj file:</div><div><br></div><div> projinfo.exe --identify fmu.prj</div><div> ...</div><div> Identification match count: 1</div><div> EPSG:26911: 100 %</div><div><br></div><div>So proj_identify() / FindMatches()-equivalent logic resolves this WKT perfectly in the exact same native build, but AutoIdentifyEPSG() fails on it.</div><div><br></div><div>This looks consistent with a few things I found in the tracker/mailing list archives while investigating:</div><div><br></div><div>- <a href="https://trac.osgeo.org/gdal/ticket/6188">https://trac.osgeo.org/gdal/ticket/6188</a> -- 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." </div><div>- <a href="https://github.com/OSGeo/gdal/issues/4038">https://github.com/OSGeo/gdal/issues/4038</a> -- 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).</div><div>- <a href="https://github.com/OSGeo/gdal/issues/2303">https://github.com/OSGeo/gdal/issues/2303</a> -- shows the standard Python workaround (fall back to FindMatches() when AutoIdentifyEPSG() fails), which leads to my second question below.</div><div><br></div><div>Questions:</div><div><br></div><div>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?</div><div>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?</div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Tom</div><div><br></div></body></html>