Question on using groups to organize content in a CF file

[TomLav]

Question

Hello.

My question is related to an on-going discussion / proposal, initiated by @pvanlaake.

I am in the situation where I need to define a file template for future satellite-based products containing many (gridded) variables. The variables are all on the same projection (grid_mapping) but with varying grid postings (3km, 9km, 18km etc...). I have been exploring groups to organize information.

Below is a minimal example of where I am at today:

netcdf file {
dimensions:
	x_3km = 3600 ;
	y_3km = 3600 ;
	x_18km = 600 ;
	y_18km = 600 ;
	time = UNLIMITED ; // (1 currently)
	two = 2 ;
variables:
	double time(time) ;
		time:units = "seconds since 2028-01-01T00:00:00Z" ;
		time:calendar = "standard" ;
		time:standard_name = "time" ;
		time:bounds = "time_bounds" ;
	double time_bounds(time, two) ;

// global attributes:
                // global attributes //

group: Data {

  group: Geolocation {
    variables:
    	double x_3km(x_3km) ;
    		x_3km:standard_name = "projection_x_coordinate" ;
    		x_3km:units = "m" ;
    		x_3km:bounds = "x_3km_bounds" ;
    	double x_3km_bounds(x_3km, two) ;
    	double y_3km(y_3km) ;
    		y_3km:standard_name = "projection_y_coordinate" ;
    		y_3km:units = "m" ;
    	double y_3km_bounds(y_3km, two) ;
    	double x_18km(x_18km) ;
    		x_18km:standard_name = "projection_x_coordinate" ;
    		x_18km:units = "m" ;
    		x_18km:bounds = "x_18km_bounds" ;
    	double x_18km_bounds(x_18km, two) ;
    	double y_18km(y_18km) ;
    		y_18km:standard_name = "projection_y_coordinate" ;
    		y_18km:units = "m" ;
    	double y_18km_bounds(y_18km, two) ;
    	int crs ;
    		crs:crs_wkt = // WKT // ;
    		crs:semi_major_axis = 6378137. ;
    		crs:semi_minor_axis = 6356752.31424518 ;
    		crs:inverse_flattening = 298.257223563 ;
    		crs:reference_ellipsoid_name = "WGS 84" ;
    		crs:longitude_of_prime_meridian = 0. ;
    		crs:prime_meridian_name = "Greenwich" ;
    		crs:geographic_crs_name = "unknown" ;
    		crs:horizontal_datum_name = "World Geodetic System 1984" ;
    		crs:projected_crs_name = "unknown" ;
    		crs:grid_mapping_name = "lambert_azimuthal_equal_area" ;
    		crs:latitude_of_projection_origin = 90. ;
    		crs:longitude_of_projection_origin = 0. ;
    		crs:false_easting = 0. ;
    		crs:false_northing = 0. ;
    } // group Geolocation

  group: SeaIceConcentration {
    variables:
    	float sea_ice_concentration(time, y_3km, x_3km) ;
    		sea_ice_concentration:grid_mapping = "/Data/Geolocation/crs"

    // group attributes:
    		// group attributes //
    } // group SeaIceConcentration

  group: SeaIceDrift {
    variables:
    	float sea_ice_drift_dx(time, y_18km, x_18km) ;
    		sea_ice_drift_dx:grid_mapping = "/Data/Geolocation/crs" ;

    // group attributes:
    		// group attributes //
    } // group SeaIceDrift

  } // group Data
}

As you can see, my axis coordinate (x_3km, etc...) variables and my crs variables are in a sibling group to the variables using them (/Data/SeaIceConcentration/sea_ice_concentration).

I have several questions:

• For the coordinate variables, is my construct valid at all? Can I expect an application to find its way to x_3km from the sea_ice_concentration variable with such a file? If not, is there a solution where x_3km etc... stays in the Data/Geolocation group?
• For the crs variable, is sea_ice_concentration:grid_mapping = "/Data/Geolocation/crs" enough for the application to find it.
• In general, how would you suggest I re-organize this file @pvanlaake, in light of your proposal.

[pvanlaake]

For the coordinate variables the construct is valid but discouraged. Whether or not an application can find it is more difficult to say. What the application needs to find the coordinate variable is to support "lateral search" (see the sub-section on "Search by proximity" in section 2.7.1 of the conventions). Not all applications may support that feature, particularly not because its use is discouraged and should not be used for new data sets. Instead, use absolute or relative paths. Showing both options in one line (pick one):

    float sea_ice_drift_dx(time, /Data/Geolocation/y_18km, ../Geolocation/x_18km) ;

For time there is no problem because it is defined in a parent group of where the data variables are located. That brings me to the third point: I would always place coordinate variables in a parent of the data variables that reference them as that is the cleanest and the easiest to understand. In your case you could consider making a group below the root group for each grid holding the coordinate variables at that resolution. In or below that group you can then have your data variables. The crs GMV could then go in the root group which would leave the GeoLocation group empty.

On point two: Any application that supports group traversal by absolute path would be able to find it.

A final note, the proposal you refer to is in limbo as there is some support for the principles behind it but not enough so to move it forward.

[TomLav]

Thank you for the quick reply @pvanlaake,

I think I will restructure my files in the future to make sure everything my data variables need is defined in one of their parent groups.

Your proposed solution is neat, but nudges the user to first consider what resolution it needs before accessing the variables.

Another solution would be to remove my Geolocation group and rather dump all those x_ and y_ coordinate variables (and crs) in the root group alongside time. Then I can have my groups and variables below that, and everything should be fine.