Hi Chris,
There are two philosophies.
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.
More years of experience than I like to admit is bringing me kicking and screaming from camp (1) to camp (2). Although the transform from 'sea_binary_mask' to 'land_binary_mask' may be straightforward, the logistics of the conversion is not.
I therefore share Jonathan's view that accepting Rick's suggestion is the best course of action.
Cheers, Roy.
________________________________________
From: cf-metadata-bounces at cgd.ucar.edu [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Christopher Barker [Chris.Barker at noaa.gov]
Sent: 03 January 2011 17:57
To: Rich Signell; cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Request for standard_name="sea_binary_mask"
On 1/2/11 6:11 PM, Rich Signell wrote:
> But they are not the same thing. They are the inverse.
yes, of course, but they carry exactly the same information, do they
not? Why have two ways to express the same information?
> Yes, it would
> be possible to have data sets providers create NcML for every ROMS
> dataset that has ever been written and serve the data with a
> land_binary_mask instead of a sea_binary_mask.
well, I suppose it may be a question of whether there are more data
providers or data consumers...
That also implies that there are a bunch of ROMS-output netcdf files
that already have a sea_binary_mask variable, and are therefor not
currently CF-compliant. Is that the case? Do we want to add things to
the standard to make common, but not compliant, use cases compliant?
Perhaps so.
> But probably easier
> to have developers add 10 lines to your code to handle this, IMHO.
well, on the writing the file end, it's not even one line, it's a couple
of characters (or however you spell "not" in your language of choice):
land_binary_mask_variable = ~ sea_binary_mask # in Python/numpy
But if there are two names for the same information, reading code needs
to look for both of those names, which is more code, more logic and more
room for errors/missing features. And multiply that by every logical
variable one might want to express both ways.
Anyway, I'm new to the CF standards discussion -- if there is precedent
for this kind of thing, go for it.
-Chris
> -Rich
>
> On Sun, Jan 2, 2011 at 12:31 PM, Chris Barker<Chris.Barker at noaa.gov> wrote:
>> On 12/30/2010 2:40 PM, Rich Signell wrote:
>>>
>>> CF Standard Name Team:
>>>
>>> I would like to request a new standard_name="sea_binary_mask" defined as
>>>
>>> sea_binary_mask X_binary_mask has 1 where condition X is met, 0
>>> elsewhere. 1 = sea, 0 = land.
>>>
>>> This is used by the popular ROMS ocean model, and perhaps others.
>>>
>>> The new "sea_binary_mask" would join the existing "land_binary_mask",
>>> which has 1 = land, 0 = sea.
>>>
>>
>> which makes it completely redundant. How hard it is to translate a
>> sea_binary_mask into a land_binary mask?
>>
>> as an end user, now all my code has to look for both, despite them being the
>> same thing.
>>
>> Isn't it an ideal to have only one standard way to express a given quantity?
>>
>> -Chris
>>
>>
>
>
>
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata--
This message (and any attachments) is for the recipient only NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
Received on Mon Jan 03 2011 - 13:25:37 GMT
