Hi Steve,
I think there is a CF precedent would pacify you a little here, which is to
have Standard Names of the form 'volume_mixing_ratio' with canonical units of
dimensionless such as volume_mixing_ratio_of_oxygen_at_stp_in_sea_water. I
would suggest following this practice in this case
CF Folks,
What would be the best DSG featureType to represent a wire-crawling
sensor that has a fixed lon,lat location, but non-uniform depth
interval as it goes up and down, and takes enough time that the
profile might not be accurately represented with a single time value?
On this ERDDAP site
Regarding the last point, the CF Conventions document is
now being managed on github -
https://github.com/cf-convention/cf-conventions
On 2/27/17 5:17 PM, Chris Barker wrote:
On Mon, Feb 27, 2017 at 10:08 AM,
Hi Roy and Steve. Your modified names will work fine. I would prefer
units of "ppm" and "ppb" as they match our historical naming. I'm very new
to the CF Conventions, please bear with me. Here is the modified request
for new fields:
name: volume_mixing_ratio_of_water_vapor_in_air
description:
[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
Dear Rich, Bob
Rich asked
> What is the difference that makes example CF H.4 okay, but not Bob's example?
That's a good question. You're right, I think example H4 has the same
problem! I didn't read it carefully enough - sorry. The station_name:cf_role
attribute in H4 says it's a station ID, but
Dear Chris and Bob
> I wasn't clear -- even if you know a CHAR array is supposed to be an array
> of strings, you don't know which dimension is the "string" dimension, and
> which is the array dimension. If you have a 3x4 array of length-5 strings,
> what is your CHAR array dimension? either of
CF Folks,
Okay, with help from the ERDDAP community
https://groups.google.com/forum/#!topic/erddap/xfAufA8Qyhg
I think I figured this out:
The solution would be to use nominal "time(profiles)" and
"precise_time(obs)". So we would write something like
