Dear Jim
I agree that for some purposes you want a field of integers that identifies the
area types, rather than a binary mask. I think this can be achieved by using
the existing standard_name of area_type. This standard_name indicates a string-
valued data variable, but it can be encoded as self-describing integers with
flag_values and flag_meanings, as you say.
Best wishes
Jonathan
----- Forwarded message from Jim Biard <jbiard at cicsnc.org> -----
> Date: Tue, 11 Jul 2017 09:33:54 -0400
> From: Jim Biard <jbiard at cicsnc.org>
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] Standard name for land/sea mask
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
> Gecko/20100101 Thunderbird/52.2.1
>
> Hi.
>
> Given the prior existence of land_binary_mask, Elodie's request for
> sea_binary_mask makes sense. Even given my request below, if Elodie
> needs this standard name, I endorse it's addition. I don't want to
> bog her down.
>
> I'd like to suggest that we do something slightly more flexible and
> create the standard name discrete_mask, which could handle both
> these cases. It could also handle numerous other use cases that
> generally go without a standard name right now. The definition could
> be something like below.
>
> discrete_mask: A variable with the standard name discrete_mask is
> used to indicate a finite set of discrete, related conditions that
> hold across the dimensional range of the variable. These conditions
> are marked by integer values, each of which indicates a specific
> condition. The particular conditions being indicated are defined
> using flag_values and flag_meanings attributes associated with the
> variable. A single element of the variable can indicate only one
> condition - bit field combinations are not allowed.
>
>
> I'm thinking this way because in the particular domain Elodie is
> referring to, some files have trinary masks, sea = 0, coast = 1,
> land = 2, different ones define the numbers used to indicate the
> different conditions, some cover more cases (fresh water, for
> example), etc.
>
> I do, on one level, appreciate that it can be nice to see the
> standard name on a variable and not need to look further to
> understand how the contents are implemented, but I don't think it
> buys us near as much as we like to think.
>
> Grace and peace,
>
> Jim
>
> On 7/11/17 3:55 AM, Elodie Fernandez wrote:
> >Dear all,
> >
> >I would like to suggest the addition of a new standard_name to
> >describe land-sea masks. A standard_name already exists:
> >land_binary_mask (
> >X_binary_mask has 1 where condition X is met, 0 elsewhere. 1 =
> >land, 0 = sea.). But in the ocean modelling community, we have
> >already existing files describing those masks, but from an "ocean
> >point of view", so 1 is for sea and 0 is for land points.
> >So I would like to request the addition of the standard_name
> >"*sea_binary**_mask*",
> >with definition "X_binary_mask has 1 where condition X is met, 0
> >elsewhere. 1 = sea, 0 = land" and unit "1".
> >
> >Best regards,
> >Elodie
> >
> >
> >_______________________________________________
> >CF-metadata mailing list
> >CF-metadata at cgd.ucar.edu
> >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> --
> CICS-NC <http://www.cicsnc.org/> Visit us on
> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
> *Research Scholar*
> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
> North Carolina State University <http://ncsu.edu/>
> NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
> /formerly NOAA?s National Climatic Data Center/
> 151 Patton Ave, Asheville, NC 28801
> e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
> o: +1 828 271 4900
>
> /Connect with us on Facebook for climate
> <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
> <https://www.facebook.com/NOAANCEIoceangeo> information, and follow
> us on Twitter at _at_NOAANCEIclimate
> <https://twitter.com/NOAANCEIclimate> and _at_NOAANCEIocngeo
> <https://twitter.com/NOAANCEIocngeo>. /
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
Received on Tue Jul 11 2017 - 09:26:32 BST