iPhone App
NOAAPORT Unisys Channel
Data Specifications and Content
December 2001
Data Specifications and Content
December 2001
Data Specifications
The Unisys Channel is available to provide data in a NOAAPORT format that is not currently available on the standard NOAAPORT channels. The content is a variety of legacy data, commercially available data and value added products. Because of the proprietary nature, the data on the channel is encypted and compressed. In order to access the data, a decryption program and key files will be provided.
The key files will be sent 3 times during the afternoon to make sure the enduser receives it. They will be sent at roughly hour intervals between 19 and 22Z. The key files are themselves encrypted and keys must be used to decrypyt these. Here is a header from a key file:
Once the key file is saved to disk, it can be used to decrypt other products on the channel. Obviously each product will have to be piped through the decode program. The "-f" parameter to decode tells the program to file the product. The additional parameters determine the location of the key file, the input file name ("-" is standard input) and output filename. In these cases, the product manager constructs the output filename from the tags/wildcards. This will vary depending on the product manager.
The process for decrypting goes as follows:
Data Content
This is a list of the channel contents including WMO and AWIPS header and data format:
Radar Data
NOTES:
1 - Regional mosaics. The WMO header characters "xx" denote the region. These are: "NE" for northeast, "SE" for southeast, "NC" for north central, "SC" for south central, "CE" for central, "NW" for northwest and "SW" for southwest.
FORMAT: The NIDS+ format is essentially the NIDS rastor format. The source ID rather than being the site ID is a number greater than 10000 (10000 for national mosaics, 10001-10007 for the regional mosaics). The rastor data is placed on a Lambert Conformal projection centered at 98 west and having true latitudes of 33 and 45 north. The grid resolution is specified in the description for the product and the center of the projection is the latitude and longitude in the NIDS header.
NOTES:
1 - The number "xx" denotes the minute of the hour for the particular data ranging from 00-57 every 3 minutes.
NOTES:
1 - The 3 digits "xxx" denote the difax chart number ranging from 001 to 290.
The second format is standard GIF image format.
Encryption Key Files
Data Encryption and Compression
The encryption uses a public domain encyption API and the ZLIB deflate/gzip for compression. This requires a slightly different structure to the data content. The NOAAPORT CCB (header) is the same. The WMO header is developed to mimic WMO standards so data can be classified using existing WMO categories even though any WMO header could be used. The originating location will be ZUNI to denote Unisys as the source. Every product will have an AWIPS header that describes more closely the data content. These headers will be described in more detail below in the Data Content section. In addition, there will always be a Unisys header following the AWIPS header. This header describes the type of data, the encryption key name and compression type (if used). Here is an example header:DFAA91 ZUNI 040334This example is for FAA 604 data. The data type is "FOS". The encryption key name is "FOS6041A" and the data is GZIP compressed. There will be a different key name for each type of data on the channel. This gives Unisys the ability to control access to each data type. So individual data types can be turned on and off at any time by changing parameters in the encryption key file (see below). The PAD is for word alignment for encryption.
454FAA
UNISYS=V1.0 TYPE=FOS KEY=FOS6041A COMP=GZIP PAD=!!!!!!!
Encryption Key Files
This file contains a mapping between data key names and encryption key values. The values are fed into the encryption API to decrypt the data. The filename will always be "mykeybox.inf". Here is a sample key file:CRYPTOKEY=NatMos1B CRYPTOVALUE=NONEEach type of data (such as FOS604) on the channel will have a specific key and decryption value. For each data type, there will be two keys: an A and a B key (FOS604A and FOS604B). At any time, one of the two is active but at a predetermined time, the key will change. For example, if the current active key is A, the A key will be used. This is determined by the "KEY=" tag in the Unisys header. If the key changeover is set for 00Z, at that time, the key will be B, rather than A. The key file contains both so that there is no interruption in data if a new key file is not received prior to the changeover. After the changeover time, a new key file will be sent with the current B key and a new A key that will be used after the next changeover.
CRYPTOKEY=NatMos1A CRYPTOVALUE=NONE
CRYPTOKEY=RegMos1B CRYPTOVALUE=NONE
CRYPTOKEY=RegMos1A CRYPTOVALUE=NONE
CRYPTOKEY=DIFAX1B CRYPTOVALUE=NONE
CRYPTOKEY=DIFAX1A CRYPTOVALUE=NONE
CRYPTOKEY=FOSPPS1B CRYPTOVALUE=NONE
CRYPTOKEY=FOSPPS1A CRYPTOVALUE=NONE
CRYPTOKEY=FOSDDS1B CRYPTOVALUE=NONE
CRYPTOKEY=FOSDDS1A CRYPTOVALUE=NONE
CRYPTOKEY=FOSIDS1B CRYPTOVALUE=NONE
CRYPTOKEY=FOSIDS1A CRYPTOVALUE=NONE
CRYPTOKEY=FOS6041B CRYPTOVALUE=6CQ5S9jT8tTr9TwJC5i2Dfne
CRYPTOKEY=FOS6041A CRYPTOVALUE=wyyfekmM7rE4MQqW9YBk4osA
The key files will be sent 3 times during the afternoon to make sure the enduser receives it. They will be sent at roughly hour intervals between 19 and 22Z. The key files are themselves encrypted and keys must be used to decrypyt these. Here is a header from a key file:
NLIC99 ZUNI 022100The end user will be provided with a key name specific to the customer and value to decrypt this file. Once decrypted, the file will be written to "mykeybox.inf" and can be used to decrypt the other data types.
KUNI03
UNISYS=V1.0 TYPE=KEY KEY=UNISYS3 COMP=NONE PAD=!!!!!!!!
Product Manager Setup and decode Program
To decrypt and decompress the data, there are two steps. First is to decrypt the key file and the second is to decrypt the data. Here are examples using the WXP product manager:#The NLIC99 line takes the products with a NLIC99 WMO header and pipes the output through the decode program and outputs the "mykeybox.inf" file. Since there are multiple customers using the channel, each customer will be issued a key name. In this case, it is "UNISYS3". There will be more than one NLIC99 product that comes across (one for each customer) and the decode program will use only the product that has a key equal to UNISYS3 and will ignore all others. The "-k" option tells the decode program that this is a key file. The additional parameters include the directory to save the key file, the key name for the customer and the key value used to decrypt the file. The "-" parameter is for addition file output and is ignored.
# Key files
#
NLIC99 B| /usr/prodman/bin/decode -k /usr/prodman/unisys/lic UNISYS3 120101UNISYS3KEYTEST -
#
# FOS/FAA 604 products
#
DFAA91 B| /usr/prodman/bin/decode -f /usr/prodman/unisys/lic - %D/faa604/%y%m%d%h%n.faa
DDDS91 B| /usr/prodman/bin/decode -f /usr/prodman/unisys/lic - %D/fos/%y%m%d%h%n.dds
DPPS91 B| /usr/prodman/bin/decode -f /usr/prodman/unisys/lic - %D/fos/%y%m%d%h%n.pps
DIDS91 B| /usr/prodman/bin/decode -f /usr/prodman/unisys/lic - %D/fos/%y%m%d%h%n.ids
Once the key file is saved to disk, it can be used to decrypt other products on the channel. Obviously each product will have to be piped through the decode program. The "-f" parameter to decode tells the program to file the product. The additional parameters determine the location of the key file, the input file name ("-" is standard input) and output filename. In these cases, the product manager constructs the output filename from the tags/wildcards. This will vary depending on the product manager.
The process for decrypting goes as follows:
- The data for the product type is received and is sent to the decode program.
- The Unisys header is read and the product key name is found.
- The product key name is searched for in the key file and the key value is obtained
- The key value is used to decrypt the data in the product
- If the Unisys header specifies the data is compressed, the decode program will then decompress the data
- The output is saved to the file name listed.
LDM Setup
If the product manager is the LDM, then the procedure is very similar to the procedure listed above. The only difference is that the "decode" program must be obtained for the particular platform the LDM resides on. This could be Linux, Solaris, Intel Solaris, etc. Check with Unisys to see if your platform is supported. Here is a sample "pqact.conf" entry# Key files
WMO ^NLIC99
PIPE -close /home/ldm/bin/decode -k /home/ldm/unisys/lic UNISYS3 120101UNISYS3KEYTEST -
# FOS data
WMO ^DFAA91 .... ([0-3][0-9])([0-2][0-9])([0-5][0-9])
PIPE -close /home/ldm/bin/decode -f /home/ldm/unisys/lic - /home/ldm/unisys/faa604/(\1:yy)(\1:mm)\1\2\3.faa
Data Content
This is a list of the channel contents including WMO and AWIPS header and data format:
Radar Data
| WMO Header |
AWIPS Header |
Description |
Format |
| SDUS91 |
BR2MNA |
2km base reflectivity national mosaic (prod=140) |
NIDS+ |
| SDUS91 |
BR4MNA |
4km base reflectivity national mosaic (prod=141) |
NIDS+ |
| SDUS91 |
BR8MNA |
8km base reflectivity national mosaic (prod=142) |
NIDS+ |
| SDUS91 |
CR4MNA |
4km composite reflectivity national mosaic (prod=27) |
NIDS+ |
| SDUS91 |
CR8MNA |
8km composite reflectivity national mosaic (prod=28) |
NIDS+ |
| SDUS91 |
CP4MNA |
4km composite reflectivity national mosaic, precip only (prod=103) |
NIDS+ |
| SDUS91 |
ET4MNA |
4km echo top national mosaic (prod=95) |
NIDS+ |
| SDUS91 |
R14MNA |
4km 1 hour precipitation national mosaic (prod=90) |
NIDS+ |
| SDUS91 |
RA4MNA |
4km precipitation accumulation since 12Z mosaic (prod=101) |
NIDS+ |
| SDUS91 |
RD4MNA |
4km 24 hour (daily) precipitation mosaic 12Z-12Z (prod=102) |
NIDS+ |
| SDUS91 |
SATMNA |
Storm attribute table for all sites (prod=100) |
NIDS+ |
| SDxx911 |
BR2MRC |
2km base reflectivity regional mosaic (prod=140) |
NIDS+ |
| SDxx911 |
RD2MRC |
2km 24 hours (daily) regional precipitation 12Z-12Z (prod=106) |
NIDS+ |
NOTES:
1 - Regional mosaics. The WMO header characters "xx" denote the region. These are: "NE" for northeast, "SE" for southeast, "NC" for north central, "SC" for south central, "CE" for central, "NW" for northwest and "SW" for southwest.
FORMAT: The NIDS+ format is essentially the NIDS rastor format. The source ID rather than being the site ID is a number greater than 10000 (10000 for national mosaics, 10001-10007 for the regional mosaics). The rastor data is placed on a Lambert Conformal projection centered at 98 west and having true latitudes of 33 and 45 north. The grid resolution is specified in the description for the product and the center of the projection is the latitude and longitude in the NIDS header.
Family Of Services/FAA Data
This is not stream data but 3 minute collectives. The contents of the files are identical to the stream data.|
WMO Header |
AWIPS Header |
Description |
Format |
| DPPS91 |
1xxPPS
1 |
Public
products data (3 minute file) |
ASCII |
| DDDS91 |
2xxDDS
1 |
Domestic
data (3 minute files) |
ASCII |
| DIDS91 |
3xxIDS
1 |
International
data (3 minute files) |
ASCII |
| DFAA91 |
4xxFAA
1 |
FAA
604 data (3 minute files) |
ASCII |
NOTES:
1 - The number "xx" denotes the minute of the hour for the particular data ranging from 00-57 every 3 minutes.
Difax Charts
The charts are the standard set of Difax charts distinguished by chart number and saved in PNG image format.|
WMO Header |
AWIPS Header |
Description |
Format |
| QDFX11 |
xxxDFX
1 |
Difax
charts |
PNG image |
NOTES:
1 - The 3 digits "xxx" denote the difax chart number ranging from 001 to 290.
Satellite Imagery
These files are in two formats. The first is a rastor dump format. There is an ASCII header imbedded into the first several pixels of the image that describe the image size, time and type. Here is a sample:hs107 x1024 y1024 wr11185 hr11185 iddisk_vis b2 ssn8 sln2 esn9164 eln2291 sr1 lr5 fld1007494368 v10137 endThe image size is defined in the "x" and "y" values. Other parameters can be used with navigation information specific to the satellite to do more precise navigation of the image.
The second format is standard GIF image format.
|
WMO Header |
AWIPS Header |
Description |
Format |
| TIGM91 |
VFDGMS |
Visible
full disk GMS image |
Rastor |
| TIGM91 |
IFDGMS |
IR
full disk GMS image |
Rastor |
| TIGM91 |
WFDGMS |
Water
Vapor full disk GMS image |
Rastor |
| TIGM91 |
VASGMS |
Visible
GMS image, eastern Asia sector |
Rastor |
| TIGM91 |
IASGMS |
IR
GMS image, eastern Asia sector |
Rastor |
| TIGM91 |
VINGMS |
Visible
GMS image, India sector |
Rastor |
| TIGM91 |
IJKGMS |
IR
GMS image, Japan/Korea sector |
Rastor |
| TIGM92 |
VFDGMS |
Visible
full disk GMS image |
GIF
image |
| TIGM92 |
IFDGMS |
IR
full disk GMS image |
GIF
image |
| TIGM92 |
WFDGMS |
Water
Vapor full disk GMS image |
GIF
image |
| TIGM92 |
VASGMS |
Visible
GMS image, eastern Asia sector |
GIF
image |
| TIGM92 |
IASGMS |
IR
GMS image, eastern Asia sector |
GIF
image |
| TIGM92 |
VNPGMS |
Visible
GMS image, north Pacific sector |
GIF
image |
| TIGM92 |
INPGMS |
IR
GMS image, north Pacific sector |
GIF
image |
| TIGM92 |
VINGMS |
Visible
GMS image, India sector |
GIF
image |
| TIGM92 |
IJKGMS |
IR
GMS image, Japan/Korea sector |
GIF
image |
| TIME91 |
VFDMET |
Visible
full disk Meteosat image |
Rastor |
| TIME91 |
IFDMET |
IR
full disk Meteosat image |
Rastor |
| TIME91 |
WFDMET |
Water
vapor full disk Meteosat image |
Rastor |
| TIME91 |
VEUMET |
Visible
Meteosat image, Europe sector |
Rastor |
| TIME91 |
IEUMET |
IR
Meteosat image, Europe sector |
Rastor |
| TIME91 |
VPGMET |
Visible
Meteosat image, Persian Gulf sector |
Rastor |
| TIME91 |
IPGMET |
IR
Meteosat image, Persian Gulf sector |
Rastor |
Encryption Key Files
|
WMO Header |
AWIPS Header |
Description |
Format |
| NLIC99 |
Encryption
key file |
ASCII |