What is GDAL and what is it used for?

Updated

GDAL is a translator library for raster and vector geospatial data formats, released under an MIT-style open source license by the Open Source Geospatial Foundation (OSGeo). It is used when you need to read, write, convert, or process geospatial data across many different formats without writing separate code for each one. As a library, it presents a single raster abstract data model and a single vector abstract data model to the calling application for all supported formats, and it also ships with a variety of command line utilities for data translation and processing.

The core idea: one data model, many formats

Geospatial data comes in dozens of incompatible formats. Without a common layer, an application that wants to open a GeoTIFF, an ENVI file, and a shapefile would need three separate format handlers.

GDAL solves this by defining one abstract model for raster data and one for vector data. A driver for each format translates between that format and the abstract model. Your application talks only to the abstract model, so adding a new format means adding a driver — not rewriting your code.

This is why GDAL is often described as a translator library rather than a single tool. The translation happens both between formats and between the format's native structure and the model your program expects.

Raster vs. vector

GDAL handles two families of data, and the distinction matters when you search the documentation:

Raster Vector
Data type Grids of cells (pixels) with values Points, lines, polygons with attributes
Typical examples Satellite imagery, elevation models, scanned maps Shapefiles, GeoJSON, road networks, boundaries
Abstract model Single raster abstract data model Single vector abstract data model
Drivers Raster drivers (e.g. AAIGrid, ADRG, COG, DTED, ECW, ENVI) Vector drivers

Historically the vector side was called OGR, and you will still see "GDAL/OGR" in release notes and older documentation. In current GDAL, both live under the same project.

What you can actually do with it

The documentation groups the practical uses into a few areas:

  • Format conversion — read data in one format and write it in another, using the same abstract model on both ends.
  • Data processing — the command line utilities cover translation and processing tasks, so you can run operations without writing code.
  • Act as a foundation for other software — GDAL is used as the geospatial read/write layer inside many other applications. The documentation maintains a "Software using GDAL" page listing these.

A concrete example: you have elevation data in a military DTED file and need it as a Cloud Optimized GeoTIFF for a web map. Both are raster formats with drivers in GDAL, so the conversion is a translation between two drivers through the shared raster model — no custom parsing of the DTED structure required.

Where to start in the documentation

The GDAL documentation is organized so you can go directly to what you need:

  • Download — source code, binaries, and containers.
  • Programs — the command line utilities, split into the gdal application, "traditional" applications, and the individual raster and vector drivers.
  • Raster drivers and Vector drivers — the full list of supported formats, each with its own page.
  • User API — for calling GDAL from your own code.
  • Tutorials — guided introductions.
  • How to develop GDAL? and How to contribute? — for working on the project itself.
  • FAQ, Glossary, and License — reference material.

The documentation is also available as a PDF for offline browsing.

Version and citation details

The NEWS page describes the August 2026 GDAL/OGR 3.13.3 release, so that is the version to check when you need current behavior. If you cite GDAL in a publication, the documentation provides a Digital Object Identifier (DOI) for that purpose.

When GDAL is the right fit

GDAL is a strong choice when your problem is fundamentally about moving geospatial data between formats or reading it in a consistent way, and when you are comfortable working either through a command line or through a library API. It is less about producing finished maps and more about making the data underneath them accessible.

If you only ever work with one format and one application that already handles it, you may never need to touch GDAL directly — but it is likely running underneath that application anyway.