Re: [CF-metadata] fixed sensors, depth, datum

[Ethan Davis]

Hi Jonathan,

I would argue against them being different quantities because there 
exist transformations between these various heights. Is that not enough 
to indicate they are the same quantity?


Ethan

Jonathan Gregory wrote:

Dear Jon

  

- height relative to the ellipsoid
- height relative to the geoid
  

From a coordinate referencing point of view they both
give height (in units of length) above a reference surface, but the
surfaces happen to be different.  Do you consider them geophysically
distinct because height relative to geoid is a close approximation
to potential energy, whereas height relative to ellipsoid is not?
Similarly, the geoid approximates sea level whereas the ellipsoid does not?



Yes, I would say that distinctions like that make them different quantities.
Plain height (above the surface) is likewise a different geophysical
quantity. However, I think that specification of geoid or ellipsoid is not part
of the identity of the geophysical quantity. It is more in the nature of an
extra parameter for working out the numbers, like the reference pressure used
for potential temperature. Of course, I realise this is somewhat arbitrary.

Best wishes

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


--
Ethan R. DavisTelephone: (303) 497-8155
Software Engineer Fax:   (303) 497-8690
UCAR Unidata Program Center   E-mail:[EMAIL PROTECTED]
P.O. Box 3000
Boulder, CO  80307-3000   http://www.unidata.ucar.edu/
---

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

Re: [CF-metadata] Cell bounds associated with coordinate variable rather than data variable

[Ethan Davis]

Hi Benno,

Benno Blumenthal wrote:
 Also, it is not particularly natural to use the end point as the label
 for the data, certainly not so natural that a program would assume that
 not knowing anything else about the data.   It makes sense from a data
 collection point of view, maybe, but stops there.   Most of us use
 center of interval as default, particularly since our semantics are not
 good enough to detect accumulation (which is the only case where end of
 interval is natural).

The accumulated precipitation data from these models is currently
labeled by the end points of the accumulation intervals (i.e., they are
all on the forecast time dimension). I'm trying to add the semantics to
make it possible to detect that this data is an accumulation without
breaking backwards compatibility.

Since, as you say, accumulation is the only case where the end of
interval is natural, adding the cell bounds information while using the
same forecast time dimension seems natural for this case.

Ethan


Benno Blumenthal wrote:
 I have to vote for multiple dimensions here -- these are different,
 parallel dimensions which happen to have the same number of points.
 
 Also, it is not true that a generic program cannot use the bounds. 
 Ingrid, in fact, prints time almost always as an interval, e.g. Jan 1980
 if the time cell goes from  1 Jan 1980 to  1 Feb 1980, so that
 cell boundaries are critical for time, much more important that
 spacially. This is because in common usage when we specify a time we
 almost always implicitly specify an interval.
 
 Also, it is not particularly natural to use the end point as the label
 for the data, certainly not so natural that a program would assume that
 not knowing anything else about the data.   It makes sense from a data
 collection point of view, maybe, but stops there.   Most of us use
 center of interval as default, particularly since our semantics are not
 good enough to detect accumulation (which is the only case where end of
 interval is natural).
 
 Benno
 
 On Thu, Oct 22, 2009 at 6:08 PM, Ethan Davis eda...@unidata.ucar.edu
 mailto:eda...@unidata.ucar.edu wrote:
 
 Hi John,
 
 John Caron wrote:
 
  The time coordinate here means forecast time, and you are trying to
  capture interval of accumulation.
 
 I'm not sure I understand your point here. The forecast time is the only
 time dimension we have. What other time coordinate would the interval
 of accumulation be over?
 
  As jonathan says, you would have to create separate time
 coordinates for
  each variable which has a distinct bounds.
 
 Yes, CF is currently written so only one boundary variable can be
 associate with one coordinate variable so this situation would require
 multiple time coordinates. I'm wondering if CF should be extended to
 allow multiple boundary variables to be associated with a single
 coordinate variable.
 
  theoretically theres no
  problem with that, practically it may be more confusing than just
  documenting the bounds on the variable in a non-standard but
  human-readable way. it seems unlikely that a generic program could do
  anything useful with those coordinate bounds.
 
 I agree that multiple time coordinates would do nothing for clarity.
 Which is why I'm wondering about extending CF to allow for a clearer,
 programmatically useful representation of this data.
 
 Ethan
 
 
 
 
 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu mailto:CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
 
 
 
 
 -- 
 Dr. M. Benno Blumenthal  be...@iri.columbia.edu
 mailto:be...@iri.columbia.edu
 International Research Institute for climate and society
 The Earth Institute at Columbia University
 Lamont Campus, Palisades NY 10964-8000   (845) 680-4450
 
 
 
 
 ___
 CF-metadata mailing list
 CF-metadata@cgd.ucar.edu
 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

-- 
Ethan R. DavisTelephone: (303) 497-8155
Software Engineer Fax:   (303) 497-8690
UCAR Unidata Program Center   E-mail:eda...@ucar.edu
P.O. Box 3000
Boulder, CO  80307-3000   http://www.unidata.ucar.edu/
---
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Question on WKT representation of CRS

[Ethan Davis]

Hi Phil, all,

This latest round of discussion around using CRS WKT reminded me of a
few questions:

1) How easy is it to form a WKT that has good interoperability between
different client libraries?

I've had multiple WKT for the same CRS with differences in AUTHORITY,
AXIS, and a few other things and had trouble having certain software
read them in without some tweaking. For instance, the
http://spatialreference.org/ pages for a given CRS list both OGC WKT and
ESRI WKT.

2) Are there good specification documents for WKT?

I believe the relevant OGC document is OGC 06-103r4 which can be found
here: http://portal.opengeospatial.org/files/?artifact_id=25355

   OpenGIS Implementation Standard for Geographic Information -
Simple Feature Access - Part I: Common Architecture

See section 9 WKT Representation of Spatial Reference Systems.

It has an non-normative, non-exhaustive list of units, ellipsoids,
projection names, projection parameters, and the like in Appendix B.

But in the wild, there seem to be lots of variations in projection names
and parameter names. There's even variation between them in the OGC spec
mentioned above and the EPSG data base.

3) Given that, is CRS as WKT well enough defined so that providing a
place for it in CF get us the interoperability we want?

Or, Phil, would the proposal you have in mind go into more detail (or
add to) the OGC spec?

4) One last question. The OGC CRS WKT specification is less than two
pages of EBNF (without a lot of explanation). How far is the current CF
grid mapping spec from complete coverage of the CRS WKT? Prime meridian
and some units?

Which would bring us back to the issue of maintaining controlled lists
in CF or defining how to use the EPSG database (for names rather than
code numbers, e.g., Lambert Conic Conformal (2SP) not 9802).


Ethan

-- 
Ethan Davis   UCAR Unidata Program
eda...@unidata.ucar.eduhttp://www.unidata.ucar.edu
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] CF upgrade to netCDF variable names

[Ethan Davis]

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

-- 
Ethan Davis   UCAR Unidata Program
eda...@unidata.ucar.eduhttp://www.unidata.ucar.edu
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Ethan Davis]

 the
 geoid -
 again, that is a single geophysical concept, with many alternative
 versions.

 So we need a place to name the geoid, if that is the vertical datum.
 It would
 be good to have a similar treatment to CRS WKT for this, but I don't
 see a
 place in WKT where the geoid can be identified. Can anyone help? Is
 the geoid
 implied by, or identical to, the vertical datum name, perhaps? How
 does one
 know, in WKT, whether the vertical datum is a geoid or a ref ellipsoid?

 Best wishes

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



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

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

-- 
Ethan Davis   UCAR Unidata Program
eda...@unidata.ucar.eduhttp://www.unidata.ucar.edu
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Ethan Davis]

 the geoid, ellipsoid or tidal datum
 elsewhere in the grid_mapping variable, right?

 Yes, that is the way we've been proceeding up to now. In fact we do not 
 have
 any stdnames yet referring to tidal datum, but you're welcome to propose 
 them
 if they're needed now, of course.

 geoid:  NAVD88, GEOID93, GEOID96, USGG2009, etc
 ellipsoid: WGS84, Airy 1830, Airy Modified 1849, etc
 tidal_datum: MLLW, MLW, MTL, MHW, MHHW, etc

 Thanks for these useful lists! I would tend to think that we should
 give different standard names for the various different tidal datums, 
 since
 I would regard those as different geophysical quantities - would you 
 agree?
 If there was data which referred to a tidal datum but didn't actually know
 which one it was, I suppose it might still be useful (if imprecise) and it
 could have a standard name that referred to tidal datum generically. But
 if you know it's mean_high_water (for instance), I would spell that out in
 the standard name.

 However I think the various geoids are all different estimates of the same
 geophysical quantity, so they should *not* have different standard names.
 Likewise the ref ellipsoid is the best ellipsoid approximating the 
 geoid -
 again, that is a single geophysical concept, with many alternative 
 versions.

 So we need a place to name the geoid, if that is the vertical datum. It 
 would
 be good to have a similar treatment to CRS WKT for this, but I don't see a
 place in WKT where the geoid can be identified. Can anyone help? Is the 
 geoid
 implied by, or identical to, the vertical datum name, perhaps? How does 
 one
 know, in WKT, whether the vertical datum is a geoid or a ref ellipsoid?

 Best wishes

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



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

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

 
 ___
 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
 

-- 
Ethan Davis   UCAR Unidata Program
eda...@unidata.ucar.eduhttp://www.unidata.ucar.edu
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] standard name aliases

[Ethan Davis]

Hi all,

Appendix B. Standard Name Table Format states that [t]he purpose of
the alias elements are to provide a means for maintaining the table in a
backwards compatible fashion. However, it isn't really clear (at least
to me) if entry terms in the standard name table should be preferred
over alias terms.

... Just found this in the About the CF Standard Name Table page:

  The use of an alias for the standard_name attribute when
  writing new data is not recommended.

Perhaps some discussion of standard name aliases should be added to
Section 3.3 Standard Name?

Ethan

-- 
Ethan Davis   UCAR Unidata Program
eda...@unidata.ucar.eduhttp://www.unidata.ucar.edu
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] CF data model discussion and OGC CF-netCDF docs

[Ethan Davis]

Hi all,

[Sorry to post here instead of on the trac data model discussion. I'm
having trouble (on my end) logging into the trac site.]

I'm not remembering or finding any mention in the CF data model
discussion of the OGC CF-netCDF [1] implementation specification
(11-165r2) [2]. Stefano Nativi and Ben Domenico have put a lot of work
into developing this mapping of CF-netCDF into the various OGC/ISO
abstract models. Seems like it might be useful especially in terms of
the recent grid mapping / dimensionless vertical coordinates / CRS
discussions given that OGC has a lot of experience with CRS and is more
recently trying to include concepts to cover dimensionless vertical
coordinates (sorry, not finding that specification).

Hope that's helpful,

Ethan


[1] http://www.opengeospatial.org/standards/netcdf
[2] https://portal.opengeospatial.org/files/?artifact_id=51908

-- 
Ethan Davis   UCAR Unidata Program
eda...@unidata.ucar.eduhttp://www.unidata.ucar.edu
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Meeting invite: Advancing netCDF-CF, 24-26 May 2016, Boulder, CO, USA

[Ethan Davis]

Hi Jonathan,

Thanks for your comments.

I've added them to our agenda planning notes. We'll work to get all this
integrated in some form for the meeting and future discussions.

Yes, though I'm not that familiar with the details of UGRID, it does (now
that you mention it) seem related in some ways to the river/basin topic.
I've been thinking of the river/basin issue as an extension to cell bounds
and the footprint of a data value. But, at least in the case of river
segments and drainage basins, capturing the connections between those 1-D
and 2-D objects seems much more appropriate. It would also be nice to use
similar mechanisms so that hydrological model outputs could interoperate
nicely with estuary and coastal modeling.

Cheers,

Ethan

On Tue, Mar 29, 2016 at 6:43 AM, Jonathan Gregory <j.m.greg...@reading.ac.uk
> wrote:

> Dear Ethan
>
> I agree with Steve about ugrid and aggregation being important topics.
>
> > 1. "UGRID"
>
> The ugrid design is rather CF-compatible and it would be good if they
> could be
> cemented together somehow. ugrid could be a proposed as a chapter of CF
> but it
> doesn't have to be, of course. I suppose the advantage of doing so would be
> that CF and ugrid development would subsequently remain compatible.
>
> Could ugrid deal with this one of your agenda items:
>
> > * Drafting a CF enhancement that would add support for complex data
> >   footprints (e.g., river segments and drainage basins)
>
> I'm not sure what you have in mind but it sounds possibly related.
>
> > 2. "Aggregation" -- CF structures to link multiple files into larger
> > conceptual datasets.  Time series aggregations, union aggregations
> > (associated variables in separate files), and ensemble membership
> > are the most obvious applications of this.   Another important
> > application is "tiled grids" (ref. the "gridspec" proposal).
>
> There are various types of aggregation which should be distinguished, I
> think.
>
> * Aggregation of variables. This is needed when one variable is split among
> several files (often along the time axis) but it can also apply to
> variables in
> the same file (for instance combining ensemble members or time series with
> the
> same time coordinates - Steve's other examples). In general it means
> combining
> several variables to make one variable, by concatenating one or more of
> their
> axes. This can be done entirely using CF metadata and David Hassell and I
> wrote
> a CF proposal for it http://cf-trac.llnl.gov/trac/ticket/78 a long time
> ago,
> which David has since implemented in cf-python software. I believe that
> this
> approach is fine for CMIP6 purposes, for example.
>
> * Aggregation of domains. By this I mean regarding domains which have their
> own axes as part of a larger domain, like gridspec does. It's not
> aggregation
> of variables in the same sense as above because the axes can't be
> concatenated.
> It is similar to ugrid, though, and I think it would be good if an
> extension
> to CF like ugrid could be developed for this.
>
> * Aggregation of files. By this I mean regarding several files as one file
> *without* associating or joining variables together, just putting them into
> one container. This needs rules for dealing with collisions of identically
> named variables, like NCO ncks has, or groups could be used, which are
> also on
> Ethan's agenda.
>
> > Harmonizing CF grid mapping with OGC CRS (coordinate reference
> > systems), possibly with WKT
>
> It should be possible to translate between CF and OGC CRS descriptions.
> Some
> extensions to help with this are in http://cf-trac.llnl.gov/trac/ticket/80
> ,
> which will be in CF 1.7, as will http://cf-trac.llnl.gov/trac/ticket/69,
> which
> allows WKT to be stored in a CF attribute. CF and OGC CRS have different
> views
> of the data space, so I don't think we can expect to make them look the
> same,
> but we should be able to define a mapping for all those concepts which are
> in
> both.
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from Ethan Davis <eda...@ucar.edu> -
>
> > Date: Sun, 27 Mar 2016 22:24:56 -0600
> > From: Ethan Davis <eda...@ucar.edu>
> > To: CF metadata <cf-metadata@cgd.ucar.edu>, netCDF SWG
> >   <netcdf@lists.opengeospatial.org>
> > Subject: [CF-metadata] Meeting invite: Advancing netCDF-CF, 24-26 May
> 2016,
> >   Boulder, CO, USA
> >
> > Hi all,
> >
> > As some of you have heard, we are holding a meeting to discuss current
> and
> > future netCDF-CF efforts and directions. The meeting will be held on
> 24-26
>

Re: [CF-metadata] Meeting invite: Advancing netCDF-CF, 24-26 May 2016, Boulder, CO, USA

[Ethan Davis]

Hi Randy,

Sorry you won't be able to join us in May.

Thanks for the GOES-R / CF document! I'm sure it will be a good resource in
discussions about CF and satellite data. The project folks focused on
satellite data are planning to use the existing
cf-satell...@unidata.ucar.edu email list [1] to make sure the broader
community can easily get involved in that conversation.

Also, we will have some form of remote participation available. Let me know
if you want to participate in any parts of the meeting that way.

Cheers,

Ethan

[1] http://www.unidata.ucar.edu/support/index.html#mailinglists

On Mon, Mar 28, 2016 at 5:50 AM, Randy Horne <rho...@excaliburlabs.com>
wrote:

> Ethan:
>
>
> RE:
>
>
>- Adding features to better support satellite data
>
>
>
> See attached white paper for how to extend CF conventions for GOES-R level
> 1b space weather data.  These conventions will work for polar orbiting
> satellite level 1b space weather data also.  Level 2 space weather products
> ill require additional constructs,
>
> Business has been lousy.  Otherwise, I would love to come !
>
>
> very respectfully,
>
> randy
>
>
>
>
>
>
>
> On Mar 28, 2016, at 12:24 AM, Ethan Davis <eda...@ucar.edu> wrote:
>
> Hi all,
>
> As some of you have heard, we are holding a meeting to discuss current and
> future netCDF-CF efforts and directions. The meeting will be held on 24-26
> May 2016 in Boulder, CO, USA at the UCAR Center Green facility.
>
> This meeting is organized by the “Advancing netCDF-CF for Geoscience”
> project [1] which has been funded by the US NSF EarthCube program. The
> project goals include several specific CF development efforts, both
> standards development and software prototyping. (We are just starting to
> spin-up community conversations around these specific goals for drafting CF
> extensions.) Another aspect of the funded project is community engagement
> including with the existing CF community, geoscience domains that have not
> been very involved in CF, and other standards bodies (e.g., OGC). These and
> other topics are on the current list of possible agenda items. Please let
> us know if you have other agenda items in mind.
>
> The current list of possible agenda items includes:
>
>- Investigate using features of the netCDF enhanced data model to
>improve/simplify the CF Discrete Sampling Geometries (which includes point,
>sounding, and trajectory data types)
>- Drafting a CF enhancement that would add support for complex data
>footprints (e.g., river segments and drainage basins)
>- Further develop the CFRadial proposal for representing Radar data
>- Adding features to better support satellite data
>- Adding CF support for hierarchical groups for organizing data and
>metadata
>- Enhancing CF to support Linked Data / semantic technology concepts
>- Harmonizing CF grid mapping with OGC CRS (coordinate reference
>systems), possibly with WKT
>- Adding CF support for attribute namespaces and the use of URI
>prefixes in attribute values
>- Improved support for dimensionless data variables, logarithmic
>scales, differences, etc.
>
> While we wish we could host all those interested in attending, given the
> available meeting space and the number of project participants, we are
> asking members of the CF community that are interested in attending to
> contact us directly and let us know which aspects of CF are of interest to
> you and your goals for the meeting. Please submit your expressions of
> interest by Monday, 4 April 2016. We plan to invite participants by Friday,
> 8 April 2016.
>
> Travel and other information will be on the meeting page [2] later this
> week.
>
> Also, for anyone attending EGU in Vienna in April, we will have a splinter
> meeting (SMP32) to discuss netCDF-CF. The splinter meeting will be held on
> Thursday, 21 April 2016 at 15:30 in room 2.96.
>
> Thank you,
>
> Meeting Organizers
>
> Ethan Davis, UCAR Unidata
> Charlie Zender, Univ of CA, Irvine
> David Arctur, Univ of TX, Austin
> Dave Santek, Univ of WI, Madison / SSEC
> Kevin O’Brien, Univ of WA/JISAO and NOAA/PMEL
> Aleksandar Jelenak, The HDF Group
> Mike Dixon, NCAR/EOL
>
> [1] http://www.nsf.gov/awardsearch/showAward?AWD_ID=1541031
>
> [2] http://www.unidata.ucar.edu/events/2016CFWorkshop/
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> _
>
> Randy C Horne (rho...@excaliburlabs.com)
> Principal Engineer, Excalibur Laboratories Inc.
> voice & fax: (321) 952.5100
> cell: (321) 693.1074
> url: http://www.excaliburlabs.com
>
>
>
>
>
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Meeting invite: Advancing netCDF-CF, 24-26 May 2016, Boulder, CO, USA

[Ethan Davis]

Hi Steve,

Thanks for those introducing those topics. I've added them to our list of
topics and made note of Chris, David, and Roy's comments.

I will get our list of possible agenda topics and a rough schedule up on
the meeting page [1] today or tomorrow that we will update as the agenda
solidifies.

Cheers,

Ethan

[1] http://www.unidata.ucar.edu/events/2016CFWorkshop/

On Mon, Mar 28, 2016 at 10:25 AM, Steve Hankin <steven.c.han...@noaa.gov>
wrote:

> Ethan,
>
> Two more topics to consider as additions to your list:
>
> 1. "UGRID" -- Of interest to the coastal ocean modeling community, and
> stuck in a holding pattern for quite a long time, is the harmonization of
> mesh/unstructured grid coordinates into the main body of CF.  The work is
> mostly completed ...
>
> 2. "Aggregation" -- CF structures to link multiple files into larger
> conceptual datasets.  Time series aggregations, union aggregations
> (associated variables in separate files), and ensemble membership are the
> most obvious applications of this.   Another important application is
> "tiled grids" (ref. the "gridspec" proposal).
>
>     - Steve
>
> 
>
>
> On 3/27/2016 9:24 PM, Ethan Davis wrote:
>
> Hi all,
>
> As some of you have heard, we are holding a meeting to discuss current and
> future netCDF-CF efforts and directions. The meeting will be held on 24-26
> May 2016 in Boulder, CO, USA at the UCAR Center Green facility.
>
> This meeting is organized by the “Advancing netCDF-CF for Geoscience”
> project [1] which has been funded by the US NSF EarthCube program. The
> project goals include several specific CF development efforts, both
> standards development and software prototyping. (We are just starting to
> spin-up community conversations around these specific goals for drafting CF
> extensions.) Another aspect of the funded project is community engagement
> including with the existing CF community, geoscience domains that have not
> been very involved in CF, and other standards bodies (e.g., OGC). These and
> other topics are on the current list of possible agenda items. Please let
> us know if you have other agenda items in mind.
>
> The current list of possible agenda items includes:
>
>- Investigate using features of the netCDF enhanced data model to
>improve/simplify the CF Discrete Sampling Geometries (which includes point,
>sounding, and trajectory data types)
>- Drafting a CF enhancement that would add support for complex data
>footprints (e.g., river segments and drainage basins)
>- Further develop the CFRadial proposal for representing Radar data
>- Adding features to better support satellite data
>- Adding CF support for hierarchical groups for organizing data and
>metadata
>- Enhancing CF to support Linked Data / semantic technology concepts
>- Harmonizing CF grid mapping with OGC CRS (coordinate reference
>systems), possibly with WKT
>- Adding CF support for attribute namespaces and the use of URI
>prefixes in attribute values
>- Improved support for dimensionless data variables, logarithmic
>scales, differences, etc.
>
> While we wish we could host all those interested in attending, given the
> available meeting space and the number of project participants, we are
> asking members of the CF community that are interested in attending to
> contact us directly and let us know which aspects of CF are of interest to
> you and your goals for the meeting. Please submit your expressions of
> interest by Monday, 4 April 2016. We plan to invite participants by Friday,
> 8 April 2016.
>
> Travel and other information will be on the meeting page [2] later this
> week.
>
> Also, for anyone attending EGU in Vienna in April, we will have a splinter
> meeting (SMP32) to discuss netCDF-CF. The splinter meeting will be held on
> Thursday, 21 April 2016 at 15:30 in room 2.96.
>
> Thank you,
>
> Meeting Organizers
>
> Ethan Davis, UCAR Unidata
> Charlie Zender, Univ of CA, Irvine
> David Arctur, Univ of TX, Austin
> Dave Santek, Univ of WI, Madison / SSEC
> Kevin O’Brien, Univ of WA/JISAO and NOAA/PMEL
> Aleksandar Jelenak, The HDF Group
> Mike Dixon, NCAR/EOL
>
> [1] http://www.nsf.gov/awardsearch/showAward?AWD_ID=1541031
>
> [2] http://www.unidata.ucar.edu/events/2016CFWorkshop/
>
>
> ___
> CF-metadata mailing 
> listcf-metad...@cgd.ucar.eduhttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Meeting invite: Advancing netCDF-CF, 24-26 May 2016, Boulder, CO, USA

[Ethan Davis]

Hi Randy,

Great, I'll add you to the list of folks planning to join remotely.

Yes, there is a lot in that tech memo. An overview/introduction sounds very
useful.

Thanks for the information on the ISO work dealing with space weather. I've
had some conversations with others interested in this work. I'll send a
separate email shortly with more on that.

Cheers,

Ethan

On Wed, Mar 30, 2016 at 1:49 PM, Randy Horne <rho...@excaliburlabs.com>
wrote:

> Ethan:
>
> I would very much appreciate participating remotely when the discussions
> of space weather products came up.
>
> I am already a member of cf_satellite so no issue.
>
> The problem with my tech memo is there is SO MUCH THERE. Discussions on
> the message board usually attack one “construct” at a time.  It will be
> overwhelming without an overarching introduction (which I would be glad to
> do).
>
> Note that I have had a quick email exchange with *W. Kent Tobiska (**"W.
> Kent Tobiska" <ktobi...@spacenvironment.net
> <ktobi...@spacenvironment.net>>) **who is a top authority on space
> weather in general, but I don’t think he is plugged into netCDF/cf.  I
> think he has been laying the groundwork/foundation for many types of level
> 2 and level 3 space weather products and using ISO as a means
> to standardize. The ASCII product files that his efforts generate are
> self-describing, but they are not done in a standards-based way like CF
> requires, and he is not using netCDF. ** I have attached an ISO working
> draft of the kind of work he is doing.  I suspect it would be a **formidable
> activity to get everybody on the same page.*
>
> *I wish I could spend more time on it, but I have got to pay the bills. *
>
> Thanks !
>
> randy
>
>
>
> _
>
> Randy C Horne (rho...@excaliburlabs.com)
> Principal Engineer, Excalibur Laboratories Inc.
> voice & fax: (321) 952.5100
> cell: (321) 693.1074
> url: http://www.excaliburlabs.com
>
>
>
> On Mar 30, 2016, at 3:29 PM, Ethan Davis <eda...@ucar.edu> wrote:
>
> Hi Randy,
>
> Sorry you won't be able to join us in May.
>
> Thanks for the GOES-R / CF document! I'm sure it will be a good resource
> in discussions about CF and satellite data. The project folks focused on
> satellite data are planning to use the existing
> cf-satell...@unidata.ucar.edu email list [1] to make sure the broader
> community can easily get involved in that conversation.
>
> Also, we will have some form of remote participation available. Let me
> know if you want to participate in any parts of the meeting that way.
>
> Cheers,
>
> Ethan
>
> [1] http://www.unidata.ucar.edu/support/index.html#mailinglists
>
> On Mon, Mar 28, 2016 at 5:50 AM, Randy Horne <rho...@excaliburlabs.com>
> wrote:
>
>> Ethan:
>>
>>
>> RE:
>>
>>
>>- Adding features to better support satellite data
>>
>>
>>
>> See attached white paper for how to extend CF conventions for GOES-R
>> level 1b space weather data.  These conventions will work for polar
>> orbiting satellite level 1b space weather data also.  Level 2 space weather
>> products ill require additional constructs,
>>
>> Business has been lousy.  Otherwise, I would love to come !
>>
>>
>> very respectfully,
>>
>> randy
>>
>>
>>
>>
>>
>>
>>
>> On Mar 28, 2016, at 12:24 AM, Ethan Davis <eda...@ucar.edu> wrote:
>>
>> Hi all,
>>
>> As some of you have heard, we are holding a meeting to discuss current
>> and future netCDF-CF efforts and directions. The meeting will be held on
>> 24-26 May 2016 in Boulder, CO, USA at the UCAR Center Green facility.
>>
>> This meeting is organized by the “Advancing netCDF-CF for Geoscience”
>> project [1] which has been funded by the US NSF EarthCube program. The
>> project goals include several specific CF development efforts, both
>> standards development and software prototyping. (We are just starting to
>> spin-up community conversations around these specific goals for drafting CF
>> extensions.) Another aspect of the funded project is community engagement
>> including with the existing CF community, geoscience domains that have not
>> been very involved in CF, and other standards bodies (e.g., OGC). These and
>> other topics are on the current list of possible agenda items. Please let
>> us know if you have other agenda items in mind.
>>
>> The current list of possible agenda items includes:
>>
>>- Investigate using features of the netCDF enhanced data model to
>>improve/simplify the CF D

[CF-metadata] EGU splinter meeting: Advancing netCDF-CF for the Geoscience Community

[Ethan Davis]

Hi all,

Just a reminder for anyone attending EGU in Vienna this week.

Please join us for a splinter meeting to discuss netCDF-CF (session SMP32
[1]). The meeting will be in room 2.96 on 21 April 2016 (Thursday),
15:30-17:00.

Hope to see you there.

Ethan

[1] http://meetingorganizer.copernicus.org/EGU2016/session/22532
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] NetCDF-CF session at AGU: call for contributions

[Ethan Davis]

Dear all,

At the upcoming AGU Fall meeting (12-16 Dec 2016, San Francisco) [1],  we
will be hosting a session dedicated  to CF and netCDF, entitled: “Advancing
netCDF-CF for the Geoscience Community”.

Please, consider contributing to the session by submitting a short abstract
at the link below [2]. The abstract submission deadline is the 3rd of
August, 11:59 P.M. EDT.

Thank you,

Ethan Davis
Stefano Nativi
Lesley Wyborn
Ben Domenico

[1] http://fallmeeting.agu.org/2016/

[2] https://agu.confex.com/agu/fm16/preliminaryview.cgi/Session13459
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Temporal nitpicks.

[Ethan Davis]

Hi Chris,


> I'm going to venture a guess that the netcdf Java libs can [handle the
> "T"] (anyone know for sure?)


Yes, the netCDF-Java library can parse date/time strings with the "T".

Ethan

On Fri, Sep 23, 2016 at 1:26 PM, Chris Barker  wrote:

> On Thu, Sep 22, 2016 at 3:38 PM, Seth McGinnis  wrote:
>
>> I hesitate to support encouraging the use of the T because in my
>> experience, approximately 0% of existing NetCDF files have it.
>>
>
> in my experience, > 0% (but still small).
>
> But that isn't the right question -- given that few existing ?CF files
> have the T, we can be confident that code that expects to be able to parse
> CF can parse it without the T.
>
> The question is: how much code that expects to be able to parse CF can not
> handle the "T":
>
> UDUNITS can
> The Python netCDF4 lib can
> Anything that can parse ISO stings can
> I'm going to venture a guess that the netcdf Java libs can (anyone know
> for sure?)
>
> Which covers a lot of ground, but not all the various custom Fortran and
> what have you code out there.
>
> So I expect leaving the T out is going to have to remain as "best
> practice" for CF
>
>
>> There is benefit in encouraging alignment with a separate standard, but
>> it comes at the cost of increasing the amount of disagreement in the set
>> of all CF-compliant files out there.  It's not obvious to me that the
>> former is greater than the latter.
>>
>
> again, disagreement with the files isn't really relevant -- disagreement
> with parsers is key.
>
> I'd be interested if anyone on this list can say "my code won't parse the
> T" -- that would settle it.
>
> It also worries me that there is a small but fundamental mismatch
>> between the two standards: ISO 8601 is only intended to support
>> real-world dates and times using the Gregorian calendar, while CF also
>> needs to support non-standard model calendars.  Being able to use
>> software that understands ISO datetimes when working with NetCDF data is
>> great right up until the point that it gives you the wrong answer
>> because it doesn't understand the "calendar" attribute and ignores it.
>>
>
> I think this is totally irrelevant -- we're only talking about the
> datetime string here.
>
> an pure ISO 8601 code isn't going to understand stuff like "seconds since"
> anyway -- of course, you'll need a CF compliant reader to do more.
>
> As it stands, there are multiple ways to write a datetime string in CF --
> all I'm suggesting is that we pick one as "best practice", and make that
> clear in the docs.
>
> If we ever get to the mythical CF2 or "pedantic CF" standard, we could
> make it the one and only way to express datetimes.
>
> If we're going to move to align CF more closely with external standards,
>> is there any way to also apply corresponding pressure on external
>> systems to better accommodate CF?
>>
>
> one's that aren't CF-focused anyway? I doubt it :-(
>
> and I'm not sure what you are suggesting -- that we should ask that all
> datetime string parsers should read non-iso compliant strings? I don't know
> that I'd ever suggest that anyway.
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Temporal nitpicks.

[Ethan Davis]

I totally agree. Don't deprecate anything but definitely encourage ISO
8601:2004(E) with the caveat of requiring an offset-from-Z indicator.

Cheers,

Ethan

On Fri, Sep 23, 2016 at 9:38 AM, Bob Simons - NOAA Federal <
bob.sim...@noaa.gov> wrote:

> 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
> should encourage. So the issue of what is in current files should be
> irrelevant. Tons of .nc files have "days since 1-1-1" (which is a horrid
> format). Just because a format is common is not a good reason to encourage
> its use.
>
> b) The CF community needs to respect (i.e., faithfully follow) other
> standards, just as we ask people to respect our standard. Some in the CF
> community might think that CF is a self-contained standard, but it isn't.
> We rely on IEEE-754 for binary number formats, various charsets for
> character encoding, the CRS Well Known Text Format, numerous calendar
> standards, numerous projections, etc. These are all external standards that
> we have included in CF simply by referencing them. We shouldn't slightly
> modify any of these standards when we use them in .nc files. Similarly we
> should cleanly adopt the ISO 8601:2004(E) standard format (with the T) for
> date times. [Okay, it weakens my argument that ISO 8601 says that the T may
> be omitted by mutual consent, but I think is is better for CF to recommend
> the format that is clearly recommended by ISO 8601:2004(E) (i.e., with the
> T).]
>
>
> --
> Sincerely,
>
> Bob Simons
> IT Specialist
> Environmental Research Division
> NOAA Southwest Fisheries Science Center
> 99 Pacific St., Suite 255A  (New!)
> Monterey, CA 93940   (New!)
> Phone: (831)333-9878(New!)
> Fax:   (831)648-8440
> Email: bob.sim...@noaa.gov
>
> The contents of this message are mine personally and
> do not necessarily reflect any position of the
> Government or the National Oceanic and Atmospheric Administration.
> <>< <>< <>< <>< <>< <>< <>< <>< <><
>
>
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

[Ethan Davis]

Hi all,

Just a quick note on Chris' CF 2 question (until I have a bit more time to
think more fully on this discussion)  ...

The EC netCDF-CF project that Ben mentioned is working on a number of CF
extension efforts that are looking to use features of the netCDF enhanced
data model. Those efforts will all target CF 2 rather than CF 1.x. However,
as with the Simple Geometries, we should also expect suggestions for
changes to CF 1.x spinning out of these efforts.

The CF-2 discussion has been pretty quite for awhile now. However, I expect
it will be more active as these various CF extension efforts start seeking
more community input and making proposals.

Cheers,

Ethan


On Thu, Sep 22, 2016 at 12:00 PM, Chris Barker 
wrote:

> Sorry, not enough time to really read tis all carefully, but a couple
> comments from a brief look:
>
>>
>> If the regions were irregular
>> polygons in latitude and longitude, nv would be the number of vertices
>> and the
>> lat and lon bounds would trace the outline of the polygon e.g. nv=3,
>> lat=0,90,0
>> and lon=0,0,90 describes the eighth of the sphere which is bounded by the
>> meridians at 0E and 90E and the Equator. I think, therefore, we do not
>> need an
>> additional convention for points or polygonal regions.
>
>
> this seems fine for this simple example, but burying a bunch of
> coordinates of a complex polygon in a text string in an attribute is really
> not a good idea -- the coordinates of a polygon should be in the array data
> one way or another, rather than having to parse out attribute strings.
>
> * I suspect that geometries of this kind can be described by the ugrid
>> convention http://ugrid-conventions.github.io/ugrid-conventions, which is
>> compliant with CF. Their purpose is to describe a set of connected points,
>> edges or faces at which values are given,
>
>
> I'm not so sure -- UGRID is about defining a bunch of polygons that all
> share vertices, and are all of the same order (usually all triangles, or
> quads, or maybe hexes). if they are a mixture, you still store the full set
> (say, six vertices), while marking some as unused. But it's not that well
> set up for a bunch of polygons of different order.
>
> Not too bad if there are only one or two complex polygons, but it would be
> a bit weird -- you'd have vertices and boundaries, but no faces. And you'd
> lose t order of the vertices (thought that could probably be added to the
> UGRID standard)
>
>
>> whereas in your case you'd give a
>> single value for the whole set, but the description of the geometry itself
>> might be similar. Have you had a look at whether ugrid could meet your
>> needs?
>> If it almost does so, perhaps a better thing to do would be to propose
>> additions to ugrid. We would like to avoid having more than one way to
>> describe
>> such geometries.
>>
>
> Ben has been involved in UGRID, so I'm sure he's thought this out. For my
> part, I think it's really a different problem, though it would be nice if
> it were as similar to UGRID as possible.
>
> * So far CF does not say anything about the use of netCDF-4 features (i.e.
>> not
>> the classic model). We have often discussed allowing them but the general
>> argument is also made that there has to be a compelling case for
>> providing a
>> new way to do something which can already be done. (Steve Hankin often
>> made
>> this argument, but since he's mostly retired I'll make it now in his name
>> :-)
>>
>
> Maybe it's time to embrace netcdf4? It's been a while! Though maybe for CF
> 2.* -- any movement on that?
>
>
>> If there are two ways to do something, software has to support both of
>> them. We
>> already have ways to encode ragged arrays, so is there a compelling case
>> for
>> needing the netCDF-4 vlen array as well?
>
>
> I think the ragged array option ins fine -- though I haven't looked at
> vlen arrays enough to know if they offer a compelling alternative. One
> issue is that the programming environments that we use to work with the
> data may not have an equivalent of vlen arrays.
>
> * Similarly, you propose attributes for clockwise/anticlockwise node order
>> and
>> for the polygon closure convention.
>
>
> This should match the OGC conventions as much as is practical.
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Advancing netCDF-CF workshop: agenda and hotel block rate deadline

[Ethan Davis]

Hi all,

We just posted the agenda for the workshop [1]. There will be some minor
tweaks to the schedule coming. Please take a look and let us know if you
have any suggestions for changes to the content or schedule.

We will have a session for a series of short lightning talks. There is a
spot to express interest in giving a lightning talk in the registration
form or feel free to email me directly.

Also, the deadline for the room block at the hotel [2] is next Tuesday, 15
Aug. So, if you plan to attend, please reserve your hotel room by then.

Thanks,

The Workshop Organizing Committee

[1] http://www.unidata.ucar.edu/events/2017CFWorkshop/#schedule

[2] http://www.unidata.ucar.edu/events/2017CFWorkshop/#travel
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Advancing netCDF-CF workshop on 6-8 Sept 2017 in Boulder, CO USA

[Ethan Davis]

Hi Antonio,

Yes, we will have remote participation available.

Cheers,

Ethan

On Wed, Jul 26, 2017 at 1:28 PM, Antonio S. Cofiño <antonio.cof...@unican.es
> wrote:

> Hi Ethan,
>
> There is any chance to enable remote virtual participation into this
> workshop?
>
> Thank you and regards
>
> Antonio
>
>
> --
> Antonio S. Cofiño
> Associate Professor and Researcher
> Grupo de Meteorología de Santander
> Dep. of Applied Mathematics and Computer Sciences
> Universidad de Cantabria (Spain)
>
> Academic Visitor
> National Centre for Atmospheric Science
> Department of Meteorology
> School of Mathematical, Physical and Computational Sciences
> University of Reading (UK)
> http://antonio.cofino.es
>
> On 26/07/17 18:10, Ethan Davis wrote:
>
> Hi all,
>
> As many of you know, we are holding an "Advancing netCDF-CF" workshop [1]
> on 6-8 September 2017 at UCAR in Boulder, CO USA. This workshop will focus
> on efforts to advance the Climate and Forecast (CF) metadata conventions
> for netCDF (netCDF-CF). The meeting is being hosted by the EarthCube
> “Advancing netCDF-CF for Geoscience” project, which is funded by the US
> National Science Foundation's EarthCube program.
>
> The main focus will be on recent and ongoing efforts to advance netCDF-CF.
> There will be time devoted to several current proposals: satellite swath
> data, group hierarchies, and geometries (e.g., ploylines and polygons).
> There will also be sessions on more general CF topics including the
> recently proposed CF Data Model, ongoing work looking at how to use
> features of the netCDF enhanced data model (string vs char, VLen, etc.),
> and possible change to the latitude/longitude requirement. A detailed
> schedule [2] will be available shortly.
>
> Hotel and other travel information is available on the web site [3]. If
> you plan to attend, please register for the workshop [4]. (There is no
> registration fee, but we do need to know who will be attending and want to
> ensure that everyone attending gets all the relevant workshop details.)
>
> Thanks,
>
> The Workshop Organizing Team
>
> [1] http://www.unidata.ucar.edu/events/2017CFWorkshop/#home
>
> [2] http://www.unidata.ucar.edu/events/2017CFWorkshop/#schedule
>
> [3] http://www.unidata.ucar.edu/events/2017CFWorkshop/#travel
>
> [4] http://www.unidata.ucar.edu/events/2017CFWorkshop/#reginfo
>
>
> ___
> CF-metadata mailing 
> listcf-metad...@cgd.ucar.eduhttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Advancing netCDF-CF workshop on 6-8 Sept 2017 in Boulder, CO USA

[Ethan Davis]

Hi all,

As many of you know, we are holding an "Advancing netCDF-CF" workshop [1]
on 6-8 September 2017 at UCAR in Boulder, CO USA. This workshop will focus
on efforts to advance the Climate and Forecast (CF) metadata conventions
for netCDF (netCDF-CF). The meeting is being hosted by the EarthCube
“Advancing netCDF-CF for Geoscience” project, which is funded by the US
National Science Foundation's EarthCube program.

The main focus will be on recent and ongoing efforts to advance netCDF-CF.
There will be time devoted to several current proposals: satellite swath
data, group hierarchies, and geometries (e.g., ploylines and polygons).
There will also be sessions on more general CF topics including the
recently proposed CF Data Model, ongoing work looking at how to use
features of the netCDF enhanced data model (string vs char, VLen, etc.),
and possible change to the latitude/longitude requirement. A detailed
schedule [2] will be available shortly.

Hotel and other travel information is available on the web site [3]. If you
plan to attend, please register for the workshop [4]. (There is no
registration fee, but we do need to know who will be attending and want to
ensure that everyone attending gets all the relevant workshop details.)

Thanks,

The Workshop Organizing Team

[1] http://www.unidata.ucar.edu/events/2017CFWorkshop/#home

[2] http://www.unidata.ucar.edu/events/2017CFWorkshop/#schedule

[3] http://www.unidata.ucar.edu/events/2017CFWorkshop/#travel

[4] http://www.unidata.ucar.edu/events/2017CFWorkshop/#reginfo
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Save the Date: Advancing netCDF-CF Workshop, 6-8 Sept 2017 in Boulder, CO USA

[Ethan Davis]

Hi all,

We will be holding an "Advancing netCDF-CF" workshop on 6-8 September 2017
at UCAR in Boulder, CO USA.

Please save the date. More information will be coming soon.

Thanks,

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

Re: [CF-metadata] Some issues with example H.2 / timeseries

[Ethan Davis]

Hi Heiko and David,

Its been awhile since I looked at this but I don't think the Trac ticket
covers the order of the dimensions. Here's the PR I put together in
February for the missing string length dimension issue. It adds definitions
for dimensions but does nothing regarding dimension order.

https://github.com/cf-convention/cf-conventions/pull/128/files

Cheers,

Ethan

On Mon, Jun 11, 2018 at 4:57 AM, Heiko Klein  wrote:

> Dear David,
>
> thanks, I agree, it sounds very related. I have no possiblity to check,
> either. Not sure if the dimension ordering is mentioned there.
>
> Heiko
>
>
>
> On 2018-06-08 17:38, David Hassell wrote:
> > Dear Heiko,
> >
> > According the trac summary
> > (http://www.met.reading.ac.uk/~david/cf_trac_summary.html) the
> > unresolved ticket #161 is titled "h.2 name_strlen" - I wonder (in the
> > absence of being able have a look) if that is for the same issue.
> >
> > All the best,
> >
> > David
> >
> > On 8 June 2018 at 16:29, Heiko Klein  > > wrote:
> >
> > Hi,
> >
> > I've just been working with timeseries and looked at example H.2 in
> the
> > conventions document:
> > http://cfconventions.org/Data/cf-conventions/cf-conventions-
> 1.7/cf-conventions.html#example-h.2
> >  conventions.html#example-h.2>
> >
> > The example isn't valid because
> >  a) the name_strlen dimension is used but not declared
> >  b) humidity has time/UNLIMITED as second dimension, while UNLIMITED
> > dimensions must be first. Either it must be humidity(o,i) or time
> should
> > not be UNLIMIED.
> >
> > (and c) the Conventions attribute is missing). I attach a working
> > example with humidity(o,i).
> >
> > Trac seems to be down, so I post it here. I hope somebody can fix the
> > document.
> >
> > Best wishes,
> >
> > Heiko
> >
> >
> > --
> > Dr. Heiko Klein   Norwegian Meteorological Institute
> > Tel. + 47 22 96 32 58 P.O. Box 43 Blindern
> > http://www.met.no 0313 Oslo NORWAY
> >
> > ___
> > CF-metadata mailing list
> > CF-metadata@cgd.ucar.edu 
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > 
> >
> >
> >
> >
> > --
> > David Hassell
> > National Centre for Atmospheric Science
> > Department of Meteorology, University of Reading,
> > Earley Gate, PO Box 243, Reading RG6 6BB
> > Tel: +44 118 3785183
> > http://www.met.reading.ac.uk/
>
> --
> Dr. Heiko Klein   Norwegian Meteorological Institute
> Tel. + 47 22 96 32 58 P.O. Box 43 Blindern
> http://www.met.no 0313 Oslo NORWAY
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] 2018 netCDF-CF Workshop, 19-20 June 2018, Reading, UK

[Ethan Davis]

Forgot to mention ...

There will be WebEx for remote participation. Connection and dial-in
details will be posted on the workshop web page once available.

On Fri, Jun 1, 2018 at 3:07 PM, Ethan Davis  wrote:

> Hi all,
>
> Just a reminder that the 2018 netCDF-CF Workshop [1] will be on 19-20
> June 2018 at the University of Reading in the UK.
>
> The agenda, as it currently stands, is available on the workshop web page
> [1] (or directly here [2]). Suggestions are still welcome.
>
> If you plan to attend, please be sure to register [3]. Travel and hotel
> information is available on the workshop page [1].
>
> Hope to see many of you there.
>
> Thanks,
>
> The Workshop Organizing Committee
>
> [1] https://www.ncas.ac.uk/en/conferencesandworkshops/2018cfworkshop
>
> [2] https://www.ncas.ac.uk/images/Draft-Agenda-for-June-
> 2018-netCDF-CF-Workshop.pdf
>
> [3] https://www.regonline.com/builder/site/?eventid=2368248
>
>
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] 2018 netCDF-CF Workshop, 19-20 June 2018, Reading, UK

[Ethan Davis]

Hi all,

Just a reminder that the 2018 netCDF-CF Workshop [1] will be on 19-20 June
2018 at the University of Reading in the UK.

The agenda, as it currently stands, is available on the workshop web page
[1] (or directly here [2]). Suggestions are still welcome.

If you plan to attend, please be sure to register [3]. Travel and hotel
information is available on the workshop page [1].

Hope to see many of you there.

Thanks,

The Workshop Organizing Committee

[1] https://www.ncas.ac.uk/en/conferencesandworkshops/2018cfworkshop

[2]
https://www.ncas.ac.uk/images/Draft-Agenda-for-June-2018-netCDF-CF-Workshop.pdf

[3] https://www.regonline.com/builder/site/?eventid=2368248
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] 2018 netCDF-CF Workshop, 19-20 June 2018, Reading, UK

[Ethan Davis]

Hi all,

As many of you know, the 2018 netCDF-CF Workshop [1] will be on 19-20 June
2018 at the University of Reading in the UK. This workshop will focus on
efforts to advance the Climate and Forecast (CF) metadata conventions for
netCDF (netCDF-CF). The meeting is being hosted by the National Centre for
Atmospheric Science (NCAS) at the University of Reading.

Hotel and other travel information is available on the web site [1]. If you
plan to attend, please register for the workshop [2]. (There is no
registration fee, but we do need to know who will be attending and want to
ensure that everyone attending gets all the relevant workshop details.)

The workshop agenda is still developing. We will have a rough draft
available on the workshop web site in the next week or so. The main focus
will be on recent and ongoing efforts to advance netCDF-CF as well as some
CF governance and process discussion.

Hope to see many of you there.

Thanks,

The Workshop Organizing Committee

[1] https://www.ncas.ac.uk/en/conferencesandworkshops/2018cfworkshop

[2] https://www.regonline.com/builder/site/?eventid=2368248
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] Bad reference to example in CF 6.1 "Labels"

[Ethan Davis]

Hi all,

The last sentence at the end of the first paragraph in Section 6.1 "Labels"
[1] says:

Example H.1, "Point data" illustrates another application for labels.


However, that example doesn't have any labels. Section 6.1 was rewritten
when the DSG chapter was added. Looking at the last draft Word Doc file [2]
I found for the DSG chapter, I suspect it should instead say something like

Example 6.1 "Northward heat transport in Atlantic Ocean" illustrates
another application for labels.


or with a bit more context:

There are several other uses for labels in CF, for instance, example 6.1
"Northward heat transport in Atlantic Ocean" shows the use of labels to
indicate geographic regions.


Let me know if anyone has a different interpretation or solution, or
remembers more details from the DSG discussion around this? I'm not seeing
anything on a quick search through Trac #37.

Also, there is currently no Example 6.1. Section 6 has an example 6.2 and
6.3, but no 6.1. Looks like an error catching all the changes in the DSG
Word Doc. The draft DSG chapter says (very bottom)

Delete Example 6.1 (there are plenty of such examples in section 9).
Renumber Example 6.2 as 6.1 and 6.3 as 6.2.


Anyway, couldn't get to Trac, so sending to email list. I will also have a
GitHub PR up shortly that includes an update to the "other use of labels"
sentence and updates the example numbers in Section 6.

Cheers,

Ethan

[1] http://cfconventions.org/cf-conventions/cf-conventions.html#labels

[2] https://cf-trac.llnl.gov/trac/attachment/ticket/37/CFch9-may4.docx
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Platform Heave

[Ethan Davis]

Hi Jim, all,

I'm a bit confused by the "clockwise" and "anticlockwise". You mention the
orientation of the observer but not the location/orientation of the clock.
My assumptions (not sure why) for the clock: for roll, the observer (who is
facing forward) would be facing the clock; for pitch, the observer would
look right to see the clock; and for yaw, the observer would look down to
see the clock. That works for your definitions of pitch and yaw, but is
backwards for roll.

Does "clockwise" add, in some way, another degree of freedom to the
definition? Does that degree of freedom need to be nailed down in the
definitions? Or other terms used instead? I don't have any good suggestions
other than "positive" and "negative".

Cheers,

Ethan

On Wed, Aug 29, 2018 at 9:03 AM Jim Biard  wrote:

> Hi.
>
>
> I've finally gotten back to this topic! The definitions below call out an
> attribute named "direction" that is used to specify the direction for
> positive values of the different quantities. We may need to add a
> definition for the attribute to the Conventions. The values and meanings
> for the direction attribute are:
>
> roll: "clockwise" for positive right side up and "anticlockwise" for
> positive right side down.
> pitch: "clockwise" for positive nose up and "anticlockwise" for positive
> nose down.
> yaw: "clockwise" for positive nose right and "anticlockwise" for positive
> nose left.
> surge: "positive" for positive forward and "negative" for positive
> backward.
> sway: "positive" for positive left and "negative" for positive right.
> heave: "positive" for positive up and "negative" for positive down.
>
> And here are the standard name definitions:
>
> platform_roll: Platform is a structure or vehicle that serves as a base
> for mounting sensors. Platforms include, but are not limited to,
> satellites, aeroplanes, ships, buoys, ground stations, and masts. Roll is a
> rotation about an axis (the X axis) that is perpendicular to the local
> vertical axis (the Z axis) and is coplanar with the nominal forward motion
> direction of the platform. Roll is relative to the “at rest” rotation of
> the platform with respect to the X axis. The “at rest” rotation of the
> platform may change over time. The direction for positive values of roll is
> specified by an attribute named direction. The value of the direction
> attribute is "clockwise" if positive values of roll represent the right
> side of the platform rising as viewed by an observer on top of the platform
> facing forward. The value of the direction attribute is "anticlockwise" if
> positive values of roll represent the right side of the platform falling.
> The directionality of roll values is unspecified if no direction attribute
> is present.
>
> platform_pitch: Platform is a structure or vehicle that serves as a base
> for mounting sensors. Platforms include, but are not limited to,
> satellites, aeroplanes, ships, buoys, ground stations, and masts. Pitch is
> a rotation about an axis (the Y axis) that is perpendicular to both the
> local vertical axis (the Z axis) and the nominal forward motion direction
> of the platform. Pitch is relative to the “at rest” rotation of the
> platform with respect to the Y axis. The “at rest” rotation of the platform
> may change over time. The direction for positive values of pitch is
> specified by an attribute named direction. The value of the direction
> attribute is "clockwise" if positive values of pitch represent the front of
> the platform rising as viewed by an observer on top of the platform facing
> forward. The value of the direction attribute is "anticlockwise" if
> positive values of pitch represent the front of the platform falling. The
> directionality of pitch values is unspecified if no direction attribute is
> present.
>
> platform_yaw: Platform is a structure or vehicle that serves as a base for
> mounting sensors. Platforms include, but are not limited to, satellites,
> aeroplanes, ships, buoys, ground stations, and masts. Yaw is a rotation
> about the local vertical axis (the Z axis). Yaw is relative to the “at
> rest” rotation of the platform with respect to the Z axis. The “at rest”
> rotation of the platform may change over time. The direction for positive
> values of yaw is specified by an attribute named direction. The value of
> the direction attribute is "clockwise" if positive values of yaw represent
> the front of the platform moving to the right as viewed by an observer on
> top of the platform facing forward. The value of the direction attribute is
> "anticlockwise" if positive values of yaw represent the front of the
> platform moving to the left. The directionality of yaw values is
> unspecified if no direction attribute is present.
>
> platform_surge: Platform is a structure or vehicle that serves as a base
> for mounting sensors. Platforms include, but are not limited to,
> satellites, aeroplanes, ships, buoys, ground stations, and masts. Surge is
> a displacement along an 

Re: [CF-metadata] Platform Heave

[Ethan Davis]

Hey Jim,

How about removing one layer of terminology by using your definitions for
the allowed values of "direction":

roll: "positive_right_side_up" and "positive_right_side_down".
pitch: "positive_nose_up" and "positive_nose_down".
yaw: "positive_nose_right" and "positive_nose_left".
surge: "positive_forward" and "positive_backward".
sway: "positive_left" and "positive_right".
heave: "positive_up" and "positive_down".

Cheers,

Ethan

On Wed, Aug 29, 2018 at 12:02 PM Jim Biard  wrote:

> John,
>
> There are a variety of conventions for defining roll, pitch, and yaw out
> there. This is why we are avoiding a specific one. Others have searched
> existing datasets that are using earlier versions of these standard names
> (or not using standard names) and found that they don't all follow the same
> convention.
>
> Ethan,
>
> We purposely aren't answering that question directly because of the issue
> above. I believe that I have consistently followed the convention in which
> clockwise and anticlockwise are rotational directions around a unit vector
> facing the observer, where the X unit vector is in the nominally forward
> direction, the Z axis is in the local up direction, and the Y axis unit
> vector is "Z cross X", which forms a right-handed coordinate system. The
> terms are meaningful and accurate using that convention, but the names
> could be "alpha" and "beta" or "dog" and "cat" as long as they are used
> correctly.
>
> This whole topic is fraught with competing conventions, so we are
> attempting to avoid declaring that only one of them is valid, with it's
> corresponding requirement that everyone follow that one sign convention.
>
> In fact, we could reword things to remove naming the axes X, Y, and Z, and
> perhaps we should. I know of satellite platforms that define their Y axis
> unit vector as pointing forward and the Z axis unit vector as pointing down.
>
> Thoughts?
>
> Grace and peace,
>
> Jim
>
> On 8/29/18 1:32 PM, John Helly wrote:
>
> Perhaps one should refer to the discipline of hydrostatics for help with
> this?  This paper, pulled from a quick search, has a diagram referencing
> the platforms' frame of reference with respect to its center of gravity.
> Sorry if this comment is retrograde.
>
> https://www.hindawi.com/journals/mpe/2010/934714/
>
> J.
>
> On 8/29/18 10:09, Ethan Davis wrote:
>
> Hi Jim, all,
>
> I'm a bit confused by the "clockwise" and "anticlockwise". You mention the
> orientation of the observer but not the location/orientation of the clock.
> My assumptions (not sure why) for the clock: for roll, the observer (who is
> facing forward) would be facing the clock; for pitch, the observer would
> look right to see the clock; and for yaw, the observer would look down to
> see the clock. That works for your definitions of pitch and yaw, but is
> backwards for roll.
>
> Does "clockwise" add, in some way, another degree of freedom to the
> definition? Does that degree of freedom need to be nailed down in the
> definitions? Or other terms used instead? I don't have any good suggestions
> other than "positive" and "negative".
>
> Cheers,
>
> Ethan
>
> On Wed, Aug 29, 2018 at 9:03 AM Jim Biard  wrote:
>
>> Hi.
>>
>>
>> I've finally gotten back to this topic! The definitions below call out an
>> attribute named "direction" that is used to specify the direction for
>> positive values of the different quantities. We may need to add a
>> definition for the attribute to the Conventions. The values and meanings
>> for the direction attribute are:
>>
>> roll: "clockwise" for positive right side up and "anticlockwise" for
>> positive right side down.
>> pitch: "clockwise" for positive nose up and "anticlockwise" for positive
>> nose down.
>> yaw: "clockwise" for positive nose right and "anticlockwise" for positive
>> nose left.
>> surge: "positive" for positive forward and "negative" for positive
>> backward.
>> sway: "positive" for positive left and "negative" for positive right.
>> heave: "positive" for positive up and "negative" for positive down.
>>
>> And here are the standard name definitions:
>>
>> platform_roll: Platform is a structure or vehicle that serves as a base
>> for mounting sensors. Platforms include, but are not limited to,
>> satellites, aeroplanes, s

Re: [CF-metadata] Units of projection_x_coordinate values in "Geospatial projection"

[Ethan Davis]

Hi Randy,

This projection was added to CF with Trac #72
<https://cf-pcmdi.llnl.gov/trac/ticket/72>. There's some discussion around
the x,y coordinates. I think comment 12
<https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:12> from John Caron
addresses the issue of using radians instead of meters:

"Ideally they would be something like "km on the projection plane", but
then (I think) you need scaling factors that depend on the instrument. If
you include the scaling factors into the coordinates, then you have (I
guess) radians."


Cheers,

Ethan

On Tue, Apr 10, 2018 at 8:09 AM, Randy Horne <rho...@excaliburlabs.com>
wrote:

> Ethan:
>
> What you suggest is fine.
>
> As an aside ….
> If you look at the CF standard name table, the canonical units for
> standard name “ projection_x_coordinate” and “projection_y_coordinate” are
> meters (not radians).
>
> The GOES-R designers (specifically me) inadvertently used these two
> standard names, not realizing they should NOT have used them because a
> standard name can not have two different canonical units.
>
> Now, because the GOES-R system is already operational and in use, it would
> be major rework for GOES-R to use a yet to be defined standard name (such
> as projection_x_angilar_coordinate and projection_y_angular_coordinate).
>
>
> Not sure what to d about this ….
>
>
>
> v/r
>
> randy
>
>
>
> On Apr 9, 2018, at 3:54 PM, Ethan Davis <eda...@ucar.edu> wrote:
>
> Hi all,
>
> The "Geostationary projection" section of Appendix F "Grid Mappings" says
>
> The x (abscissa) and y (ordinate) rectangular coordinates are identified
> by the standard_name attribute values projection_x_coordinate and
> projection_y_coordinate respectively. In the case of this projection, the
> projection coordinates in this projection are directly related to the
> scanning angle of the satellite instrument, and their units are radians.
>
>
> To more explicitly fit CF expectations for units of variables with a
> standard_name attribute, I believe the last bit should read:
>
> ... and their *canonical* units are radians.
>
>
> This came up because the GOES-16 Full Disk data (example below [1]) is
> stored with the projection_{x|y}_coordinate values in microradians and, it
> turns out, the netCDF-Java code didn't like that as it expected radians.
> (Oops!)
>
> Unless anyone disagrees, I will open a CF Trac ticket for this change
> later this week.
>
> Thanks,
>
> Ethan
>
> [1]
> http://thredds-test.unidata.ucar.edu/thredds/dodsC/
> satellite/goes16/GOES16/FullDisk/Channel08/20180406/
> GOES16_FullDisk_20180406_201540_6.19_6km_0.0S_75.0W.nc4.html
>
> netcdf GOES16_FullDisk_20180406_201540_6.19_6km_0.0S_75.0W {
> dimensions:
> x = 1808 ;
> y = 1808 ;
> variables:
> int time ;
> time:units = "seconds since 2017-01-01" ;
> time:standard_name = "time" ;
> time:long_name = "The start date / time that the satellite began capturing
> the scene" ;
> time:axis = "T" ;
> time:calendar = "standard" ;
> short y(y) ;
> y:standard_name = "projection_y_coordinate" ;
> y:units = "microradian" ;
> y:scale_factor = -167.9971 ;
> y:add_offset = 151788. ;
> short x(x) ;
> x:standard_name = "projection_x_coordinate" ;
> x:units = "microradian" ;
> x:scale_factor = 167.9971 ;
> x:add_offset = -151788. ;
> int fixedgrid_projection ;
> fixedgrid_projection:grid_mapping_name = "geostationary" ;
> fixedgrid_projection:latitude_of_projection_origin = 0. ;
> fixedgrid_projection:longitude_of_projection_origin = -75. ;
> fixedgrid_projection:semi_major = 6378137. ;
> fixedgrid_projection:semi_major_axis = 6378137. ;
> fixedgrid_projection:semi_minor = 6356752.31414 ;
> fixedgrid_projection:semi_minor_axis = 6356752.31414 ;
> fixedgrid_projection:perspective_point_height = 35785831. ;
> fixedgrid_projection:sweep_angle_axis = "x" ;
> short Sectorized_CMI(y, x) ;
> Sectorized_CMI:_FillValue = 0s ;
> Sectorized_CMI:standard_name = "brightness_temperature" ;
> Sectorized_CMI:units = "kelvin" ;
> Sectorized_CMI:grid_mapping = "fixedgrid_projection" ;
> Sectorized_CMI:add_offset = 138.05f ;
> Sectorized_CMI:scale_factor = 0.04224986f ;
> Sectorized_CMI:valid_min = 0s ;
> Sectorized_CMI:valid_max = 4095s ;
> Sectorized_CMI:coordinates = "time y x" ;
>
> // global attributes:
> :title = "Sectorized Cloud and Moisture Imagery for the EFD region." ;
> :ICD_version = "GROUND SEGMENT (GS) TO ADVANCED WEATHER INTERACTIVE
> PROCESSING SYSTEM (AWIPS) INTE

Re: [CF-metadata] Units of projection_x_coordinate values in "Geospatial projection"

[Ethan Davis]

Hi Jonathan,

Yes, the change of units is unfortunate. However, there are now operational
platforms generating data using this projection as it stands. It will be
years (if ever) before a change like this would propagate through those
operational systems.

This means software would have to support two variants and I am very
hesitant to move in that direction.

There is much discussion in Trac #72 comments 12
<https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:12>, 13
<https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:13>, 14
<https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:14> on the whys and
wherefores around the transformation between radians and meters for these
coordinates. I wonder if there is an alternate path forward that would
allow us to keep projection_{x|y}_coordinate for this projection. Maybe add
(a very brief) discussion of how radians maps in this case to linear
distance. Not perfect but perhaps better than the alternative.

Cheers,

Ethan


On Tue, Apr 10, 2018 at 11:30 AM, Jonathan Gregory <
j.m.greg...@reading.ac.uk> wrote:

> Dear all
>
> Metres and radians are not interconvertible, so projection_[xy]_coordinate
> should not be used as a standard name for a quantity in radians. I think
> that
> a defect ticket is needed to change App F for this projection. Possibly we
> might need new standard names if there aren't appropriate ones.
>
> Best wishes
>
> Jonathan
>
>
> - Forwarded message from Jim Biard <jbi...@cicsnc.org> -
>
> > Date: Tue, 10 Apr 2018 12:32:00 -0400
> > From: Jim Biard <jbi...@cicsnc.org>
> > To: CF metadata <cf-metadata@cgd.ucar.edu>
> > Subject: Re: [CF-metadata] Units of projection_x_coordinate values in
> >   "Geospatial projection"
> >
> > Hi.
> >
> > It sounds like perhaps we should avoid the word "canonical". Perhaps we
> > should change the relevant bit of the definition to read
> >
> > The x (abscissa) and y (ordinate) rectangular coordinates are identified
> by
> > the standard_name attribute values projection_x_coordinate and
> > projection_y_coordinate respectively. In the case of this projection, the
> > projection coordinates in this projection are directly related to the
> > scanning angle of the satellite instrument - typically an angular
> quantity.
> >
> >
> > Software shouldn't assume the units. Microradians, degrees, grads, etc
> > should all be fine. Does anyone think there is a problem with storing an
> > angle in a variable with the standard name projection_x_coordinate? Do we
> > need different standard names for these?
> >
> > This may indicate that projections that have specific requirements about
> > units in the coordinates need to declare that information in the
> > grid_mapping variable attributes. We tend to gloss over that, but there
> are
> > projections that expect the coordinates to be latitude and longitude
> > instead of x and y. In addition, spherical or cylindrical coordinate
> > systems would expect at least one coordinate to be angular. Thoughts?
> >
> > Grace and peace,
> >
> > Jim
> >
> > [image: CICS-NC] <http://www.cicsnc.org/>Visit us on
> > Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
> > *Research Scholar*
> > Cooperative Institute for Climate and Satellites NC  <http://cicsnc.org/
> >
> > North Carolina State University  <http://ncsu.edu/>
> > NOAA National Centers for Environmental Information  <
> http://ncdc.noaa.gov/>
> > *formerly NOAA’s National Climatic Data Center*
> > 151 Patton Ave, Asheville, NC 28801
> > e: jbi...@cicsnc.org
> > o: +1 828 271 4900
> >
> > *Connect with us on Facebook for climate
> > <http://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
> > <http://www.facebook.com/NOAANCEIoceangeo> information, and follow us on
> > Twitter at @NOAANCEIclimate
> > <http://www.twitter.com/NOAANCEIclimate>and @NOAANCEIocngeo
> > <http://www.twitter.com/NOAANCEIocngeo>.*
> >
> >
> > On Tue, Apr 10, 2018 at 10:09 AM, Randy Horne <rho...@excaliburlabs.com>
> > wrote:
> >
> > > Ethan:
> > >
> > > What you suggest is fine.
> > >
> > > As an aside ….
> > > If you look at the CF standard name table, the canonical units for
> > > standard name “ projection_x_coordinate” and “projection_y_coordinate”
> are
> > > meters (not radians).
> > >
> > > The GOES-R designers (specifically me) inadvertently used these two
> > > standard names, not realizing they should NOT have used them 

[CF-metadata] Units of projection_x_coordinate values in "Geospatial projection"

[Ethan Davis]

Hi all,

The "Geostationary projection" section of Appendix F "Grid Mappings" says

The x (abscissa) and y (ordinate) rectangular coordinates are identified by
the standard_name attribute values projection_x_coordinate and
projection_y_coordinate respectively. In the case of this projection, the
projection coordinates in this projection are directly related to the
scanning angle of the satellite instrument, and their units are radians.


To more explicitly fit CF expectations for units of variables with a
standard_name attribute, I believe the last bit should read:

... and their *canonical* units are radians.


This came up because the GOES-16 Full Disk data (example below [1]) is
stored with the projection_{x|y}_coordinate values in microradians and, it
turns out, the netCDF-Java code didn't like that as it expected radians.
(Oops!)

Unless anyone disagrees, I will open a CF Trac ticket for this change later
this week.

Thanks,

Ethan

[1]
http://thredds-test.unidata.ucar.edu/thredds/dodsC/satellite/goes16/GOES16/FullDisk/Channel08/20180406/GOES16_FullDisk_20180406_201540_6.19_6km_0.0S_75.0W.nc4.html

netcdf GOES16_FullDisk_20180406_201540_6.19_6km_0.0S_75.0W {

dimensions:

x = 1808 ;

y = 1808 ;

variables:

int time ;

time:units = "seconds since 2017-01-01" ;

time:standard_name = "time" ;

time:long_name = "The start date / time that the satellite began capturing
the scene" ;

time:axis = "T" ;

time:calendar = "standard" ;

short y(y) ;

y:standard_name = "projection_y_coordinate" ;

y:units = "microradian" ;

y:scale_factor = -167.9971 ;

y:add_offset = 151788. ;

short x(x) ;

x:standard_name = "projection_x_coordinate" ;

x:units = "microradian" ;

x:scale_factor = 167.9971 ;

x:add_offset = -151788. ;

int fixedgrid_projection ;

fixedgrid_projection:grid_mapping_name = "geostationary" ;

fixedgrid_projection:latitude_of_projection_origin = 0. ;

fixedgrid_projection:longitude_of_projection_origin = -75. ;

fixedgrid_projection:semi_major = 6378137. ;

fixedgrid_projection:semi_major_axis = 6378137. ;

fixedgrid_projection:semi_minor = 6356752.31414 ;

fixedgrid_projection:semi_minor_axis = 6356752.31414 ;

fixedgrid_projection:perspective_point_height = 35785831. ;

fixedgrid_projection:sweep_angle_axis = "x" ;

short Sectorized_CMI(y, x) ;

Sectorized_CMI:_FillValue = 0s ;

Sectorized_CMI:standard_name = "brightness_temperature" ;

Sectorized_CMI:units = "kelvin" ;

Sectorized_CMI:grid_mapping = "fixedgrid_projection" ;

Sectorized_CMI:add_offset = 138.05f ;

Sectorized_CMI:scale_factor = 0.04224986f ;

Sectorized_CMI:valid_min = 0s ;

Sectorized_CMI:valid_max = 4095s ;

Sectorized_CMI:coordinates = "time y x" ;


// global attributes:

:title = "Sectorized Cloud and Moisture Imagery for the EFD region." ;

:ICD_version = "GROUND SEGMENT (GS) TO ADVANCED WEATHER INTERACTIVE
PROCESSING SYSTEM (AWIPS) INTERFACE CONTROL DOCUMENT (ICD) Revision B" ;

:Conventions = "CF-1.6" ;

:channel_id = 8 ;

:central_wavelength = 6.19f ;

:abi_mode = 3 ;

:source_scene = "FullDisk" ;

:periodicity = 15.f ;

:production_location = "RBU" ;

:product_name = "EFD-060-B12-M3C08" ;

:satellite_id = "GOES-16" ;

:product_center_latitude = 0. ;

:product_center_longitude = -75. ;

:projection = "Fixed Grid" ;

:bit_depth = 12 ;

:source_spatial_resolution = 2.f ;

:request_spatial_resolution = 6.f ;

:start_date_time = "2018096201540" ;

:number_product_tiles = 4 ;

:product_tile_width = 1024 ;

:product_tile_height = 1024 ;

:product_rows = 1808 ;

:product_columns = 1808 ;

:pixel_x_size = 6. ;

:pixel_y_size = 6. ;

:satellite_latitude = 0. ;

:satellite_longitude = -75. ;

:satellite_altitude = 35785831. ;

:created_by = "ldm-alchemy" ;

:product_tiles_received = 4 ;

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

Re: [CF-metadata] Units of projection_x_coordinate values in "Geospatial projection"

[Ethan Davis]

 If the
>
> > > coordinates are truly in radians, I think the right solution is to
> define a new
>
> > standard name and change App F.
>
> > >
>
> > > However, I realise that you need some workrounds to use during the
>
> > > (possibly
>
> > > infinite) time before this change is thoroughly implemented, and for
>
> > > archived data. Would it be practical to patch the software that
>
> > > processes this data so that it doesn't object to the erroneous units?
>
> > > If a conversion can be done between m and rad by making some standard
>
> > > assumption about distances, then you could relabel the existing
>
> > > numbers, which are actually in microradians, with units="m" and a
>
> > > scale_factor, or which units="X m", where X is the scale factor, so
> that the
>
> > numbers themselves don't have to be changed.
>
> > >
>
> > > Best wishes
>
> > >
>
> > > Jonathan
>
> > >
>
> > > - Forwarded message from Ethan Davis <eda...@ucar.edu eda...@ucar.edu>> -
>
> > >
>
> > >> Date: Tue, 10 Apr 2018 11:59:55 -0600
>
> > >> From: Ethan Davis <eda...@ucar.edu<mailto:eda...@ucar.edu>>
>
> > >> To: Jonathan Gregory <j.m.greg...@reading.ac.uk j.m.greg...@reading.ac.uk>>
>
> > >> Cc: CF metadata <cf-metadata@cgd.ucar.edu cf-metadata@cgd.ucar.edu>>
>
> > >> Subject: Re: [CF-metadata] Units of projection_x_coordinate values in
>
> > >>   "Geospatial projection"
>
> > >>
>
> > >> Hi Jonathan,
>
> > >>
>
> > >> Yes, the change of units is unfortunate. However, there are now
>
> > >> operational platforms generating data using this projection as it
>
> > >> stands. It will be years (if ever) before a change like this would
>
> > >> propagate through those operational systems.
>
> > >>
>
> > >> This means software would have to support two variants and I am very
>
> > >> hesitant to move in that direction.
>
> > >>
>
> > >> There is much discussion in Trac #72 comments 12
>
> > >> <https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:12>, 13
>
> > >> <https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:13>, 14
>
> > >> <https://cf-pcmdi.llnl.gov/trac/ticket/72#comment:14> on the whys and
>
> > >> wherefores around the transformation between radians and meters for
>
> > >> these coordinates. I wonder if there is an alternate path forward
>
> > >> that would allow us to keep projection_{x|y}_coordinate for this
>
> > >> projection. Maybe add (a very brief) discussion of how radians maps
>
> > >> in this case to linear distance. Not perfect but perhaps better than
> the
>
> > alternative.
>
> > >>
>
> > >> Cheers,
>
> > >>
>
> > >> Ethan
>
> > >>
>
> > >>
>
> > >> On Tue, Apr 10, 2018 at 11:30 AM, Jonathan Gregory <
>
> > >> j.m.greg...@reading.ac.uk<mailto:j.m.greg...@reading.ac.uk>> wrote:
>
> > >>
>
> > >>> Dear all
>
> > >>>
>
> > >>> Metres and radians are not interconvertible, so
>
> > >>> projection_[xy]_coordinate should not be used as a standard name for
>
> > >>> a quantity in radians. I think that a defect ticket is needed to
>
> > >>> change App F for this projection. Possibly we might need new
>
> > >>> standard names if there aren't appropriate ones.
>
> > >>>
>
> > >>> Best wishes
>
> > >>>
>
> > >>> Jonathan
>
> > >>>
>
> > >>>
>
> > >>> - Forwarded message from Jim Biard <jbi...@cicsnc.org jbi...@cicsnc.org>> -
>
> > >>>
>
> > >>>> Date: Tue, 10 Apr 2018 12:32:00 -0400
>
> > >>>> From: Jim Biard <jbi...@cicsnc.org<mailto:jbi...@cicsnc.org>>
>
> > >>>> To: CF metadata <cf-metadata@cgd.ucar.edu cf-metadata@cgd.ucar.edu>>
>
> > >>>> Subject: Re: [CF-metadata] Units of projection_x_coordinate values
> in
>
> > >>>>  "Geospatial projection"
>
> > >>>>
>
> > >>>> Hi.
>
> > >>>&

[CF-metadata] Save The Date! 2018 netCDF-CF Workshop, 19-20 June 2018, Reading, UK

[Ethan Davis]

Hi all,

Please save the date for the 2018 netCDF-CF Workshop, it will be on 19-20
June 2018 at the University of Reading in the UK.

More information will be coming soon.

Thanks,

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

[CF-metadata] Save-the-Date for 2019 CF Workshop

[Ethan Davis]

Hi all,

We will hold a 2019 CF Workshop during the week of 15 July 2019. It will be
held as a series of sessions within the ESIP Summer Meeting [1] in Tacoma,
WA (about 40 miles south of Seattle). We are looking at a day long meeting
(probably spread across two half days) but don’t have the exact schedule
yet. Remote participation will be available. More detailed plans will be
coming soon.

Topics from previous meetings have included:

   - The CF Data Model
   - DOIs for CF
   - External variables
   - Groups
   - Strings
   - Satellite Swath Data
   - Geometries
   - CfRadial
   - Linked Data  with netCDF
   - Reporting Uncertainty

If you have any suggestions for session or breakout topics, please send
them along.

Thank you,

The Organizing Committee

[1] https://2019esipsummermeeting.sched.com/info
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[CF-metadata] CF Workshop in July

[Ethan Davis]

Hi all,

The CF Workshop to be held in Tacoma, WA (south of Seattle) in July will
start in the late afternoon on 16 July (Tuesday) and continue most of the
day of 17 July (Wednesday). Here's the session schedule (Seattle time - US
Pacific) and the current rough plan for the agenda:

Tuesday, 16 July

   -

   16:30 - 18:00 (16 July) - Kick-off, Introductions, Review discussions
   and decisions from last year (session info
   

   )

Wednesday, 17 July

   -

   08:30 - 10:00 (17 July) - Discussion of CF Governance and Process (session
   info
   

   )
   -

   10:30 - 12:00 (17 July) - Update on recent and current proposed changes
   to CF (session info
   

   )
   -

   13:30 - 15:00 (17 July) - Other recent topics; wrap-up and next
steps (session
   info
   

   )


As I mentioned in the Save-the-Date email, the workshop is part of the ESIP
Summer Meeting. If you plan to attend in person, you can find registration
and hotel information on the ESIP meeting page
 (early registration ends 10
June). The ESIP meeting is Tuesday through Friday and there are other
sessions related to CF and that may be of interest. So please review the
ESIP schedule  before deciding on
travel dates.

Two closely related sessions immediately proceed the CF Workshop:

   -

   12:45 - 14:15 (16 July) - Data Product Developer's’ Guide session
   

   developed by a NASA working group
   -

   14:45 - 16:15 (16 July) - NetCDF and CF: The Basics session
   


For those that can’t attend in person, there will be support for remote
participation (GoToMeeting I believe).

More details on the agenda will follow and be posted on the session pages
(see links above).

Thank you,

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

[CF-metadata] CF Workshop - remote participation

[Ethan Davis]

Hi all,

Remote participation information is in the individual session pages:

Session 1 (in about 3 hours)

   -
   https://2019esipsummermeeting.sched.com/event/PtPD/netcdf-cf-workshop-part-i

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