On Fri, Aug 14, 2026 at 5:58 AM <[email protected]> wrote:
> Send gdal-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osgeo.org/mailman/listinfo/gdal-dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gdal-dev digest..." > > > Today's Topics: > > 1. Re: AutoIdentifyEPSG() fails on standard ESRI-dialect > NAD83/UTM .prj (proj_identify succeeds); FindMatches() also > missing from Java bindings (Barry DeZonia) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 13 Aug 2026 19:28:00 -0500 > From: Barry DeZonia <[email protected]> > To: Tom Moore <[email protected]> > Cc: Even Rouault <[email protected]>, > [email protected] > Subject: Re: [gdal-dev] AutoIdentifyEPSG() fails on standard > ESRI-dialect NAD83/UTM .prj (proj_identify succeeds); FindMatches() > also missing from Java bindings > Message-ID: > <CAKcvfuT0AFzHboG8uiWwkGZ6MowhfjUUtQZPB4gvBmeX= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > One maybe nonsense question: where does panConfidence4 come from? Are you > using an undeclared variable? > > On Thu, Aug 13, 2026 at 7:24?PM Barry DeZonia <[email protected]> wrote: > > > My foggy memory tells me that this looks good. I will let you and > > Even figure out the PR issue. > > > > On Thu, Aug 13, 2026 at 6:56?PM Tom Moore <[email protected]> wrote: > > > >> 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. > >> > >> 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: > >> > >> #ifdef SWIGJAVA > >> OSRSpatialReferenceShadow** FindMatches( char** options, int* > >> nvalues, int** confidence_values ) > >> { > >> return (OSRSpatialReferenceShadow**) OSRFindMatches(self, > >> options, nvalues, confidence_values); > >> } > >> #endif > >> > >> 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. > >> > >> Here is the addition to typemaps_java.i: > >> == start == > >> %typemap(in,numinputs=0) int* nvalues (int nMatches = 0) > >> { > >> /* %typemap(in,numinputs=0) int* nvalues */ > >> $1 = &nMatches; > >> } > >> > >> %typemap(in) int** confidence_values (int* panConfidence = NULL) > >> { > >> /* %typemap(in) int** confidence_values. Ignore the input, > >> keep $input around so argout can write the real > >> result into element [0]. */ > >> $1 = &panConfidence; > >> } > >> > >> %typemap(argout) int** confidence_values > >> { > >> /* %typemap(argout) int** confidence_values will fill the caller's > >> int[][] */ > >> if ($input && jenv->GetArrayLength($input) >= 1) { > >> jintArray confArray = jenv->NewIntArray(nMatches3); > >> jenv->SetIntArrayRegion(confArray, 0, nMatches3, > >> (jint*)panConfidence4); > >> jenv->SetObjectArrayElement($input, 0, confArray); > >> jenv->DeleteLocalRef(confArray); > >> } > >> CPLFree(panConfidence4); > >> } > >> > >> %typemap(jni) int** confidence_values "jobjectArray" > >> %typemap(jtype) int** confidence_values "int[][]" > >> %typemap(jstype) int** confidence_values "int[][]" > >> %typemap(javain) int** confidence_values "$javainput" > >> > >> %typemap(out) (OSRSpatialReferenceShadow**) > >> { > >> const jclass srsClass = > >> jenv->FindClass("org/gdal/osr/SpatialReference"); > >> const jmethodID srsCtor = jenv->GetMethodID(srsClass, "<init>", > >> "(JZ)V"); > >> > >> jresult = jenv->NewObjectArray(nMatches3, srsClass, NULL); > >> for (int i = 0; i < nMatches3; i++) { > >> OSRReference(result[i]); > >> jobject srsObj = jenv->NewObject(srsClass, srsCtor, > (jlong)result[i], > >> (jboolean)true); > >> jenv->SetObjectArrayElement(jresult, i, srsObj); > >> jenv->DeleteLocalRef(srsObj); > >> } > >> OSRFreeSRSArray(result); > >> } > >> > >> %typemap(jni) OSRSpatialReferenceShadow** "jobjectArray" > >> %typemap(jtype) OSRSpatialReferenceShadow** > >> "org.gdal.osr.SpatialReference[]" > >> %typemap(jstype) OSRSpatialReferenceShadow** > >> "org.gdal.osr.SpatialReference[]" > >> %typemap(javaout) OSRSpatialReferenceShadow** { > >> return $jnicall; > >> } > >> == end == > >> > >> 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). > >> > >> 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. > >> > >> End result: > >> > >> public SpatialReference[] FindMatches(Vector options, int[][] > >> confidenceValuesOut) > >> > >> The function returns an array of matches (SpatialReference[] as > >> OSRSpatialReferenceShadow**), which is the primary thing that you want > to > >> get from this function. > >> > >> How to use: > >> int[][] confidence = new int[1][]; > >> SpatialReference[] matches = srs.FindMatches(null, confidence); > >> int[] confidenceValues = confidence[0]; > >> > >> 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. > >> > >> 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? > >> > >> Thanks again for your help, and full disclosure, thanks to llm for > >> significant assistance on this. > >> Tom > >> > >> On Thu, Aug 13, 2026, at 5:16 PM, Barry DeZonia wrote: > >> > >> AI is helping me remember > >> > >> 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. > >> > >> One AI said this: > >> 2. Handle Java JNI Typemaps > >> Because int** and object arrays (OSRSpatialReferenceShadow***) 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. > >> Alternatively, if dealing with direct pointer manipulation via SWIG > >> typemaps is too complex, developers routinely implement a *custom C++ > >> wrapper function* inside osr.i 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: > >> > >> swig > >> > >> %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... > >> // BDZ - TODO - NOTE - This is the real work needed to > finish this method. > >> } > >> > >> OSRFreeSRSArray(pahSRS); > >> CPLFree(panConfidence); > >> return papszResult; > >> } > >> } > >> > >> > >> On Thu, Aug 13, 2026 at 3:08?PM Barry DeZonia <[email protected]> > wrote: > >> > >> 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]:// > 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 > >> > >> > >> -- > >> Tom Moore > >> Spatial Planning Systems > >> 960 Burkes Bluff Lane > >> Deep River ON K0J 1P0 > >> Canada > >> > >> Phone: +1 613 584 9354 > >> > >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260813/1850b865/attachment.htm > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > ------------------------------ > > End of gdal-dev Digest, Vol 267, Issue 6 > **************************************** >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
