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

Re: European radar data standard



Hi Ernst:

Funny you should mention OPERA and BUFR. Someone just asked me to read some 
OPERA/BUFR files
(apparently radar?) but i couldnt because they are putting a missing value into 
the center id, and
using non-standard descriptors that require you (me) to use special tables 
based on the ... you
guessed it, the center id. Anyway, Ive written someone there (havent heard 
back) but if you have any
friends who can help fix that problem, i would appreciate it.

Anyway, thats a side topic, some comments are embedded:

Vreede de, Ernst (KNMI) wrote:
> Hi John,
>  
> A European project (OPERA) is busy harmonizing all European radar products 
> into one (or two, some parties insist on BUFR!) format. A few colleagues of 
> mine are participating in te Opera project.
> One of them asked me to take a look at the draft version for the data format.
>  
> To my surprise a it is simple and readable document, describing the 
> envisioned dataformat. Because HDF5 is already used for radar at KNMI and in 
> the Baltic states it is an HDF5 format. That's good. A simple hierarchy has 
> been devised, which appears to be very complete.

its nice when you see competent work.

>  
> After hearing about NetCDF4 and especially netcdf-java 4.0 at the workshop in 
> november, I reckoned it might be worth to try to add a minimal set of tags to 
> the HDF5 file to make the files easier to recognize for the netcdf-java 
> library. As far as I know there is currently no NetCDF convention for radar.
> I have some experience with the radar data structures in CDM; what I've seen 
> seems to be mappable between the Opera format and CDM without too much work.

The big problem with HDF5 is they dont have shared dimensions like netcdf. For 
simple cases one can
use dimension scales, so i hope thats possible here. Otherwise we have to 
develop a little bit of
metadata to clarify this to the CDM.

>  
> I am wondering if you could help me out a little here.
> I think that at least a global Conventions attribute is needed. The value of 
> that attribute should be some unique name. Does Unidata keep track of those 
> names? This tag would then make it possible for the software to select the 
> right conversion module in the software (I've been trying this already with 
> our KNMI HDF5 format for radar volume scans, but haven't finished that yet).

yes, very important for generic software!

add an attribute in the root group named "Conventions", with a String value 
something unique like
"OPERA Radar v1.0". Then write up something about it, put it on the web, send 
us a URL to it and we
put it on this page:

  http://www.unidata.ucar.edu/software/netcdf/conventions.html

Alternatively, one could use the existing CF conventions, at least for the 
coordinate system
specification. Its quite easy, I can show you how if interested.

>  
> Are there any other tags that are really needed?

have a look at this document:

  http://www.unidata.ucar.edu/software/netcdf/docs/BestPractices.html

the main things from my POV are clear specification of the coordinates, and 
units on the variables,
preferable udunits compatible.


>  
> I am not in a position to change the whole format, because a lot of work has 
> already been done, but a few adaptations to make the format more easy to use 
> in netcdf-java 4.0 (and then IDV and all those other nice applications) 
> should be possible. 

With some small changes, we can probably get this to work. can you send me a 
sample file?

> [ Of course any netcdf-java implementations for the new format will be sent 
> to Unidata!!]

that sounds great.

>  
> Thanks in advance, Ernst de Vreede
>  
>