This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: address@hidden >Organization: . >Keywords: 200003131922.MAA08549 > > > >>The directory structure under $SAT is shown in the nsat section of the >tutorial. >>The GOES8 and GOES9 are just convenience variable- not needed. GARP, NSAT >and >>in the next release NMAP, use the directory structure to classify the >products. >>The sat files can be either GINI from NOAAport or McIDAS area files. The >radar >>products can be either NIDS format from NOAAport or McIDAS area files. >>See: http://www.unidata.ucar.edu/packages/gempak/tutorial/nsat.html > >NSAT is confusing me a bit. I understand the directory structure from the >nsat.html, but I'm not sure if the actual files get stored there or is it a >link? I would be ok with entries in pqact.conf that put these files in >your specific directory struture (do you have any sample pqact entries?) >I'm also not sure what these scripts do and if I need to set them up since >I don't have area files. > >I know how busy you are, but would appreciate any more info you can >provide.... > >Alan. > > > > Alan, Our AREA files come with names like AREA0120, AREA0121, etc. Those names don't tell the uses what is in them, so I have to rename them in to the $SAT directory struction. These can be either links, or files. Since we have McIDAS users as well, I just create links to the files to avoid storing duplicate sets of data- and I use the areaInfo program to read the area files and output the necessary file name info from the McIDAS data. You don't have to work about any of this. My intention of pointing you to the nsat page was to give you the basic directory heirachy that Garp and NSAT use to produce the sucession of menu entries in the GUI. When you pop up the browser, those GUIs use the GOES-8, GINI-E, SUPER-NATIONAL etc names to make a top level of widges to select what satellite. Then After selecting a widget, the GUI uses the resolution (1km, 4km, 8km etc) subdirectory names under the sector name to provide the next level of menu. Finally the file/times are presented. Its just a directory structure to shorten the search through the available files. For the GINI data off the NOAAport feed, you can create pqact.conf entries to file the data directly into the $SAT structure (or Glenn Rutledge had mentioned using a script from COMET to do the same). In my NOAAport stream, I actually rename the products so that all the pieces needed in the file structure- eg the sector, resolution, band, platform are all in the LDM id...I know you don't have this. An example of filing the data directly from pqact.conf would look like: TIG([EW])01 KNES ([0-3][0-9])([0-2][0-9])([0-5][0-9]) FILE data/gempak/images/sat/GINI-\1/1km/VIS/VIS_(\2:yy)(\2:mm)\2_\3\4 TIGN01 KNES ([0-3][0-9])([0-2][0-9])([0-5][0-9]) FILE data/gempak/images/sat/SUPER-NATIONAL/8km/VIS/VIS_(\1:yy)(\1:mm)\1_\2\3 In the above, the first line will capture the 01 (visible) images from the CONUS Goes East and GOES West and file them to the appropriate ditectory name. The ([EW]) allows the one line to work for both East and West. The second line is an example of the 8km supernational composite. Though, you could have a single line of ([A-Z]) etc for GINI-E, GINI-W, GINI-N, GINI-I etc....however, that forces the user to know that GINI-P is a Puerto Rico sector. Since the WMO type of names like TIGW01 don't really relate well to directory names, you just have to have a lot of pqact.conf entries for all the different combinations of the sector and band identifiers. You just have to copy and paste a lot in the pqact.conf file so that you have separate entries for 01, 02, 03, 04, 05 for VIS, IR, IR12.0, IR3.9 and WV respectively as well as sector/resolution names. My products in the LDM look like: sat/ch2/GOES-10/WV/20000311 1045/WEST-CONUS/8km/ TIGW05 KNES 111045 sat/ch2/GOES-10/IR/20000311 1045/WEST-CONUS/4km/ TIGW02 KNES 111045 sat/ch2/GOES-10/12.0/20000311 1045/WEST-CONUS/4km/ TIGW03 KNES 111045 sat/ch2/GOES-10/VIS/20000311 1100/WEST-CONUS/1km/ TIGW01 KNES 111100 sat/ch2/GOES-10/3.9/20000311 1100/WEST-CONUS/4km/ TIGW04 KNES 111100 So I just store the products using the individual pieces I can parse out. Steve Chiswell