This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.
#74: Allow sharing of ancillary variables among multiple data variables ---------------------------------------+------------------------------------ Reporter: [email protected] | Owner: [email protected] Type: enhancement | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: "ancillary data" "standard name modifiers" ---------------------------------------+------------------------------------ Comment (by [email protected]): Dear All: The message is a recap and a suggestion for a path forward. The intent of this trac item is to provide a convention that allows a status_flag variable to be associated with more than one data variable. In the project I am working, the data variables have different standard_names, and, for the enhancement to be useful to us, it needs to support this case. In the declaration of the status flag variable, the current conventions allow only a single standard name, which is that associated with the data variable, followed by the standard_name modifier “status_flag” to be the standard_name value. The initial proposal to allow multiple data variables, each with a different standard_name, to be associated with a single standard_name included multiple, space-delimited standard_names to exist as values in the status flag variable’s standard_name attribute followed by "status_flag". A subsequent proposal involved promoting two of the current standard_name modifiers, status_flag and number_of_observations to standard_name status. This allows multiple data variables to share status_flag or number_of_observation variables per the following: float data_1(lat,lon); data_1:ancillary_variables="status_1"; float data_2 (lat,lon); data_2:ancillary_variables="status_1"; int status_1 status_1:standard_name="status_flag"; Note that the reason that only status_flag and number_of_observations could use this approach is that they are unitless versus the other two current standard_name modifiers, standard_error and detection_minimum that have the same units as the related data variable. The con of this approach was identified, and it revolves around the standard_names “status_flag” and “number_of_observations” not being interpretable without understanding the related data variables. There was then some discussion that ensued related to how the functionality provided the standard_name modifiers, standard_error and detection_minimum, could be subsumed with cell_methods. This discussion dovetailed with that which occurred on message thread “[CF-metadata] Question from NODC about interplay of standard name modifiers, cell_methods, etc.” While I think there is a strong argument to be made that standard_error and detection_minimum are essentially cell_methods, I would suggest we work this issue, separately, in the context of a different discussion topic / trac item. It would seem at this juncture that the reasonable candidate solutions to allowing multiple data variables to share a status_flag variable have been explored sufficiently well. It is pretty clear there is no perfect solution. It would also seem that there is some validity to the argument revolving around the overlap in functionality provided by cell_methods, and the standard_error and detection_minimum standard_name modifiers. As a result, I think the best option to allow multiple data variables to share a status_flag variable is to promote status_flag and number_of_observations to standard_name status as described above. These would no longer be standard_name modifiers. Going with approach sets the stage for subsequent discussion about cell methods and the remaining two standard_name modifiers. Is this a reasonable path forward ? If so, I will write up the changes to the standard in a subsequent post. very respectfully, randy -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/74#comment:48> CF Metadata <http://cf-pcmdi.llnl.gov/> CF Metadata This message came from the CF Trac system. To unsubscribe, without unsubscribing to the regular cf-metadata list, send a message to "[email protected]" with "unsubscribe cf-metadata" in the body of your message.
