 |
|
Loading...
Searching...
No Matches
|
|
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.
Essential properties of a composite are:
The size of the composite, in pixels, is set with –cSize.
Projection definition command –cProj uses Proj.4 syntax and additionally supports direct EPSG codes, --cProj\ 3067 .
If the projection is not given, Rack uses the Azimuthal Equidistant (AEQD) projection centered at radar site of the first input.
When writing GeoTIFF files, using EPSG codes is recommended because not all Proj.4 project definition strings are supported by the GeoTIFF library. The following list produced as a part of release tests.
The geographical area – the bounding box – of the composite is set with --cBBox taking lower left and upper right points as arguments. The points can be always given in degrees. If the applied projection is metric, the coordinates can be given as meters. If the bounding box is not explictly given with --cBBox command, the corner points of the first radar input are used.
Hint: look at additional attributes of prefix where:BBOX written in output files. These attributes display the coordinates of metric projections in native (i.e. metric) units and also report extent and overlap of input data. The bounding boxes can be used in optimising composite products. (Write of additional non-standard attributes is controlled with the --odim command. )
Command --cInit creates an empty compositing array of desired size in the memory and stores the essential attributes listed above. The command is optional – initialisation is implicitly invoked when the first input is introduced with --cAdd or --cAddWeighted . However, explicit command is recommended, if the user wants to get an empty image (instead of an error) in case no inputs are available.
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 is not 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 comma-separated list of above keywords. Notice that the command –cCreate for creating single radar "composite" is equivalent to --cAdd cExtract DATA,WEIGHT . For example:
Upon initialisation of teh compositing array, Rack stores the encoding parameters – storage type, scaling and marker values (undetect , nodata) – given explicitly or adopted from the first input. Then, in extraction stage, that encoding is applied by default. The internal compositing array itself is floating point data, so encoding of the output can be also set upon extraction. Reusing the above single-radar example, as follows:
The encoding is applied to the first field (like DATA ) listed; the remaining field (typically quality fields) use their default encodings. But if desired, encoding of each field can be set, for example as follows:
For now, the old syntax is also supported: a string composed of single letters (d ), weight, (w ), deviation (std.dev., s ) and count of radars (c ).
Cropping is supported by a new optional parameter: the desired bounding box can be given explicitly <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.8