Open gaochen-larc opened 1 year ago
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
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";
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?