Re: CF/Radial - netCDF CF files for radar and lidar data
- To: Mike Dixon <address@hidden>
- Subject: Re: CF/Radial - netCDF CF files for radar and lidar data
- From: John Caron <address@hidden>
- Date: Wed, 31 Mar 2010 16:33:10 -0600
On 3/30/2010 12:30 PM, Mike Dixon wrote:
Sorry - please ignore the previous email, I sent it by mistake.
Thanks for your help in reviewing the CF/Radial doc.
I need some clarification:
1. Variable names:
CF uses standard_name attribute to identify variables, rather thanIt is possible for us to be more specific than CF on this point? Can we
specifying the variable names.
require that the time variable is always called 'time', and range is
called 'range'? This seems a sensible approach to me, since this is a
new sub-convention to the main CF convention.
Yes, you could standardize variable names in the radar convention as a
sub-convention. Im pretty sure you will get some pushback, though. Not
sure how hard.
2. Computing position from the coordinates:
I assume for moving platform, one uses pitch / roll instead ??I'll add a section later in the doc which describes the geometry
this kind of info to unambiguously specify georeferencing is at the
heart of CF, and any good convention. i would spell that out very
clearly, perhaps in this section.
considerations, and how one computes position from the other variables.
3. Grid mapping
We have a variable for latitude, longitude, altitude.
For moving platforms these will be vectors, and for fixed platforms
these will be scalars.
Following the CF doc as as guide, I also included latitude, longitude
and altitude as attributes on the grid_mapping variable. However, this
seems confusing and redundant.
Do you think we can remove these attributes, and just use the variables?
you need to write a description for that grid mapping (as in Appendix
F). That description explains how the coordinates are calculated from
the parameters, etc. Depending on how clear that is, its possible you
dont need to reduntantly name the latitude, longitude and altitude. But
this ties into the previous question, as CF has not standardized
variable names before. Without that, one needs to name the coordinates
here in the grid mapping attributes.
4. Field name array.
The EOL guys would like me to add an array of strings which specifically
lists the field names. For example:
Is it OK to do this as part of CF/Radial? Does this somehow break the
I assume these are redundant with the actual variable names? what is the
One of the things you will have to clarify is what is required by your
convention, and what is optional. The optional stuff is like "if you
want to do X, then this is how you do it, and this is what it means".
5. CF or not CF?
In working through this stuff, I wonder if we really gain anything by
going with CF on this format? I'm OK with it, so long as we can craft a
format which is not arcane like some of the CF stuff.
What is your opinion on this?
like any standardization process, the advantage of CF is that you get
some help thinking through your decisions, plus its imprimatur if you
can make it through the gauntlet. Arguably the resulting set of CF
standards (including yours) have some uniformity so that once you get
the idea, they all become easier to understand, etc.
Another piece that I dont involve myself with is the standard name
effort. Many people are mostly interested in working on this controlled
vocabulary. In the long run, that can also be a big win.
In the end, going through the process means you dont have to defend
against claims that you have an "ad-hoc" format, and its easier to get
others to adopt it. But if its likely that you will resist the "CF way"
of doing things, then its probably not worth the struggle. The CF group
will definietly run you through the wringer.
I would advise to go ahead and submit it. The criticism/suggestions you
get will make your format better. If in the end you dont want to do
everything they want, you can withdraw the proposal and publish the
"NCAR Radial Data Conventions" which will be partially CF compliant.
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.