[McIDAS #GTQ-654343]: Re: 20100219: Inquiry 14708 updated (cont.)

Hi Barry,

I wasn't able to get to this on Friday...

re: testing of new Nexrad Level III and TDWR products should be
straightforward

> Good to hear that the testing shouldn't be too difficult. :-)

Please let me know as soon as possible if you run into anything...

re: TDWR station information

> The new TDWR stations that need to be added to the station database is
> certainly an issue. I will bring it up at our team meeting tomorrow to
> get input from Kevin, Becky, Rick and others to see how they think we
> should handle it. If possible, I would rather *not* have users put the
> stations into the STNDB.SITE file for the reason you stated (needing to
> remove them once they're in STNDB.CORE - it's likely that some users
> would forget or not bother).

I agree completely.  If I had had a way to updated STNDB.CORE I would
have made the additions there, not in STNDB.SITE.

re:
> My inclination is to make a separate
> inquiry for just the station database changes so we can get it tested
> and into a release ASAP (either with, or possibly before, the release
> that includes the inq 14708 changes).

Sounds good to me.

re:

> I think a big help for us would be if you could provide a list of
> websites or other references that you find useful (e.g., indicating
> what data is currently out there and what is planned). For example, is
> 
> http://www.roc.noaa.gov/WSR88D/Level_III/Level3Info.aspx
> 
> one of the better references? Others?

Yes, this is definitely one of the important references.  In particular,
the PDF linked in:

Technical Implementation Notice 09_41 (PDF)
Addition of Higher Resolution WSR-88D Products to SBN/NOAAPORT and RPCCDS:
  Effective 9 February, 2010

Lists the "high resolution" Nexrad Level III products that are being
added to the NOAAPort SBN.

Some other useful links:

Nexrad Level III
http://www.roc.noaa.gov/WSR88D/Program/IFRAMES/ICDS/icd_downloads_iframe.asp
2620001M - ICD FOR RPG TO CLASS 1 USER - Build 11.0 (PDF)

TDWR
http://www.roc.noaa.gov/SPG/PublicDocs/SPG_Class1_ICD.pdf

Proposed Level III dual polarization products
http://www.unidata.ucar.edu/mailing_lists/archives/nws-changes/2010/msg00073.html

re: possible need for new enhancement tables for "high resolution"
Nexrad Level III products

> I will also bring up this topic at tomorrow's meeting. If the new
> products are simply higher resolution versions of the existing
> products, then my vote would be to *not* create any new enhancements
> (i.e., just use the existing ones).

I have put "high resolution" in quotes in my emails because:

- the new products do not have higher spatial resolution
- the new products have more display levels, up to 256

re:
> Would you be willing to share those mods to IMGDISP.CORE that you're
> making or have already made? If so, please send them to us. Thanks!

Sure.  The problem, however, is that I do not use the same descriptor
names for my Nexrad Level III datastets as SSEC:

- you use NEXRAD for the group name, and I use RTNEXRAD
- you have different descriptors than me:

  NEXRAD/BREF1  <->  RTNEXRAD/N0R
  NEXRAD/BREF2  <->  RTNEXRAD/N1R
  etc.

  I chose to use the the names that the NWS uses for sets of
  images as my descriptor names (e.g., NxR -> base reflectivities;
  NxV -> base velocities; etc.).  Looking at the proposed dual
  polarization products, I will easily be able to add new
  datasets if/when the products are added:

  RTNEXRAD/NxX  -> differential reflectivity 159/DZD
  RTNEXRAD/NxC  -> correlation coefficient 161/DCC
  and so on.

  RTTDWR/TRx    -> TDWR base reflectivities
  RTTDWR/TVx    -> TDWR base velocities
  RTTDWR/TZL    -> 225 nmi base reflectivity

  NB: there is an overlap in a number of the datasets for Nexrad
  Level III and TDWR.  For instance:

  RTNEXRAD/NCR  -> composite reflectivity
  RTTDWR/NCR    -> TDWR composite reflectivity

So, the first order of business is for you (SSEC) to decide
on how to name the new Level III, TDWR, and proposed dual
polarization datasets.

re:
> I agree that it would be nice if the IMGDISP.CORE entries centered the
> images at the radar station (rather than loading the image such that
> the upper-left corner of the image is placed at the upper-left corner
> of the frame). I remember looking into this years ago, and I think we
> agreed it would be nice, but that it would be better to let the user
> choose whether to center it (with STA= keyword in their command entry)
> rather than force them to specify it (with REQUIRE=STA in
> IMGDISP.CORE). You could argue that REQURE=STA would be a good idea,
> but I think some users would complain that they shouldn't be forced to
> specify that keyword since they're fine with the default (upper-left
> corner).

Actually, I would argue that radar images are fundamentally different
from satellite images.  It makes the most sense to me that radar
images get loaded so that the radar is at the center of the display.
The user can always change the load (override IMGDISP.CORE settings)
by specifying STATION=, LATLON=, LINELE=.

It seems to me that the most useful change would be to finish the
implementation of the notion of LATLON=CENTER and/or LINELE=CENTER
in IMGDISP.  This effort seems to have been started quite some time
ago since the source code for IMGDISP has the stubs for this:

C ? *********************  Frame Positioning Keywords  ***********************
C ?    LATlon=lat lon | latitude and longitude to place at the frame location
C ?                     specified in the PLACE keyword
C            =CENTER  | places center of image at the frame location specified
C                       in the PLACE keyword
C ?    LINele=line ele sys | line and element numbers and coordinate system
C ?                          (F or I for file and image, respectively) to
C ?                          place at frame location specified in the PLACE
C ?                          keyword (line def=0, ele def=line, sys def=F)
C            =CENTER       | places center of image at the frame location
C                            specified in the PLACE keyword

If a user could specify that center of the image should be loaded at
the center of the display, then output from things like CIRCLE could
easily be added to IMGDISP.(CORE|SITE|USER) entries.

re:
> Perhaps another option would be to update imgdisp.pgm so that its ID=
> keyword both picks the NEXRAD station ID and automatically centers the
> image on the station (by doing the equivalent of STA=). Therefore
> IMGDISP MKX_BREF1 ID=DVN would both select the Quad Cities image *and*
> center the image display on the station.  But having a keyword (ID= in
> this case) perform a second function that's already available in
> another keyword (STA= in this case) might be objectionable. What do you
> think?

Yup, I have already looked into this approach for the Unidata release.  I
haven't implemented it because I wanted to have a discussion with you guys
about what the best approach would be for all McIDAS users.

re:
> Just wanted to let you know that I shifted some things around in inquiry
> 14708. Specifically, I moved the existing entries in the Comments field to
> the Request and Action fields, and added our emails to the Comments field.
> 
> I did that because
> 
> (a) we prefer to use the Comments field for background info and discussion
> of issues like those in our emails [we don't have a searchable email
> archive so putting them in the inquiry kinda serves that purpose],
> 
> (b) we also prefer that the descriptions of completed code changes be
> placed with the corresponding lists of modules in the Action
> field. Descriptions of needed code changes that haven't been done yet
> can go in either the Request field or Comments field. So where you
> originally put them (in the Comments field) was fine. But in this
> case I moved them to the Request field because I didn't want them
> to get lost with all the background info and discussions contained
> in the emails I added to the Comments field.
> 
> I hope you're ok with those changes.

Yes, I am AOK with the changes.  I would have not scattered my comments
around like I did if I had had this guidance previously!  I will try
to follow these guidelines in the future.

re:
> Adding all that content to the
> Comments field will make it easy for anyone with access to that field
> (which I believe is restricted to the IPs of "code and inquiry editors"
> like you and us) to access the discussions that were associated with
> the inquiry, and thus see why certain code changes were done the way
> they were.

OK.

re:
> Also, I fixed what I think was a minor typo in 26-feb-2010 entry in the
> Action field (I changed "nerutil.c" and "nerutil.h" to "nexrutil.c" and
> "nexrutil.h", respectively).

Oops.  Thanks for catching and fixing the typos!

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