[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[McIDAS #STG-808468]: Conversion of mcidas area to shapefile format

Hi Martha and Randy,

Martha said:
> I did what Tom suggested, edited the MCPATH in ~mcadde/.mcenv, but that
> didn't fix the problem.

My comments yesterday were about how to make your remote ADDE setup look
more like the one I recommend for Unidata McIDAS.  The current inquiry
is tangentially, not directly, associated with that.

> We are not storing the NEXRAD in the UNIDATA suggested hierarchy
> (/data/ldm/nexrad...) but instead in /data/nexrad...  I suspect that is
> what is causing the problem.  I thought that I edited all the CFG files
> to reflect the different directory, but perhaps I missed some.

A comment and a question:

- the current Unidata procedure for NEXRAD Level III data serving uses the
  DIRFILE= approach, not the INFO=NNEXRAD.CFG approach.  Both should work
  with no problems, but the INFO=NNEXRAD.CFG approach is not what is
  implemented in what 'mcxconfig' does.

- you say you store your NEXRAD Level III files in /data/nexrad.  What do
  the file names look like?  (I do not use the SSEC approach for saving
  the NEXRAD Level III data, so I am not familiar with how the files are
  laid out on disk.)

> What I edited, all in /home/mcidas/workdata, are NNEXRAD.CFG,
> NEXRCOMP.CFG, and WNEXRAD.CFG setting up the DIRMASK to point to /data/nexrad.

The template, ~mcidas/workdata/NNEXRAD.CFG (which is designed to be copied
to a new file of a different name), has the following lines that are used:


The DIRMASK portion is a regular type expression for the directory(ies) in 
which the
files live; the FILEMASK portion is a regular type expression for the names of
the files.  This brings me back to the question above:

- what do the file names look like for your NEXRAD Level III processing?

> I would write to Tom telling him this, asking what we have missed.

After your local copy of NNEXRAD.CFG is setup correctly (meaning that DIRMASK
and FILEMASK match how your files are saved on disk), then you would setup
ADDE serving of those data using:


You may want to consider using the more standard DIRFILE approach as it is more
in line with SSEC's approach (I developed the the INFO= before SSEC adopted
my code for NEXRAD Level III serving).  Please take a look at 
to see what I am referring to for defining RTNEXRAD datasets.

Randy said:
> We just discovered that we are not able to see the NEXRAD data which is
> coming in over noaaport. I believe with the SSEC mcidas-xcd the dataset
> is called NEXRAD and the unidata is called RTNEXRAD.

Yes, we use different group names for the ADDE datasets.  This should not
be any problem.

> So when we now do a
> dsinfo.k ALL RTNEXRAD we get all the datasets, although they have
> different names then SSEC (e.g., N0R vs. BREF1).

Correct again.  I opted to name my dataset descriptors after the product
names in NOAAPort.  The BREF1, etc., names match those from the original
WSI datafeed that Unidata universities used a number of years ago.

> However, when we do an
> imglist on RTNEXRAD/N0R ID=LWX it does not see the data that is clearly
> there.

This implies that the server mapping table entries for RTNEXRAD are not
correctly setup for the way you are storing your files on disk.

> Martha is researching this from home today, since it finally
> snowed here, but I thought I would query you on this as well.

I think that the solution will be simple.  I will be better able to advise
you after I know more about how your NEXRAD Level III files are saved to
disk (i.e., directory structure and file naming).


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: STG-808468
Department: Support McIDAS
Priority: Normal
Status: Closed

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.