Please see my comment below...
On 2014-04-25 7:13 AM, Nan Galbraith wrote:
This message came from the CF Trac system. Do not reply. Instead, enter your
comments in the CF Trac system at http://kitt.llnl.gov/trac/.
#113: Review of CF feature types
in a variable-length
array.
On Fri, Feb 3, 2017 at 9:07 AM, <cf-metadata-requ...@cgd.ucar.edu> wrote:
> Date: Fri, 3 Feb 2017 11:07:00 -0600
> From: David Blodgett <dblodg...@usgs.gov>
> To: Bob Simons - NOAA Federal <bob.sim...@noaa.gov>
> Cc: CF Metadata <
quot;) because other encodings
(e.g., "UTF-8") need multiple bytes for some characters..
---
I have a slight preference (2), because it is cleaner and might be better
in the future (I don't know the implications for nc4 and CF2).
Thoughts? Votes?
On Mon, Feb 6, 2017 at 3:08 PM, Bo
1) There is a vague comment in the proposal about possibly changing the
point featureType. Please don't, unless the changes don't affect current
uses of Point. There are already 1000's of files that use it. If this new
system offers an alternative, then fine, it's an alternative. One of the
most
No. CF section 9.5 says: "The variable carrying the cf_role attribute may
have any data type."
And that makes sense, because some profile_id might be an integer and
theoretically could be a single char.
Date: Wed, 22 Feb 2017 18:15:46 +
> From: Jonathan Gregory
>
Jonathan and David, I disagree. The sample file I showed is a valid CF DSG
file.
CF Section 9.2 says "If there is only a single feature to be stored in a
data variable, there is no need for an instance dimension and it is
permitted to omit it. [followed by more details and examples]" I was
On Wed, Feb 22, 2017 at 10:56 AM, Chris Barker <chris.bar...@noaa.gov>
wrote:
>
> Another note:
>
> On Mon, Feb 6, 2017 at 3:08 PM, Bob Simons - NOAA Federal <
> bob.sim...@noaa.gov> wrote:
>
>> * "HTML" - the chars are to be interpreted as an array
As for needing a different subject for the email: I'm lumping together 2
new related attribute names: "charset=..." and "data_type=string|char" so
that the information stored in char variables in netcdf-3 files can be
easily and unambiguously interpreted.
You are correct. My proposal is for
Background:
As you all know, the vast majority of standard_names are for numeric
variables and have an associated "Canonical Units".
However, there are some existing standard_names for string variables
(e.g., area_type, institution, land_cover, land_cover_lccs,
platform_id, platform_name, region,
aining the names of the months
> would be dimensioned (12,9) in order to accommodate "September", the month
> with the longest name.
My proposed change does not alter that text.
On Mon, Feb 27, 2017 at 4:58 PM, Chris Barker <chris.bar...@noaa.gov> wrote:
> On Wed, Feb 22, 2017 at 11:
[This has degenerated into a debate about whether a given file is a valid
CF DSG file, but I'll continue.]
Perhaps I am misunderstanding this, but it is very hard for me to interpret
H4 as "defective", as if it were a minor error within an otherwise valid CF
DSG file.
The description right above
Seth McGinnis said:
"I hesitate to support encouraging the use of the T because in my
experience, approximately 0% of existing NetCDF files have it."
a) We aren't advocating forbidding the older formats / saying that files
with those time formats will become invalid. This is a question of what we
Aren't the missing values only a problem for CF when they are in the
axis/dimension variables?
Isn't this observation data? If so, can't you store the data in one of the
DSG formats (not multidimensional array), where the dates are just another
variable with data?
--
Sincerely,
Bob Simons
IT
t; it may not be), then software should be able to unambiguously interpret
> things. [This requirement was suggestion 2 (of 3), made my Jonathan in one
> of his earlier comments.]
>
> best regards,
> Karl
>
>
>
> On 3/7/17 11:08 AM, Bob Simons - NOAA Federal wrote:
>
>
14 matches
Mail list logo