You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Extract the SDK, and put the contents of the directory in a known location, I used ~/local/filegdb. Here's an example path to one of the files: ~/local/filegdb/lib/libFileGDBAPI.dylib
I use ~/local/filegdb so it can stay isolated in it's own place. You can put it anywhere, but the next few steps might be different.
Go into the directory containing the FileGDB SDK, e.g. ~/local/filegdb
ESRI built these dylib's using @rpath's, so to avoid needing to mess with DYLD_LIBRARY_PATH, I updated the @rpath's using install_name_tool. There might be a more elegant way to handle this. If so, comments are welcome!
Here are the commands I used to patch the dylibs, this is not required if you want to use DYLD_LIBRARY_PATH yourself:
The configure script has many options, here is the configure line I use for my custom build: https://gist.github.com/2005091, if you have other GDAL builds on your machine (e.g. homebrew) that you don't want to interfere with, I recommend at least using --prefix=~/local or some other place on your machine besides /usr/local (default for homebrew) or /opt/local (default for MacPorts).
If it worked properly, you should see in the output of configure indicating yes for FileGDB support
which ogr2ogr # make sure it's the correct ogr2ogr first
ogrinfo --formats # list out the formats
ogrinfo ~/Downloads/test_fgdb.gdb
#convert FileGDB directly to PostGIS
ogr2ogr -f "PostgreSQL" PG:"dbname='somedatabase' host='localhost' port='5432'" ~/Downloads/test_fgdb.gdb
Hmm. With version 10.gdb INFO: Open of /Users/me/TestGDAL.gdb' using driver FileGDB' successful. And won't work with .gdb's created in 9.3, as expected. But after following the symlink instructions, I fail adding in QGIS (What Type do you choose after selecting Directory button, btw?) and I cannot convert with ogr2ogr - - it gives no messages or anything, can't find a -flag for more verbose message.
There's a --debug flag you can pass to ogr2ogr that might print some information. Also, in QGIS I didn't select any format, so whatever is selected by default worked for me. I did get errors opening some files in QGIS, but I think they were 9.x gdb's. What format are you trying to convert to with ogr2ogr?
Here's output from my machine:
➜ ~ ogrinfo ~/Downloads/test_fgdb.gdb
INFO: Open of `/Users/zacmcc/Downloads/test_fgdb.gdb'
using driver `FileGDB' successful.
1: basetable_2 (None)
2: basetable (None)
3: base_table1 (None)
4: test_lines (3D Multi Line String)
5: more_test_lines (3D Multi Line String)
6: test_points (3D Point)
7: test_areas (3D Multi Polygon)
@rclark it would be technically possible to do, but I don't think it'd be accepted because the FileGDB API is available only in binary form and requires you to agree to a license. There are other GDAL plugins besides the GDB one that fall into the same category. See this section of the current formula: https://github.com/mxcl/homebrew/blob/master/Library/Formula/gdal.rb#L151
I just keep multiple versions of GDAL on my machine. I use /usr/local for the stable homebrew build and have a ~/local for all other custom built stuff (like this...) and use a shell script to edit my $PATH so I can select which GDAL I want to use.
Thanks for the info. I guess you could make your own gdal.rb too, and just keep it local. I'll have to look into that. Otherwise it sounds like you've got a good setup.
I was wondering if you had a chance to test this against the 1.9.1 or current svn branches? I was trying to build against the svn trunk today and was unable to get the filegdb api detected when running ./configure after applying the supplied configure.in.
I downloaded GDAL 1.9.1 and was able to get it built and working. I updated this gist with the new configure.in script. Note that you have to run ./autogen.sh after changing the configure.in file.
On May 24, 2012, at 13:46 , Zac McCormick wrote:
I downloaded GDAL 1.9.1 and was able to get it built and working. I updated this gist with the new `configure.in` script. Note that you have to run `./autogen.sh` after changing the `configure.in` file.
Here is the new configure.in for 1.9.1: https://gist.github.com/2784084
<pre>
➜ ~/local/src/gdal-1.9.1 ogrinfo --version
GDAL 1.9.1, released 2012/05/15
➜ ~/local/src/gdal-1.9.1 ogrinfo ~/Downloads/demo.gdb
INFO: Open of `/Users/zacmcc/Downloads/demo.gdb'
using driver `FileGDB' successful.
1: layer1 (Multi Polygon)
2: layer2 (Multi Polygon)
</pre>
---
Reply to this email directly or view it on GitHub:
https://gist.github.com/2005158
Thanks for this--it's exactly what I needed. However, I'm having trouble getting QGIS to work with the custom build of GDAL. GDAL builds successfully as it's able to open the test GDB. However, when I try to open QGIS, it crashes with the following error:
Dyld Error Message:
Library not loaded: /Library/Frameworks/GDAL.framework/Versions/1.9/GDAL
Referenced from: /Applications/QGIS.app/Contents/MacOS/QGIS
Reason: image not found
I checked and the symlink is pointing to the right place. Any ideas on what else to check? Thanks.
It looks like you're running the new version of QGIS (1.8) that wants the GDAL 1.9 Framework. Did you install the 1.9 framework and change the paths when doing the symlink stuff? I hadn't tested with QGIS 1.8 until now and it did work for me.
When I installed QGIS 1.8, I also installed the GDAL 1.9 Complete Framework from KyngChaos (it won't mess up your custom compiled GDAL...)
# save your current GDAL so you can put it back if you want
cp /Library/Frameworks/GDAL.framework/Versions/1.9/GDAL /Library/Frameworks/GDAL.framework/Versions/1.9/GDAL_orig
# symlink the custom GDAL build to the place QGIS looks
rm /Library/Frameworks/GDAL.framework/Versions/1.9/GDAL
ln -s ~/local/lib/libgdal.dylib /Library/Frameworks/GDAL.framework/Versions/1.9/GDAL
From the looks of the error, it seems like /Library/Frameworks/GDAL.framework/Versions/1.9/GDAL either doesn't exist, or isn't a dylib.
You can run otool -L /Library/Frameworks/GDAL.framework/Versions/1.9/GDAL and it should output all of the shared libraries it loads.
@zhm Thanks for the quick reply. I rebuilt GDAL, this time taking your advice to not mess with DYLD_LIBRARY_PATH and set filegdb_api paths explicitly. Now it works! Thanks for your help.
@rburhum: Your simplified approach does not work for me using the latest gdal formula with homebrew. This would be a nice and simple method, but the filegdb path is not getting picked up for some reason for me. I used the symlink approach, so maybe that is part of the problem. Also, gdal.rb changed in the past day or so to reflect new approaches for writing install formulae. This might also have something to do with it.
In the absence of this simplified approach, I have resorted to using a custom formula that performs the necessary patching. I use this statement for my homebrew install, assuming the custom gdal formula is in /usr/local/Library/Formula. I use the -v switch so I can verify desired file support is in place during the configuration phase of the install:
option 'complete', 'Use additional Homebrew libraries to provide more drivers.'
option 'with-postgres', 'Specify PostgreSQL as a dependency.'
option 'with-mysql', 'Specify MySQL as a dependency.'
option 'without-python', 'Build without Python support (disables a lot of tools).'
option 'enable-opencl', 'Build with OpenCL acceleration.'
option 'enable-armadillo', 'Build with Armadillo accelerated TPS transforms.'
option 'enable-unsupported', "Allow configure to drag in any library it can find. Invoke this at your own risk."
depends_on "postgresql" if postgres?
depends_on "mysql" if mysql?
Without Numpy, the Python bindings can't deal with raster data.
depends_on 'numpy' => :python unless no_python?
depends_on 'armadillo' if armadillo?
if complete?
# Raster libraries
depends_on "netcdf" # Also brings in HDF5
depends_on "jasper"
depends_on "poppler"
depends_on "webp"
depends_on "cfitsio"
depends_on "epsilon"
depends_on "libdap"
# Fix a bug in LibDAP detection and patch FileGDB support
def patches; DATA; end unless build.head?
# Vector libraries
depends_on "unixodbc" # OS X version is not complete enough
depends_on "xerces-c"
# Other libraries
depends_on "xz" # get liblzma compression algorithm library from XZutils
end
def options
[
['--complete', 'Use additional Homebrew libraries to provide more drivers.'],
['--with-postgres', 'Specify PostgreSQL as a dependency.'],
['--with-mysql', 'Specify MySQL as a dependency.'],
['--without-python', 'Build without Python support (disables a lot of tools).'],
['--enable-opencl', 'Build with OpenCL acceleration.'],
['--enable-armadillo', 'Build with Armadillo accelerated TPS transforms.']
]
end
# GDAL native backends.
"--with-pcraster=internal",
"--with-pcidsk=internal",
"--with-bsb",
"--with-grib",
"--with-pam",
# Backends supported by OS X.
"--with-libiconv-prefix=/usr",
"--with-libz=/usr",
"--with-png=#{(MacOS.version >= :mountain_lion) ? HOMEBREW_PREFIX : MacOS::X11.prefix}",
"--with-expat=/usr",
"--with-curl=/usr/bin/curl-config",
# Default Homebrew backends.
"--with-jpeg=#{HOMEBREW_PREFIX}",
"--with-jpeg12",
"--with-libtiff=#{HOMEBREW_PREFIX}",
"--with-geotiff=#{HOMEBREW_PREFIX}",
"--with-gif=#{HOMEBREW_PREFIX}",
"--with-sqlite3=#{HOMEBREW_PREFIX}",
"--with-freexl=#{HOMEBREW_PREFIX}",
"--with-spatialite=#{HOMEBREW_PREFIX}",
"--with-geos=#{HOMEBREW_PREFIX}/bin/geos-config",
# GRASS backend explicitly disabled. Creates a chicken-and-egg problem.
# Should be installed separately after GRASS installation using the
# official GDAL GRASS plugin.
"--without-grass",
"--without-libgrass"
]
# Optional Homebrew packages supporting additional formats.
supported_backends = %w[
liblzma
fgdb
cfitsio
hdf5
netcdf
jasper
xerces
odbc
dods-root
epsilon
webp
libkml
poppler
]
if complete?
supported_backends.delete 'liblzma'
supported_backends.delete 'fgdb'
args << '--with-liblzma=yes'
args << '--with-fgdb=/Users/jctull/sources/FileGDB_API'
args.concat supported_backends.map {|b| '--with-' + b + '=' + HOMEBREW_PREFIX}
else
args.concat supported_backends.map {|b| '--without-' + b} unless build.include? 'enable-unsupported'
end
# The following libraries are either proprietary, not available for public
# download or have no stable version in the Homebrew core that is
# compatible with GDAL. Interested users will have to install such software
# manually and most likely have to tweak the install routine.
#
# Podofo is disabled because Poppler provides the same functionality and
# then some.
unsupported_backends = %w[
gta
ogdi
fme
hdf4
openjpeg
ecw
kakadu
mrsid
jp2mrsid
mrsid_lidar
msg
oci
ingres
dwgdirect
idb
sde
podofo
rasdaman
]
args.concat unsupported_backends.map {|b| '--without-' + b} unless build.include? 'enable-unsupported'
# Database support.
args << (postgres? ? "--with-pg=#{HOMEBREW_PREFIX}/bin/pg_config" : '--without-pg')
args << (mysql? ? "--with-mysql=#{HOMEBREW_PREFIX}/bin/mysql_config" : '--without-mysql')
# Python is installed manually to ensure everything is properly sandboxed.
args << '--without-python'
# Scripting APIs that have not been re-worked to respect Homebrew prefixes.
#
# Currently disabled as they install willy-nilly into locations outside of
# the Homebrew prefix. Enable if you feel like it, but uninstallation may be
# a manual affair.
#
# TODO: Fix installation of script bindings so they install into the
# Homebrew prefix.
args << "--without-perl"
args << "--without-php"
args << "--without-ruby"
args << (opencl? ? '--with-opencl' : '--without-opencl')
args << (armadillo? ? '--with-armadillo=yes' : '--with-armadillo=no')
return args
end
def install
# Linking flags for SQLite are not added at a critical moment when the GDAL
# library is being assembled. This causes the build to fail due to missing
# symbols.
#
# Fortunately, this can be remedied using LDFLAGS.
ENV.append 'LDFLAGS', '-lsqlite3'
# Needed by libdap.
ENV.append 'CPPFLAGS', '-I/usr/include/libxml2' if complete?
# Reset ARCHFLAGS to match how we build.
if MacOS.prefer_64_bit?
ENV['ARCHFLAGS'] = "-arch x86_64"
else
ENV['ARCHFLAGS'] = "-arch i386"
end
system "echo 'It is necessary to use --env=std.'" unless build.head?
system "./autogen.sh" unless build.head?
system "./configure", *get_configure_args
system "make"
system "make install"
unless no_python?
# If setuptools happens to be installed, setup.py will cowardly refuse to
# install to anywhere that is not on the PYTHONPATH.
#
# Really setuptools, we're all consenting adults here...
python_lib = lib + which_python + 'site-packages'
ENV.append 'PYTHONPATH', python_lib
# setuptools is also apparently incapable of making the directory it's
# self
python_lib.mkpath
# `python-config` may try to talk us into building bindings for more
# architectures than we really should.
if MacOS.prefer_64_bit?
ENV.append_to_cflags '-arch x86_64'
else
ENV.append_to_cflags '-arch i386'
end
cd 'swig/python' do
system "python", "setup.py", "install_lib", "--install-dir=#{python_lib}"
bin.install Dir['scripts/*']
end
end
system 'make', 'man' if build.head?
system 'make', 'install-man'
# Clean up any stray doxygen files.
Dir[bin + '*.dox'].each { |p| rm p }
end
unless no_python?
def caveats
<<-EOS
This version of GDAL was built with Python support. In addition to providing
modules that makes GDAL functions available to Python scripts, the Python
binding provides ~18 additional command line tools.
Unless you are using Homebrew's Python, both the bindings and the
additional tools will be unusable unless the following directory is added to
the PYTHONPATH:
#{HOMEBREW_PREFIX}/lib/#{which_python}/site-packages
EOS
end
if test -r $with_openjpeg/include/openjpeg-1.99/openjpeg.h ; then
EXTRA_INCLUDES="-I$with_openjpeg/include/openjpeg-1.99 $EXTRA_INCLUDES"
elif test -r $with_openjpeg/include/openjpeg.h ; then
EXTRA_INCLUDES="-I$with_openjpeg/include $EXTRA_INCLUDES"
elif test -r $with_openjpeg/openjpeg.h ; then
EXTRA_INCLUDES="-I$with_openjpeg $EXTRA_INCLUDES"
else
AC_MSG_ERROR([openjpeg.h not found in $with_openjpeg/include or $with_openjpeg/include/openjpeg-2.0])
AC_MSG_ERROR([openjpeg.h not found in $with_openjpeg/include or $with_openjpeg/include/openjpeg-1.99])
fi
AC_CHECK_LIB(openjpeg,opj_decode_tile_data,HAVE_OPENJPEG=yes,HAVE_OPENJPEG=no,)
@@ -1710,15 +1710,39 @@ elif test "$with_fgdb" = "yes" -o "$with_fgdb" = "" ; then
rm -f testfgdb
else
case "${host_os}" in
darwin)
AC_MSG_CHECKING([for libFileGDBAPI.dylib in in $with_fgdb/lib])
FGDB_ENABLED=yes
if test -r $with_fgdb/lib/libFileGDBAPI.dylib ; then
AC_MSG_RESULT([found.])
AC_MSG_CHECKING([for libFileGDBAPI.so in in $with_fgdb/lib])
#AC_MSG_CHECKING([for libFileGDBAPI.so in in $with_fgdb/lib])
#FGDB_ENABLED=yes
#if test -r $with_fgdb/lib/libFileGDBAPI.so ; then
#AC_MSG_RESULT([found.])
#FGDB_LIB="-L$with_fgdb/lib -lFileGDBAPI"
#else
#AC_MSG_ERROR([not found.])
#fi
AC_MSG_CHECKING([for FileGDBAPI.h in $with_fgdb/include])
if test -r $with_fgdb/include/FileGDBAPI.h ; then
@@ -3415,6 +3453,10 @@ dnl RHEL6
elif test -d /usr/lib/jvm/java-openjdk; then
with_java="/usr/lib/jvm/java-openjdk"
+dnl OS X and possibly others
elif test -d /usr/libexec/java_home; then
with_java=`/usr/libexec/java_home`
dnl elif test -d /System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers; then
dnl JAVA_INC="-I/System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers"
@@ -3447,6 +3489,10 @@ elif test "x$with_java" != "x" -a "x$with_java" != "xno"; then
JAVA_HOME="$with_java"
JAVA_INC="-I$JAVA_HOME/include -I$JAVA_HOME/include/freebsd"
AC_MSG_RESULT([yes])
elif test -d "$with_java/include"; then
JAVA_HOME="$with_java"
JAVA_INC="-I$JAVA_HOME/include"
AC_MSG_RESULT([yes])
else
AC_MSG_ERROR("Cannot find $with_java/include/linux or solaris or freebsd directory.")
fi
@@ -3483,10 +3529,27 @@ if test "$with_mdb" = "yes" ; then
if test "x$with_jvm_lib" != "x"; then
if test -d "$with_jvm_lib"; then
I found a world of pain getting FileGDB to work using ESRI drivers, but the good news is that as of GDAL 1.11 an open driver has been included. So now you can use homebrew to install it.
Sincere thanks Zac! So helpful.