A raster is a regular grid of cells (pixels), each
storing a numeric value. In geospatial work, rasters represent
continuous surfaces — elevation models (DEMs), satellite imagery,
precipitation grids, bathymetry, land-cover classifications, and
more. Every cell maps to a geographic location defined by the
raster's origin, cell size, and coordinate reference system.
HEC-RAS relies heavily on rasters. The terrain model that drives
the 2D solver is a DEM raster, and simulation outputs — depth,
velocity, water surface elevation — are written as raster grids
for every time step. Efficient raster I/O is critical to both
pre-processing and post-processing performance.
Anatomy of a Raster File
A raster file (GeoTIFF, HDF5, etc.) contains the pixel data plus
metadata: the grid dimensions (columns × rows), the geographic
transform (origin + cell size), the coordinate system, and the
data type (e.g. Float32). A 10,000 × 10,000 Float32 raster holds
100 million cells — roughly 400 MB of raw pixel data before
compression.
At this scale, naively reading the entire file for every
operation is impractical. Two techniques solve this:
tiling and pyramids.
Tiles
A tiled raster divides the pixel grid into
fixed-size blocks — typically 256×256 or 512×512 pixels. Each tile
is stored contiguously on disk, so reading one tile requires a
single sequential disk read rather than thousands of scattered
seeks across the file.
When a viewer or analysis tool needs to display or process a small
region, it computes which tiles overlap the region of interest and
reads only those tiles. The remaining tiles are never touched.
For a large raster viewed at a local extent, this often means
reading less than 1% of the file.
Phase 1 — A 24×16 raster grid appears, colored by elevation.
Phase 2 — Tile boundaries appear (4×4-cell tiles).
Phase 3 — "Without tiling" flash — entire file must be read.
Phase 4 — A viewport pans across; only intersecting tiles load.
Tiled vs. Striped Layout
Untiled (striped) rasters store pixels row by row. Reading a
rectangular subregion requires seeking to every row in the region,
reading only the relevant columns, and discarding the rest.
Tiled rasters make this a simple block read — dramatically faster
on spinning disks and still faster on SSDs due to reduced syscall
overhead.
Tile Size Trade-offs
Small tiles (64×64) — fine-grained access,
but more overhead per tile (headers, index entries).
Large tiles (1024×1024) — fewer tiles to
manage, but you may read more data than needed at the edges
of your viewport.
256×256 or 512×512 — the most common defaults;
a good balance for typical pan-and-zoom workflows.
Pyramids (Overview Levels)
Even with tiling, viewing an entire large raster requires reading
every tile. If the raster is 40,000 × 40,000 pixels and the
screen is only 2,000 × 1,000, the viewer would read 1.6 billion
pixels only to downsample them to 2 million. That is 800× more
data than the screen can display.
Pyramids (also called overviews) solve this by
pre-building downsampled copies of the raster at progressively
lower resolutions. A typical pyramid halves the dimensions at each
level: the full-resolution Level 0 is followed by a
half-resolution Level 1, a quarter-resolution
Level 2, and so on.
Phase 1 — Four pyramid levels appear (Level 0 at bottom, Level 3 at top).
Phase 2 — The zoom level cycles; at each zoom, the viewer
reads from the matching pyramid level. The viewport (dashed box) always
covers the same number of cells — same data loaded at every zoom.
The key insight: at any zoom level, the application reads
roughly the same number of pixels from disk. Zoomed out, it
reads a small overview. Zoomed in, it reads a small window of
the full-resolution data. The pyramid ensures the data volume
stays proportional to the screen size, not the raster size.
Storage Overhead
A full pyramid (halving at each level down to 1×1) adds only
~33% to the file size. Each successive level is 1/4 the area
of the previous one: 1 + 1/4 + 1/16 + 1/64 + … ≈ 1.33.
This modest overhead pays for itself many times over in read
performance.
Compression
Raster data can be compressed to reduce both disk footprint and
I/O bandwidth. Because tiled rasters compress each tile
independently, random access is preserved — the reader
decompresses only the tiles it needs, without touching the rest
of the file.
Common Codecs
DEFLATE — Lossless, widely supported (the
default in many GeoTIFF writers). Good compression ratio,
moderate speed.
LZW — Lossless, slightly faster decompression
than DEFLATE but often a lower ratio on floating-point data.
ZSTD — Lossless, excellent balance of ratio
and speed. Increasingly adopted for large rasters.
JPEG / WEBP — Lossy, very high compression.
Ideal for aerial imagery where minor artifacts are acceptable,
but unsuitable for elevation or scientific data.
LERC — Lossy-to-lossless with a configurable
error threshold. Designed for elevation data — can achieve
10–20× compression on DEMs while bounding the maximum error
per cell.
Predictor Filters
Before compression, a predictor transform can be
applied. The most common is horizontal differencing:
each pixel stores the difference from its left neighbor. Because
adjacent terrain cells tend to have similar elevations, the
differences are small and compress far better than raw values.
Predictor + DEFLATE typically halves a DEM's file size compared
to DEFLATE alone.
NoData Values
Real-world rasters rarely have valid data in every cell. A DEM
may cover an irregular study area boundary; satellite imagery has
gaps from cloud cover or orbital paths. Cells with no valid
measurement are assigned a NoData sentinel value
— commonly -9999, -3.4e38, or
NaN.
NoData cells serve two purposes: they tell the renderer to draw
nothing (transparent), and they tell analysis tools to exclude
those cells from calculations (min, max, mean, interpolation).
NoData and compression: Large contiguous blocks
of identical values are a compressor's dream. A 256×256 tile
filled entirely with -9999 compresses from 256 KB
down to a few dozen bytes — effectively free storage. Rasters
with irregular boundaries (lots of NoData at the edges) often
compress dramatically better than their raw size suggests.
Choosing a NoData Value
For elevation data — use a value far outside the
physical range, like -9999 or the Float32 minimum.
For imagery (UInt8/UInt16) — 0 or
255 are common but risk collisions with real values.
An alpha band is often safer.
Float32/Float64 — NaN is
semantically clean and propagates through arithmetic naturally,
but not all software handles it consistently.
Impact on the HEC-RAS Pipeline
When HEC-RAS samples terrain for sub-cell property tables, cells
flagged as NoData are excluded from the elevation histogram. If
an entire computational cell falls within a NoData region, the
solver marks it as permanently dry. Correct NoData handling is
essential — a missing sentinel can introduce phantom terrain at
-9999 m elevation, causing the solver to create an
infinitely deep pit that traps all incoming flow.
