EVOLUTION-MANAGER

Edit File: aigrid_format.html

<html>

<head>
<title>Arc/Info Binary Grid Format</title>
</head>

<h1>Arc/Info Binary Grid Format</h1>

<i>by <a href="http://pobox.com/~warmerdam">Frank Warmerdam</a></i>
(<a href="mailto:warmerdam@pobox.com">warmerdam@pobox.com</a>)<p>

The Arc/Info Binary Grid format is the internal working format of the
Arc/Info Grid product.  It is also usable and creatable within the
spatial analyst component of ArcView.  It is a tiled (blocked) format with run
length compression capable of holding raster data of up to 4 byte integers
or 4 byte floating data. <p>

This format should not be confused with the Arc/Info ASCII Grid format
which is the interchange format for grids.  Files can be converted between
binary and ASCII format with the GRIDASCII and ASCIIGRID commands in
Arc/Info.  This format is also different than the flat binary raster
output of the GRIDFLOAT command.  The Arc/Info binary float, and ASCII
formats are also accessible from within ArcView.<p>

This format should also not be confused with what I know as ESRI BIL format.
This is really a standard ESRI way of creating a header file (.HDR)
describing the data layout a binary raster file containing raster data.<p>

<h2>Version</h2>

I am not sure yet how the versions work for grid files.  I have been
working primarily with grid files generated by ArcView 3.x, and its associated
gridio API.  The hdr.adf files I have examined start with the string
<b>GRID1.2</b> for what that's worth.  Certainly the file naming conventions
seem to follow the Arc/Info 7.x conventions rather than that of earlier
versions.<p>

A grid coverage actually consists of a number of files.  A grid normally
lives in its own directory named after the grid.  For instance, the
grid <b>nwgrd1</b> lives in the directory <b>nwgrd1</b>, and has the following
component files:<p>

<pre>
-rwxr--r--   1 warmerda users          32 Jan 22 16:07 nwgrd1/dblbnd.adf
-rwxr--r--   1 warmerda users         308 Jan 22 16:07 nwgrd1/hdr.adf
-rwxr--r--   1 warmerda users          32 Jan 22 16:07 nwgrd1/sta.adf
-rwxr--r--   1 warmerda users        2048 Jan 22 16:07 nwgrd1/vat.adf
-rwxr--r--   1 warmerda users      187228 Jan 22 16:07 nwgrd1/w001001.adf
-rwxr--r--   1 warmerda users        6132 Jan 22 16:07 nwgrd1/w001001x.adf
</pre>

Sometimes datasets will also include a prj.adf files containing the projection
definition in the usual ESRI format. Grids also normally have associated
tables in the info directory.  This is beyond the scope of my discussion
for now.<p>

The files have the following roles:

<ul>

<li> <a href="#dblbnd">dblbnd.adf</a>: Contains the bounds
(LLX, LLY, URX, URY) of the portion of utilized portion of the grid.<p>

<li> <a href="#hdr.adf">hdr.adf</a>: This is the header, and contains
information on the tile sizes, and number of tiles in the dataset.  It also
contains assorted other information I have yet to identify.<p>

<li> <a href="#sta">sta.adf</a>: This contains raster statistics.  In
particular, the raster min, max, mean and standard deviation.<p>

<li> <b>vat.adf</b>: This relates to the value attribute table.  This is
the table corresponding integer raster values with a set of attributes.  I
presume it is really just a pointer into info in a manner similar to the
pat.adf file in a vector coverage, but I haven't investigated yet. <p>

<li> <a href="#w001001">w001001.adf</a>:
This is the file containing the actual raster data.
<p>

<li> <a href="#w001001x">w001001x.adf</a>:
This is an index file containing pointers to
each of the tiles in the w001001.adf raster file.<p>

</ul>

<hr>

<h2><a name="dblbnd">dblbnd.adf - Georef Bounds</a></h2>

Fields:<p>

<table border>
<th>Start Byte
<th># of Bytes
<th>Format
<th>Name
<th>Description

<tr>
  <td> 0
  </td><td> 8
  </td><td> MSB double
  </td><td> D_LLX
  </td><td> Lower left X (easting) of the grid.  Generally -0.5 for an
ungeoreferenced grid.
  </td>
</tr>

<tr>
  <td> 8
  </td><td> 8
  </td><td> MSB double
  </td><td> D_LLY
  </td><td> Lower left Y (northing) of the grid. Generally -0.5 for an
ungeoreferenced grid.
  </td>
</tr>

<tr>
  <td> 16
  </td><td> 8
  </td><td> MSB double
  </td><td> D_URX
  </td><td> Upper right X (easting) of the grid. Generally #Pixels-0.5 for an
ungeoreferenced grid.
  </td>
</tr>

<tr>
  <td> 24
  </td><td> 8
  </td><td> MSB double
  </td><td> D_URY
  </td><td> Upper right Y (northing) of the grid. Generally #Lines-0.5 for an
ungeoreferenced grid.
  </td>
</tr>

</table>

This file is always 32 bytes long.  The bounds apply to the portion of the
grid that is in use, not the whole thing.<p>

<hr>

<h2><a name="w001001x">w001001x.adf - Tile Index</a></h2>

This is a binary dump of the first 320 bytes of a w001001x.adf
file.  <p>

<pre>
       0: 0000270A FFFFFC14 00000000 00000000 ~~'~~~~~~~~~~~~~
      16: 00000000 00000000 00000BFA 00000000 ~~~~~~~~~~~~~~~~
      32: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~
      48: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~
      64: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~
      80: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~
      96: 00000000 00000032 00000202 00000235 ~~~~~~~2~~~~~~~5
     112: 000001D4 0000040A 00000000 0000040B ~~~~~~~~~~~~~~~~
     128: 00000000 0000040C 00000000 0000040D ~~~~~~~~~~~~~~~~
     144: 00000000 0000040E 00000000 0000040F ~~~~~~~~~~~~~~~~
     160: 00000000 00000410 00000202 00000613 ~~~~~~~~~~~~~~~~
     176: 000001D4 000007E8 00000000 000007E9 ~~~~~~~~~~~~~~~~
     192: 00000000 000007EA 00000000 000007EB ~~~~~~~~~~~~~~~~
     208: 00000000 000007EC 00000000 000007ED ~~~~~~~~~~~~~~~~
     224: 00000000 000007EE 00000202 000009F1 ~~~~~~~~~~~~~~~~
     240: 000001D4 00000BC6 00000000 00000BC7 ~~~~~~~~~~~~~~~~
     256: 00000000 00000BC8 00000000 00000BC9 ~~~~~~~~~~~~~~~~
     272: 00000000 00000BCA 00000000 00000BCB ~~~~~~~~~~~~~~~~
     288: 00000000 00000BCC 00000202 00000DCF ~~~~~~~~~~~~~~~~
     304: 000001D4 00000FA4 00000000 00000FA5 ~~~~~~~~~~~~~~~~
</pre>

Fields:<p>

<table border>
<th>Start Byte
<th># of Bytes
<th>Format
<th>Description

<tr>
  <td> 0
  </td><td> 8
  </td><td>
  </td><td> Magic Number (always hex 00 00 27 0A FF FF ** **, usually ending in FC 14, FB F8 or FC 08).
  </td>
</tr>

<tr>
  <td> 24
  </td><td> 4
  </td><td> MSB Int32
  </td><td> Size of whole file in shorts (multiply by two
            to get file size in bytes).
  </td>
</tr>

<tr>
  <td> 100 + <b>t</b>*8
  </td><td> 4
  </td><td> MSB Int32
  </td><td> Offset to tile <b>t</b> in w001001.adf measured in two byte
            shorts.
  </td>
</tr>

<tr>
  <td> 104 + <b>t</b>*8
  </td><td> 4
  </td><td> MSB Int32
  </td><td> Size of tile <b>t</b> in 2 byte shorts.

</td>
</tr>

</table>

<hr>

<h2><a name="sta">sta.adf - Raster Statistics</a></h2>

Fields:<p>

<table border>
<th>Start Byte
<th># of Bytes
<th>Format
<th>Name
<th>Description

<tr>
  <td> 0
  </td><td> 8
  </td><td> MSB double
  </td><td> SMin
  </td><td> Minimum value of a raster cell in this grid.
  </td>
</tr>

<tr>
  <td> 8
  </td><td> 8
  </td><td> MSB double
  </td><td> SMax
  </td><td> Maximum value of a raster cell in this grid.
  </td>
</tr>

<tr>
  <td> 16
  </td><td> 8
  </td><td> MSB double
  </td><td> SMean
  </td><td> Mean value of a raster cells in this grid.
  </td>
</tr>

<tr>
  <td> 24
  </td><td> 8
  </td><td> MSB double
  </td><td> SStdDev
  </td><td> Standard deviation of raster cells in this grid.
  </td>
</tr>

</table>

This file is always 32 bytes long. <p>

<hr>

<h2><a name="w001001">w001001.adf - Raster Data</a></h2>

This is a binary dump of the first 320 bytes of a w001001.adf
file.<p>

<pre>
       0: 0000270A FFFFFC14 00000000 00000000 ~~'~~~~~~~~~~~~~
      16: 00000000 00000000 00016DAE 00000000 ~~~~~~~~~~m~~~~~
      32: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~
      48: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~
      64: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~
      80: 00000000 00000000 00000000 00000000 ~~~~~~~~~~~~~~~~
      96: 00000000 02020800 00373D42 5C5A4D31 ~~~~~~~~~7=B\ZM1
     112: 200A0108 0E1D4F89 9C9A9392 8C7E6653  ~~~~~O~~~~~~~fS
     128: 5151596D 83919290 868A8B87 807A7A7B QQYm~~~~~~~~~zz{
     144: 7C7A766F 64481D00 0406305F 6B6C6A5B |zvodH~~~~0_klj[
     160: 5D53513C 2D2D2732 24293F54 40354C55 ]SQ<--'2$)?T@5LU
     176: 67686258 514E4943 5859534A 41394D70 ghbXQNICXYSJA9Mp
     192: 75665659 66625A63 737A848E 9090979F ufVYfbZcsz~~~~~~
     208: 9F908C8F 8F96998E 8778685B 53536274 ~~~~~~~~~xh[SSbt
     224: 747B838A 8A8C8F92 8D979B94 8C8D9294 t{~~~~~~~~~~~~~~
     240: 8D8D8D8D 8C8B8989 8B8E908F 8E8E9092 ~~~~~~~~~~~~~~~~
     256: 90929394 989C9891 92939698 9B9B9C9C ~~~~~~~~~~~~~~~~
     272: 8E8E8F8F 8E8E8F90 898E918F 8B8A8E93 ~~~~~~~~~~~~~~~~
     288: 8B8D9093 94918C86 838DA1BC B7CEC9B0 ~~~~~~~~~~~~~~~~
     304: D4B0BB96 A0929E99 9797999B 9D9C9C9B ~~~~~~~~~~~~~~~~
</pre>

Fields:<p>

<table border>
<th>Start Byte
<th># of Bytes
<th>Format
<th>Name
<th>Description

<tr>
  <td> 0
  </td><td> 8
  </td><td>
  </td><td> RMagic
  </td><td> Magic Number (always hex 00 00 27 0A FF FF ** **, usually ending in FC 14, FB F8 or FC 08).
  </td>
</tr>

<tr>
  <td> 24
  </td><td> 4
  </td><td> MSB Int32
  </td><td> RFileSize
  </td><td> Size of whole file in shorts (multiply by two
            to get file size in bytes).
  </td>
</tr>

<tr>
  <td> 100, ...
  </td><td> 2
  </td><td> MSB Int16
  </td><td> RTileSize
  </td><td> Size of this tiles data measured in shorts.  This matches the size
in the index file, and does not include the tile size itself.  The next
tile starts <b>2*n+2</b> bytes after the start of this tile, where <b>n</b>
is the value of this field.
  </td>
</tr>

<tr>
  <td> 102, ...
  </td><td> 1
  </td><td> byte
  </td><td> RTileType
  </td><td> Tile type code indicating the organization of the following
data (integer coverages only).
  </td>
</tr>
<tr>
  <td> 103, ...
  </td><td> 1
  </td><td> byte
  </td><td> RMinSize
  </td><td> Number of bytes following to form the minimum value for the tile
(integer coverages only).
  </td>
</tr>

<tr>
  <td> 104, ...
  </td><td> (RMinSize bytes)
  </td><td> MSB Int (var size)
  </td><td> RMin
  </td><td> The minimum value pixels for this tile.  This number is added
to the pixel values for each pixel in this tile (integer coverages only).
I must stress that if RMinSize is less than 4 this is still a signed quantity.
For instance, if RMinSize is 2, the value is 65536 - byte0*256 - byte1 if
byte0 is &gt; 127.
  </td>
</tr>

<tr>
  <td> 104+RMinSize, ...
  </td><td> RTileSize*2 - 3 - RMinSize
  </td><td> variable
  </td><td> RTileData
  </td><td> The data for this tile.  Format varies according to RTileType
for integer coverages.
  </td>
</tr>

</table>
<p>

The fields RTileSize, RTileType, RMinSize, RMin, and RTileData occur in the
file for each tile of data present.  They are usually packed one after the
other, but this isn't necessarily guaranteed.  The index file (w001001x.adf)
should be used to establish the tile locations.  Note that tiles that
appear in the index file with a size of zero will appear as just two
bytes (zeros) for the RTileSize for that tile.<p>

<h3>Raster Size</h3>

The size of a the grid isn't as easy to deduce as one might expect.
The hdr.adf file contains the HTilesPerRow, HTilesPerColumn,
HTileXSize, and HTileYSize fields which imply a particular raster
space. However, it seems that this is created much larger than
necessary to hold the users raster data.  I have created 3x1 rasters
which resulted in the standard 8x512 tiles of 256x4 pixels each.<p>

It seems that the user portion of the raster has to be computed
based on the georeferenced bounds in the dblbnd.adf file (assumed
to be anchored at the top left of the total raster space), and
the HPixelSizeX, and HPixelSizeY fields from hdr.adf.<p>

<b> #Pixels = (D_URX - D_LRX) / HPixelSizeX</b><p>
<b> #Lines = (D_URY - D_LRY) / HPixelSizeY</b><p>

Based on this number of pixels and lines, it is possible to establish
what portion out of the top left of the raster is really <i>of
interest</i>.  All regions outside this appear to empty tiles,
or filled with no data markers.<p>

<h3>RTileType/RTileData</h3>

Each tile contains HBlockXSize * HBlockYSize pixels of data.  For floating
point and uncompressed integer files the data is just the tile size (in two
bytes) followed by the pixel data as 4 byte MSB order IEEE floating point
words.  For compressed integer
tiles it is necessary to interpret the RTileType to establish the details
of the tile organization:

<h4>RTileType = 0x00 (constant block)</h4>

All pixels take the value of the RMin.  Data is ignored.  It appears there is
sometimes a bit of meaningless data (up to four bytes) in the block.<p>

<h4>RTileType = 0x01 (raw 1bit data)</h4>

One full tile worth of data pixel values follows the RMin field, with
1bit per pixel.<p>

<h4>RTileType = 0x04 (raw 4bit data)</h4>

One full tiles worth of data pixel values follows the RMin field, with
4 bits per pixel.  The high order four bits of a byte comes before the low
order four bits.<p>

<h4>RTileType = 0x08 (raw byte data)</h4>

One full tiles worth of data pixel values (one byte per pixel) follows the
RMin field.<p>

<h4>RTileType = 0x10 (raw 16bit data)</h4>

One full tiles worth of data pixel values follows the RMin field, with
16 bits per pixel (MSB).<p>

<h4>RTileType = 0x20 (raw 32bit data)</h4>

One full tiles worth of data pixel values follows the RMin field, with
32 bits per pixel (MSB).<p>

<h4>RTileType = 0xCF (16 bit literal runs/nodata runs)</h4>

The data is organized in a series of runs.  Each run starts with a marker
which should be interpreted as:

<ul>
<li> <b>Marker < 128</b>: The marker is followed by <b>Marker</b> pixels of
literal data with two MSB bytes per pixel. <p>

<li> <b>Marker > 127</b>: The marker indicates that <b>256-Marker</b> pixels
of <i>no data</i> pixels should be put into the output stream.  No data
(other than the next marker) follows this marker.

</ul>

<h4>RTileType = 0xD7 (literal runs/nodata runs)</h4>

The data is organized in a series of runs.  Each run starts with a marker
which should be interpreted as:

<ul>
<li> <b>Marker < 128</b>: The marker is followed by <b>Marker</b> pixels of
literal data with one byte per pixel. <p>

<li> <b>Marker > 127</b>: The marker indicates that <b>256-Marker</b> pixels
of <i>no data</i> pixels should be put into the output stream.  No data
(other than the next marker) follows this marker.

</ul>

<h4>RTileType = 0xDF (RMin runs/nodata runs)</h4>

The data is organized in a series of runs.  Each run starts with a marker
which should be interpreted as:

<ul>
<li> <b>Marker < 128</b>: The marker is followed by <b>Marker</b> pixels of
literal data with one byte per pixel. <p>

<li> <b>Marker > 127</b>: The marker indicates that <b>256-Marker</b> pixels
of <i>no data</i> pixels should be put into the output stream.  No data
(other than the next marker) follows this marker.

</ul>

This is similar to 0xD7, except that the data size is zero bytes instead of
1, so only RMin values are inserted into the output stream.<p>

<h4>RTileType = 0xE0 (run length encoded 32bit)</h4>

The data is organized in a series of runs.  Each run starts with a marker
which should be interpreted as a <b>count</b>.  The four bytes following the
count should be interpreted as an MSB Int32 <b>value</b>.  They indicate
that <b>count</b> pixels of <b>value</b> should be inserted into the output
stream.<p>

<h4>RTileType = 0xF0 (run length encoded 16bit)</h4>

The data is organized in a series of runs.  Each run starts with a marker
which should be interpreted as a <b>count</b>.  The two bytes following the
count should be interpreted as an MSB Int16 <b>value</b>.  They indicate
that <b>count</b> pixels of <b>value</b> should be inserted into the output
stream.<p>

<h4>RTileType = 0xFC/0xF8 (run length encoded 8bit)</h4>

The data is organized in a series of runs.  Each run starts with a marker
which should be interpreted as a <b>count</b>.  The following byte is the
<b>value</b>.  They indicate
that <b>count</b> pixels of <b>value</b> should be inserted into the output
stream.<p>

The interpretation is the same for 0xFC, and 0xF8.  I believe that 0xFC has
a lower dynamic (2 bit) range than 0xF8 (4 or 8 bit).<p>

<h4>RTileType = 0xFF (RMin CCITT RLE 1Bit)</h4>

The data stream for this file is CCITT RLE (G1 fax) compressed.  The
format is complex but source is provided with the sample program (derived
from libtiff) for reading it. The result of uncompressing is 1bit data so
which the RMin value should be added.<p>

<hr>

<h2><a name="hdr.adf">hdr.adf - Header</a></h2>

This is a binary dump of the first 308 bytes of a hdr.adf
file.<p>

<pre>
       0: 47524944 312E3200 00000000 FFFFFFFF GRID1.2~~~~~~~~~
      16: 00000001 00000000 0000164E 3F800000 ~~~~~~~~~~~N?~~~
      32: 00000F00 F6180000 90060000 3603D601 ~~~~~~~~~~~~6~~~
      48: 6403E301 01000000 7620F808 43012B03 d~~~~~~~v ~~C~+~
      64: D6019903 E3012B03 D6019903 E301F7BF ~~~~~~+~~~~~~~~~
      80: 00007406 6E1FC2A4 7A370D00 0B004200 ~~t~n~~~z7~~~~B~
      96: 4E1654A4 00000000 00000000 00000000 N~T~~~~~~~~~~~~~
     112: 34A5A89D FF0414A5 A70F0002 00000000 4~~~~~~~~~~~~~~~
     128: 00000000 3C0B5F06 A8C05F06 08005AC0 ~~~~<~_~~~_~~~Z~
     144: 0A00E101 36035AC0 72085F06 FAA42F3C ~~~~6~Z~r~_~~~/<
     160: 0A001667 02000E00 A80B0200 08370200 ~~~g~~~~~~~~~7~~
     176: 0CA00200 9C0B0200 04370200 36A0E436 ~~~~~~~~~7~~6~~6
     192: 84000000 36A00200 5F063EA5 0883FF04 ~~~~6~~~_~>~~~~~
     208: 00008400 00000010 BD810200 5F010000 ~~~~~~~~~~~~_~~~
     224: 670E0000 5F01560E 4C4F0001 84008CA5 g~~~_~V~LO~~~~~~
     240: 28008F01 1000E00A 6628F7BF 4076FF04 (~~~~~~~f(~~@v~~
     256: 3FF00000 00000000 3FF00000 00000000 ?~~~~~~~?~~~~~~~
     272: C08FFC00 00000000 C0A1BF00 00000000 ~~~~~~~~~~~~~~~~
     288: 00000008 00000200 00000100 00000001 ~~~~~~~~~~~~~~~~
     304: 00000004                            ~~~~
</pre>

Fields:<p>

<table border>
<th>Start Byte
<th># of Bytes
<th>Format
<th>Name
<th>Description

<tr>
  <td> 0
  </td><td> 8
  </td><td> Char
  </td><td> HMagic
  </td><td> Magic Number - always "GRID1.2\0"
  </td>
</tr>

<tr>
  <td> 8
  </td><td> 8
  </td><td> &nbsp;
  </td><td> &nbsp;
  </td><td> assorted data, I don't know the purpose.
  </td>
</tr>

<tr>
  <td> 16
  </td><td> 4
  </td><td> MSB Int32
  </td><td> HCellType
  </td><td> 1 = int cover, 2 = float cover.
  </td>
</tr>

<tr>
  <td> 20
  </td><td> 4
  </td><td> MSB Int32
  </td><td> CompFlag
  </td><td> 0 = compressed, 1 = uncompressed
  </td>
</tr>

<tr>
  <td> 24
  </td><td> 232
  </td><td> &nbsp;
  </td><td> &nbsp;
  </td><td> assorted data, I don't know the purpose.
  </td>
</tr>

<tr>
  <td> 256
  </td><td> 8
  </td><td> MSB Double
  </td><td> HPixelSizeX
  </td><td> Width of a pixel in georeferenced coordinates.  Generally 1.0
for ungeoreferenced rasters.
  </td>
</tr>

<tr>
  <td> 264
  </td><td> 8
  </td><td> MSB Double
  </td><td> HPixelSizeY
  </td><td> Height of a pixel in georeferenced coordinates.  Generally 1.0
for ungeoreferenced rasters.
  </td>
</tr>

<tr>
  <td> 272
  </td><td> 8
  </td><td> MSB Double
  </td><td> XRef
  </td><td> dfLLX-(nBlocksPerRow*nBlockXSize*dfCellSizeX)/2.0
  </td>
</tr>

<tr>
  <td> 280
  </td><td> 8
  </td><td> MSB Double
  </td><td> YRef
  </td><td> dfURY-(3*nBlocksPerColumn*nBlockYSize*dfCellSizeY)/2.0
  </td>
</tr>

<tr>
  <td> 288
  </td><td> 4
  </td><td> MSB Int32
  </td><td> HTilesPerRow
  </td><td> The width of the file in tiles (often 8 for files of
less than 2K in width).
  </td>
</tr>

<tr>
  <td> 292
  </td><td> 4
  </td><td> MSB Int32
  </td><td> HTilesPerColumn
  </td><td> The height of the file in tiles.  Note this may be much more than
            the number of tiles actually represented in the index file.<p>
  </td>
</tr>

<tr>
  <td> 296
  </td><td> 4
  </td><td> MSB Int32
  </td><td> HTileXSize
  </td><td> The width of a file in pixels.  Normally 256.  </td>
</tr>

<tr>
  <td> 300
  </td><td> 4
  </td><td> MSB Int32
  </td><td>
  </td><td> Unknown, usually 1.
</tr>

<tr>
  <td> 304
  </td><td> 4
  </td><td> MSB Int32
  </td><td> HTileYSize
  </td><td> Height of a tile in pixels, usually 4.
</tr>

</table>

<hr>

<h2>Acknowledgements</h2>

I would like to thank <a href="http://www.geosoft.com/">Geosoft Inc.</a>
for partial funding of my research into this
format.  I would also like to thank:<p>

<ul>
<li> Kenneth R. McVay for providing the statistics file format.
<li> Noureddine Farah of ThinkSpace who dug up lots of datasets that caused
problems.
<li> Luciano Fonseca who worked out RTileType 0x01.
<li> Martin Manningham of Global Geomatics for additional problem sample files.
<li> Harry Anderson of EDX Engineering, for showing me that floating point
tiles don't have RTileType.
<li> Ian Turton for supplying a sample files demonstrating the need to be
careful with the sign of "short" RMin values.
<li> Duncan Chaundy at PCI for poking hard till I finally deduced 0xFF tiles.
<li> Stephen Cheeseman of GeoSoft for yet more problem files.
<li> Geoffrey Williams for a files demonstrating tile type 0x20.
</ul>

</body>
</html>