conda-forge / gdal-feedstock

A conda-smithy repository for gdal.

About gdal-split-feedstock

Feedstock license: BSD-3-Clause

About gdal-split

Home: http://www.gdal.org

Package license: MIT

Summary: GDAL is a translator library for raster and vector geospatial data formats that is released under an X/MIT style Open Source license by the Open Source Geospatial Foundation.

About libgdal

Package license: MIT

Summary: The Geospatial Data Abstraction Library (GDAL)

About libgdal-arrow-parquet

Package license: MIT

Summary: Arrow and Parquet drivers for the Geospatial Data Abstraction Library (GDAL)

Current build status

Azure

Variant Status linux_64 linux_aarch64 linux_ppc64le osx_64 osx_arm64 win_64

Current release info

Name	Downloads	Version	Platforms

Installing gdal-split

Installing gdal-split from the conda-forge channel can be achieved by adding conda-forge to your channels with:

conda config --add channels conda-forge
conda config --set channel_priority strict

Once the conda-forge channel has been enabled, gdal, libgdal, libgdal-arrow-parquet can be installed with conda:

conda install gdal libgdal libgdal-arrow-parquet

or with mamba:

mamba install gdal libgdal libgdal-arrow-parquet

It is possible to list all of the versions of gdal available on your platform with conda:

conda search gdal --channel conda-forge

or with mamba:

mamba search gdal --channel conda-forge

Alternatively, mamba repoquery may provide more information:

# Search all versions available on your platform:
mamba repoquery search gdal --channel conda-forge

# List packages depending on `gdal`:
mamba repoquery whoneeds gdal --channel conda-forge

# List dependencies of `gdal`:
mamba repoquery depends gdal --channel conda-forge

About conda-forge

conda-forge is a community-led conda channel of installable packages. In order to provide high-quality builds, the process has been automated into the conda-forge GitHub organization. The conda-forge organization contains one repository for each of the installable packages. Such a repository is known as a feedstock.

A feedstock is made up of a conda recipe (the instructions on what and how to build the package) and the necessary configurations for automatic building using freely available continuous integration services. Thanks to the awesome service provided by Azure, GitHub, CircleCI, AppVeyor, Drone, and TravisCI it is possible to build and upload installable packages to the conda-forge anaconda.org channel for Linux, Windows and OSX respectively.

To manage the continuous integration and simplify feedstock maintenance conda-smithy has been developed. Using the conda-forge.yml within this repository, it is possible to re-render all of this feedstock's supporting files (e.g. the CI configuration files) with conda smithy rerender.

For more information please check the conda-forge documentation.

Terminology

feedstock - the conda recipe (raw material), supporting scripts and CI configuration.

conda-smithy - the tool which helps orchestrate the feedstock. Its primary use is in the construction of the CI .yml files and simplify the management of many feedstocks.

conda-forge - the place where the feedstock and smithy live and work to produce the finished article (built conda distributions)

Updating gdal-split-feedstock

If you would like to improve the gdal-split recipe or build a new package version, please fork this repository and submit a PR. Upon submission, your changes will be run on the appropriate platforms to give the reviewer an opportunity to confirm that the changes result in a successful build. Once merged, the recipe will be re-built and uploaded automatically to the conda-forge channel, whereupon the built conda packages will be available for everybody to install and use from the conda-forge channel. Note that all branches in the conda-forge/gdal-split-feedstock are immediately built and any created packages are uploaded, so PRs should be based on branches in forks and branches in the main repository should only be used to build distinct package versions.

In order to produce a uniquely identifiable distribution:

• If the version of a package is not being increased, please add or increase the build/number.
• If the version of a package is being increased, please remember to return the build/number back to 0.

Feedstock Maintainers

• @akrherz
• @gillins
• @kmuehlbauer
• @mingwandroid
• @msarahan
• @ocefpaf
• @xylar
• @zklaus

gdal-feedstock's Issues

Did you remove some builds?

Trying to install - gdal=2.1.0=np111py27_3 seems no longer possible. It is also gone from https://anaconda.org/conda-forge/gdal/files

libjpeg dependency on OS X

When installing fiona in a fresh environment on OS X libjpeg 8d-1 is pulled down as a dependency by GDAL. But when the module is imported an ImportError is raised. It looks like GDAL was linked against libjpeg 9. Manually upgrading to version 9 seems to resolve the issue. I'm not sure why 8 gets installed in the first place.

snorfmac:~ snorf$ conda create -n python34 python=3.4
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata: ........
Solving package specifications: .........
Package plan for installation in environment /Users/snorf/miniconda3/envs/python34:

The following NEW packages will be INSTALLED:

    openssl:    1.0.2g-0     
    pip:        8.1.1-py34_1 
    python:     3.4.4-0      
    readline:   6.2-2        
    setuptools: 20.7.0-py34_0
    sqlite:     3.9.2-0      
    tk:         8.5.18-0     
    wheel:      0.29.0-py34_0
    xz:         5.0.5-1      
    zlib:       1.2.8-0      

Proceed ([y]/n)? 

Linking packages ...
[      COMPLETE      ]|###################################################| 100%
#
# To activate this environment, use:
# $ source activate python34
#
# To deactivate this environment, use:
# $ source deactivate
#
snorfmac:~ snorf$ source activate python34
discarding /Users/snorf/miniconda3/bin from PATH
prepending /Users/snorf/miniconda3/envs/python34/bin to PATH
(python34)snorfmac:~ snorf$ conda install fiona
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata: ........
Solving package specifications: ....................
Package plan for installation in environment /Users/snorf/miniconda3/envs/python34:

The following NEW packages will be INSTALLED:

    click:         6.6-py34_0        
    click-plugins: 1.0.3-py34_0      
    cligj:         0.4.0-py34_0      
    curl:          7.45.0-0          
    expat:         2.1.0-0           
    fiona:         1.6.3-np111py34_3 
    freexl:        1.0.2-0           
    gdal:          1.11.4-np111py34_4
    geos:          3.4.2-1           
    giflib:        5.1.2-0           
    hdf4:          4.2.11-0          
    hdf5:          1.8.15.1-2        
    jasper:        1.900.1-1         
    jbig:          2.1-0             
    jpeg:          8d-1              
    json-c:        0.12-0            
    krb5:          1.13.2-0          
    libgcc:        4.8.5-1           
    libnetcdf:     4.3.3.1-3         
    libpng:        1.6.17-0          
    libtiff:       4.0.6-1           
    mkl:           11.3.1-0          
    munch:         2.0.4-py34_0      
    numpy:         1.11.0-py34_0     
    openjpeg:      2.1.0-1           
    proj.4:        4.9.1-2           
    six:           1.10.0-py34_0     
    xerces-c:      3.1.2-0           

Proceed ([y]/n)? 

Linking packages ...
[      COMPLETE      ]|###################################################| 100%
(python34)snorfmac:~ snorf$ python
Python 3.4.4 |Continuum Analytics, Inc.| (default, Jan  9 2016, 17:30:09) 
[GCC 4.2.1 (Apple Inc. build 5577)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import fiona
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/snorf/miniconda3/envs/python34/lib/python3.4/site-packages/fiona/__init__.py", line 72, in <module>
    from fiona.collection import Collection, BytesCollection, vsi_path
  File "/Users/snorf/miniconda3/envs/python34/lib/python3.4/site-packages/fiona/collection.py", line 7, in <module>
    from fiona.ogrext import Iterator, ItemsIterator, KeysIterator
ImportError: dlopen(/Users/snorf/miniconda3/envs/python34/lib/python3.4/site-packages/fiona/ogrext.so, 2): Library not loaded: @rpath/libjpeg.9.dylib
  Referenced from: /Users/snorf/miniconda3/envs/python34/lib//libjasper.1.dylib
  Reason: image not found

Update libjpeg:

(python34)snorfmac:~ snorf$ conda install jpeg
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata: ........
Solving package specifications: ......
Package plan for installation in environment /Users/snorf/miniconda3/envs/python34:

The following packages will be UPDATED:

    jpeg: 8d-1 --> 9b-0

Proceed ([y]/n)? 

Unlinking packages ...
[      COMPLETE      ]|###################################################| 100%
Linking packages ...
[      COMPLETE      ]|###################################################| 100%
(python34)snorfmac:~ snorf$ python
Python 3.4.4 |Continuum Analytics, Inc.| (default, Jan  9 2016, 17:30:09) 
[GCC 4.2.1 (Apple Inc. build 5577)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import fiona
>>> fiona.__version__
'1.6.3.post1'

Remove the need for the GDAL_DATA environment variable

It is causing us to have to workaround the problem elsewhere, and would be nice to avoid if possible (even if it means a patch).

Not a huge priority, but it would be helpful to keep a list of places that the GDAL_DATA information has leaked out of this feedstock:

• https://github.com/conda-forge/staged-recipes/pull/159/files#r59058552

build problem with libtool

As experienced in #79, there is currently a problem building gdal python bindings using libtool.

I contacted the gdal-dev list for help in this matter: https://lists.osgeo.org/pipermail/gdal-dev/2016-June/044658.html.

Fix gdal 1.x branch

Not sure what is need to fix it right now but I will take a look soon.

Link gdal to jpeg and zlib on Windows

@gillins:

Under Windows GDAL cannot be build against an external zlib for some reason (there is no option to do this). jpeg isn't available as a DLL under Windows, and the provided .lib is built for use in a .exe rather than a .dll so it won't even link to GDAL (another conda-forge project??)

• jpeg
• zlib

Reducing the build matrix

Currently, whenever we do anything with GDAL, it consumes a huge amount of resource from AppVeyor and ends up queueing lots of things behind it. So the question is, are we able to reduce the build matrix for GDAL so that we don't end up building 12 variants (x86/x64, py27/py34/py35, np110/np111)? Looking at the download numbers, it isn't obvious that there are any variants which aren't downloaded, so it is a perfectly reasonable answer to say "no".

Add support for spatialite/sqlite

Spatialite (and sqlite) would be very nice to have. There's a conda-foge spatialite package, so this should be as simple as adding

--with-sqlite3=$PREFIX \
--with-spatialite=$PREFIX \

to build.sh, and to add dependencies to sqlite and libspatialite in meta.yaml (both for compile and run times). This seems to be working on Linux, and I guess it would also work for OSX, and there would be an equivalently simple Windows incantation. I can produce a PR, but this would probably conflict with Windows builds, and the PR is pretty much stated above anyway ;-)

Split into libgdal and gdal

I am not a big fan of this move, but defaults did this and packages on defaults that depend on libgdal get confused when mixing with conda-forge's packages.

@pelson, @msarahan, @ccordoba12, @groutr, @gillins, and @kmuehlbauer what do you think? Should I just go ahead and do the split+rename here? I am on the fence, which means that I will do this if I get 3 👍 here 😄

xref: conda-forge/rasterio-feedstock#13 (comment)

ice 48 vs 56

It looks like the icu library was recently upgraded from .48 to .56.

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    icu-56.1                   |                2        21.5 MB

On both OSX and linux, this appears to have broken the GDAL 2.1.0 installation.

>>> import gdal
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jlaura/miniconda3/envs/lidar2image/lib/python3.5/site-packages/gdal.py", line 2, in <module>
    from osgeo.gdal import deprecation_warn
  File "/home/jlaura/miniconda3/envs/lidar2image/lib/python3.5/site-packages/osgeo/__init__.py", line 21, in <module>
    _gdal = swig_import_helper()
  File "/home/jlaura/miniconda3/envs/lidar2image/lib/python3.5/site-packages/osgeo/__init__.py", line 17, in swig_import_helper
    _mod = imp.load_module('_gdal', fp, pathname, description)
  File "/home/jlaura/miniconda3/envs/lidar2image/lib/python3.5/imp.py", line 242, in load_module
    return load_dynamic(name, filename, file)
  File "/home/jlaura/miniconda3/envs/lidar2image/lib/python3.5/imp.py", line 342, in load_dynamic
    return _load(spec)
ImportError: libicuuc.so.48: cannot open shared object file: No such file or directory

I am not sure which dependency is looking for ICU, or I would open a ticket / PR there with an upgrade. Can anyone confirm that the build is not working? If so, does anyone know what gdal dep. requires ICU?

Build for Windows + Python 3.5

We are currently skipping that build.

libuuid not getting installed?

I ran into this installing fiona, but this appears to be a problem with gdal. In a fresh conda environment, containing only ipython.

|10112 $ conda --version
conda 4.1.8

|10105 $ conda install -c conda-forge fiona
Fetching package metadata .........
Solving package specifications: ..........

Package plan for installation in environment /Users/user/.miniconda3/envs/temp:

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    libgfortran-3.0.0          |                0         465 KB  conda-forge
    mkl-11.3.3                 |                0       101.4 MB  defaults
    ------------------------------------------------------------
                                           Total:       101.9 MB

The following NEW packages will be INSTALLED:

    click:         6.6-py35_1        conda-forge
    click-plugins: 1.0.3-py35_0      conda-forge
    cligj:         0.4.0-py35_0      defaults
    curl:          7.49.1-1          conda-forge
    expat:         2.1.0-2           conda-forge
    fiona:         1.7.0-np111py35_2 conda-forge
    freexl:        1.0.2-1           conda-forge
    gdal:          2.1.1-np111py35_5 conda-forge
    geos:          3.4.2-2           conda-forge
    giflib:        5.1.4-0           conda-forge
    hdf4:          4.2.12-0          conda-forge
    hdf5:          1.8.17-7          conda-forge
    icu:           56.1-4            conda-forge
    jpeg:          9b-0              conda-forge
    json-c:        0.12-0            conda-forge
    kealib:        1.4.6-3           conda-forge
    libdap4:       3.18.0-4          conda-forge
    libgfortran:   3.0.0-0           conda-forge
    libiconv:      1.14-3            conda-forge
    libnetcdf:     4.4.1-0           conda-forge
    libpng:        1.6.24-0          conda-forge
    libpq:         9.5.4-3           conda-forge
    libspatialite: 4.3.0a-10         conda-forge
    libtiff:       4.0.6-6           conda-forge
    libxml2:       2.9.4-2           conda-forge
    mkl:           11.3.3-0          defaults
    munch:         2.0.4-py35_0      conda-forge
    numpy:         1.11.2-py35_0     defaults
    openjpeg:      2.1.2-1           conda-forge
    proj.4:        4.9.3-0           conda-forge
    xerces-c:      3.1.4-2           conda-forge

>>> import fiona
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/user/.miniconda3/envs/temp/lib/python3.5/site-packages/fiona/__init__.py", line 69, in <module>
    from fiona.collection import Collection, BytesCollection, vsi_path
  File "/Users/user/.miniconda3/envs/temp/lib/python3.5/site-packages/fiona/collection.py", line 7, in <module>
    from fiona.ogrext import Iterator, ItemsIterator, KeysIterator
ImportError: dlopen(/Users/user/.miniconda3/envs/temp/lib/python3.5/site-packages/fiona/ogrext.cpython-35m-darwin.so, 2): Library not loaded: @rpath/libuuid.1.dylib
  Referenced from: /Users/user/.miniconda3/envs/temp/lib/libgdal.20.dylib
  Reason: image not found

Doing

conda install -c conda-forge libuuid

Solves the problem. Shouldn't libuuid be a transitive dependency met via gdal? Does it need to be added to the meta.yaml file?

Python 3.4 32-bit failing on Windows/AppVeyor

Looks like GDAL builds are failing on Python 3.4 32-bit Windows. This started in the last couple builds. Seems to not be able to find tiffio.h. Sample failure in this log.

Extra drivers test

@gillins in #75 (comment)

We need to add these other drivers to run_test.py. I was hoping to get libspatialite etc going under Windows this week, but I'm heading off on leave until Monday in a few hours, so hopefully next week.

Let's add the exta drivers tests once we have them all working on Windows to avoid workarounds in run_test.py.

gdal suggesting downgrade of libgdal

I just upgraded from OSX 10.10.5 to 10.11.6
Have gdal installed from conda default channel.
Was living without bleeding edge gdal for a while, waiting for conda-forge to sort it all out. ;)
Trying to install it now into a conda Python 3.5 environment that has (lib)/gdal 2.0.0 installed gives me currently this:

(stable) └─❱❱❱ conda install -c conda-forge gdal                   1 ⏎  +6237 14:23 ❰─┘
Using Anaconda API: https://api.anaconda.org
Fetching package metadata .........
Solving package specifications: ..........

Package plan for installation in environment /Users/klay6683/miniconda3/envs/stable:

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    expat-2.1.0                |                1         105 KB  conda-forge
    giflib-5.1.2               |                1          70 KB  conda-forge
    icu-56.1                   |                4        22.0 MB  conda-forge
    jpeg-9b                    |                0         243 KB  conda-forge
    json-c-0.12                |                0          44 KB  conda-forge
    libgdal-1.11.2             |                1        12.8 MB
    libiconv-1.14              |                3         1.3 MB  conda-forge
    libuuid-1.0.3              |                1          12 KB  conda-forge
    proj.4-4.9.2               |                0         436 KB  conda-forge
    freexl-1.0.2               |                1          38 KB  conda-forge
    hdf5-1.8.17                |                2         3.4 MB  conda-forge
    libtiff-4.0.6              |                6         556 KB  conda-forge
    libxml2-2.9.3              |                9         1.9 MB  conda-forge
    postgresql-9.5.3           |                2         6.4 MB  conda-forge
    kealib-1.4.6               |                3         178 KB  conda-forge
    libdap4-3.18.0             |                2         2.7 MB  conda-forge
    libnetcdf-4.4.0            |                2         1.5 MB  conda-forge
    libspatialite-4.3.0a       |                9         2.1 MB  conda-forge
    openjpeg-2.1.0             |                6         203 KB  conda-forge
    gdal-2.1.1                 |      np111py35_1        17.9 MB  conda-forge
    pillow-3.2.0               |           py35_1         513 KB  conda-forge
    pytables-3.2.3.1           |      np111py35_0         1.7 MB
    ------------------------------------------------------------
                                           Total:        76.0 MB

The following NEW packages will be INSTALLED:

    expat:         2.1.0-1           conda-forge
    freexl:        1.0.2-1           conda-forge
    giflib:        5.1.2-1           conda-forge
    icu:           56.1-4            conda-forge
    json-c:        0.12-0            conda-forge
    libdap4:       3.18.0-2          conda-forge
    libiconv:      1.14-3            conda-forge
    libspatialite: 4.3.0a-9          conda-forge
    libuuid:       1.0.3-1           conda-forge
    libxml2:       2.9.3-9           conda-forge
    openjpeg:      2.1.0-6           conda-forge
    postgresql:    9.5.3-2           conda-forge
    proj.4:        4.9.2-0           conda-forge

The following packages will be UPDATED:

    gdal:          2.0.0-np111py35_3             --> 2.1.1-np111py35_1   conda-forge
    hdf5:          1.8.16-0                      --> 1.8.17-2            conda-forge
    jpeg:          8d-1                          --> 9b-0                conda-forge
    kealib:        1.4.5-2                       --> 1.4.6-3             conda-forge
    libnetcdf:     4.4.0-1                       --> 4.4.0-2             conda-forge
    libtiff:       4.0.6-2                       --> 4.0.6-6             conda-forge
    pytables:      3.2.2-np111py35_4             --> 3.2.3.1-np111py35_0

The following packages will be SUPERCEDED by a higher-priority channel:

    pillow:        3.3.0-py35_0                  --> 3.2.0-py35_1        conda-forge

The following packages will be DOWNGRADED due to dependency conflicts:

    libgdal:       2.0.0-4                       --> 1.11.2-1

Proceed ([y]/n)?

As you can see, it suggests to downgrade pillow from 3.3.0 to 3.2.0, but weirdly, it wants to downgrade libgdal 2.0.0 to 1.11.2, even so it wants to install gdal 2.1.1 with it? Isn't that wrong?

gdal2 branch windows packages not uploaded

If this is the same as in conda-forge/wradlib-feedstock#5 I could issue the necessary PR.

GDAL > 2.0.0

Is there a gdal2 feedstock somewhere, or in planning. I'm trying to set this up locally, but with condaforge it seems much nicer.

Latest version of gdal pulls in libnetcdf from default channel (built against jpeg 8d) which causes error when running

Installing the latest version of gdal (2.1.1) from conda-forge gives the following error:

gdal_translate: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory

I think this is due to pulling in libnetcdf 4.4.1 from default in preference to 4.4.0 from conda-forge.
Downgrading libnetcdf to 4.4.0 (from conda-forge) fixes gdal and doesn't change any other packages so I think this is where the problem is.

From what I can tell the version of libnetcdf in default is built against the default version of hdf4, which is built against jpeg 8d, rather than jpeg 9d used for the conda-forge hdf4 build. The version of libnetcdf from default requires hdf4 4.2.*, which the conda-forge build satisfies, but they use different versions of jpeg

Pinning gdal to use libnetcdf 4.4.0 would be the quickest solution (and I'm happy to submit a pull request for this) but I'm unsure if it is the best way to resolve.

Pinning PR

Looks libtiff, libpng, and hdf5 are pinned incorrectly. Could we please have a pinning PR here to fix this, @pelson. Thanks @kmuehlbauer for pointing this out.

xref: conda-forge/wradlib-feedstock#13 (comment)

ImportError: No module named '_gdal_array' on py3

Hi,

I don't know when it started but I think it is recent. It happens only on py3, on py2 there is no apparent problem:

/home/docs/checkouts/readthedocs.org/user_builds/oggm/conda/docs/lib/python3.5/site-packages/osgeo/gdalnumeric.py in <module>()
----> 1 from osgeo.gdal_array import *
      2 from numpy import *

/home/docs/checkouts/readthedocs.org/user_builds/oggm/conda/docs/lib/python3.5/site-packages/osgeo/gdal_array.py in <module>()
    166 
    167 import numpy
--> 168 import _gdal_array
    169 
    170 from . import gdalconst

ImportError: No module named '_gdal_array'

Thanks!

Add jpeg dependency on linux

It seems that jpeg missing on linux. I cannot import gdal

libjpeg.so.9: cannot open shared object file: No such file or directory

Recent builds broken?

I'm having issues on linux with 3.5 and 3.4

$ conda create -n gdal34 python=3.4
Fetching package metadata .......
Solving package specifications: ..........

Package plan for installation in environment /home/kwilcox/miniconda3/envs/gdal34:

The following NEW packages will be INSTALLED:

    openssl:    1.0.2h-1      defaults
    pip:        8.1.2-py34_0  defaults
    python:     3.4.4-5       defaults
    readline:   6.2-2         defaults
    setuptools: 23.0.0-py34_0 defaults
    sqlite:     3.13.0-0      defaults
    tk:         8.5.18-0      defaults
    wheel:      0.29.0-py34_0 defaults
    xz:         5.2.2-0       defaults
    zlib:       1.2.8-3       defaults

Proceed ([y]/n)? 

Linking packages ...
[      COMPLETE      ]|##########################################################################################################################################################################| 100%
#
# To activate this environment, use:
# $ source activate gdal34
#
# To deactivate this environment, use:
# $ source deactivate
#

$ source activate gdal34                                                                                                                                                                                                

(gdal34)$ conda install -c conda-forge gdal
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata .........
Solving package specifications: ..........

Package plan for installation in environment /home/kwilcox/miniconda3/envs/gdal34:

The following NEW packages will be INSTALLED:

    curl:          7.49.1-0          conda-forge
    expat:         2.1.0-1           conda-forge
    freexl:        1.0.2-1           conda-forge
    gdal:          2.1.0-np111py34_6 conda-forge
    geos:          3.4.2-2           conda-forge
    giflib:        5.1.2-1           conda-forge
    hdf4:          4.2.11-4          conda-forge
    hdf5:          1.8.17-2          conda-forge
    jpeg:          9b-0              conda-forge
    json-c:        0.12-0            conda-forge
    kealib:        1.4.6-2           conda-forge
    krb5:          1.14.2-0          conda-forge
    libiconv:      1.14-2            conda-forge
    libnetcdf:     4.4.0-1           conda-forge
    libpng:        1.6.23-0          conda-forge
    libspatialite: 4.3.0a-8          conda-forge
    libtiff:       4.0.2-0           defaults   
    libxml2:       2.9.2-0           defaults   
    mkl:           11.3.3-0          defaults   
    numpy:         1.11.1-py34_0     defaults   
    openjpeg:      2.1.0-5           conda-forge
    postgresql:    9.1.4-1           defaults   
    proj.4:        4.9.2-0           conda-forge
    xerces-c:      3.1.2-0           defaults   

Proceed ([y]/n)? y

Linking packages ...
[      COMPLETE      ]|##########################################################################################################################################################################| 100%

(gdal34)$ python
Python 3.4.4 |Continuum Analytics, Inc.| (default, Jun 15 2016, 15:26:54) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gdal
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/kwilcox/miniconda3/envs/gdal34/lib/python3.4/site-packages/gdal.py", line 2, in <module>
    from osgeo.gdal import deprecation_warn
  File "/home/kwilcox/miniconda3/envs/gdal34/lib/python3.4/site-packages/osgeo/__init__.py", line 21, in <module>
    _gdal = swig_import_helper()
  File "/home/kwilcox/miniconda3/envs/gdal34/lib/python3.4/site-packages/osgeo/__init__.py", line 17, in swig_import_helper
    _mod = imp.load_module('_gdal', fp, pathname, description)
  File "/home/kwilcox/miniconda3/envs/gdal34/lib/python3.4/imp.py", line 243, in load_module
    return load_dynamic(name, filename, file)
ImportError: libjpeg.so.62: cannot open shared object file: No such file or directory

ISIS3/USGS driver problem

This version (or maybe only this compile) suffers from a recently popping up problem with USGS ISIS3 cube files. It was previously seen years ago, when it was suggested that it can happen from an unclean compile, see here for a discussion:
https://lists.osgeo.org/pipermail/gdal-dev/2009-September/022101.html

Symptom: Opening an USGS ISIS cube errors with:

ERROR 6: SetNoDataValue() not supported for this dataset.
ERROR 6: SetOffset() not supported on this raster band.
ERROR 6: SetScale() not supported on this raster band.

while this driver is well supported for many years.

I just tried the recently updated pure conda version of gdal, and that one currently does not have this problem.
Here is a mini cube file to try things out: https://dl.dropboxusercontent.com/u/139035/cropped.cub
When called with this version of gdal it looks like this:

(gdal_forge)└─❱❱❱ gdalinfo cropped.cub                                                       +5067 18:11 ❰─┘
ERROR 6: SetNoDataValue() not supported for this dataset.
ERROR 6: SetOffset() not supported on this raster band.
ERROR 6: SetScale() not supported on this raster band.
Driver: ISIS3/USGS Astrogeology ISIS cube (Version 3)
Files: cropped.cub
Size is 100, 100
Coordinate System is:
PROJCS["Sinusoidal Mars",
    GEOGCS["GCS_Mars",
        DATUM["D_Mars",
            SPHEROID["Mars",3396190,0]],
        PRIMEM["Reference_Meridian",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Sinusoidal"],
    PARAMETER["longitude_of_center",296.28065864847],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0]]
Origin = (-4959.626702915599708,-4803213.120008500292897)
Pixel Size = (0.495566217317710,-0.495566217317710)
Corner Coordinates:
Upper Left  (   -4959.627,-4803213.120) ( 64d15'22.21"W, 81d 1'59.20"S)
Lower Left  (   -4959.627,-4803262.677) ( 64d15'22.39"W, 81d 2' 2.21"S)
Upper Right (   -4910.070,-4803213.120) ( 64d15' 2.90"W, 81d 1'59.20"S)
Lower Right (   -4910.070,-4803262.677) ( 64d15' 3.07"W, 81d 2' 2.21"S)
Center      (   -4934.848,-4803237.898) ( 64d15'12.64"W, 81d 2' 0.70"S)
Band 1 Block=100x100 Type=Float32, ColorInterp=Undefined

When called with conda's gdal, it does not show this error:

(gdal_try)└─❱❱❱ gdalinfo cropped.cub                                                         +5070 18:13 ❰─┘
Driver: ISIS3/USGS Astrogeology ISIS cube (Version 3)
Files: cropped.cub
Size is 100, 100
Coordinate System is:
PROJCS["Sinusoidal Mars",
    GEOGCS["GCS_Mars",
        DATUM["D_Mars",
            SPHEROID["Mars",3396190,0]],
        PRIMEM["Reference_Meridian",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Sinusoidal"],
    PARAMETER["longitude_of_center",296.28065864847],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0]]
Origin = (-4959.626702915599708,-4803213.120008500292897)
Pixel Size = (0.495566217317710,-0.495566217317710)
Corner Coordinates:
Upper Left  (   -4959.627,-4803213.120) ( 64d15'22.21"W, 81d 1'59.20"S)
Lower Left  (   -4959.627,-4803262.677) ( 64d15'22.39"W, 81d 2' 2.21"S)
Upper Right (   -4910.070,-4803213.120) ( 64d15' 2.90"W, 81d 1'59.20"S)
Lower Right (   -4910.070,-4803262.677) ( 64d15' 3.07"W, 81d 2' 2.21"S)
Center      (   -4934.848,-4803237.898) ( 64d15'12.64"W, 81d 2' 0.70"S)
Band 1 Block=100x100 Type=Float32, ColorInterp=Undefined
  NoData Value=-3.40282265508890445e+38

Problems with GDAL linking on OSX

I'm getting random crashes when running code that uses the latest version of GDAL on OSX. (actually the https://github.com/conda-forge/rios-feedstock test script).

Code runs fine with earlier versions.

I suspect this is the same problem @danclewley reported to me earlier. Some libraries are built against /usr/lib/libstdc++ and some against Conda's libstdc++. I think this is due to some packages requiring libgcc (ie giflib - conda-forge/giflib-feedstock#2 and libspatialite).

Multiple runtime libs sounds a recipe for disaster...

Can we remove the dependency on libgcc easily?

@danclewley : can you confirm that the RIOS test script works fine with your libgcc-less versions of gif and spatialite?

Build issue with libxml2 on OS X

For some reason (I can not figure out why), libxml2 is being installed from defaults channel (2.9.2), not conda-forge (which has 2.9.3). Setting the libxml2 2.9.3 dependency explicitly in gdal solves this issue.

Before setting dependency:
https://travis-ci.org/aleksandervines/gdal-feedstock/builds/143299375

After:
https://travis-ci.org/aleksandervines/gdal-feedstock/builds/143318936

From what I can find, only libspatialite of gdal dependencies requires libxml2, and when installing libspatialite itself it seems to use the conda-forge libxml2 (unless I have already downloaded the default one by attempting to build gdal).

geo pdf not supported on linux

To be supported on linux, gdal must be compiled with poppler lib.
gdal-config --dep-libs should show: -lpoppler

Unable to install gdal 1.11.4 through conda forge

I am trying to install gdal 1.11.4 like this:
conda install -c conda-forge gdal=1.11.4

When I try to import gdal
python -c 'import gdal'

I get this error:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/ritvik/anaconda2/lib/python2.7/site-packages/gdal.py", line 2, in <module>
    from osgeo.gdal import deprecation_warn
  File "/Users/ritvik/anaconda2/lib/python2.7/site-packages/osgeo/__init__.py", line 21, in <module>
    _gdal = swig_import_helper()
  File "/Users/ritvik/anaconda2/lib/python2.7/site-packages/osgeo/__init__.py", line 17, in swig_import_helper
    _mod = imp.load_module('_gdal', fp, pathname, description)
ImportError: dlopen(/Users/ritvik/anaconda2/lib/python2.7/site-packages/osgeo/_gdal.so, 2): Library not loaded: @rpath/libjpeg.8.dylib
  Referenced from: /Users/ritvik/anaconda2/lib//libjasper.1.dylib
  Reason: image not found

How do I fix this?

Test the drivers

Add a test that checks the compiled drivers against an expected driver list.

Shared Libraries Error

OS: Ubuntu 16.04
Anaconda: 4.0
Python: 3.5

I installed gdal via conda:

$ conda install -c conda-forge gdal

with no issues.

However I get the following error with any call to GDAL:

$ gdalinfo --version
gdalinfo: error while loading shared libraries: libcharset.so.1: cannot open shared object file: No such file or directory

Windows 10 64-bit Environment Variable Path Issue with Gdal

Hi I am on Windows 10 (64-bit), using Anaconda3 4.1.1. I am trying to create a geospatial analysis environment in Python 2.7.12.

When attempting to install Fiona, I am having a Gdal related environment variable issue. I am told that the issue is with Gdal, not with Fiona.

I arrived here through the following steps:

1. I created an environment with 'conda create -n testenv python=2'.

2. Next I installed Fiona with 'conda install -c conda-forge fiona=1.7.0'. The following packages were installed:

Fiona is supposed to take care of the environment variables. When activating my environment I get the following error:

Even if I add the Gdal dll, and the gdal-data directory, to my Windows system PATH I get the same error. Sorry if I've missed anything in the installation instructions.

Thanks

libgdal.20.dylib links againsty Homebew libraries on OS X

The libgdal.20.dylib library shipped in 2.0.2 build 2 conda package links again Homebrew libraries which are not guaranteed to available on a user's system (and are not on my systems which uses MacPorts). On systems without these libraries gdal is not importable.

$ wget https://anaconda.org/conda-forge/gdal/2.0.2/download/osx-64/gdal-2.0.2-np19py35_2.tar.bz2
...
$ tar xf gdal-2.0.2-np19py35_2.tar.bz2
...
$ otool -L lib/libgdal.20.dylib
lib/libgdal.20.dylib:
    @rpath/libgdal.20.dylib (compatibility version 21.0.0, current version 21.2.0)
    @rpath/libproj.9.dylib (compatibility version 10.0.0, current version 10.0.0)
    /usr/local/lib/libjson-c.2.dylib (compatibility version 3.0.0, current version 3.1.0)
    /usr/local/lib/libfreexl.1.dylib (compatibility version 2.0.0, current version 2.0.0)
    @rpath/libgeos_c.1.dylib (compatibility version 10.0.0, current version 10.2.0)
    @rpath/libgeos-3.4.2.dylib (compatibility version 0.0.0, current version 0.0.0)
    @rpath/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0)
    /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 7.2.0)
    @rpath/./libxerces-c-3.1.dylib (compatibility version 0.0.0, current version 0.0.0)
    @rpath/libopenjp2.7.dylib (compatibility version 7.0.0, current version 2.1.0)
    @rpath/./libnetcdf.7.dylib (compatibility version 10.0.0, current version 10.0.0)
    /usr/local/lib/libgif.4.1.6.dylib (compatibility version 6.0.0, current version 6.6.0)
    /usr/local/lib/libgeotiff.2.dylib (compatibility version 4.0.0, current version 4.0.0)
    @rpath/libtiff.5.dylib (compatibility version 8.0.0, current version 8.4.0)
    @rpath/liblzma.5.dylib (compatibility version 6.0.0, current version 6.5.0)
    @rpath/libjpeg.8.dylib (compatibility version 13.0.0, current version 13.0.0)
    @rpath/libpng16.16.dylib (compatibility version 34.0.0, current version 34.0.0)
    /usr/local/lib/libpq.5.dylib (compatibility version 5.0.0, current version 5.6.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
    @rpath/libcurl.4.dylib (compatibility version 9.0.0, current version 9.0.0)
    @rpath/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    @rpath/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.9.0)
    @rpath/./libkea.1.4.5.dylib (compatibility version 1.4.5, current version 1.4.5)
    @rpath/./libhdf5_hl.10.dylib (compatibility version 11.0.0, current version 11.1.0)
    @rpath/./libhdf5_cpp.10.dylib (compatibility version 11.0.0, current version 11.1.0)
    @rpath/./libhdf5.10.dylib (compatibility version 11.0.0, current version 11.1.0)
    @rpath/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0)

Libraries in /usr/local/... are from Homebrew.

Add support for expat

As pointed out by @jakirkham, gdal is linked against the system libexpat on OSX which should be corrected. As we have a conda-forge libexpat we should link against that on all platforms which will give us a few more formats.

ERROR 1: Cannot create TIFF file due to missing codec for JPEG/DEFLATE

Environment:
Windows 7 / conda 4.1.8 / Conda Env

Running the following gdal_translate commands fails when the compress config option is set to JPEG or DEFLATE

> activate py35
(py35) > gdal_translate -co compress=JPEG test1.tif test2.tif
Input file size is 8061, 7101
Warning 6: 'JPEG' is an unexpected value for compress creation option of type string-select.
0ERROR 1: Cannot create TIFF file due to missing codec for JPEG.

(py35) > gdal_translate -co compress=DEFLATE test1.tif test2.tif
Input file size is 8061, 7101
Warning 6: 'DEFLATE' is an unexpected value for compress creation option of type string-select.
0ERROR 1: Cannot create TIFF file due to missing codec for DEFLATE.

(py35) > gdal_translate -co compress=LZW test1.tif test2.tif
Input file size is 8061, 7101
0...10...20...30...40...50...60...70...80...90...100 - done.

(py35) > gdalinfo test1.tif
Driver: GTiff/GeoTIFF                                                           
Files: test1.tif
Size is 8061, 7101                                                              
Coordinate System is:                                                           
PROJCS["WGS 84 / UTM zone 52N",                                                 
    GEOGCS["WGS 84",                                                            
        DATUM["WGS_1984",                                                       
            SPHEROID["WGS 84",6378137,298.257223563,                            
                AUTHORITY["EPSG","7030"]],                                      
            AUTHORITY["EPSG","6326"]],                                          
        PRIMEM["Greenwich",0,                                                   
            AUTHORITY["EPSG","8901"]],                                          
        UNIT["degree",0.0174532925199433,                                       
            AUTHORITY["EPSG","9122"]],                                          
        AUTHORITY["EPSG","4326"]],                                              
    PROJECTION["Transverse_Mercator"],                                          
    PARAMETER["latitude_of_origin",0],                                          
    PARAMETER["central_meridian",129],                                          
    PARAMETER["scale_factor",0.9996],                                           
    PARAMETER["false_easting",500000],                                          
    PARAMETER["false_northing",0],                                              
    UNIT["metre",1,                                                             
        AUTHORITY["EPSG","9001"]],                                              
    AXIS["Easting",EAST],                                                       
    AXIS["Northing",NORTH],                                                     
    AUTHORITY["EPSG","32652"]]                                                  
Origin = (568785.000000000000000,-2611485.000000000000000)                      
Pixel Size = (30.000000000000000,-30.000000000000000)                           
Metadata:                                                                       
  AREA_OR_POINT=Point                                                           
  METADATATYPE=ODL                                                              
Image Structure Metadata:                                                       
  INTERLEAVE=BAND                                                               
Corner Coordinates:                                                             
Upper Left  (  568785.000,-2611485.000) (129d40'27.35"E, 23d36'44.90"S)         
Lower Left  (  568785.000,-2824515.000) (129d41' 4.71"E, 25d32'10.82"S)         
Upper Right (  810615.000,-2611485.000) (132d 2'35.57"E, 23d35' 2.78"S)         
Lower Right (  810615.000,-2824515.000) (132d 5'23.86"E, 25d30'19.25"S)         
Center      (  689700.000,-2718000.000) (130d52'23.26"E, 24d33'51.67"S)         
Band 1 Block=8061x1 Type=Byte, ColorInterp=Gray                                 

gdal 1.11.5 does not build with sqlite

From @gillins in #97

You mean that with sqlite GDAL 1.11.5 didn't build? Seems to make sense looking at the differences with 2.1 (https://trac.osgeo.org/gdal/browser/branches/1.11/gdal/ogr/ogrsf_frmts/sqlite/ogrsqlitevirtualogr.cpp vs https://trac.osgeo.org/gdal/browser/branches/2.1/gdal/ogr/ogrsf_frmts/sqlite/ogrsqlitevirtualogr.cpp).

conda-forge sqlite doesn't come with sqlite3ext.h and GDAL 2.1 doesn't include it. Seems a bug in GDAL 1.11.5?

Upgrading gdal drivers in geopandas

The geopandas that is downloaded via "conda install geopandas" has a gdal version that does not contain all of the necessary drivers. For example, when I run a command like "

ogrinfo input.shp -dialect SQLite -sql..."

I get the response, "ERROR 6: The SQLite driver needs to be compiled to support the SQLite SQL dialect"

Trying to upgrade GDAL, I run into dependency issues. If I upgrade fiona, everything breaks and geopandas can no longer interact with fiona.

Is there a way to choose the drivers to be downloaded with Conda?

Library broken on os.

import gdal gives an import error:

ImportError: dlopen(/Users/rob/anaconda/lib/python3.5/site-packages/osgeo/_gdal.so, 2): Symbol not found: __ZN6kealib10KEAImageIO10isKEAImageESs
Referenced from: /Users/rob/anaconda/lib/python3.5/site-packages/osgeo/../../..//libgdal.20.dylib
Expected in: /Users/rob/anaconda/lib//libkea.1.4.6.dylib
in /Users/rob/anaconda/lib/python3.5/site-packages/osgeo/../../..//libgdal.20.dylib

HDF 4 on Windows need features

@gillins:

HDF4 on Windows is only available as a 'pre-VC Features' build - hence built with the wrong compiler for Python 3.x. HDF4 needs to be brought up to date (maybe another conda-forge project?). With the wrong compiler random application crashes will be likely.

Failing to compile on Windows with latest hdf5 (1.8.16)

I get the errors below with conda-forge's hdf5. I've logged it here as the symbols are in fact exported in the lib/dll so likely to be a weird include problem inside GDAL.

gh5_convenience.obj : error LNK2019: unresolved external symbol H5T_NATIVE_DOUBLE_g referenced in function "bool __cdecl GH5_FetchAttribute(int,char const *,double &,bool)" (?GH5_FetchAttribute@@YA_NHPEBDAEAN_N@Z)
hdf5dataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_DOUBLE_g
gh5_convenience.obj : error LNK2019: unresolved external symbol H5T_NATIVE_FLOAT_g referenced in function "bool __cdecl GH5_FetchAttribute(int,char const *,double &,bool)" (?GH5_FetchAttribute@@YA_NHPEBDAEAN_N@Z)
hdf5dataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_FLOAT_g
hdf5imagedataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_FLOAT_g
gh5_convenience.obj : error LNK2019: unresolved external symbol H5T_NATIVE_INT_g referenced in function "bool __cdecl GH5_FetchAttribute(int,char const *,double &,bool)" (?GH5_FetchAttribute@@YA_NHPEBDAEAN_N@Z)
hdf5dataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_INT_g
gh5_convenience.obj : error LNK2019: unresolved external symbol H5T_NATIVE_ULLONG_g referenced in function "enum GDALDataType __cdecl GH5_GetDataType(int)" (?GH5_GetDataType@@YA?AW4GDALDataType@@H@Z)
hdf5dataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_ULLONG_g
gh5_convenience.obj : error LNK2019: unresolved external symbol H5T_NATIVE_LLONG_g referenced in function "enum GDALDataType __cdecl GH5_GetDataType(int)" (?GH5_GetDataType@@YA?AW4GDALDataType@@H@Z)
hdf5dataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_LLONG_g
gh5_convenience.obj : error LNK2019: unresolved external symbol H5T_NATIVE_ULONG
_g referenced in function "enum GDALDataType __cdecl GH5_GetDataType(int)" (?GH5_GetDataType@@YA?AW4GDALDataType@@H@Z)
hdf5dataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_ULONG_g
gh5_convenience.obj : error LNK2019: unresolved external symbol H5T_NATIVE_LONG_g referenced in function "enum GDALDataType __cdecl GH5_GetDataType(int)" (?GH5_GetDataType@@YA?AW4GDALDataType@@H@Z)
hdf5dataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_LONG_g
gh5_convenience.obj : error LNK2019: unresolved external symbol H5T_NATIVE_UINT_g referenced in function "enum GDALDataType __cdecl GH5_GetDataType(int)" (?GH5_GetDataType@@YA?AW4GDALDataType@@H@Z)
hdf5dataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_UINT_g
gh5_convenience.obj : error LNK2019: unresolved external symbol H5T_NATIVE_USHORT_g referenced in function "enum GDALDataType __cdecl GH5_GetDataType(int)" (?GH5_GetDataType@@YA?AW4GDALDataType@@H@Z)
hdf5dataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_USHORT_g
gh5_convenience.obj : error LNK2019: unresolved external symbol H5T_NATIVE_SHORT_g referenced in function "enum GDALDataType __cdecl GH5_GetDataType(int)" (?GH5_GetDataType@@YA?AW4GDALDataType@@H@Z)
hdf5dataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_SHORT_g
gh5_convenience.obj : error LNK2019: unresolved external symbol H5T_NATIVE_UCHAR_g referenced in function "enum GDALDataType __cdecl GH5_GetDataType(int)" (?GH5_GetDataType@@YA?AW4GDALDataType@@H@Z)
hdf5dataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_UCHAR_g
gh5_convenience.obj : error LNK2019: unresolved external symbol H5T_NATIVE_SCHAR
_g referenced in function "enum GDALDataType __cdecl GH5_GetDataType(int)" (?GH5_GetDataType@@YA?AW4GDALDataType@@H@Z)
hdf5dataset.obj : error LNK2001: unresolved external symbol H5T_NATIVE_SCHAR_g
gdal200.dll : fatal error LNK1120: 12 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0
\VC\Bin\amd64\link.EXE"' : return code '0x460'

Having issues installing fiona from conda-forge, looks related to conda-forge gdal install

Can't seem to get a working conda build of fiona in a development environment in osx (works fine in root environment). I think it's a gdal issue. Here's the output:

conda create -y --name test_fiona3 python=3.4
Fetching package metadata: ....
Solving package specifications: .........

Package plan for installation in environment /Users/Nick/anaconda/envs/test_fiona3:

The following NEW packages will be INSTALLED:

    openssl:    1.0.2g-0      defaults
    pip:        8.1.1-py34_0  defaults
    python:     3.4.4-0       defaults
    readline:   6.2-2         defaults
    setuptools: 20.3-py34_0   defaults
    sqlite:     3.9.2-0       defaults
    tk:         8.5.18-0      defaults
    wheel:      0.29.0-py34_0 defaults
    xz:         5.0.5-1       defaults
    zlib:       1.2.8-0       defaults

Linking packages ...
[      COMPLETE      ]|#############################################################################################| 100%
#
# To activate this environment, use:
# $ source activate test_fiona3
#
# To deactivate this environment, use:
# $ source deactivate
#
➜  ~ source activate test_fiona3
discarding /Users/Nick/anaconda/bin from PATH
prepending /Users/Nick/anaconda/envs/test_fiona3/bin to PATH
(test_fiona3)➜  ~ conda install -y -c conda-forge fiona
Fetching package metadata: ......
Solving package specifications: .........

Package plan for installation in environment /Users/Nick/anaconda/envs/test_fiona3:

The following NEW packages will be INSTALLED:

    click:         6.3-py34_0         defaults   
    click-plugins: 1.0.3-py34_0       conda-forge
    cligj:         0.4.0-py34_0       defaults   
    curl:          7.45.0-0           defaults   
    fiona:         1.6.3-np110py34_0  conda-forge
    gdal:          1.11.4-np110py34_0 conda-forge
    geos:          3.4.2-0            conda-forge
    hdf4:          4.2.11-0           defaults   
    hdf5:          1.8.15.1-2         defaults   
    jbig:          2.1-0              defaults   
    jpeg:          8d-1               defaults   
    kealib:        1.4.5-0            defaults   
    krb5:          1.13.2-0           defaults   
    libnetcdf:     4.3.3.1-3          defaults   
    libpng:        1.6.17-0           defaults   
    libtiff:       4.0.6-1            defaults   
    mkl:           11.3.1-0           defaults   
    munch:         2.0.4-py34_0       conda-forge
    numpy:         1.10.4-py34_0      defaults   
    openjpeg:      2.1.0-1            conda-forge
    proj.4:        4.9.1-2            conda-forge
    six:           1.10.0-py34_0      defaults   
    xerces-c:      3.1.2-0            defaults   

Linking packages ...
[      COMPLETE      ]|#############################################################################################| 100%
(test_fiona3)➜  ~ python -c 'import fiona'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/Nick/anaconda/envs/test_fiona3/lib/python3.4/site-packages/fiona/__init__.py", line 72, in <module>
    from fiona.collection import Collection, BytesCollection, vsi_path
  File "/Users/Nick/anaconda/envs/test_fiona3/lib/python3.4/site-packages/fiona/collection.py", line 7, in <module>
    from fiona.ogrext import Iterator, ItemsIterator, KeysIterator
ImportError: dlopen(/Users/Nick/anaconda/envs/test_fiona3/lib/python3.4/site-packages/fiona/ogrext.so, 2): Library not loaded: /usr/local/lib/libgif.4.1.6.dylib
  Referenced from: /Users/Nick/anaconda/envs/test_fiona3/lib/libgdal.1.dylib
  Reason: image not found
(test_fiona3)➜  ~ 

Any thoughts? Cross-listed in Fiona-feedstock.

gdal 1 vs gdal 2 feedstock

We are using these dependencies on gdal 1.11.4 but not in gdal 2.1.0.

        - expat
        - postgresql  # [not win]
        - giflib  # [not win]
        - json-c  # [not win]
        - freexl  # [not win]
        - libspatialite  # [not win]

Edit:

Maybe we don't need this as we are using openjpeg.

        - jasper  # [not win]

Problem when importing gdal from a conda environment

I am facing a weird problem when I try to import from a gdal installation that has been installed to a conda environment. I am working on Windows 7. This is what happens:

I created a fresh conda 2.7 environment (named gdaltest in the following text) and I installed gdal (from the conda-forge channel), into that environment:

> conda create --name gdaltest python=2.7
> activate gdaltest
(gdaltest) conda install gdal

When I invoke the Python interpreter from the activated gdaltest environment and try to import from osgeo, everthing is fine:

(gdaltest) python
>>> from osgeo import ogr

However, if I deactivate the conda environment and invoke the Python interpreter from the gdaltest environment directly, it does not work anymore:

(gdaltest) deactivate gdaltest
> C:\Anaconda3\envs\gdaltest\python.exe
>>> from osgeo import ogr
File "C:\Anaconda3\envs\wradlib\lib\site-packages\osgeo\__init__.py", line 21, in swig_import_helper
    _mod = imp.load_module('_gdal', fp, pathname, description)
ImportError: DLL load failed...

You might ask: why not use activate then? But when I work from an IDE (such as PyCharm or Spyder), I have to specify the path to the Python interpreter in a conda environment instead of using activate. So right now, I cannot use gdal from any IDE...

I have no idea what causes the problem. But I tried different versions of gdal from the conda-forge channel. The problem appears to occur only with gdal>=2.1.0. So conda install gdal=2.1.0 will reproduce the problem while conda install gdal=2.0.2 (and other lower versions) will not.

Edit: Attached conda env export file

Thanks a lot in advance for taking the time to consider this issue!

Best,
Maik

vsizip behaves strangely: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".

Problem
After Installing gdal from conda-forge on fresh linux and attempting to open zip file with Sentinel data I got the following errors:

gdalinfo /vsizip//vagrant/shared/test_data/sentinel1a_l1/S1A_EW_GRDM_1SDH_20150702T172954_20150702T173054_006635_008DA5_55D1.zip/S1A_EW_GRDM_1SDH_20150702T172954_20150702T173054_006635_008DA5_55D1.SAFE/measurement/s1a-ew-grd-hv-20150702t172954-20150702t173054-006635-008da5-002.tiff
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
Warning 1: Recode from CP437 to UTF-8 failed with the error: "Invalid argument".
gdalinfo failed - unable to open '/vsizip//vagrant/shared/test_data/sentinel1a_l1/S1A_EW_GRDM_1SDH_20150702T172954_20150702T173054_006635_008DA5_55D1.zip/S1A_EW_GRDM_1SDH_20150702T172954_20150702T173054_006635_008DA5_55D1.SAFE/measurement/s1a-ew-grd-hv-20150702t172954-20150702t173054-006635-008da5-002.tiff'.

Workaround.
Following the hint in this ticket I've set environment variable:
export CPL_ZIP_ENCODING=UTF-8
Then it works as expected.

But why does it happen? It did not happen with gdal binaries from other channles (recipe)

Fix?

gdalwarp missing libjson library...

Mac OS 10.10.5
conda 4.0.5
conda create --name py3exp python=3 -y
source activate py3exp

Then I run the following shell script:

#!/bin/sh

echo "1 2 3 4\n5 6 7 8\n9 10 11 12\n13 14 15 16" > grid.asc
echo "ncols 4\nnrows 4\nxllcenter -70.0\nyllcenter -19.0\ncellsize 5\nodata_value -9999\n" > grid.hdr
proj4="+y_0=2400761.714982585 +lat_ts=-19.6097 +a=6378137.0 +proj=merc +units=m +b=6356752.3142 +lat_0=-19.6097 +x_0=-0.0 +lon_0=-70.7691"
gdalwarp -s_srs "+proj=latlong" -t_srs "$proj4" -of EHdr grid.asc grid.flt

and I get the following error:

dyld: Library not loaded: /usr/local/lib/libjson-c.2.dylib
Referenced from: /Users/mhearne/anaconda/envs/py3exp/bin/gdalwarp
Reason: image not found
testwarp.sh: line 6: 19723 Trace/BPT trap: 5 gdalwarp -s_srs "+proj=latlong" -t_srs "$proj4" -of EHdr grid.asc grid.flt

install fails on a fresh conda installation

Installer used: Anaconda3-4.1.1-Windows-x86_64

log:

The following specifications were found to be in conflict: - gdal -> jpeg 9* - gdal -> python 2.6*|2.7*|3.3*|3.4* Use "conda info <package>" to see the dependencies for each package.

Re-build gdal for Python 3.4 and 3.5

Currently we have the following dependencies pulling our latest xz:

openjpeg → libtiff → xz

libspatialite → libxml2 → xz

and our xz 5.2.2 is a no-no in Python 3.4.4 and Python 3.5. (It is OK on Python 3.4.1 though.)

To work around that I added the following lines to our recipe:

https://github.com/conda-forge/gdal-feedstock/blob/master/recipe/meta.yaml#L38-L39
https://github.com/conda-forge/gdal-feedstock/blob/master/recipe/meta.yaml#L49
https://github.com/conda-forge/gdal-feedstock/blob/master/recipe/meta.yaml#L61-L62
https://github.com/conda-forge/gdal-feedstock/blob/master/recipe/meta.yaml#L72
https://github.com/conda-forge/gdal-feedstock/blob/master/recipe/run_test.py#L43-L47
https://github.com/conda-forge/gdal-feedstock/blob/master/recipe/build.sh#L13-L16

All that should be fixed once we can install xz 5.2.2 in Pythons 3.4 and 3.5

Missing AdobeDeflate codec on Windows

I've been experiencing the following exception using rasterio on Windows:

Traceback (most recent call last):
  File "fix2.py", line 5, in <module>
    src = rasterio.open(filename, "r")
  File "C:\Miniconda3-x64\envs\deflate\lib\site-packages\rasterio\__init__.py",
line 193, in open
    s.start()
  File "rasterio\_base.pyx", line 72, in rasterio._base.DatasetReader.start (ras
terio/_base.c:2836)
  File "rasterio\_base.pyx", line 74, in rasterio._base.DatasetReader.start (ras
terio/_base.c:2788)
  File "rasterio\_err.pyx", line 196, in rasterio._err.CPLErrors.check (rasterio
/_err.c:1760)
rasterio._err.CPLE_AppDefined: Cannot open TIFF file due to missing codec.

I get a similar message trying to use the command line utils for GDAL:

0...10...20...30...40...50...60...70...80...90...100 - done.
Warning 1: 15_DSM.tif:AdobeDeflate compression support is not configured
ERROR 1: Cannot open TIFF file due to missing codec.
Warning 1: Can't open 15_DSM.tif. Skipping it

This seems to be a Windows specific issue - I have no issues reading the file(s) on Linux. I can't presently share the specific files in question due to licencing restrictions. I'll try to find something I can share.

I can't see anything in the builds that would cause this. I'm running the latest everything (64-bit):

    affine:        2.0.0.post1-py34_0     conda-forge
    click:         6.6-py34_0
    click-plugins: 1.0.3-py34_0           conda-forge
    cligj:         0.4.0-py34_0
    curl:          7.48.0-vc10_2          conda-forge [vc10]
    expat:         2.1.0-vc10_1           conda-forge [vc10]
    gdal:          2.1.0-np111py34_vc10_5 conda-forge [vc10]
    geos:          3.4.2-vc10_2           conda-forge [vc10]
    hdf4:          4.2.11-vc10_4          conda-forge [vc10]
    hdf5:          1.8.17-vc10_2          conda-forge [vc10]
    jpeg:          9b-vc10_0              conda-forge [vc10]
    kealib:        1.4.6-vc10_2           conda-forge [vc10]
    krb5:          1.14.2-vc10_0          conda-forge [vc10]
    libnetcdf:     4.4.0-vc10_1           conda-forge [vc10]
    libpng:        1.6.21-vc10_1          conda-forge [vc10]
    libtiff:       4.0.6-vc10_4           conda-forge [vc10]
    mkl:           11.3.3-1
    numpy:         1.11.0-py34_1
    openjpeg:      2.1.0-vc10_5           conda-forge [vc10]
    proj.4:        4.9.2-py34_vc10_0      conda-forge [vc10]
    pyparsing:     2.1.1-py34_0           conda-forge
    rasterio:      0.36.0-np111py34_0     conda-forge
    snuggs:        1.3.1-py34_0           conda-forge
    xerces-c:      3.1.2-vc10_0                       [vc10]
    zlib:          1.2.8-vc10_3           conda-forge [vc10]

GDAL_DATA environment variable not set in Windows

Hi,
I am working on Windows 10 and I have installed gdal using:

conda config --add channels conda-forge
conda install gdal

However, it does not set (or reset) GDAL_DATA. First, I had GDAL_DATA already defined from a previous installation, but it did not point to the right folder so my scripts did not work. Then I deleted it and re-installed gdal but that did not work either. The environment variable is not defined.

BTW, I am using Python 2.7 and Anaconda 4.0.0.
Thanks.

Use libxml2 and libspatialite on OS X

I am not using libxml2 and libspatialite on OS X because of #27 (comment)

Missing Windows binaries for version 2.1.0 build number 4

It appears some of the version 2.1.0 build number 4 binaries are missing for Windows. To be accurate, these are the only ones I can find. List generated by running conda server show conda-forge/gdal/2.1.0 and doing some filtering.

win-32/gdal-2.1.0-np110py27_vc9_4.tar.bz2
win-32/gdal-2.1.0-np110py34_vc10_4.tar.bz2
win-32/gdal-2.1.0-np110py35_vc14_4.tar.bz2
win-32/gdal-2.1.0-np111py27_vc9_4.tar.bz2
win-64/gdal-2.1.0-np110py27_vc9_4.tar.bz2
win-64/gdal-2.1.0-np110py34_vc10_4.tar.bz2
win-64/gdal-2.1.0-np111py27_vc9_4.tar.bz2

This is actually causing @kmuehlbauer significant difficulties building wradlib on Windows. I'm going to try restarting AppVeyor on master to see if those binaries merely didn't get uploaded. However, if that doesn't work, we need to do some detective work to figure out what went wrong.

Symbol not found: __ZN6kealib10KEAImageIO10isKEAImageESs

This looks like gdal needs a rebuild against the latest version of kealib?

https://travis-ci.org/OGGM/OGGM-Anaconda/jobs/144452309#L1940