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