Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple Feature Types in one CF file #231

Open
gaochen-larc opened this issue May 3, 2023 · 2 comments
Open

Multiple Feature Types in one CF file #231

gaochen-larc opened this issue May 3, 2023 · 2 comments
Labels
question Further information is requested or discussion invited

Comments

@gaochen-larc
Copy link

It is a common practice to report lidar measurements of vertical profiles and vertically integrated quantity in the same file. For example, the file will contain vertical profile of aerosol extinction and aerosol optical depth (AOD). For airborne sampling, the FeatureType for extinction profile is trajectoryProfile. The AOD is timeSeriesProfile. Sample files can be found at: https://www-air.larc.nasa.gov/cgi-bin/ArcView/cpex.2022#NEHRIR.AMIN/. This practice appears inconsistent with the recent version of the CF convention: "When using these new conventions, the features contained within a collection must always be of the same type; and all the collections in a CF file must be of the same feature type." However, this type of files is convenient for the researchers in the subject area, Could someone to clarify how multiple FeatureTypes in a CF file would cause problems? Or maybe this is not a correct interpretation of the CF conventions?

@gaochen-larc gaochen-larc added the question Further information is requested or discussion invited label May 3, 2023
@davidhassell
Copy link
Collaborator

Hello @gaochen-larc, thanks for raising this question, which has been discussed a few times over the years. Perhaps now is the time for us to act? You are quite right - at present a netCDF dataset can contain at most one featureType (although there may be more than one data variables defined on it).

My thoughts are that modifying the conventions to allow different data variables in the same dataset to have different feature types is possible. Allowing the featureType attribute to be an attribute of data variables would be the easy part. Unambiguously identifying the appropriate "count" and "index" variables might require a little more thought (the current mechanism could already be OK - but might it be possible (if unlikely) for two data variables to share a sample dimension but have different profile definitions?). A variable identified by cf_role could raise similar concerns, but insisting that it is listed as an auxiliary coordinate variable might solve that, perhaps.

Anyway, I'd be happy to discuss this further to see if we can solve this.

All the best,
David

@gaochen-larc
Copy link
Author

Thank you, David! Maybe we should look into a few cases and see if we are doing reasonable things or how should we improve, e.g., adding attributes or other things... Here is the link: https://www-air.larc.nasa.gov/cgi-bin/ArcView/cpex.2022. Could you please take a look at the .nc files under different names if you have time. Also, we have a more complicated case. We may have crossed the line... In this case, we used "lat", "lon" in different groups as they different dimensions, Here is the example (I can email you the small sample file if it is more convenient):

netcdf file:/D:/CPEX-CV/APR3/cpexcv-APR3_t08.nc {
dimensions:
time = 706;
z = 131;
crk = 25;
variables:
double time(time=706);
:units = "seconds since 2022-09-02 00:00:00";
:long_name = "UTC time of the retrieval instant";
:standard_name = "time";
:_ChunkSizes = 706U; // uint

double z(z=131);
  :units = "m";
  :long_name = "Altitude of each resolution bin below the aircraft, i.e. seen through the nadir ports. Constant vector between [-1,12] km";
  :_ChunkSizes = 131U; // uint

group: lores {
variables:
double lat(time=706);
:units = "degrees_north";
:long_name = "lattitude of 1D bin";
:standard_name = "latitude";
:_ChunkSizes = 706U; // uint

  double lon(time=706);
    :long_name = "longitude of 1D bin";
    :standard_name = "longitude";
    :units = "degrees_east";
    :_ChunkSizes = 706U; // uint

  double s095s(time=706);
    :units = "dB";
    :long_name = "Surface NRCS at W-Band (scanning mode)";
    :_FillValues = NaN; // double
    :_ChunkSizes = 706U; // uint

  double s0hh35(time=706, crk=25);
    :units = "dB";
    :long_name = "Surface NRCS at Ka-Band (scanning mode)";
    :_FillValues = NaN; // double
    :_ChunkSizes = 706U, 25U; // uint

}

group: hi2lo {
variables:
double lat(time=706, z=131);
:standard_name = "latitude";
:units = "degrees_north";
:long_name = "lattitude of 2D bin";
:_ChunkSizes = 706U, 131U; // uint

  double lon(time=706, z=131);
    :units = "degrees_east";
    :long_name = "longitude of 2D bin";
    :standard_name = "longitude";
    :_ChunkSizes = 706U, 131U; // uint

  double z95n(time=706, z=131);
    :units = "dBZ";
    :long_name = "Reflectivity factor at W-band (nadir-only)";
    :_FillValues = NaN; // double
    :_ChunkSizes = 706U, 131U; // uint

}

// global attributes:
:Conventions = "CF-1.8";
:history = "initial test";
:title = "APR3 data test";

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested or discussion invited
Projects
None yet
Development

No branches or pull requests

2 participants