<!DOCTYPE html><html><head><title></title></head><body><div>I have submitted a pull request for my draft solutions. </div><div><a href="https://github.com/OSGeo/gdal/pull/15033">https://github.com/OSGeo/gdal/pull/15033</a></div><div><br></div><div>It is probably a good idea to switch the discussion of this issue to github.</div><div>Tom</div><div><br></div><div><br></div><div>On Thu, Aug 13, 2026, at 7:53 AM, Even Rouault wrote:</div><blockquote type="cite" id="qt" style=""><p>Tom,</p><p>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.</p><p>Even</p><div class="qt-moz-cite-prefix">Le 13/08/2026 à 13:15, Tom Moore via
gdal-dev a écrit :</div><blockquote type="cite" cite="mid:9c159c4a-7202-40c7-9058-696a3a041c62@app.fastmail.com"><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 <a class="qt-moz-txt-link-freetext">EPSG:26911</a>.</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 <a class="qt-moz-txt-link-freetext">EPSG:26911</a> 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> <a class="qt-moz-txt-link-freetext">EPSG:26911</a>: 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" class="qt-moz-txt-link-freetext">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" class="qt-moz-txt-link-freetext">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 <a class="qt-moz-txt-link-freetext">EPSG:6269</a>,
but the top-level PROJCS never gets an ID).</div><div>- <a href="https://github.com/OSGeo/gdal/issues/2303" class="qt-moz-txt-link-freetext">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><div><br></div><pre class="qt-moz-quote-pre">_______________________________________________
gdal-dev mailing list
<a class="qt-moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="qt-moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre></blockquote><pre class="qt-moz-signature" cols="72">--
<a class="qt-moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
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 !"</pre></blockquote><div><br></div><div id="sig151763583"><div><br></div></div><div><br></div></body></html>