Dear all,
It might be useful to distinguish between two types of masks:
1) a mask that indicates where valid data exists
2) masks that are useful in sub-selecting data (e.g., certain regions,
certain area_type(s), certain time samples, etc.).
For case 1, it would seem to be redundant to define the mask, since
invalid data should be indicated by the missing_value. I therefore
would not be in favor of defining a mask for this purpose.
For case 2, different researchers will presumably want to access
different subsets of the data, so there would often be multiple maps
(for different surface types, for example) that could be associated with
the data. If that is the case, how can software know what to do with
any masks it might infer should be associated with the data?
So the case 2 mask(s) might fall into a category of information that
might be quite useful in processing the data (somewhat like the areas or
volumes pointed to by the cell_measures attribute), but different users
would want to access different masks. The masks are not some attribute
of the primary data itself. Note that we don't provide information
about the northward wind component in our description of the eastward
wind component, even though it might be essential for an analyst to know
this if he wanted to compute say a wind speed or the vorticity. Why is
some mask a "more intimate" field, which requires us to say it is an
attribute of (or associated with) the primary field of interest?
Best regards,
Karl
On 1/4/11 3:40 AM, Jonathan Gregory wrote:
> Dear all
>
> In standard names I think CF has generally followed Roy's no (2):
>
>> 1) Create an idealised model with everything normalised and harmonised to the nth degree, declare it as a standard and force everybody to conform.
>> 2) Accept community practice but make sure that everything is unambiguously described. Interoperability then comes through the development of semantic resources describing the relationships between the descriptions.
> That is, we try to describe what people actually use, rather than force them
> to use a particular thing. Doing the latter may not work and in the end means
> the standard is not adopted. That is why we have standard names for quantities
> which could be interconverted. On the other hand, in CF in general we also try
> to discourage unnecessary proliferation of choices, by not introducing new
> mechanisms if we already have ones that would serve a new purpose.
>
> I agree that a general mask would be a good way forward, but land/sea is such
> a common case, which we already support, that I think we should continue to
> support it. But we could also introduce a standard name for a general type
> mask, as Steve suggests. A data variable containing a mask with this standard
> name should have a string-valued scalar coordinate variable with standard name
> of area_type to specify it further. This is consistent with the idea behind
> introducing the area_type, which allows us to describe quantities that depend
> on area type without providing specific standard names for them.
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110104/8880dc0f/attachment.html>
Received on Tue Jan 04 2011 - 11:34:27 GMT
