> I've had this issue for years, but concede I might be missing something. Is > there anything that can remedy this issue utilizing existing functionality?
No need for a complicated thing like a JNI bridge, but someone has to code it in GDAL. All the basic functionnality is there. Just needs to be put together. A basic approach would be to iterate over the EPSG codes from the gcs.csv and pcs.csv files, use importFromEPSG() and compare the resulting WKT with the user WKT. Some fuzzing would be needed to be robust to slight naming variations, etc. This was actually an idea for a GSoc project, but anyone is free to pick it up and bring his/her contribution. In the .prj you pointed, prj2epsg first suggestion, EPSG:32139, is actually completely inappropriate given it uses meter as linear unit, whereas the .prj uses foot_us. EPSG:2277 looks to be the exact match. And another interesting thing is that the .prj has Standard_Parallel_1 = 30.11666666666667 and Standard_Parallel_2 = 31.88333333333333. Whereas EPSG:2277 has them in the reverse order. Which is equivalent mathematically, but a matcher should be aware of that equivalence. So not completely a trivial task. Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
