Changes for docs/production_doppler_lidar_conversion/other_scan_types/processing_differences_from_vertical_scan.md: 117 added lines, 0 removed lines.
Original line number
Diff line number
Diff line
# Processing Differences Relative to the Vertical-Scan Workflow
## Purpose
This page documents only the **differences** between the non-vertical and vertical scan workflows.
The general design philosophy of the production Doppler lidar conversion system remains the same and is documented elsewhere. This page therefore avoids repeating information already covered in the vertical-scan pages.
## What remains the same
The non-vertical workflow still follows the same broad principles as the vertical-scan case:
- source-preserving HPL parsing,
- retention of all parseable source rays,
- retention of all parseable non-negative range-gate records,
- rectangular Level-1 representation in NetCDF,
- daily aggregation after source-aligned Level-1 conversion,
- separate provenance tracking through manifest files,
- subsequent CF-oriented metadata application.
## Main differences
## 1. Scan geometry is fundamentally different
### Vertical-scan case
In the vertical-scan workflow, the beam is interpreted as near-vertical, so the data are naturally associated with a profile-like measurement geometry.
### Non-vertical case
In the User5 workflow, the beam is **not vertical**. Instead, the data represent a directed scan with:
- fixed azimuth,
- changing elevation,
- slant-range sampling along the beam.
This means the measurements should not be described as conventional vertical profiles.
## 2. Daily aggregation is grouped by scan family as well as date
### Vertical-scan case
Vertical-stare products are aggregated at the daily level without needing an additional scan-family split.
### Non-vertical case
For User5, files are aggregated by:
-**UTC date**, and
-**scan family** (`north` or `south`).
This prevents geometrically distinct scans from being merged into a single daily product.
## 3. No range-gate geolocation is performed
### Vertical-scan case
For vertical-stare files, altitude derivation may be straightforward enough to support a later CF-oriented geolocated product.
### Non-vertical case
For User5, the workflow intentionally **does not derive**:
- latitude of range-gate centres,
- longitude of range-gate centres,
- altitude of range-gate centres.
Instead, the products retain only:
- instrument location,
- beam azimuth,
- beam elevation,
- pitch,
- roll,
- slant range.
This avoids embedding an unreviewed geometric transformation into the production product.
## 4. CF-oriented files omit `featureType`
### Vertical-scan case
Vertical products may support a clearer mapping to a CF discrete sampling geometry, especially for time-series/profile-like representations.
### Non-vertical case
For User5, the current CF-oriented product **does not declare a `featureType`**.
This is intentional. At present, the files are represented simply as a generic **time × range** dataset with auxiliary beam coordinates. This is the most conservative and defensible representation until a stronger geometry-specific CF mapping is needed.
## 5. Science-variable coordinates are more restrictive
For the User5 CF-oriented files, the science variables use:
```text
coordinates = "azimuth elevation"
```
This differs from earlier exploratory forms that might also have listed additional supporting variables.
`pitch` and `roll` are retained in the file, but they are treated as supporting engineering variables rather than core auxiliary coordinates for the atmospheric measurements.
Likewise, scalar instrument latitude, longitude, and altitude are **not** listed in the science-variable `coordinates` attribute, because they do not represent the location of every individual gate measurement.
## 6. Provenance remains important because intermediate files may later be removed
As with the vertical-scan workflow, the non-vertical daily products preserve provenance through summary attributes and sidecar manifests. This is especially important because the daily products are intended to remain interpretable even if the source-aligned intermediate NetCDF files are later archived or removed from the working area.
## Practical consequence for downstream use
Users of the non-vertical User5 products should interpret them as:
- preservation-oriented beam-coordinate data products,
- not yet geolocated range-gate products,
- suitable for later application-specific transformation.
In practice, any conversion from beam geometry into geophysical spatial coordinates should be carried out within the scientific workflow that uses the data, so that assumptions and uncertainty can be documented explicitly.
