ADF File Documentation

---

Technical details

Feature	Value
Full name (SITE identity)	Esri ARC/INFO coverage / ArcInfo Binary Grid file
File extension	.adf
MIME type	application/octet-stream
Format type	Binary GIS data; a coverage/grid is a folder of .adf files
Developer	Esri (Environmental Systems Research Institute)
Byte order	Big-endian (MSB) integers and doubles
Grid data file	w001001.adf — tiled cell values, run-length compressed
Grid index file	w001001x.adf — per-tile offset and size
Header file	hdr.adf — 308 bytes; magic GRID1.2, cell type, tile geometry
Bounds file	dblbnd.adf — 32 bytes; four MSB doubles (LLX, LLY, URX, URY)
Statistics file	sta.adf — 32 bytes; min, max, mean, std-dev
Projection file	prj.adf — optional map-projection text
Attribute file	vat.adf — value attribute table (for integer grids)
Block header magic	w001001.adf / w001001x.adf begin with a 100-byte header
Read by	QGIS, ArcGIS, GDAL (AIG driver), GRASS GIS
Open standard	No (Esri format; documented by GDAL through reverse engineering)
Also uses .adf	Amiga Disk File (floppy image, mounted in WinUAE/FS-UAE)
Specification	GDAL — Arc/Info Binary Grid

What is an ADF file?

Under the identity this page uses, an .adf file is a piece of an Esri ARC/INFO coverage or binary grid — the native internal format of Esri’s ARC/INFO (later ArcInfo) GIS. The defining fact is that a single .adf is not a standalone dataset. An ArcInfo grid or coverage is a directory (a workspace subfolder) containing several .adf files that only make sense together: one holds the raster cell values, another the header, another the tile index, others the bounds, statistics and projection. You point a GIS application at the folder, and it assembles them into one raster or feature dataset.

This article describes that GIS format, following the layout documented by the GDAL Arc/Info Binary Grid driver. One caveat up front, because .adf is badly overloaded: the same extension is used for the Amiga Disk File, a raw 1:1 image of a Commodore Amiga floppy that you mount in an emulator such as WinUAE or FS-UAE. If your .adf is a single file of about 901,120 bytes and has nothing to do with maps, it is an Amiga floppy image, not GIS data. The sections below cover the multi-file structure, each companion file, and then the real substance: the tiled, run-length-compressed raster in w001001.adf and its index.

A grid is a folder, not a file

An ArcInfo binary grid is organised as a coverage-level directory inside an ARC/INFO workspace. The files you find in it are:

a_grid/                (the grid directory = the dataset)
 ├─ hdr.adf            header: cell type, tile geometry, pixel size
 ├─ w001001.adf        the raster data itself (tiled, compressed)
 ├─ w001001x.adf       tile index: offset + size of each tile
 ├─ dblbnd.adf         georeferenced bounds of the grid
 ├─ sta.adf            statistics: min, max, mean, std-dev
 ├─ vat.adf            value attribute table (integer grids)
 └─ prj.adf            projection definition (optional)

Every one of these is a binary file, and every multi-byte value in them is stored big-endian (most-significant byte first), a legacy of ARC/INFO’s origins on big-endian workstations. Because the dataset is the folder, you cannot meaningfully double-click a lone w001001.adf; the reader needs hdr.adf to know the grid’s geometry and w001001x.adf to locate tiles within the data file.

hdr.adf: the 308-byte header

The header file hdr.adf is a fixed 308-byte record that describes the grid’s geometry and how its data is stored. Its documented fields include:

Offset	Size	Field	Meaning
0	8	HMagic	ASCII GRID1.2
16	4	HCellType	1 = integer, 2 = floating-point
20	4	CompFlag	compression flag
256	8	HPixelSizeX	cell width (double)
264	8	HPixelSizeY	cell height (double)
288	4	HTilesPerRow	tiles across
292	4	HTilesPerColumn	tiles down
296	4	HTileXSize	cells per tile, horizontally
304	4	HTileYSize	cells per tile, vertically

The magic string GRID1.2 at offset 0 is the closest thing the format has to a signature. HCellType tells the reader whether cells are integers (with an attribute table in vat.adf) or floating-point values. The tile fields matter because the raster is not stored as one continuous scanline image; it is cut into rectangular tiles, and these numbers say how many tiles there are and how big each is.

dblbnd.adf and sta.adf: georeferencing and statistics

Two small 32-byte files pin the grid to the world and summarise its values. dblbnd.adf holds four big-endian doubles — lower-left X, lower-left Y, upper-right X, upper-right Y — the georeferenced bounding box of the grid. Combined with the pixel size from hdr.adf, the bounds give the raster’s true row and column count (the raster dimensions come from the bounds and pixel size, because tiles are allocated a little larger than the data they hold). sta.adf holds four more doubles: the minimum, maximum, mean and standard deviation of the cell values, which a GIS uses to stretch a display or report grid statistics without rescanning every cell. The optional prj.adf is a small text file naming the map projection, and vat.adf is the value attribute table that pairs each distinct integer value (a “zone”) with attribute data.

w001001x.adf: the tile index

The index file w001001x.adf is what lets a reader find any tile without scanning the whole data file. It begins with a 100-byte header (its first bytes are a fixed magic, commonly 00 00 27 0A, and a file-size field near offset 24, measured in 16-bit shorts). After the header comes one 8-byte entry per tile, at offsets 100 + t×8: a 4-byte tile offset followed by a 4-byte tile size, both expressed in shorts (multiply by 2 for bytes). To read tile t, the reader jumps to entry t in the index, reads the offset and size, and then seeks to exactly that place in w001001.adf. Because tiles are variable length once compressed, this index is essential; without it, tile boundaries in the data file could not be found.

w001001.adf: tiled cells and run-length compression

The raster values live in w001001.adf. It too opens with a 100-byte header, after which the tiles follow, each pointed to by the index. Every tile starts with a short block header before its pixel data:

Tile block
  RTileSize  int16   size of this tile, in shorts
  RTileType  byte    how the pixels are encoded (see table)
  RMinSize   byte    number of bytes in the following minimum value
  RMin       ...     the tile's base/minimum value (RMinSize bytes)
  data       ...     pixel data, encoded per RTileType

The RTileType byte selects the encoding, and this is where the format’s compression lives. A tile that is entirely one value (very common in classified or masked rasters) is stored as a single constant block with type 0x00 and no pixel data at all — every cell equals RMin. Other types store raw pixels at a given bit depth, and several use run-length encoding, which is efficient for the large uniform regions typical of elevation, land-cover and mask grids:

RTileType	Encoding
0x00	Constant block — every cell equals RMin
0x01 / 0x04 / 0x08	Raw 1-bit / 4-bit / 8-bit pixels
0x10 / 0x20	Raw 16-bit / 32-bit pixels
0xF0 / 0xFC	Run-length encoded 16-bit / 8-bit
0xE0	Run-length encoded 32-bit
0xDF / 0xD7 / 0xCF	Runs mixing RMin/literal/no-data values
0xFF	CCITT RLE (1-bit)

Storing a per-tile RMin and coding pixels as offsets from it, then run-length compressing runs of equal cells, is what keeps ArcInfo grids compact for the smoothly varying or blocky data GIS rasters usually contain.

Coverages, grids and reading them today

The .adf extension appears in two related Esri contexts. A grid is the raster case described above. A coverage is the older ARC/INFO vector model (arcs, nodes, polygons, labels), whose geometry and topology are likewise stored as a set of .adf files in a coverage directory (for example arc.adf, lab.adf) with an INFO subfolder holding attribute tables. Both are legacy Esri formats: ArcInfo Workstation and ArcMap are retired, and reading these datasets today is done in tools that implemented the format independently — the free GDAL library (its AIG driver), QGIS, and GRASS GIS all open an ArcInfo grid folder directly, and modern ArcGIS Pro can still read them. The practical workflow is to open or point the tool at the whole grid/coverage directory and, if you want a portable copy, export to GeoTIFF for a raster or a shapefile/GeoPackage for a coverage.

FAQ

Why can’t I open a single w001001.adf on its own?

Because an ArcInfo grid is a whole folder, not one file. w001001.adf holds only the compressed cell data; the reader also needs hdr.adf for the grid geometry and w001001x.adf for the tile index to locate anything inside it. Point QGIS, GDAL or ArcGIS at the containing directory, not at the lone file.

My .adf is a single file about 901 KB and has no GIS files — what is it?

That is almost certainly an Amiga Disk File, a raw image of a Commodore Amiga floppy (the standard double-density image is exactly 901,120 bytes). It is unrelated to Esri GIS data. Mount it in an Amiga emulator such as WinUAE or FS-UAE, or extract its files with ADFlib’s unadf.

How do I convert an ArcInfo grid to something more portable?

Open the grid folder in GDAL, QGIS or ArcGIS and export it. For a raster grid, GeoTIFF is the usual portable target (gdal_translate a_grid out.tif, giving GDAL the grid directory). A vector coverage exports to a shapefile or GeoPackage. There is no in-place file swap because the source is a multi-file Esri dataset.

References

• GDAL — Arc/Info Binary Grid format driver
• Esri — File structure of an Arc/Info Grid
• Esri — Esri Grid format

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.