Re: NetCDF dual-Polametric radar data format specification



John Krause wrote:
I don't have any specific plans, but I can comment on what I saw.

First we normally generate the image files on one machine and then have to transport them across the network to another machine to view. Rarely would more than a single elevation or single product be in one file. Larger files don't transport well in realtime across busy networks. We work to keep the files as small as possible both for transport and archive.

interesting tradeoff: managing zillions of small files is one of the limiting 
factors for the server. but you generate them to satisfy a request, and then 
discard?


Second, you don't take into account horizontal beamwidth. The new Phased Array Radar has a variable horizontal beamwidth and that needs to be accounted for. KOUN in general has terrible beamwidth stability especially early in its development. We have been using a technique like this.

2-D Array of Data:
Data (azimuth, range)

1-D Array's of
Azimuth()
GateSpacing()
BeamWidth()


This could change to a sector with the Phased Array Radar
2-D Array of Data:
Data_Sector ( radial number, range)

1-D Arrays of
Azimuth()
GateSpacing()
BeamWidth()
Elevation()
Time()

ok, thats a variation we havent seen before. Im cc'ing Yuan Ho, who is 
specializing in reading radar formats.


We have a variety of self-described global attributes that talk to our display system, WG. I think we are generally indifferent to the actual name's of the variables both of the main arrays and global attributes. If you would like to suggest a set of conventions that seem reasonable, I would push for their adoption.

We could probably try a first pass, and maybe with your's and other's help 
converge quickly. Are you talking about writing netcdf files directly, or using 
an IOSP to read binary files into the CDM?


The main problem that I see is that no one has specified what the minimum set of required data is to store radial data in, or what the minimum set of Global Radar Attributes is. With the new Phased Array Radar all of the standard sets of conventions are turned on their ear because you do not collect in clockwise spinning, elevation at a time mode. I can say that most of the data from the Phased Array Radar will be in Level II, Msg 31 format, which is in late stage development.

so the radials are in random order? are they time ordered?

Yuan, are you familiar with Msg 31 format?


  • 2006 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: