<!DOCTYPE html><html><head><title></title></head><body><div>Thanks for offering to take a look. I have a working draft already, but I'm not sure if I'm taking the right approach and could use a review.</div><div><br></div><div>The signature translation itself is the easy part. The C# binding in osr.i was an almost perfect example, and this is what I changed it to:</div><div><br></div><div> #ifdef SWIGJAVA</div><div> OSRSpatialReferenceShadow** FindMatches( char** options, int* nvalues, int** confidence_values )</div><div> {</div><div> return (OSRSpatialReferenceShadow**) OSRFindMatches(self, options, nvalues, confidence_values);</div><div> }</div><div> #endif</div><div><br></div><div>Everything interesting (haha, challenging) turned out to be in typemaps_java.i, getting SWIG to actually expose that return value and the two output parameters sensibly in Java. I haven't used swig in a long time, so I had forgotten most of the incantations. Llm to the rescue.</div><div><br></div><div>Here is the addition to typemaps_java.i:</div><div>== start ==</div><div>%typemap(in,numinputs=0) int* nvalues (int nMatches = 0)</div><div>{</div><div> /* %typemap(in,numinputs=0) int* nvalues */</div><div> $1 = &nMatches;</div><div>}</div><div><br></div><div>%typemap(in) int** confidence_values (int* panConfidence = NULL)</div><div>{</div><div> /* %typemap(in) int** confidence_values. Ignore the input, </div><div> keep $input around so argout can write the real</div><div> result into element [0]. */</div><div> $1 = &panConfidence;</div><div>}</div><div><br></div><div>%typemap(argout) int** confidence_values</div><div>{</div><div> /* %typemap(argout) int** confidence_values will fill the caller's int[][] */</div><div> if ($input && jenv->GetArrayLength($input) >= 1) {</div><div> jintArray confArray = jenv->NewIntArray(nMatches3);</div><div> jenv->SetIntArrayRegion(confArray, 0, nMatches3, (jint*)panConfidence4);</div><div> jenv->SetObjectArrayElement($input, 0, confArray);</div><div> jenv->DeleteLocalRef(confArray);</div><div> }</div><div> CPLFree(panConfidence4);</div><div>}</div><div><br></div><div>%typemap(jni) int** confidence_values "jobjectArray"</div><div>%typemap(jtype) int** confidence_values "int[][]"</div><div>%typemap(jstype) int** confidence_values "int[][]"</div><div>%typemap(javain) int** confidence_values "$javainput"</div><div><br></div><div>%typemap(out) (OSRSpatialReferenceShadow**)</div><div>{<br></div><div> const jclass srsClass = jenv->FindClass("org/gdal/osr/SpatialReference");</div><div> const jmethodID srsCtor = jenv->GetMethodID(srsClass, "<init>", "(JZ)V");</div><div><br></div><div> jresult = jenv->NewObjectArray(nMatches3, srsClass, NULL);</div><div> for (int i = 0; i < nMatches3; i++) {</div><div> OSRReference(result[i]);</div><div> jobject srsObj = jenv->NewObject(srsClass, srsCtor, (jlong)result[i], (jboolean)true);</div><div> jenv->SetObjectArrayElement(jresult, i, srsObj);</div><div> jenv->DeleteLocalRef(srsObj);</div><div> }</div><div> OSRFreeSRSArray(result);</div><div>}</div><div><br></div><div>%typemap(jni) OSRSpatialReferenceShadow** "jobjectArray"</div><div>%typemap(jtype) OSRSpatialReferenceShadow** "org.gdal.osr.SpatialReference[]"</div><div>%typemap(jstype) OSRSpatialReferenceShadow** "org.gdal.osr.SpatialReference[]"</div><div>%typemap(javaout) OSRSpatialReferenceShadow** {</div><div> return $jnicall;</div><div> }<br></div><div>== end ==</div><div><br></div><div>The nvalues argument stays hidden (numinputs=0), while confidence_values becomes visible as an int[][] out-box, following the same caller-passes-a-1-element-array-and-we-fill-it idiom already used elsewhere in typemaps_java.i (the GDALDimensionHS** pattern was the model here).</div><div><br></div><div>SWIG auto-suffixes typemap-declared local variables with the argument's position in the full parameter list to avoid collisions. FOr example, a variable I declared as (int nMatches = 0) inside the nvalues typemap (argument position 3) actually gets emitted into the generated code as nMatches3, not nMatches. This isn't visible from the .i source at all, I only found it by examining the generated osr_wrap.cpp after a failed compile. Any other typemap block that needs to reference that same variable (the argout/out blocks) has to hardcode the anticipated suffixed name directly because SWIG doesn't rewrite references for you.</div><div><br></div><div>End result:</div><div><br></div><div> public SpatialReference[] FindMatches(Vector options, int[][] confidenceValuesOut)</div><div><br></div><div>The function returns an array of matches (SpatialReference[] as OSRSpatialReferenceShadow**), which is the primary thing that you want to get from this function.</div><div><br></div><div>How to use:</div><div> int[][] confidence = new int[1][];</div><div> SpatialReference[] matches = srs.FindMatches(null, confidence);</div><div> int[] confidenceValues = confidence[0];</div><div><br></div><div>Patched against the current master. Tested on against an esri shapefile .prj (ESRI-dialect NAD83 / UTM zone 11N WKT) that AutoIdentifyEPSG() fails on with 'Unsupported SRS' -- FindMatches() correctly returns a single match, EPSG:26911, with confidence[0][0] = 100, matching projinfo --identify exactly on the same input. Not tested any further than that.</div><div><br></div><div>How does this look so far? Is this going in the right direction? If so, what would it take to turn this into an acceptable PR?</div><div><br></div><div>Thanks again for your help, and full disclosure, thanks to llm for significant assistance on this.</div><div>Tom</div><div><br></div><div>On Thu, Aug 13, 2026, at 5:16 PM, Barry DeZonia wrote:</div><blockquote type="cite" id="qt" style=""><div dir="ltr"><div>AI is helping me remember</div><div><br></div><div>for the FindMatches() routine would you want it matching as close as possible C types or would you want a simplified API for Java that mogt communicate info via an array of strings (or one formatted string). Sorry if that sounds out of left field.</div><div><br></div><div>One AI said this:</div><div><div class="qt-gmail-otQkpb" role="heading" style="font-family:"Google Sans", Roboto, sans-serif;font-size:20px;font-weight:600;margin-top:24px;margin-right:0px;margin-bottom:12px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);">2. Handle Java JNI Typemaps</div><div class="qt-gmail-n6owBd qt-gmail-awi2gc" style="font-family:"Google Sans", Roboto, sans-serif;font-size:16px;margin-top:12px;margin-right:0px;margin-bottom:16px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);">Because <code dir="ltr" class="qt-gmail-KDcb0c" style="font-size:14px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0.571429px;border-bottom-style:solid;border-bottom-color:rgb(240, 242, 245);">int**</code> and object arrays (<code dir="ltr" class="qt-gmail-KDcb0c" style="font-size:14px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0.571429px;border-bottom-style:solid;border-bottom-color:rgb(240, 242, 245);">OSRSpatialReferenceShadow***</code>) do not map cleanly to standard Java types, you must ensure your SWIG configuration or a companion helper helper translates them into manageable objects on the Java side.</div><div class="qt-gmail-n6owBd qt-gmail-awi2gc" style="font-family:"Google Sans", Roboto, sans-serif;font-size:16px;margin-top:12px;margin-right:0px;margin-bottom:16px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);">Alternatively, if dealing with direct pointer manipulation via SWIG typemaps is too complex, developers routinely implement a <span class="qt-gmail-rQesXe qt-gmail-MPyX" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);"><b>custom C++ wrapper function</b></span> inside <code dir="ltr" class="qt-gmail-KDcb0c" style="font-size:14px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0.571429px;border-bottom-style:solid;border-bottom-color:rgb(240, 242, 245);">osr.i</code> that bundles the results into a string format (such as an array of matching EPSG strings and confidences) before passing it over the JNI boundary:</div><div class="qt-gmail-yhAwj" style="font-family:"Google Sans", Roboto, sans-serif;font-size:14px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);"><br></div><div class="qt-gmail-r1PmQe" style="font-family:"Google Sans", Roboto, sans-serif;font-size:14px;margin-top:4px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);"><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);"><div class="qt-gmail-pHpOfb" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0.571429px;border-bottom-style:solid;border-bottom-color:rgb(240, 242, 245);"><div class="qt-gmail-z0e9Qd" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);"><div class="qt-gmail-vVRw1d" style="font-size:20px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);">swig</div></div><div class="qt-gmail-pCTyYe" dir="ltr" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);"><pre style="margin-top:14px;margin-right:0px;margin-bottom:14px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);"><code style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);"><span class="qt-gmail-undefined" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;border-bottom-width:0px;border-bottom-style:none;border-bottom-color:rgb(22, 23, 26);">%extend OSRSpatialReferenceShadow {
// A simplified wrapper returning matches as formatted string arrays to avoid pointer hell
char** FindMatchesSimple(char** options) {
int nEntries = 0;
int* panConfidence = NULL;
OGRSpatialReferenceH* pahSRS = OGRSpatialReference_FindMatches(self, options, &nEntries, &panConfidence);
char** papszResult = NULL;
// Construct a structured string array containing "EPSG:Code,Confidence"
for(int i = 0; i < nEntries; i++) {
const char* pszAuthName = OGRSpatialReference_GetAttrValue(pahSRS[i], "AUTHORITY", 0);
const char* pszAuthCode = OGRSpatialReference_GetAttrValue(pahSRS[i], "AUTHORITY", 1);
// Format string logic, append to papszResult...<br> // BDZ - TODO - NOTE - This is the real work needed to finish this method.
}
OSRFreeSRSArray(pahSRS);
CPLFree(panConfidence);
return papszResult;
}
}</span></code></pre></div></div></div></div></div></div><div><br></div><div class="qt-gmail_quote qt-gmail_quote_container"><div dir="ltr" class="qt-gmail_attr">On Thu, Aug 13, 2026 at 3:08 PM Barry DeZonia <<a href="mailto:bdezonia@gmail.com">bdezonia@gmail.com</a>> wrote:</div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div dir="ltr">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.</div><div><br></div><div class="qt-gmail_quote"><div dir="ltr" class="qt-gmail_attr">On Thu, Aug 13, 2026 at 6:53 AM Even Rouault via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>> wrote:</div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div><u></u><br></div><div><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>Le 13/08/2026 à 13:15, Tom Moore via
gdal-dev a écrit :</div><blockquote type="cite"><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>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" target="_blank">ghcr.io/osgeo/gdal:ubuntu-small-latest</a> container and running `gdalsrsinfo -e` against the same .prj
file. It resolved to <a>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>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" target="_blank">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" target="_blank">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>EPSG:6269</a>,
but the top-level PROJCS never gets an ID).</div><div>- <a href="https://github.com/OSGeo/gdal/issues/2303" target="_blank">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>_______________________________________________
gdal-dev mailing list
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre></blockquote><pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">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></div><div>_______________________________________________</div><div> gdal-dev mailing list</div><div> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a></div><div> <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div></blockquote></div></blockquote></div></blockquote><div><br></div><div id="sig151763583"><div class="signature">--</div><div class="signature">Tom Moore</div><div class="signature">Spatial Planning Systems</div><div class="signature">960 Burkes Bluff Lane</div><div class="signature">Deep River ON K0J 1P0</div><div class="signature">Canada</div><div class="signature"><br></div><div class="signature">Phone: +1 613 584 9354</div></div><div><br></div></body></html>