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

Re: CF/Radial - netCDF CF files for radar and lidar data

On 3/30/2010 12:30 PM, Mike Dixon wrote:

John

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 than
specifying the variable names.

It is possible for us to be more specific than CF on this point? Can we
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 ??
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.

I'll add a section later in the doc which describes the geometry
considerations, and how one computes position from the other variables.


ok


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:

   dimension field;
   variable field_names(field);

Is it OK to do this as part of CF/Radial? Does this somehow break the
convention?
I assume these are redundant with the actual variable names? what is the purpose?
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.