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]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
