794 lines
26 KiB
HTML
794 lines
26 KiB
HTML
<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type"
|
|
content="text/html; charset=iso-8859-1">
|
|
<meta name="GENERATOR"
|
|
content="Mozilla/4.79 [en] (X11; U; Linux 2.4.18-27.7.xsmp i686) [Netscape]">
|
|
<title>iscMosaic - User's Guide</title>
|
|
</head>
|
|
<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000"
|
|
vlink="#551a8b">
|
|
<h1>
|
|
iscMosaic User's Guide</h1>
|
|
January 6, 2012<br>
|
|
<p>
|
|
</p>
|
|
<h2><a name="TableofContents"></a>Table of Contents</h2>
|
|
<a href="#Overview">Overview</a>
|
|
<br>
|
|
<a href="#Running">Running the iscMosaic Program</a>
|
|
<br>
|
|
<a href="#Command">Command Line Switches</a>
|
|
<br>
|
|
<a href="#Restrictions">Restrictions</a>
|
|
<br>
|
|
<a href="#Examples">Examples</a>
|
|
<br>
|
|
<a href="#DefaultBehavior">Default Behavior</a>
|
|
<br>
|
|
<a href="#Blanking">Blanking</a>
|
|
<br>
|
|
<a href="#ReplaceOnlyDoNotMerge">Replace Only, Do
|
|
Not Merge</a>
|
|
<br>
|
|
<a href="#NoMask">No Mask</a>
|
|
<br>
|
|
<a href="#AlternativeMask">Alternative Mask</a>
|
|
<br>
|
|
<a href="#SimpleStorageofGrids">Simple Storage of
|
|
Grids</a>
|
|
<br>
|
|
<a href="#RequiredFormat">Required netCDF File Format</a>
|
|
<br>
|
|
<a href="#TemporalMerge">Temporal Mosaicing</a>
|
|
<p></p>
|
|
<br>
|
|
<hr width="100%">
|
|
<h2><a name="Overview"></a>Overview</h2>
|
|
The main use of the iscMosaic program is to merge and store grids
|
|
received
|
|
from the <a href="IntersiteCoordination.html">intersite coordination
|
|
of
|
|
grids</a> routine into your database. The iscMosaic program can
|
|
also
|
|
be used to merge other local data sets and for storing data, that is in
|
|
the appropriate netCDF format, into your database. Refer to the <a
|
|
href="ifpnetCDF.html">ifpnetCDF
|
|
program's user guide</a> for details on the required format of the
|
|
netCDF
|
|
file.
|
|
<p>There are a variety of options available to iscMosaic. In the
|
|
basic mode, the contents of the specified netCDF file is merged into
|
|
the
|
|
existing dataset. Only those areas identified by the source site
|
|
identifier in the netCDF file are merged; the remainder of the existing
|
|
grids remain untouched. Using the various options, you can limit
|
|
the time range scope of the merge, limit the processing to one or just
|
|
a few weather elements, define an alternative merge mask or bypass the
|
|
merge and replace the entire grid, and zero out the existing grid
|
|
inventory
|
|
before beginning.
|
|
</p>
|
|
<p>Merging of grids is generally achived through "masking". The
|
|
mask
|
|
is an edit area. Be default the edit area mask is defined by the
|
|
site identifier field in each weather element of the incoming netCDF
|
|
file.
|
|
For example, if the grids in the netCDF were created by the <a
|
|
href="ifpnetCDF.html">ifpnetCDF
|
|
program</a> at Cheyenne (CYS), and then the iscMosaic program was run
|
|
on
|
|
the data file at BOU, only the data defined by those grid points in the
|
|
Boulder's CYS edit area would be merged into the grids. The mask
|
|
can be disabled, or redefined when the iscMosaic program is run.
|
|
</p>
|
|
<p>The format of the input netCDF file is described in the <a
|
|
href="netCDFFormat.html">netCDF
|
|
Format documentation</a>.
|
|
</p>
|
|
<p>The following three images are from BOU, CYS, and PUB, when merged
|
|
and
|
|
clipped to their CWA regions, the result is the fourth image.
|
|
<br>
|
|
|
|
<table nosave="" cols="4" width="100%">
|
|
<tbody>
|
|
<tr nosave="">
|
|
<td nosave=""><img src="images/Mosaic_BOU_Orig.jpg" nosave=""
|
|
height="296" width="200"></td>
|
|
<td><img src="images/Mosaic_CYS_Orig.jpg" nosave="" height="320"
|
|
width="200"></td>
|
|
<td><img src="images/Mosaic_PUB_Orig.jpg" nosave="" height="316"
|
|
width="200"></td>
|
|
<td><img src="images/Mosaic_BOUCYSPUB.jpg" nosave="" height="285"
|
|
width="200"></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Boulder, CO (BOU)</td>
|
|
<td>Cheyenne, WY (CYS)</td>
|
|
<td>Pueblo, CO (PUB)</td>
|
|
<td>Merge of the three different office grids, each one clipped
|
|
on its
|
|
CWA.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</p>
|
|
<p></p>
|
|
<hr width="100%">
|
|
<h2><a name="Running"></a>Running the iscMosaic Program</h2>
|
|
<h3>
|
|
<a name="Command"></a>Command Line Switches</h3>
|
|
The following command line switches are supported by iscMosaic:
|
|
<br>
|
|
|
|
<table nosave="" border="1" width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<td><b>Switch</b></td>
|
|
<td><b>Mandatory</b></td>
|
|
<td><b>Description</b></td>
|
|
</tr>
|
|
<tr>
|
|
<td>-h hostname</td>
|
|
<td>YES (See Note)</td>
|
|
<td>Identifies the hostname upon which EDEX is running.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-r rpcport</td>
|
|
<td>YES (See Note)</td>
|
|
<td>Identifies the RPC port number upon which EDEX is
|
|
processing
|
|
requests.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-u user</td>
|
|
<td>NO</td>
|
|
<td>Identifies the user of the program for use in obtaining edit
|
|
areas
|
|
from the server. </td>
|
|
</tr>
|
|
<tr>
|
|
<td>-d outputDatabaseID</td>
|
|
<td>YES (See Note)</td>
|
|
<td>Defines the destination database to store the grids.
|
|
This is
|
|
a full database id, in the form of
|
|
"siteID_GRID_optType_modelName_modelDate_modelTime",
|
|
such as BOU_GRID__Fcst_00000000_0000.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-p parm</td>
|
|
<td>NO</td>
|
|
<td>If not present, then all weather elements found in the netCDF
|
|
file
|
|
that exist in the destination database will be stored. If
|
|
present,
|
|
then only those weather elements will be stored. There can be
|
|
multiple
|
|
-p switches, in the form of -p wx1 -p wx2 -p wx3. The name refers to
|
|
SFC
|
|
weather elements, to denote a weather element for a different level,
|
|
use
|
|
the parmName_level format, such as T_3K.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-f inputFile</td>
|
|
<td>YES</td>
|
|
<td>Specifies the input netCDF file for processing. This
|
|
file must
|
|
be in the same format as the output that <a href="ifpnetCDF.html">ifpnetCDF</a>
|
|
produces. There can be multiple -f switches, in the form of -f file1 -f
|
|
file2 -f file3. See the <a href="#Restrictions">restrictions
|
|
section</a>
|
|
for more information about command switch compatibility with multiple
|
|
-f
|
|
switches are given.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-b</td>
|
|
<td>NO</td>
|
|
<td>Blanking Mode. If enabled, then for all times, other
|
|
than the
|
|
times in the incoming grids, any existing grids will have the area
|
|
defined
|
|
by the area mask blanked, i.e., set to the minimum data value. If
|
|
disabled, then no data within the area defined by the area mask will be
|
|
modified in time periods that are not contained within the incoming
|
|
grids.
|
|
For purposes of <a href="IntersiteCoordination.html">intersite
|
|
coordination</a>,
|
|
which always sends the complete weather element's inventory, the switch
|
|
must be specified. The -s and -e switches affect the overall time range
|
|
that ths operation is performed.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-s startTime</td>
|
|
<td>NO</td>
|
|
<td>Start Time. By default, the start time is set to January 1,
|
|
1970 at
|
|
0000Z. Only incoming grids that contain the start time or
|
|
start
|
|
after the start time will be processed. For purposes of <a
|
|
href="IntersiteCoordination.html">intersite
|
|
coordination</a>, the -s switch should not be specified.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-e endTime</td>
|
|
<td>NO</td>
|
|
<td>Stop Time. By default, the stop time is set way into the
|
|
future.
|
|
Only incoming grids that contain the ending time or end before the
|
|
ending
|
|
time will be processed. For purposes of <a
|
|
href="IntersiteCoordination.html">intersite
|
|
coordination</a>, the -e switch should not be specified.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-x</td>
|
|
<td>NO</td>
|
|
<td>Replace Mode. By default, iscMosaic performs merges of
|
|
the incoming
|
|
data grids into any existing grids over the region defined by the area
|
|
mask. If the -x switch is given, then iscMosaic will not perform
|
|
a merge, but instead will simply replace any existing grid with the
|
|
incoming
|
|
grid. For purposes of <a href="IntersiteCoordination.html">intersite
|
|
coordination</a>, the -x switch should not be specified. The -s
|
|
and
|
|
-e switches affect the overall time range that this operation is
|
|
performed.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-z</td>
|
|
<td>NO</td>
|
|
<td>Erase Inventory First. By default, no grids are removed
|
|
from
|
|
the destination database. If the -z switch is specified, then
|
|
before
|
|
any incoming grids are stored, any existing grids in the database are
|
|
removed.
|
|
For purposes of <a href="IntersiteCoordination.html">intersite
|
|
coordination</a>,
|
|
the -z switch should not be specified. The -s and -e switches
|
|
affect
|
|
the overall time range that this operation is performed.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-n</td>
|
|
<td>NO</td>
|
|
<td>Ignore Area Mask. Be default, the site identifier field in
|
|
the input
|
|
netCDF file is used to determine the area mask. For example, if
|
|
the
|
|
netCDF file site id field is "CYS", then the program will attempt to
|
|
get
|
|
the edit area called "ISC_CYS" from EDEX and then only merge
|
|
those
|
|
grid points. If the -n switch is present, then the area mask will
|
|
be ignored and all grid points in the input netCDF will be merged into
|
|
the database. This mode is not quite identical to the -x replace
|
|
mode unless the input netCDF file and the destination database contain
|
|
the same domain (geographical information). There is another mask
|
|
within
|
|
the input netCDF file that cannot be disabled. That mask defines
|
|
valid data points vs. invalid data points. The software will not
|
|
store invalid data points, despite the absence of a mask.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-a altMask</td>
|
|
<td>NO</td>
|
|
<td>Alternative Mask. By default, the site identifier field in
|
|
the input
|
|
netCDF file is used to determine the area mask. For example, if
|
|
the
|
|
netCDF file site id field is "CYS", then the program will attempt to
|
|
get
|
|
the edit area called "ISC_CYS" from EDEX and then only merge
|
|
those
|
|
grid points. The -a switch identifies the name of the edit area
|
|
used
|
|
for masking.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-w message</td>
|
|
<td>NO</td>
|
|
<td>Warn/Alert all clients connected to EDEX that data
|
|
has been
|
|
processed. This produces a message on the AlertViz
|
|
indicating
|
|
that "message" occurred. The site identifier, number of grids,
|
|
valid
|
|
time range, and weather elements received are displayed in the message.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-k</td>
|
|
<td>NO</td>
|
|
<td>Delete the input file(s) after processing has been completed.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-i parm</td>
|
|
<td>NO</td>
|
|
<td>If not present, then all weather elements found in the netCDF
|
|
file
|
|
that exist in the destination database will be stored or those
|
|
specified
|
|
by the -p switch will be stored. If present, the identified
|
|
weather
|
|
element, if found in the input file, will be skipped, even if a -p
|
|
switch
|
|
is given. There can be multiple -i switches, in the form of -i wx1 -i
|
|
wx2
|
|
-i wx3. The name refers to SFC weather elements, to denote a
|
|
weather
|
|
element for a different level, use the parmName_level format, such as
|
|
T_3K.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-l</td>
|
|
<td>NO</td>
|
|
<td>Lock flag. If set, then only one iscMosaic can run at a
|
|
time.
|
|
This switch is used by the intersite coordination software and is not
|
|
needed
|
|
for routine use of ifpnetCDF.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-D gridDelay</td>
|
|
<td>NO</td>
|
|
<td>Grid Delay. Specifies the delay between processing of grids.
|
|
Defaults
|
|
to 0.25 seconds. The delay is used to lessen the effect of ISC traffic
|
|
on the loading of EDEX, and hence affects the GFE performance.
|
|
The value
|
|
is in seconds, and can be fractional. To eliminate the delay, use the
|
|
-D 0
|
|
switch. </td>
|
|
</tr>
|
|
<tr>
|
|
<td style="vertical-align: top;">-o<br>
|
|
</td>
|
|
<td style="vertical-align: top;">NO<br>
|
|
</td>
|
|
<td style="vertical-align: top;">Use the office type from EDEX.
|
|
Incoming weather elements will be renamed if the data
|
|
is from a different office type than your own. For example,
|
|
receiving QPF data from an RFC at a WFO will have QPF stored as QPFrfc.<br>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td style="vertical-align: top;">-S<br>
|
|
</td>
|
|
<td style="vertical-align: top;">NO<br>
|
|
</td>
|
|
<td style="vertical-align: top;">Enables the "ISC Sending" for
|
|
this process. Depending upon how the EDEX ISC
|
|
configuration is set, different behaviors may be observed. If
|
|
"Send ISC On Save" is set, then the Fcst grids will be sent upon
|
|
saving. If "Send ISC On Save" is not set, then the user must
|
|
manually send the grids via a procedure through the Send Intersite
|
|
Grids capability.<br>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td style="vertical-align: top;">-T<br>
|
|
</td>
|
|
<td style="vertical-align: top;">NO<br>
|
|
</td>
|
|
<td style="vertical-align: top;">Enables the "translate" mode for
|
|
WEATHER and DISCRETE data. If incoming data is not
|
|
considered valid per EDEX definition, then the data keys will
|
|
be translated to simpler keys that is understood by EDEX.
|
|
See <a href="#translationRules">translation rules</a>
|
|
for more details.<br>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<font color="#3366ff"><b>Note:</b> The -h serverhost, -r rpcport, and -d
|
|
outputDatabaseID
|
|
are predefined based on your installation configration of
|
|
GFESuite.
|
|
The -h and -r will be defined for the server host and port specified
|
|
during
|
|
installation. The -d output database identifier is preset to the
|
|
ISC (intersite coordination database) for the site installed. If
|
|
you wish to connect to another server, then these switches will be
|
|
necessary. </font><font color="#3366ff"> If environment
|
|
variables ${CDSHOST} or
|
|
${CDSPORT} are defined, then the default server and port will be
|
|
determined from the environment variables, unless overridden with the
|
|
user specified -h and -r switches.<br>
|
|
</font>
|
|
<p><br>
|
|
</p>
|
|
<h3>
|
|
<a name="Restrictions"></a>Restrictions</h3>
|
|
The following restrictions apply to running this program:
|
|
<ul>
|
|
<li>The -n and -a switches cannot be specified together since they
|
|
are
|
|
mutually
|
|
exclusive.</li>
|
|
<li>If more than one -f switch is given, then the -x switch should
|
|
not be
|
|
given,
|
|
since it will not perform a merge.</li>
|
|
<li>If more than one -f switch is given, then the -z switch cannot be
|
|
given.</li>
|
|
<li>For purposes of intersite coordination, the following switches
|
|
must not
|
|
be specified: -s, -e, -x, -z, -n, -a. The following switch should
|
|
be specified: -b</li>
|
|
<li>The program ignores the database time constraints, so if the data
|
|
to be
|
|
stored does not fall within a valid time constraint, the grid will not
|
|
be stored. This isn't a problem with the intersite coordination
|
|
database,
|
|
since its grids are stored into the ISC database, which has time
|
|
constraints
|
|
of 1 hour.</li>
|
|
<li>If the "-d" switch specifies a database that does not currently
|
|
exist,
|
|
it will not be automatically created for you and the program will fail.</li>
|
|
</ul>
|
|
<hr width="100%">
|
|
<h2><a name="Examples"></a>Examples</h2>
|
|
This section describes the behavior of the iscMosaic program with the
|
|
various
|
|
options.
|
|
<h3><a name="DefaultBehavior"></a>Default Behavior</h3>
|
|
The default behavior, where the -h, -r, -d, and -f switches are given,
|
|
is to merge the grids in the input netCDF files into the destination
|
|
database.
|
|
<p>The following illustrates the concept of merging. Merging is
|
|
done
|
|
both temporally, and spatially.
|
|
<br>
|
|
|
|
<table nosave="" cellspacing="10">
|
|
<tbody>
|
|
<tr nosave="">
|
|
<td nosave=""><br>
|
|
</td>
|
|
<td>Original Grid, as viewed on the GFE at the remote site. Note
|
|
the inventory
|
|
for the grids. The merging will also perform temporal merges.</td>
|
|
<td>Grid, after it has been remapped and clipped to the
|
|
destination's grid
|
|
domain.</td>
|
|
</tr>
|
|
<tr nosave="">
|
|
<td>BOU</td>
|
|
<td nosave=""><img src="images/Mosaic_BOU_Orig.jpg" nosave=""
|
|
height="532" width="359"></td>
|
|
<td><img src="images/Mosaic_BOU_CWA.jpg" nosave="" height="540"
|
|
width="401"></td>
|
|
</tr>
|
|
<tr>
|
|
<td>CYS</td>
|
|
<td><img src="images/Mosaic_CYS_Orig.jpg" nosave="" height="489"
|
|
width="305"></td>
|
|
<td><img src="images/Mosaic_CYS_CWA.jpg" nosave="" height="542"
|
|
width="379"></td>
|
|
</tr>
|
|
<tr nosave="">
|
|
<td>PUB</td>
|
|
<td nosave=""><img src="images/Mosaic_PUB_Orig.jpg" nosave=""
|
|
height="523" width="331"></td>
|
|
<td><img src="images/Mosaic_PUB_CWA.jpg" nosave="" height="541"
|
|
width="380"></td>
|
|
</tr>
|
|
<tr>
|
|
<td><br>
|
|
</td>
|
|
<td><br>
|
|
</td>
|
|
<td><br>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</p>
|
|
<p>The result of merging the grids is shown in the following
|
|
image.
|
|
Note the grids contained within the grid manager for Temperature.
|
|
The inventory is a temporal blend of the BOU, CYS, and PUB grids.
|
|
</p>
|
|
<p><img src="images/Mosaic_BOUCYSPUB.jpg" nosave="" height="543"
|
|
width="381"></p>
|
|
<p>In the event that data is not available for a particular time period
|
|
from a site, the merged grid will contain missing data. The
|
|
missing
|
|
data is denoted by the weather element's minimum value, such as -30 for
|
|
temperature, calm for winds, and <NoWx> for weather grids.
|
|
Here
|
|
is an example of looping through a sequence of merged grids:
|
|
</p>
|
|
<p><img src="images/Mosaic_Loop.gif" nosave="" height="723" width="488"></p>
|
|
<h3><a name="Blanking"></a>Blanking</h3>
|
|
Blanking is used when when the incoming grids represent the entire
|
|
inventory
|
|
of grids for that weather element. Any grids, and any portions of
|
|
grids that do not overlap the incoming grids's valid times will be
|
|
blanked
|
|
when blanking is enabled. If blanking is disabled, then the
|
|
non-overlapping
|
|
portions of the grids will not have their data modified.
|
|
<p>The data written into a grid that has been "blanked" is basically
|
|
the
|
|
minimum data value or fill value over the area mask.
|
|
</p>
|
|
<p>Non-Blanking Situation:
|
|
<table nosave="" border="1" cols="3" width="100%">
|
|
<tbody>
|
|
<tr nosave="">
|
|
<td nosave=""><img src="images/Mosaic_Blank0.jpg" nosave=""
|
|
height="450" width="307"></td>
|
|
<td><img src="images/Mosaic_Blank1.jpg" nosave="" height="462"
|
|
width="288"></td>
|
|
<td><img src="images/Mosaic_Blank2.jpg" nosave="" height="462"
|
|
width="286"></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Original Grid before merging. Note the valid time of the grid
|
|
is 00z-07z.</td>
|
|
<td>Merging results in two grids since the merged grid is valid
|
|
from 00z-01z.
|
|
The two valid times are 00z-01z, and 01-07z. This is the first
|
|
grid
|
|
which now consists of the merged CYS data.</td>
|
|
<td>The second grid looks exactly the same as before the merge,
|
|
since the
|
|
incoming merged grid valid time (00-01z) does not overlap this grid
|
|
(01-07z).
|
|
This is the effect of blanking turned off.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</p>
|
|
<p>Blanking Situation:
|
|
<table nosave="" border="1" cols="3" width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<td><img src="images/Mosaic_Blank0.jpg" nosave="" height="450"
|
|
width="307"></td>
|
|
<td><img src="images/Mosaic_Blank1.jpg" nosave="" height="462"
|
|
width="288"></td>
|
|
<td><img src="images/Mosaic_Blank3.jpg" nosave="" height="458"
|
|
width="285"></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Original Grid before merging. Note the valid time of the grid
|
|
is 00z-07z.</td>
|
|
<td>Merging results in two grids since the merged grid is valid
|
|
from 00z-01z.
|
|
The two valid times are 00z-01z, and 01-07z. This is the first
|
|
grid
|
|
which now consists of the merged CYS data.</td>
|
|
<td>The second grid is different since blanking is enabled. Since
|
|
the incoming
|
|
merged grid valid time (00z-01z) does not overlap this grid's valid
|
|
time
|
|
(01-07z), the area defined by the CYS edit area is masked out (or set
|
|
to
|
|
the minimum value) to indicate there is no valid data available.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</p>
|
|
<h3><a name="ReplaceOnlyDoNotMerge"></a>Replace Only, Do Not Merge</h3>
|
|
If the replace only, do not merge flag is set via the command line,
|
|
then
|
|
an incoming grid will completely replace any overlapping existing grid,
|
|
rather than performing a merge.
|
|
<p>Here is an example of an existing grid and the result of performing
|
|
a replace. Note that the -a nor the -n switches were provided,
|
|
which
|
|
caused the grid to be masked over the PUB CWA:
|
|
<br>
|
|
|
|
<br>
|
|
|
|
<table nosave="" border="1" cols="2" width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<td><img src="images/Mosaic_Replace0.jpg" nosave="" height="541"
|
|
width="302"></td>
|
|
<td><img src="images/Mosaic_Replace.jpg" nosave="" height="541"
|
|
width="374"></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Merged Grid before the PUB grid has been added.</td>
|
|
<td>Merged (Replaced) grid after the PUB grid has been
|
|
added. The
|
|
PUB grid has completely replaced the CYS and BOU data sets since the -x
|
|
switch was used.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<br>
|
|
|
|
</p>
|
|
<h3><a name="NoMask"></a>No Mask</h3>
|
|
The -n switch specifies that all valid data in the incoming grid will
|
|
be
|
|
used. No mask will be applied. Here is an example of
|
|
storing
|
|
a PUB grid using the -n switch. A merge is performed, but since
|
|
there
|
|
wasn't data previously from CYS, that area is blanked out. Note
|
|
the
|
|
blank area at the top of the grid; this area was not covered by PUB's
|
|
original
|
|
grid domain, and hence data values cannot be applied to it.
|
|
<p>The use of no mask is generally used only when replacing grids; it
|
|
is
|
|
used in conjunction with the -x switch.
|
|
</p>
|
|
<p><img src="images/Mosaic_NoMask.jpg" nosave="" height="543"
|
|
width="379"><br>
|
|
|
|
</p>
|
|
<h3><a name="AlternativeMask"></a>Alternative Mask</h3>
|
|
The user may specifify an alternative mask, which is the name of an
|
|
edit
|
|
area. In this example, the original data before the merge is shown, the
|
|
edit area is outlined in the second image, and those data portions
|
|
within
|
|
the incoming file that are contained within the named edit area are
|
|
merged.
|
|
<br>
|
|
|
|
<br>
|
|
|
|
<table nosave="" cols="3" width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<td><img src="images/Mosaic_AltMask0.jpg" nosave="" height="458"
|
|
width="302"></td>
|
|
<td><img src="images/Mosaic.AltMask1.jpg" nosave="" height="430"
|
|
width="300"></td>
|
|
<td><img src="images/Mosaic_AltMask2.jpg" nosave="" height="408"
|
|
width="300"></td>
|
|
</tr>
|
|
<tr nosave="">
|
|
<td>Original Data set before merging.</td>
|
|
<td nosave="">The incoming data set when masked to the specified
|
|
area.
|
|
Note that some of the area is "blank", which was outside the original
|
|
grid's
|
|
domain. </td>
|
|
<td>The result of the merge.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<br>
|
|
|
|
<h2><a name="SimpleStorageofGrids"></a>Simple Storage of Grids</h2>
|
|
Another use for the iscMosaic program is to simply store grids from
|
|
netCDF
|
|
into the server. Of course the <a href="#RequiredFormat">format
|
|
of
|
|
the file</a> must meet the appropriate standards for the iscMosaic
|
|
program
|
|
to recognize the data.
|
|
<p>It is assumed that you will completely want to replace any existing
|
|
grids in the server. The following command line switches are normally
|
|
used
|
|
for this purpose:
|
|
<br>
|
|
|
|
<br>
|
|
|
|
<table nosave="" border="1" width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<td>-h hostname</td>
|
|
<td>Hostname upon which EDEX is running</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-r portNumber</td>
|
|
<td>RPC port number upon which EDEX is handling requests</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-d databaseOutputID</td>
|
|
<td>Name of the output database to store the grids</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-f inputFile</td>
|
|
<td>Name of the input netCDF file</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-x</td>
|
|
<td>Replace grids, do not merge.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-z</td>
|
|
<td>Erase all grids before storing.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>-n</td>
|
|
<td>Do not mask the grids upon storage</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</p>
|
|
<p>In addition, if you want to completely replace all existing data,
|
|
then
|
|
you will probably want to use all of the above switches.
|
|
</p>
|
|
<p></p>
|
|
<hr width="100%">
|
|
<h2><a name="RequiredFormat"></a>Required netCDF File Format</h2>
|
|
<p><br>
|
|
The format of the netCDF file is in the <a href="netCDFFormat.html">netCDF
|
|
file format documentation</a>.
|
|
<br>
|
|
|
|
</p>
|
|
<p></p>
|
|
<hr width="100%">
|
|
<h2><a name="TemporalMerge"></a>Temporal Mosaicing</h2>
|
|
<img src="images/Mosaic_Temporal.png" nosave="" height="540" width="720">
|
|
<br>
|
|
|
|
|
|
<hr width="100%">
|
|
<h2><a name="translationRules"></a>Translation Rules</h2>
|
|
When the -T switch is specified and incoming data does not conform to
|
|
"known values" by the EDEX definition, iscMosaic will attempt to
|
|
translate the data into "known values". The iscMosaic
|
|
log file will indicate which values were translated. If the
|
|
-w switch is present, then similar information will be sent to the GFEs
|
|
as alert (orange) messages on the ISC status bar.<br>
|
|
<br>
|
|
<h3>Discrete Data</h3>
|
|
<ol>
|
|
<li>If "overlapping" data is input (as denoted by the key^key
|
|
format), and EDEX is not configured for this weather element
|
|
to have overlapping data, then only the first key is
|
|
used. For example, "FW.A^SV.A" will translate into
|
|
"FW.A".</li>
|
|
<li>If data containing aux data fields is input and the field length
|
|
exceeds EDEX configuration, then the aux data field will be
|
|
dropped. For example, if the aux data field is configured
|
|
to be a maximum of 4 characters and "FW.A:12345" is input, it will be
|
|
translated into "FW.A".</li>
|
|
<li>If data containing an unknown key is input, then the data will be
|
|
translated into the first defined value in EDEX.
|
|
For many configurations including Hazards, this value is
|
|
"<None>". For example, if "XY.Z" is input, it will be
|
|
translated into "<None>".<br>
|
|
</li>
|
|
</ol>
|
|
<h3>Weather Data</h3>
|
|
<ol>
|
|
<li>If an unknown visibility is input, then the visibility will be
|
|
translated into the first configured visibility element in
|
|
EDEX, which is normally <NoVis>. For example,
|
|
"Sct:RW:-:52M:" will translate into "Sct:RW:-:<NoVis>".</li>
|
|
<li>If an unknown type is input, then the type and all associated
|
|
fields will be translated into the first configured type element in
|
|
EDEX, which is normally <NoWx>. For example,
|
|
"Sct:ZZZ:+:<NoVis>:" will translate into
|
|
"<NoCov>:<NoWx>:<NoInten>:<NoVis>:".</li>
|
|
<li>If an unknown coverage is input, then the coverage will be
|
|
translated into the first configured coverage for that weather
|
|
type. For example, "XXX:R:+:<NoVis>:" will translate
|
|
into "Wide:R:+:<NoVis>:".</li>
|
|
<li>If an unknown intensity is input, then the intensity will be
|
|
translated into the first configured intensity for that weather
|
|
type. For example, "Wide:R:?:<NoVis>:" will translate into
|
|
"Wide:R:--:<NoVis>:".</li>
|
|
<li>If an unknown attribute is input, then the attribute will be
|
|
removed. For examplle,
|
|
"Wide:T:<NoInten>:<NoVis>:DmgW,LgA,XYZ" will translate into
|
|
"Wide:T:<NoInten><NoVis>:DmgW,LgA".<br>
|
|
</li>
|
|
</ol>
|
|
<br>
|
|
<br>
|
|
</body>
|
|
</html>
|