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

[THREDDS #QGE-896632]: Nexrad Level 2 Support

Hi,

The 2432 size is the fixed message size for older data messages. Newer data 
(like type 31) are not constrained by fixed size. My guess (I'm not completely 
sure), is that somewhere that offset is being incremented automatically with 
that legacy size, but in the case of message 31, it needs to undo that and 
instead increment by the correct size, as specified in the header. The 12 bytes 
are to skip what's known as the CTM (Channel Terminal Message?) header.

You might be better off referring to the canonical documentation (the interface 
control documents) for NEXRAD:

https://www.roc.noaa.gov/wsr88d/BuildInfo/Files.aspx

Specifically, you should look at the documents numbered 2620002 and 2620010. 
The first describes the binary layout of Level 2 messages, message headers, 
volume headers, etc.. The second describes the format for network transmission 
of the data, which is as a sequences of bz2 compressed chunks. Many servers, 
such as our own, store the data directly to disk in this compressed, 
transmitted format.

Also, if you need another implementation to look at, and know Python, we have 
an independent implementation of Level 2 decoding in MetPy here: 

https://github.com/Unidata/MetPy/blob/master/metpy/io/nexrad.py

Good luck!

Ryan

> Hi there,
> 
> I've seen your project on Github here:
> 
> https://github.com/Unidata/thredds/tree/master/cdm/src/main/java/ucar/nc2/iosp/nexrad2
> 
> I'm a web developer in the UK, who has been given some time to pick a
> project and develop a proof of concept on something to show my development
> team, and I decided upon attempting to read NexRad Level 2 Radar data,
> as I spend May each year chasing storms in the USA.
> 
> I've come across your project, and written out the code myself locally to
> try and understand the logic of reading a file by byte blocks (something
> I've never done). I've got a question about your code, which I can't
> work out myself from the data, and I wondered if you could help? In
> exchange if you can, I'd be happy to share my implementation with you
> (probably C# Web API), and also credit yourselves for your input.
> 
> My question is around your Level2VolumeScan.java file here:
> 
> https://github.com/Unidata/thredds/blob/master/cdm/src/main/java/ucar/nc2/iosp/nexrad2/Level2VolumeScan.java
> 
> specifically line 216. I'm trying to understand the logic behind updating
> the file array offset.  As I understand, the formula in the code is
> 
> messageOffset31 = messageOffset31 + (messageSize * 2 + 12 - 2432)
> 
> Do I understand correctly in the above, that you are adding onto the
> existing message offset, with the message size in halfwords, multiplied
> by 2 to calculate the number of bytes, then plus another 12 bytes for the
> header of this message? I'm also keen to understand what removing 2432 is
> for, and where this number come from? I read through the documentation
> but I can't see any reference to anything of 2432 bytes in length,
> or am I misunderstanding?
> 
> As I say if you can help me understand this, so I can and try to read
> the file for myself, I'd happily credit you and share my code.


Ticket Details
===================
Ticket ID: QGE-896632
Department: Support THREDDS
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.