GDAL Image Formats¶
GeoServer can leverage the ImageI/O-Ext GDAL libraries to read selected coverage formats. GDAL is able to read many formats, but for the moment GeoServer supports only a few general interest formats and those that can be legally redistributed and operated in an open source server.
The following image formats can be read by GeoServer using GDAL:
DTED: Military Elevation Data (
HFA: Erdas Imagine (
JP2MrSID: JPEG2000 (
MrSID: Multi-resolution Seamless Image Database
NITF: National Imagery Transmission Format
ECW: ERDAS Compressed Wavelets (
JP2ECW: JPEG2000 (
AIG: Arc/Info Binary Grid
JP2KAK: JPEG2000 (
Installing GDAL extension¶
From GeoServer version 2.2.x, GDAL must be installed as an extension. To install it:
Ensure to match plugin (example 2.26-SNAPSHOT above) version to the version of the GeoServer instance.
The download link for GDAL will be in the Extensions section under Coverage Format.
Extract the files in this archive to the
WEB-INF/libdirectory of your GeoServer installation. On Windows You may be prompted for confirmation to overwrite existing files, confirm the replacement of the files
Moreover, in order for GeoServer to leverage these libraries, the GDAL (binary) libraries must be installed through your host system’s OS. Once they are installed, GeoServer will be able to recognize GDAL data types. See below for more information.
Installing GDAL native libraries¶
Starting with GeoServer 2.21.x the imageio-ext plugin is tested with GDAL version 3.x (tested in particular with 3.2.x and 3.4.x).
The imageio-ext plugin is tested with the GDAL 3.2 SWIG bindings, included in the extension download as
In case of version mismatch¶
We recommend matching the version
gdal jar to the version of gdal available in your environment:
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
gdaljar 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).
zip file in a suitable location, and then set the following variables before starting up GeoServer:
There are a few optional drivers that you can find in file:C:<unzipped_package>bingdalplugins-extra
C:<unzipped_package>bingdalplugins-optional. Include these paths in
`GDAL_DRIVER_PATH enables the additional formats.
Before adding the extra formats please make sure that you are within your rights to use them in a server environment (some packages are specifically forbidden from free usage on the server side and require a commercial licence, e.g., ECW).
Depending on the version of the underlying operating system you will have to pick up the right one. You can google around for the one you need. Also make sure you download the 32 bit version if you are using a 32 bit version of Windows or the 64 bit version (has a “-x64” suffix in the name of the zip file) if you are running a 64 bit version of Windows. Again, pick the one that matches your infrastructure.
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:
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:
Edit the command line to include
-Djava.library.pathwith 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
/usr/share/gdal/<version>, so you can execute the following prior to start GeoServer, e.g:
In case you decide to build from sources instead, remember to run
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:
After the build and installation, export the following variables to make GeoServer use the GDAL custom build:
Testing the installation¶
Once these steps have been completed, restart GeoServer.
Navigate to Modules tab, and click ImageI/O-Ext GDAL Coverage Extension link for status information.page, and change to the
This information can be used to verify that the extension is active, the version of GDAL used, and the version of the SWIG bindings used.
If all the steps have been performed correctly, new data formats will be in the Raster Data Sources list when creating a new data store in the Stores section as shown here below.
If new formats do not appear in the GUI and you see the following message in the log file:
WARNING: Native library load failed.java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path*
WARNING: Native library load failed.java.lang.UnsatisfiedLinkError: no gdalalljni in java.library.path*
This means that the extension was installed, bu twas not able to access your gdal library for some reason.
Configuring a DTED data store¶
Configuring a EHdr data store¶
Configuring a ERDASImg data store¶
Configuring a JP2MrSID data store¶
Configuring a NITF data store¶
Supporting vector footprints¶
Starting with version 2.9.0, GeoServer supports vector footprints. A footprint is a shape used as a mask to hide those pixels that are outside of the mask, hence making that part of the parent image transparent. The currently supported footprint formats are WKB, WKT and Shapefile. By convention, the footprint file should be located in the same directory as the raster data that the footprint applies to.
In the examples of this section and related subsections, we will always use .wkt as extension, representing a WKT footprint, although both .wkb and .shp are supported too.
For example, supposing you have a MrSID file located at
to be masked, you just need to place a WKT file on the same folder, as
Note that the footprint needs to have same path and name of the original data file, with .wkt extension.
This is how the sample footprint geometry looks:
Once footprint file has been added, you need to change the FootprintBehavior parameter from None (the default value) to Transparent, from the layer configuration.
The next image depicts 2 layer previews for the same layer: the left one has no footprint, the right one has a footprint available and FootprintBehavior set to transparent.
External Footprints data directory¶
As noted above, the footprint file should be placed in the same directory as the raster file. However in some cases this may not be possible. For example, the folder containing the raster data may be read only.
As an alternative, footprint files can be located in a common directory, the footprints data directory. The subdirectories and file names under that directory must match the original raster path and file names. The footprints data directory is specified as a Java System Property or an Environment Variable, by setting the FOOTPRINTS_DATA_DIR property/variable to the directory to be used as base folder.
Suppose you have 3 raster files with the following paths:
They can be represented by this tree:
In order to support external footprints you should
/footprints(as an example) directory on disk
Replicate the rasters folder hierarchy inside the specified folder, using the full paths.
Put the 3 WKT files in the proper locations:
Which can be represented by this tree:
Such that, in the end, you will have the following folders hierarchy tree:
| | \---nitf
| | italy_2015.ntf
| | orthofoto_2014.ecw
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.