To appear
Previous: List of Figures
Since Digital Elevation Model (DEM), or, similarly, Digital Terrain Elevation Data (DTED), files are so large, minimizing storage space is important. Altho storage space becomes ever cheaper, the data has higher and higher resolution. Besides the cost of the space, the data file size also affects transmission time and cost. Even within one computer, since processors are getting faster faster than busses and memories are getting faster, smaller data can lead to faster computation. Therefore, altho the question has been studied by many people since computers were first used in cartography, it is still appropriate to ask: How should we compress elevation data?
The first decision is whether to use a general- or a special-purpose compression algorithm; this is not at all clear. The special-purpose method, such as a Triangulated Irregular Network (TIN), can take advantage of the peculiar nature of elevation data, and of the desired error behavior. However, a general-purpose algorithm might have so much effort devoted to its development that it might perform quite well on elevation data, even though not designed specifically for that. In fact, in computer engineering, special purpose machines have generally been failures for that reason. Such failures include most of the machines developed in all the following categories: Lisp machines, floating point processors, database engines, special graphics engines, and parallel machines.
In this paper, we test compress a regular gridded sample digital
elevation file with some older, generally available, compression
algorithms, such as compress, gzip and JPEG,
then with some new, lesser-known algorithms, such as lossless
JPEG, ha, codetree, progcode, and
sp_compress, and then with some semi-custom algorithms
where we compress the hi-order bytes of the data separately from
the lo-order bytes. We measure the efficiency of the methods in
terms of the number of bits per point (bpp) in the
compressed file, as well as the compression ratio relative to an
uncompressed binary file (which is already smaller than an
uncompressed ASCII file). We consider both lossless and lossy
algorithms, and in the latter case measure the error compared to
the bpp. We study the size penalty associated with partitioning
the file into many small pieces before compression, which
facilitates accessing only a small part of the file later without
needing to uncompress all of it. We then try the best methods on
extracts from 24 randomly-selected 
USGS
DEMs and on 4 extracts from the ETOPO5 files.
Finally, we will consider some ways that a specifically topographic format, the TIN, might be compressed.
To appear
Previous: List of Figures