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

[netCDFJava #LOE-612985]: Nexrad decoding errors

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.

  • Subject: [netCDFJava #LOE-612985]: Nexrad decoding errors
  • Date: Mon, 02 Jun 2014 10:05:06 -0600
David,

If I hadn't done this particular problem so many times, it wouldn't have been 
obvious.

Glad we got you up and running!

Ryan

> Ryan,
> Typically, one might be insulted by a statement like 'rudimentary map 
> projection'.... but since that is exactly what was giving me the problem, I 
> am sitting here with my hands over my face slightly embarrassed.  I will 
> admit, though, that I had suspected it was projection.    In other words, my 
> conversion was NOT robust and I forgot to do the adjustments of the longitude 
> spacing based on latitude.... That is now fixed!
> FWIW, I haven’t dealt with programming of this nature in nearly 20 years.. 
> and even then, I used Gempak.  This was a great refresher course for me; one 
> that would have failed without your help.  With that said, thanks a ton for 
> helping me out.   I'm guessing you provided 'higher than average' tech 
> support to me so I want you to know that it is appreciated.
> 
> -----Original Message-----
> From: Unidata netCDF Java Support [mailto:address@hidden]
> Sent: Friday, May 30, 2014 6:05 PM
> To: Hamilton, David
> Cc: address@hidden; Hamilton, David
> Subject: [netCDFJava #LOE-612985]: Nexrad decoding errors
> 
> The math overall looks correct. My guess is that your difference comes from 
> km2deg(), which I'm assuming is converting your range to lat/lon degrees. 
> This sounds like a rudimentary map projection, which is probably where you 
> differ from WCT. Since range is a polar variable, I'm not sure that 
> converting it to degrees is robust, since even the most simple conversion 
> would likely differ for N/S degrees vs. E/W degrees. Either way, I don't 
> think you're having any problems with the data I/O or netcdf. Good luck with 
> the MatLab!
> 

Ticket Details
===================
Ticket ID: LOE-612985
Department: Support netCDF Java
Priority: Normal
Status: Open