 |
|
|
|
Rack can also create radar image composites, sometimes called mosaics. In weather services, composites are often preferred to single-radar products. On the other hand, a Cartesian product displaying single-radar data is identified with an single-radar "composite" in Rack . This section lists related commands and examples. A quick reference is found in Compositing and Cartesian products. Compositing motion vectors is art of its own, hence explained in a separate section, Composites of motion fields .
Compositing can be apply several compositing methods (or rules):
The commands related to compositing and Cartesian products start with 'c'. In computation Rack supports two schemes:
In both direct and tiled schemes, data of each radar can undergo anomaly detection and removal. In addition, a polar product (like pseudo CAPPI or echo height) can be computed.
Projection definition command –cProj uses Proj.4 syntax, supporting also EPSG codes given like '+init=epsg:4326' . When writing GeoTIFF files, using EPSG codes is recommended because not all Proj.4 project definition strings are supported by the GeoTIFF library.
Radar data complying the ODIM standard applies special marker codes undetect and nodata . These codes have to be handled carefully in product generation and compositing. In Rack , pixel values with nodata are simply skipped; they are not accumulated in the composite array, for example.
Handling of undetect can be tuned by the user with –quantityConf and –undetectWeight . The physical value or "virtual zero" replacing undetect codes is set using –quantityConf ,
for example, –quantityConf DBZH,zero=-32.0 (corresponding the limit of signal detection sensitivity). See also Default encoding of quantities. The corresponding relative weight is set with –undetectWeight <value> . The value 0.0...1.0 describes the significance of the value relative to a "true" detected measurement value. The value is zero by default, which in compositing means that the location is marked as processed (a counter is incremented), but the value will not be accumulated.
Creating composites in a direct mode involves the following steps:
The process is illustrated in the graph below.
A 800 x 1000 maximum composite over Finland in a lat-lon projection is obtained with
A similar composite of CAPPI in 1000 m altitude, with quality-weighted compositing method is obtained with
Rack installation package contains a utility script make-composite.sh which compiles a command line string - like the one above - and executes it. For example:
The extraction command –cExtract extracts one or more data layers out of the compositing (accumulation array):
DATA - the actual composited data, like reflectivity (DBZH )WEIGHT - quality (confidence) of the data valueCOUNT - number of radars contributedDEVIATION - difference or discrepancy of data (if more than one radar contributed)The desired combination is given as a column (: ) separated list of above keywords. Note that for now, also the older syntax is supported: a string composed of single letters ( d ), weight, (w ), deviation (std.dev., s ) and count of radars (c ).
The new, second parameter is optional cropping: the desired bounding box <LLx>:<LLy>:<URx>:<URy> or DATA (automatic bounding box) or OVERLAP (overlapping area).
Rack makes composites of any selected quantity or polar product. Examples are shown in the image below.
Hint. Command lines may get lengthy in compositing. You can shorten file arguments by using general options –inputPrefix and –outputPrefix .
In a Tiled (distributed) mode, the composite is initialized as in direct mode but the tile generated is with –cCreateTile and then saved with –outputFile command. In the accumulation stage, the composite is loaded and then copied to the internal compositing array with –cAdd. The stages are illustrated in the diagrams below.
For example, creation of a tile:
Then, tiles are collectively added to composite with a single command. Notice that the composite definitions should be exactly the same as in the tile creation:
(The above commands have been generated using make-composite.sh with SCHEME=TILE and SCHEME=TILED .)
By default, each tile contains data from a single radar. Alternatively, for a large composite, one can construct a tile containing data from several radars by calling –cBBoxTile command immediately after –cBBox and –cSize . The latter commands are equal to those of the large composite. A multi-radar tile is otherwise generated like any composite, that is, –cAdd and –cExtract commands are needed (unlike in constructing a single-radar tile).
For example, consider receiving a precomputed the OPERA composite, to which the Russian and Belarussian radars are added. First, the latter data is composited to a tile cropped with –cBBoxTile under OPERA geometry:
Finally, the two composites are combined
Notice that the geometry is implicitly determined by the first composite data read (or projected).
It is also possible to continuously update a composite. It means that a previous composite is loaded as a "warm start" and –cAddWeighted command. The size and geometrical scope are set to those of the composite file. Fading with a low weight value is motivated by substituting missing radars with older measurements with however lower confidence.
Minimal bounding box of input data, cropped by the bounding box of the composite, is stored in how:dataBBOX variable.
A grid of latitudes and longitudes can be added onto Cartesiand products with –cGrid. The following command creates a grid with 5 degree spacing in latitudes and longitudes, using width of 0.9 pixels and 50% gray intensity:
The input data – a Cartesian product – can be read as a file as in this example or generated from polar data with –cCreate .
1.9.1