Have you tried OpenFileGDB? (you will need GDAL 2.2 or newer for curve geometries).
See: http://www.gdal.org/drv_openfilegdb.html 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, > Rich > > > On 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 >> >> http://www.spatialys.com >> >> _______________________________________________ >> 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
