[gdal-dev] compiling gdal with esri file gdb

[Even Rouault]

On samedi 11 mars 2017 07:18:47 CET Richard Greenwood wrote:
> On Sat, Mar 11, 2017 at 3:49 AM, fuadjsh at gmail.com <fuadjsh at gmail.com>
> 
> wrote:
> > gisinternals.org has Gdal for Windows with file geodatabase support
> 
> I don't see gdal 2.2 on gisinternals and I believe I need 2.2+ for curves
> in ESRI file geodatabases. Are you able to extract curves?

Here : http://gisinternals.com/development.php

2.2 is not yet released, so you need to fetch the development version (2.2.0dev)

> 
> Thanks,
> Rich
> 
> > 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).
> > 
> > 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.greenwood at 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.rouault at 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.rouault at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170311/59b7fdd2/attachment-0001.html>