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
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.