No way to enumerate field datasets within a sweep group

[marack]

The variables containing moment data ('field variables') are stored directly within the group of the containing sweep. Other variables containing metadata related to the sweep, rays or bins are also stored directly within the sweep group. For example, sweep_number, azimuth, range and pulse_width.

As a result of this, there is no easy way to discover or loop through all moments within a sweep.

All other levels of the data model support discovery / enumeration of child objects:

• Sweeps can be discovered via the sweep_group_names global variable
• Spectrum datasets can be discovered via the spectrum_group_names variable within each sweep

To support discovery of moments within a sweep a new variable we could reuse the mechanism established above:

• A new dimension called field added to the sweep group. Dimension should be required, and should also be an unlimited dimension to allow later insertion of new fields.
• A new variable called field_names added to the sweep group based on the field dimension. This variables will be a string type and will contain the names of each moment/field variable in the sweep.

[marack]

Taking another look I noticed that field_names is defined as a global attribute. I'd like to propose removing this attribute from the specification for the following reasons:

1. Having field_names be an attribute, while sweep_group_names and spectrum_group_names are variables is inconsistent.
2. Having field_names (even as a variable) at the top level of the file introduces an awkward dependency. Thinking of API implementations - we can no longer pass a sweep object to a function and have it populated with different moments/fields. We would instead have to pass the volume along with a sweep name/number to modify.

To illustrate complaint 2 above. Here's some pseudo-code:

void generate_rain_rate(cfradial::sweep sweep)
{
  std::vector<float> data;

  // access and read the reflectivity field
  sweep.field("DBZH").read(data);

  // calculate rain rates based on reflectivity into rvals
  for (int i = 0; i < data.size(); ++i)
    data[i] = pow(dbz_to_z(data[i]) * (1.0 / 1.6), (1.0 / 200.0))); // e.g. ...

  // write the rain rates into a new field
  sweep.add_field("RR", data_type::i16).write(data);
}

cfradial2::volume volume("my_volume_file.nc");
for (int i = 0; i < volume.sweep_count(); i++)
  generate_rain_rate(volume.sweep(i));

The above code shows how it might be natural to pass a sweep into a function and generate some new fields to be written back into the sweep. The presence of field_names at the volume level makes implementing an interface like the above difficult since the sweep must keep track of and modify it's own parent volume somehow.

[mike-dixon]

If this is seen as a problem, I agree we can remove the field_names[] attribute from the standard.

[mike-dixon]

Discovery for the fields is actually relatively simple, since only the fields have (time, range) dimensions. This is one of the normal CF mechanisms for finding things - using dimensions and attributes.
I agree that having field_names[] at the sweep_group level will be helpful, but it's not really necessary. But what if this does not match the field data? How is this discrepancy resolved?
Not all sweeps will have the same array of names. The global field_names[] array could be a superset of the sweep field names. Or left out.