GDAL Image Formats¶

In case of version mismatch¶

We recommend matching the version gdal jar to the version of gdal available in your environment:

gdalinfo --version

GDAL 3.4.1, released 2021/12/27

If you are using a version of GDAL that does not match the one expected by GeoServer, you can go and replace the gdal-3.2.0.jar file with the equivalent java binding jar (typically named either gdal-<version>.jar) included with your GDAL version:

• If your GDAL version does not include a bindings jar, it was probably not compiled with the java bindings and will not work with GeoServer.

• You may also search for the correct gdal jar here: https://search.maven.org/artifact/org.gdal/gdal

Windows packages and setup¶

For Windows, gisinternals.com provides complete packages, with Java bindings support, in the release-<version>-GDAL-<version>-mapserver-<version>.zip packages (the GDAL binary downloads at the time of writing do not include Java support).

Unpack the zip file in a suitable location, and then set the following variables before starting up GeoServer:

set PATH=%PATH%;C:\<unzipped_package>\bin;C:\<unzipped_package>\bin\gdal\java
set GDAL_DRIVER_PATH=C:\<unzipped_package>\bin\gdal\plugins
set GDAL_DATA=C:\<unzipped_package>\bin\gdal-data

There are a few optional drivers that you can find in file:C:<unzipped_package>bingdalplugins-extra and C:<unzipped_package>bingdalplugins-optional. Include these paths in `GDAL_DRIVER_PATH enables the additional formats.

Note on running GeoServer as a Service on Windows¶

Deploying the GDAL ImageI/O-Ext native libraries in a location referred by the PATH environment variable (like, as an instance, the JDK/bin folder) will not allow the GeoServer service to use GDAL. As a result, during the service startup, GeoServer log will likely report the following message:

it.geosolutions.imageio.gdalframework.GDALUtilities loadGDAL
WARNING: Native library load failed.java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path

Taking a look at the jsl74.ini configuration file available inside the GeoServer installation , there is this useful entry:

;The java command line
;The entry method below using a parameter list still works but the command line variant is more convenient.
;Everything separated by whitespace on a java command line is broken down into a parameter here.
;You don't need to care about quotes
;around strings containing spaces here. e.g.
cmdline = -cp "..\src" com.roeschter.jsl.TelnetEcho

To allow the GDAL native DLLs to be loaded:

1. Edit the command line to include -Djava.library.path with the location of your GDAL libraries.

Linux packages and setup¶

For common LTS Linux distribution there are packages for GDAL and the associated Java bindings, e.g., on Ubuntu and derivatives you can install them using:

sudo apt-get install gdal-bin libgdal-java

The libraries as installed above are already in the search path, so no extra setup is normally needed. In case setting up the GDAL_DATA is required to handle certain projections, it’s normally found in /usr/share/gdal/<version>, so you can execute the following prior to start GeoServer, e.g:

export GDAL_DATA=/usr/share/gdal/<version>

In case you decide to build from sources instead, remember to run configure with --with-java, and after the main build and install, get into the swig/java and run a build and install there. For more information about building GDAL see:

• General build information

• Specific info to build GDAL Java bindings

After the build and installation, export the following variables to make GeoServer use the GDAL custom build:

export LD_LIBRARY_PATH=/<path_to_gdal_install>/lib
export GDAL_DATA=/<path_to_gdal_install>/share/gdal

Example¶

Suppose you have 3 raster files with the following paths:

• /data/raster/charts/nitf/italy_2015.ntf

• /data/raster/satellite/ecw/orthofoto_2014.ecw

• /data/raster/satellite/landsat/mrsid/N-32-40_2000.sid

They can be represented by this tree:

/data
 \---raster
     +---charts
     |   \---nitf
     |           italy_2015.ntf
     |
     \---satellite
         +---ecw
         |       orthofoto_2014.ecw
         |
         \---landsat
             \---mrsid
                     N-32-40_2000.sid

In order to support external footprints you should

1. Create a /footprints (as an example) directory on disk

2. Set the FOOTPRINTS_DATA_DIR=/footprints variable/property.

3. Replicate the rasters folder hierarchy inside the specified folder, using the full paths.

4. Put the 3 WKT files in the proper locations:

• /footprints/data/raster/charts/nitf/italy_2015.wkt

• /footprints/data/raster/satellite/ecw/orthofoto_2014.wkt

• /footprints/data/raster/satellite/landsat/mrsid/N-32-40_2000.wkt

Which can be represented by this tree:

/footprints
 \---data
     \---raster
         +---charts
         |   \---nitf
         |           italy_2015.wkt
         |
         \---satellite
             +---ecw
             |       orthofoto_2014.wkt
             |
             \---landsat
                 \---mrsid
                         N-32-40_2000.wkt

Such that, in the end, you will have the following folders hierarchy tree:

+---data
|   \---raster
|       +---charts
|       |   \---nitf
|       |           italy_2015.ntf
|       |
|       \---satellite
|           +---ecw
|           |       orthofoto_2014.ecw
|           |
|           \---landsat
|               \---mrsid
|                       N-32-40_2000.sid
|
\---footprints
    \---data
        \---raster
            +---charts
            |   \---nitf
            |           italy_2015.wkt
            |
            \---satellite
                +---ecw
                |       orthofoto_2014.wkt
                |
                \---landsat
                    \---mrsid
                            N-32-40_2000.wkt

Note the parallel mirrored folder hierarchy, with the only differences being a /footprints prefix at the beginning of the path, and the change in suffix.