It works fine
Fuad
-------- Original Message --------
Subject: Re: [gdal-dev] compiling gdal with esri file gdb
From: Damian Dixon
To: Richard Greenwood
CC: GDAL List
Have you tried OpenFileGDB? (you will need GDAL 2.2 or newer for curve geometries).We have switched to OpenFileGDB because ESRI don't have their library available on Windows built against VS2015. Which also means we did not bother with the ESRI libraries on Linux either.The other option is to use GDAL on Windows to convert the file. The way shared libraries work on Windows means that the proj4 issue you are seeing on Linux should not occur.I don't know where you would get a Windows build of GDAL with FileGDB enabled. Someone on the list probably does.On 11 March 2017 at 00:05, Richard Greenwood <richard.greenw...@gmail.com> wrote:If any of you can share any pointers on how to even get it to compile I'd appreciate it. I just need to access a esri file geodatabase that has curves and see if I can get them into postgis. If I have to have a separate build of gdal just for that I don't care. But I'm not too good with compiling gdal with 3rd party libraries.Thanks,RichOn Fri, Mar 10, 2017 at 10:16 AM, Even Rouault <even.roua...@spatialys.com> wrote:______________________________On vendredi 10 mars 2017 12:57:05 CET Robert Coup wrote:
> Hi Even,
>
> On 9 March 2017 at 23:03, Even Rouault <even.roua...@spatialys.com> wrote:
> > For those, at least on Linux, and which use GDAL compiled *without*
> > --with-static-proj, you may get strange projection related failures at
> > runtime. This is due to libFileGDBAPI.so embedding a copy of proj.4
> > (without symbol hidding or renaming !!!), which conflicts with the proj.4
> > that GDAL will load dlopen(). Typical error emitted is about "unknown
> > ellipsoid".
>
> I presume there's no workaround apart from --with-static-proj that doesn't
> require ESRI to change their build process?
Hi Rob,
Yeah, I'm not even sure if --with-static-proj (which contrary to what its name my suggst will link against libproj.so if found) is completely safe, but it did work for me.
Strangely, even without --with-static-proj, it worked for me at first, but then failed when I probably reordered paths in my LD_LIBRARY_PATH. But I'm not so surprised: clashing symbols issues tend to be not predictable.
In fact, libFileGDBAPI.so doesn't seem to embed all public proj.4 symbols. The functions are missing. But 5 or 6 global array structures, like the list of datums (pj_datums) are exposed in the data read-only section. The issue is that pj_datums doesn't seem to have the same structure: 2 columns per record in the ESRI version whereas official proj.4 expects 4 columns
$ objdump -T /home/even/FileGDB_API-64gcc51
/lib/libFileGDBAPI.so | grep pj_ 00000000010dc880 g DO .data.rel.ro 00000000000000b0 Base pj_datums
0000000001294080 g DO .data.rel.ro 0000000000000570 Base pj_projections
00000000010dbd20 g DO .data.rel.ro 0000000000000500 Base pj_pids
00000000010dc7a0 g DO .data.rel.ro 00000000000000e0 Base pj_primems
00000000010dc380 g DO .data.rel.ro 0000000000000420 Base pj_ellipses
00000000010dc220 g DO .data.rel.ro 0000000000000160 Base pj_linunits
Even
--
Spatialys - Geospatial professional services
_________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev --Richard W. Greenwood, PLS
www.greenwoodmap.com
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
