Sorry to drag this out again, but I need to restate my question; it's
more or
less the opposite of the question that was answered.
Does the presence of a featureType attribute indicate that a file uses
the DSG
"machinery" and should therefore follow the guidelines of limited axes that
are spelled out in chapter 9?
Can I use this attribute and NOT have an instance (or station) dimension,
but stick with my current encoding:
float seatemp(time, depth, lat, lon)
rather than changing to:
float seatemp(station, time)
We need an attribute in oceansites files that indicates the type of
feature in the file -
multiple-depth moored instruments, single-depth moored instruments,
profiles ...
We'd like to use this attribute to fill that role, but if it is
overloaded in the sense that
it indicates something else about the file, we'll need to use another term.
Thanks -
Nan
On 8/29/13 9:55 AM, Jonathan Gregory wrote:
Dear Nan
It is allowed to use the new "machinery" of ch9 only if the featureType att
is included. Perhaps we should put this in Appendix A - is that your
suggestion? The new machinery is the incomplete multidimensional representation
and the two ragged representations (which collapse the data variable into 1D)
It is allowed to use the orthogonal rep (the data variable is samples*features)
because that existed anyway, before ch9 was introduced, and there were already
examples of it in the document.
Best wishes
Jonathan
----- Forwarded message from Nan Galbraith <[email protected]> -----
Date: Thu, 29 Aug 2013 09:46:14 -0400
From: Nan Galbraith <[email protected]>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0)
Gecko/20130801 Thunderbird/17.0.8
To: [email protected]
Subject: [CF-metadata] featureType attribute (was CF-1.6 DSG clarification:
time series & lat/lon coordinates)
Hi all -
Quick question on the featureType attribute.
Back in June, Jonathan Gregory said:
for a DSG (which is indicated by the presence of featureType)
I don't think this is stated clearly in the CF 1.6 manual, and as a
result, some
people have taken 'featureType' to be the equivalent of the 'cdm_data_type'
attribute.
I'm not using discrete sampling geometries yet, and am not
completely familiar
with the details of this part of CF 1.6, but I understand that the
rules for allowed
coordinate variables (dimensions) are quite different from those of non-DSG
files.
If the use of a single attribute changes the rules that much, I
think we need to
spell it out *very* clearly in the description of the featureType
attribute in the
CF document.
Regards - Nan
On 6/5/13 9:08 AM, Jonathan Gregory wrote:
Dear John
If we use the time series featureType as example
(from
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#idp8307552)
AFAIU, the orthogonal multidimensional representation would be:
float humidity(station,time)
not
float humidity(lat, lon, time)
You are quite right, sorry. I was taking a step too far! The point is not only
that the coordinates are size-1, but there is more than one of them. You are
right that (lat,lon,time) can't be a timeseries discrete sampling geometry
because it's got more than one spatial dimension. A timeseries DSG can have
only one station (instance) dimension, and it is required to have both x and y
coordinates. So these current rules mean that 2D field e.g. (lat,time) can't
be a timeseries DSG.
Like Mark, I saw the relevance of this to the discussion of scalar coordinates
but I reached a different conclusion about it! At the moment, we are talking
about the CF data model for version 1.5. DSGs were introduced in version 1.6.
As a result of this discussion, it seems me that for a DSG (which is indicated
by the presence of featureType), scalar coordinate variables have to be
interpreted as auxiliary coordinate variables of an omitted size-one instance
dimension. That is what is implied by section 9.2. It's different from the
interpretation that is implied by section 5.7, which should exclude DSGs (and
predates DSGs). I see no problem with having different interpretations for
different purposes.
Cheers
Jonathan
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
