[gdal-dev] Achieving Better WKT -> EPSG Code Autodetection When Importing Layers to Postgis

Even Rouault even.rouault at spatialys.com
Sat Sep 23 02:19:55 PDT 2017


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170923/1f4545a0/attachment-0001.html>


More information about the gdal-dev mailing list