[CF-metadata] Precise location example

[Mike McCann]

Hi,

I'm working on understanding how to properly express nominal and precise 
locations for timeSeriesProfile data from an oceanographic mooring.  Here is 
the text from section 9.5 at 
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#coordinates-metadata:

CF Discrete Geometries provides a mechanism to encode both the nominal and the 
precise positions, while retaining the semantics of the idealized feature type. 
Only the set of coordinates which are regarded as the nominal (default or 
preferred) positions should be indicated by the attribute axis, which should be 
assigned string values to indicate the orientations of the axes (X, Y, Z, or 
T).  See example A9.2.3.2.  Auxiliary coordinate variables containing the 
nominal and the precise positions should be listed in the relevant coordinates 
attributes of data variables. In orthogonal representations the nominal 
positions could be  coordinate variables, which do not need to be listed in the 
coordinates attribute, rather than auxiliary coordinate variables.

I can't find example "A9.2.3.2", but did find example H.5 which looks to be the 
correct one.  Is this just a simple typo in the above text?

-Mike

--
Mike McCann
Software Engineer
Monterey Bay Aquarium Research Institute
7700 Sandholdt Road
Moss Landing, CA 95039-9644
Voice: 831.775.1769  Fax: 831.775.1736 http://www.mbari.org

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Precise location example

[Mike McCann]

Hi,

I'm working on understanding how to properly express nominal and precise 
locations for timeSeriesProfile data from an oceanographic mooring.  Here is 
the text from section 9.5 at 
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#coordinates-metadata:

CF Discrete Geometries provides a mechanism to encode both the nominal and the 
precise positions, while retaining the semantics of the idealized feature type. 
Only the set of coordinates which are regarded as the nominal (default or 
preferred) positions should be indicated by the attribute axis, which should be 
assigned string values to indicate the orientations of the axes (X, Y, Z, or 
T).  See example A9.2.3.2.  Auxiliary coordinate variables containing the 
nominal and the precise positions should be listed in the relevant coordinates 
attributes of data variables. In orthogonal representations the nominal 
positions could be  coordinate variables, which do not need to be listed in the 
coordinates attribute, rather than auxiliary coordinate variables.

I can't find example "A9.2.3.2", but did find example H.5 which looks to be the 
correct one.  Is this just a simple typo in the above text?

-Mike

--
Mike McCann
Software Engineer
Monterey Bay Aquarium Research Institute
7700 Sandholdt Road
Moss Landing, CA 95039-9644
Voice: 831.775.1769  Fax: 831.775.1736 http://www.mbari.org

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CF-1.6 DSG Trajectory files: clarification and advice

[John Caron]

Hi Derrick:

Some first reactions:

1. "the aggregation or collection will have two trajectories, the first 
is along a time axis "time" and the second is along a time axis "time_avg".


since they are both trajectories, then i think you dont have a problem 
with more than one feature type.


however, theres no convention which says how the two trajectories are 
related. they might be though of as being along the same trajectory, 
with different sampling points. this would be useful for CF coordinate 
systems to capture in a general way.


2. The THREDDS server is implementing with "feature collections". You 
have an interesting case here of creating essentially 2 feature 
collections, each collection in multiple files, but the 2 collections 
share the same files.


Maybe I can get some sample files and see how hard it would be to extend 
the TDS.


3. "is it legal to have a variable with a valid geometry AND a variable 
that is the result of a cell_method applied to that variable in the same 
file?"


i think its legal, but the question is, does any standard software able 
to understand it? Generally, from my POV, a main use of conventions is 
to allow software to understand these relationships.


John

On 5/21/2013 11:11 AM, Derrick Snowden - NOAA Federal wrote:

All,

We are attempting to create a valid CF 1.6 discrete sampling geometry
trajectory file to exchange data from underwater profiling gliders.
There is a schematic of the major sampling features for gliders at the
following web site
(https://github.com/IOOSProfilingGliders/Real-Time-File-Format/wiki/Glider-Types-and-Sampling#sampling-patterns).
There are a few variations of the files we are working on in the
following github repo
(https://github.com/IOOSProfilingGliders/Real-Time-File-Format/tree/master/examples/proposed_templates/trajectory_uv),
and"glider_trajectory_uv_template_v.0.0.cdl
"
is file in question.

We are grappling with the constraint in CF that each file must contain
one and only one feature type.  (Section 9.1 para 1:"/the features
contained within a collection must always be of the same type; and all
the collections in a CF file must be of the same feature type/." )  As
it is written, this constraint doesn't say anything about the shape or
dimensionality of the features, only that they are the same type.  Below
I'll try to describe our use case which differs from the examples in
chapter 9 in two ways.
1. The files only contain data from a single glider so the trajectory
variable is always a scalar (i.e. the variable called trajectory with
trajectory:cf_role=trajectory_id is usually just set to one in these tests).
2. The file only contains part of a complete deployment and we need to
aggregate them together into a complete deployment (one deployment may
contain hundreds or thousands of segments) but, each of these segments
still has trajectory=1.

As stated, our files will contain one "segment" as defined on the web
site above.  A segment is defined as the data collected between two
surface gps fixes of the glider.  When the glider submerges it is
collecting data (temp/sal etc) as a function of time.  But, underwater
there are no gps fixes so the lat/lon is estimated with a dead reckoning
algorithm.  So far we think we've encoded that correctly.  Our problem
is with data that is estimated as an average between gps fixes.

For example, when the glider surfaces at the end of a segment there are
two position fixes available (1: the gps position which is considered
true, and 2: the dead reckoning position which is estimated) The
difference between these two positions can be used to estimate the
depth/time averaged currents that pushed the glider off course during
it's trajectory underwater.  We'd like to encode these "depth averaged"
currents in the same file as the measured T/S etc but this data has a
different time axis and therefore a different lat/lon coordinate.  In
practice the depth averaged currents are assigned to the midpoint (time
and space) of the subsurface trajectory.  Our goal is for aggregations
of the segment files to represent an entire glider deployment and if
we're successful the aggregation or collection will have two
trajectories, the first is along a time axis "time" and the second is
along a time axis "time_avg".  They are both trajectories but they have
different time axes.  I'm not sure if THREDDS will allow this type of
aggregation so some changes may be necessary.

Does this violate the intent of the convention?  If so, can anyone
suggest a better encoding?  We're trying to keep these two data sets in
the same file but creating two files is possible if not desirable.

A similar related question could be, is it legal to have a variable with
a valid geometry AND a variable that is the result of a cell_method
applied to that variable in the same f

[CF-metadata] GOES-R generated binary mask products under proposal

[Jonathan Gregory]

Dear Charles

Thanks for your proposals. As for the procedure, it is that Alison Pamment
(the manager of standard names) will review the discussion, and if she does
not identify any new questions, she will schedule the new standard names for
inclusion in the standard name table.

Best wishes

Jonathan

- Forwarded message from Charles Paxson  -

> Date: Thu, 23 May 2013 14:33:41 -0400
> From: Charles Paxson 
> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15)
>   Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] GOES-R generated binary mask products under
>   proposal
> 
> Dear Jonathan and Jim,
> 
> I have seen your last and recent words on the mask proposals, and I
> have incorporated your comments.  I believe we are all in agreement,
> and thank you for your work.  I have written out the proposed
> variables and definitions below according to our latest agreement.
> Please let me know the procedure to formally finish the proposal
> process for these four new mask standard names.
> 
> Sincerely,
> 
> Charles Paxson
> 
> aerosol_binary_mask: X_binary_mask has 1 where condition X is met, 0
> elsewhere. 1 = aerosols present, 0 = aerosolsabsent.  Note that if
> no threshold is supplied, the binary mask is 1 if there is any
> non-zero amount of aerosol.
> 
> smoke_binary_mask: X_binary_mask has 1 where condition X is met, 0
> elsewhere.  1 = smoke present, 0 = smoke absent. Note that if no
> threshold is supplied, the binary mask is 1 if there is any non-zero
> amount of smoke.
> 
> dust_binary_mask: X_binary_mask has 1 where condition X is met, 0
> elsewhere. 1 = dust present, 0 = dust absent. Note that if no
> threshold is supplied, the binary mask is 1 if there is any non-zero
> amount of dust.
> 
> cloud_binary_mask: X_binary_mask has 1 where condition X is met, 0
> elsewhere.1 = cloud present, 0 = cloud absent (clear). Note that
> if no threshold is supplied, the binary mask is 1 if there is any
> non-zero amount of cloud
> 
> 
> On 05/21/2013 05:25 PM, Jonathan Gregory wrote:
> >Dear Charles
> >
> >Thank you for your email, and the subsequent one to Jim. In my earlier 
> >posting
> >I was not particularly arguing against the proposal, but I thought the
> >question should be asked. Evidently it is your intention that quantities with
> >these names should indeed be regarded as comparable. That is OK. If at some
> >point there arises a need for more specifically defined binary masks, other
> >standard names could be proposed for them.
> >
> >You propose to include a nominal threshold of zero, indicating that any 
> >amount
> >of cloud etc. constitutes "presence". I think we could avoid that need, and
> >the related need to introduce standard names for the quantities in which the
> >threshold was set, by stating in the definition that if no threshold is
> >supplied, the binary mask is 1 if there is any non-zero amount of cloud etc.
> >
> >Best wishes
> >
> >Jonathan
> >___
> >CF-metadata mailing list
> >CF-metadata@cgd.ucar.edu
> >http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> 
> 
> -- 
> Charles Paxson
> System Engineer
> Atmospheric and Environmental Research (AER), Inc.
> a Verisk Analytics Company
> 131 Hartwell Avenue, Lexington, MA 02421-3126
> office: 781-761-2209
> fax:781-761-2299
> www.aer.com
> 

> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


- End forwarded message -
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata