NEXRAD Mosaic Construction

NEXRAD Mosaic Construction guides creation of a custom multi-radar analysis from aligned, validated single-site products. Every output cell should retain its source, coverage state, and quality decision. The workflow distinguishes a locally constructed composite from an official provider product such as NOAA MRMS. It does not discover, download, or decode radar files.

Supported fields include reflectivity, radial velocity, spectrum width, and dual-polarization quantities. Define the product contract before combination: units, sites, coordinates, volume times, sweeps, target domain, grid, projection, cell size, temporal policy, native spatial support, beam geometry, quality rules, overlap resolution, output format, and provenance. Similar product names do not make Level II moments and Level III display products interchangeable.

Use it to combine two or more adjacent or overlapping radars, compare cross-radar observations on a common grid, visualize source contributions and gaps, or compare a local analysis with an exact official MRMS product. It applies after the required single-site inputs have been resolved.

Do not use it to fetch an official mosaic, select a single radar, or turn a simple pixel average into a claimed physically resolved regional field. A custom product is not an official warning or ground truth. Heterogeneous range, terrain, calibration, beam width, and processing limit comparability, and spatially correlated pixels are not independent observations.

Inputs are decoded source fields with verified metadata, units, time, and quality. Align them on a declared grid and projection, retain native support, label resampling, and reject stale or invalid sources. If a common time requires excessive interpolation, preserve the actual nearest valid time difference or mark the output unavailable rather than inventing a shared observation time.

Quality selection may consider beam height, range, beam width, clutter, terrain, signal quality, attenuation, folding, time difference, and product-specific suitability. Terms and weights are modeling choices that need comparable normalization and sensitivity checks. Resolve ties deterministically and preserve the selected and runner-up sources. Fusion requires separate physical justification and validation; do not default to averaging logarithmic dBZ, radial velocity, or quality fields.

Outputs include value, source-site and source-time fields, quality or suitability, relevant beam-height or range metadata, coverage and no-data masks, and product, grid, projection, units, and timestamp metadata. Missing or blocked data stays distinct from physical zero. Any substitution from a neighboring radar must be labeled.

Vertical semantics remain explicit. A two-dimensional mosaic cannot silently mix incompatible sweep heights, and a lowest-sweep composite is not a column-integrated quantity. VIL, echo-top, and other derived products require their defined or separately validated algorithms.

Validation inspects holes, seams, boundaries, implausible values, source flips, range and terrain artifacts, agreement in non-overlap regions, independent observations where available, and sensitivity to weights, timing, and product choice. Retain rejected-source reasons, limitations, and checksums for inputs, code, configuration, and outputs. Plot source, quality, and coverage beside the value field; a colored image alone is incomplete.

Related workflows provide single-site access, official mosaic access, radar-satellite interpretation, and visualization. Feature tracking can follow construction but is optional. Public or authorized data, provider attribution, bounded input and output sizes, validated labels, and protected credentials remain requirements.

This skill supports radar researchers and analysts constructing auditable local composites who need to explain the scientific and geometric decisions behind every part of the field.