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.
Hi Yoori, re: > I went through the steps what you did. And I'm really glad that it is > working. :) Very good. > I have couple things to ask. Ready... > 1. About "set the system clock", when I see the clock on Linux machine, it > is different what I have. (i.e. LINUX - 11:00 am, my current time - > 12:00pm). It should be that way? Actually, no, it should not be that way. Since the UTC time is correct, it means that the system was setup in the wrong timezone. My surmise is borne out by a 'date' listing on nopp: [root@nopp ~]# date Mon Apr 30 13:42:40 CDT 2007 To correct the time setup on nopp, I ran 'timeconfig' as 'root' and set your time to be in the same zone as New York. Your local time is now EDT: [root@nopp ~]# date Mon Apr 30 15:51:51 EDT 2007 > 2. I checked the 'data' directory and see files what were ingested. I didn't > have any problem to open any files from 'LEVEL2' directory (it has tar file > included xml and bmp), but when I try to open any files from 'LEVEL3' > directory, none of them can not display. I checked the property of file type > and tried to open gedit, emacs, etc, but none of them had luck. The Nexrad Level III products under the /usr/local/ldm/data/LEVEL3 directory are binary; you can not use a text editor to look at them. > 3. For now, I used upstream data feeders which provide by Unidata center, > but in the future, we might get upstream data from other institution. To get > the data from upstream, then I only need to include REQUEST line in ldm.conf > and prduct line in pqact.conf files?? Yes. > Then I do the command like ldm > restart?? The command would be: <as 'ldm'> -- edit ~ldm/etc/ldmd.conf to add/subtract/modify one or more REQUEST lines ldmadmin restart > If I setup correctly both ldm.conf and pqact.conf files, then it > will automatically ingest data and store in the directory what I pointed out > in pqact.conf file without doing any extra action?? Yes, exactly. > When I see the 'LEVEL2' > directory, it seems like that data for each day and time are automatically > ingesting and storing in my machine. Correct. > And you mentioned earlier email saying > that you will contact to people (EXP) to ask about setting up 'pqact.conf' > file. Yes. My intention was to see if the other folks that are ingesting data from mapserver.unidata.ucar.edu had settled on a standard directory structure for storing ingested data. Since we did not hear back from these folks (and still haven't), I decided to go ahead and create a hierarchical directory structure using information included in the product headers in the EXP feed. I am willing to bet that others did exactly the same thing. > Usually the help to setup 'pqact.conf' file can ask through upstream > feeders? Not necessarily. What a site decides to do with data that is received is up to them. One site might decide to simply FILE the products; another might decide to process the products using some sort of a 'decoder'; etc. > As you know that, I had problem to figure out it. This is understandable since you had no exposure to the LDM before starting on this project. > 4. When I requested the upstream feeder to unidata center, I requested 3 > feeders which are 'AFOS', 'NNEXRAD', and 'EXP -FT30'. While 'AFOS' is listed as an available feed in: Unidata LDM HomePage http://www.unidata.ucar.edu/software/ldm/ LDM Feedtypes of the Current Release http://www.unidata.ucar.edu/software/ldm/ldm-current/basics/feedtypes/ there has been no AFOS data sent in the IDD for years. The Suominet project (do a Google search on Suominet for more information) uses the alternate name for this feed, GPSSRC, to send GPS occultation-derived water vapor data back to UCAR. I don't think this is something you want (I could be wrong), and we don't have the data to send to you anyway. > So I received > mapserver.unidata.ucar.edu for EXP and idd.unidata.ucar.edu for both AFOS > and NNEXRAD. Yes, I talked to Jeff Weber about this. We agreed that it would be better for you to feed all feeds other than EXP From idd.cise-nsf.gov. > When I see the ldm.conf file, EXP upstream feeders are okay, > but for NNEXRAD, it was as 'idd.cise-nsf.gov'. Since I don't have any > problem to get the data, it won't be a big deal. But I'm curious that since > I got the permission for 'AFOS' and 'NNEXRAD' as 'idd.unidata.ucar.edu', do > I have to change to this address since I also have to ingest data for 'AFOS' > as well. No. Again, there is no AFOS data to get, so you don't need to worry about it. > If it doesn't need, AFOS data was also included and ingested?? From > data feeder website, there isn't detailed description for AFOS except > "National Weather Service AFOS" so not clear. This feed is now archaic. Please disregard it. > Thanks a lot. No worries. Cheers, Tom **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: NXJ-554265 Department: Support LDM Priority: Normal Status: Closed