Re: [CF-metadata] proposed migration of these discussions to GitHub

Jonathan & List, I strongly agree with this new approach as well. Technical discussions in email are very hard to track, and I believe many people who might be contributors don't engage for this reason. I think discussion in Github issues will accelerate our progress. Thanks for doing this,

Re: [CF-metadata] Add new integer types to CF?

Evan, On Fri, Sep 22, 2017 at 1:36 PM, Manning, Evan M (398B) wrote: > I think the _Unsigned attribute would have been a grand idea before. > > But if we’re now allowing explicit unsigned types, what purpose does it serve? The purpose would be to allow NetCDF3 files

Re: [CF-metadata] Add new integer types to CF?

instead make > _Unsigned the preferred workaround for file formats > that do not support unsigned types. > Unless people want to require _both_ > _Unsigned and valid_* (seems burdensome to me), > or allow either _Unsigned or valid_* (seems > crufty to me). What do others think? &g

Re: [CF-metadata] Add new integer types to CF?

lookin at the NUG, how about saying: In file types that don't offer native support for unsigned types, integer or byte variables that are to be interpreted as unsigned must have the attribute _Unsigned = "true". On Fri, Sep 22, 2017 at 1:10 AM, Chris Barker wrote: >

Re: [CF-metadata] Best representation of wire-crawling profiler

example > that, like H.5., gets explicitly documented in the next CF version. > - Steve > > ========== > > > On 2/28/2017 11:18 AM, Signell, Richard wrote: > > CF Folks, > > Okay, with help from the ERDDAP community >

Re: [CF-metadata] Best representation of wire-crawling profiler

tions/cf-conventions.html#_ragged_array_ representation_of_time_series_profiles So in addition to "precise_time(obs)" we would also have data variables like "temperature(obs)". Thanks, Rich On Tue, Feb 28, 2017 at 7:27 AM, Signell, Richard <rsign...@usgs.gov> wrote: > CF

[CF-metadata] (no subject)

CF Folks, What would be the best DSG featureType to represent a wire-crawling sensor that has a fixed lon,lat location, but non-uniform depth interval as it goes up and down, and takes enough time that the profile might not be accurately represented with a single time value? On this ERDDAP site

[CF-metadata] Discussion of technical CF issues as GitHub issues?

I was trying to catch up on "Pre-proposal for charset" conversation and found it extremely challenging to ferret out the technical thread of discussion from the numerous email threads, further obfuscated due to mishmash of top posting, in line postings and quoted previous emails. I couldn't

Re: [CF-metadata] Proposed standard_name for river discharge

Dave, Do you think we should also introduce other water_volume_transport quantities together to make this clear? water_volume_transport_in_river_channel water_volume_transport_over_land water_volume_transport_in_??? -Rich On Tue, May 3, 2016 at 10:14 AM, David Blodgett

[CF-metadata] Proposed standard_name for river discharge

CF folks, There are a bunch of hydrology standard_names, but none that seem appropriate for one of the most common quantities, plain old "river discharge". We currently have "water_volume_transport_into_sea_water_from_rivers" with the right units "m3/s", but in the CF Standard Name list, but

[CF-metadata] Can trajectory data without data variables be CF-compliant?

Some ocean drifters record only position and time information, with no additional sensor information. So just (lon,lat, time) and no (salinity, temp, etc). Can files with only coordinate variables be CF-compliant? It's not clear from the DSG information in the Conventions doc -- it doesn't seem

Re: [CF-metadata] Practical Salinity units

I like the simpler version that John made, and Rich Pawlowicz reported back to me that both versions are acceptable to him, so Nan, do you think we could resolve the issue you have with John's version? If so, perhaps we could put this one to bed! On Fri, Jun 12, 2015 at 3:11 PM, Nan Galbraith

Re: [CF-metadata] Roms: ocean_s_coordinate_g1 and g2?

Heiko, Back in January the pull request to add these two coordinates was merged into the CF 1.7 document xml files: https://github.com/cf-convention/cf-convention.github.io/pull/33 But those changes didn't show up in the CF 1.7 web page:

Re: [CF-metadata] Salinity units

as possible. On May 26, 2015, at 8:48 AM, Signell, Richard rsign...@usgs.gov wrote: Rich, Thanks for this. Yes, I guess my concern is that folks will do a catalog search for *salinity* variables, and with a few spot checks, see that they are have data values in the range of 29-36 or so

Re: [CF-metadata] Salinity units

different units. Rich. On May 22, 2015, at 1:01 PM, Signell, Richard rsign...@usgs.gov wrote: Roy, For sure dimensionless. But 1.0, 0.001 or g/kg? The latest version (27) of the CF Standard Name list (http://cfconventions.org/Data/cf-standard-names/27/build/cf-standard-name-table.html) states

Re: [CF-metadata] Salinity units

Roy, For sure dimensionless. But 1.0, 0.001 or g/kg? The latest version (27) of the CF Standard Name list (http://cfconventions.org/Data/cf-standard-names/27/build/cf-standard-name-table.html) states: sea_water_salinity: 0.001 sea_water_absolute_salinity: g kg-1 sea_water_practical_salinity:

Re: [CF-metadata] Applying multiple conventions

can't see any reason why unidata chooses to promote 2 versions of this, except maybe for profiles, in which some of the requirements of a convention are dropped, or assumed to have default values, and not required by the profile. Cheers - Nan On 3/13/15 1:59 PM, Signell, Richard wrote

Re: [CF-metadata] Applying multiple conventions

David, I looked at this a bit and I'm not sure that http://cf-trac.llnl.gov/trac/ticket/76 actually captures this need, as UGRID is intended to *extend* CF, rather than a stand-alone alternative. For situations like CF and UGRID, which *extends* CF, it would appear from this guidance

Re: [CF-metadata] Editing/publishing workflow update

Jonathan, You requested to hear more opinions about the provisional status issue. I think the highlighting of text as provisiona should be eliminated for all the reasons that John Graybeal mentioned. It just creates confusion. If there is a feeling that newly proposed standards need more

Re: [CF-metadata] Proposals for Versioning CF Conventions and Standard Names on Github

Jonathan, I think that the difficulty in updating the document is not that we have inconvenient software for doing and facilitating it. It is the intellectual difficulty of working out what the changes should be that makes the process slow. When we have agreed a ticket, enacting it in the doc

Re: [CF-metadata] Proposals for Versioning CF Conventions and Standard Names on Github

Back in mid-March we had a long discussion on this topic, initiated when Richard Hattersley presented a model of what CF could look like on github using restructured text and github style versioning. His mock-up is still at https://cf-conventions.readthedocs.org/en/v1.6/ In the conversation

Re: [CF-metadata] Proposals for Versioning CF Conventions and Standard Names on Github

Jonathan, I wonder if we might have a webinar to demonstrate/talk about the concepts we envision here. We've done a lot of typing, but I get with 30 min together online I bet we could end up with consensus. -Rich On Tue, Sep 23, 2014 at 12:16 PM, Jonathan Gregory j.m.greg...@reading.ac.uk wrote:

Re: [CF-metadata] Time series related to a polygonal region and cell_bounds

. Grace and peace, Jim On 9/19/14, 5:43 PM, Signell, Richard wrote: Jim, Awesome. And I guess if we save it as netcdf4 with deflation, it doesn't really matter how large we make the maximum number of vertices because all those fillValues at the end will compress very well. I'm still

[CF-metadata] Proposals for Versioning CF Conventions and Standard Names on Github

CF Folks, One of the reasons for moving the CF Conventions and Standard Names to Github was so that the community could help support CF development. The github fork/branch/pull-request process allows contributors to submit changes that can be discussed, modified, discussed some more and then

Re: [CF-metadata] Proposals for Versioning CF Conventions and Standard Names on Github

Does this mean the current CF source is docbook xml? https://github.com/cf-convention/repository-cf/tree/master/cf-conventions/trunk/docbooksrc On Mon, Sep 22, 2014 at 3:22 PM, Chris Barker chris.bar...@noaa.gov wrote: On Mon, Sep 22, 2014 at 9:45 AM, Christopher Duncombe Rae - NOAA Affiliate

Re: [CF-metadata] Proposals for Versioning CF Conventions and Standard Names on Github

Since CF conventions are already moved to github, I'd be in favor of migrating the trac tickets to github as well: https://github.com/trustmaster/trac2github/blob/master/README all we would have to do is make sure that the trac users sign up for github and get their usernames so we could do the

[CF-metadata] Time series related to a polygonal region and cell_bounds

Folks, A colleague asked me if a time series of data associated with a polygonal region (e.g. rainfall in a watershed) could be represented in CF. So two questions: 1. Any reason this could be represented as a simple time series with a cell_bounds = lon_verts, lat_verts lon_verts(npoly_verts),

Re: [CF-metadata] Time series related to a polygonal region and cell_bounds

; watershed_areas.units = km2; I have left lots of attributes out. I hope this helps. Grace and peace, Jim On 9/19/14, 4:09 PM, Signell, Richard wrote: Folks, A colleague asked me if a time series of data associated with a polygonal region (e.g. rainfall in a watershed) could

[CF-metadata] Why surface_altitude instead of platform_altitude?

In the CF-1.6 and CF-1.7 draft doc, in section H.2, we have: It is recommended that there should be station variables with standard_name attributes platform_name , surface_altitude and “ platform_id ” when applicable. Why is this surface_altitude instead of platform_altitude? In the ocean,

Re: [CF-metadata] Why surface_altitude instead of platform_altitude?

to the standard. John On Sep 18, 2014, at 06:40, Signell, Richard rsign...@usgs.gov wrote: In the CF-1.6 and CF-1.7 draft doc, in section H.2, we have: It is recommended that there should be station variables with standard_name attributes platform_name , surface_altitude and “ platform_id

Re: [CF-metadata] Why surface_altitude instead of platform_altitude?

: I assume surface_altitude is an important variable for providing the vertical location of measurements relative to a surface (as opposed to relative to a geoid -- notwithstanding the definition issue). John On Sep 18, 2014, at 08:30, Signell, Richard rsign...@usgs.gov wrote: Maybe

Re: [CF-metadata] How to help correct problems with CF documents on github

On Apr 16, 2014, at 05:49, Nan Galbraithngalbra...@whoi.edu wrote: Hi Rich - There's a trac ticket for problems with the new website: http://kitt.llnl.gov/trac/ticket/111 For other types of problems, not related to the site itself, I'm not sure. Nan On 4/16/14 7:47 AM, Signell, Richard

[CF-metadata] How to help correct problems with CF documents on github

CF folks, Moving to github should help the community contribute and be able to fix problem with the CF documents. But I'm a little confused about what to do if we see a problem at http://cf-convention.github.io/ and we want to submit a pull request to change them. At the CF github organization

[CF-metadata] Where does the CF standard name list live now?

Where does the CF standard name list live now? It doesn't seem to be at the location http://cf-convention.github.io/standard-names.html linked from http://cf-convention.github.io/ -- Dr. Richard P. Signell (508) 457-2229 USGS, 384 Woods Hole Rd. Woods Hole, MA 02543-1598

Re: [CF-metadata] Editing/publishing workflow

Richard, I think moving to github would be a huge improvement. The git model and the tools that github provides would make it much easier for other folks to propose changes, and for those changes to be reviewed, discussed and merged.I think Brian and a few others were also in favor when we

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

Although we've got plenty of food for thought already, here's an extra helping: How ESRI (arguably the largest purveyor of geospatial software, e.g. 10,000 users at their annual conference) handles vertical datums: http://resources.arcgis.com/en/help/main/10.1/index.html#//003r001500

Re: [CF-metadata] How to handle a forecast model with non-monotonic coordinate variables

Jonathan, In the very last comment in ticket #85 (https://cf-pcmdi.llnl.gov/trac/ticket/85) you say: In the Description column of Appendix A, in the entries for _FillValue andmissing_value, replace Not allowed for coordinate data except in the case of auxiliary coordinate varibles in discrete

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

It looks like the OGC Met-Ocean Domain Working Group has also been thinking about this: http://external.opengeospatial.org/twiki_public/MetOceanDWG/MetOceanWMSBP20120206 This doc is two years old, so I'll ask Jeff DLB if he can summarize for the list what they came up with. -Rich -R On Mon,

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

Jonathan, Thanks for the detailed explanation (and analogy) of why it's useful to tack on the _above_geoid or _above_ellipsoid or _above_tidal_datum to the standard-name. So we do that and then specify the geoid, ellipsoid or tidal datum elsewhere in the grid_mapping variable, right? geoid:

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

-metadata-boun...@cgd.ucar.edu] on behalf of Signell, Richard [rsign...@usgs.gov] Sent: 04 February 2014 11:47 To: CF metadata Subject: [CF-metadata] Vertical datums (again) CF folks, On a telecon yesterday with a coastal inundation modeling group, one of the PIs asked me how to handle vertical

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

of model data), but we could make it possible if that's useful. Is NAVD88 not a geoid name in your example? Best wishes Jonathan - Forwarded message from Signell, Richard rsign...@usgs.gov - On a telecon yesterday with a coastal inundation modeling group, one of the PIs asked me

Re: [CF-metadata] Can we please close ticket 93 and modify the latest CF document accordingly?

Jonathan, The good thing about the git pull request method of updating CF-conventions would be that someone can fork the repository (make their own copy of the document, in this case), make the edits related to their issue, and then submit a pull request to the person with authority to update the

Re: [CF-metadata] Can we please close ticket 93 and modify the latest CF document accordingly?

without a new version of CF, it can be assumed that ticket 93 (and all the other concluded ones) will be part of CF 1.7. Software developers can act on that assumption. Cheers Jonathan - Forwarded message from Signell, Richard rsign...@usgs.gov - Date: Thu, 12 Sep 2013 13:59:39

Re: [CF-metadata] Towards recognizing and exploiting hierarchical groups (Charlie Zender - Steve Hankin - Richard Signell)

All, I'm glad we are discussing this topic, but the fact that large data providers are already distributing data using groups and hierarchies is not a compelling reason to endorse this practice through CF. After all, a lot of data providers are currently distributing scientific data in any

Re: [CF-metadata] Towards recognizing and exploiting hierarchical groups

Charlie Co, Also, regardless of whether these hierarchical structures are stored in NetCDF4 or flattened NetCDF3, we get a big boost in interoperability when we write datasets with known featureTypes (profile, time series collection, swath, etc), because then workflows that have performed a

[CF-metadata] Can we please close ticket 93 and modify the latest CF document accordingly?

CF Folks, The Iris project would like to add support for the ocean_s_coordinate_g1 and ocean_s_coordinate_g2 coordinate that was described in this enhancement ticket for CF 1.7: https://cf-pcmdi.llnl.gov/trac/ticket/93 The last comment in this ticket is 11 months ago by Jonathan Gregory saying

Re: [CF-metadata] use of _FillValue vs valid_range, and minimum and maximum variable attributes

Seth, On Wed, May 22, 2013 at 5:04 PM, Seth McGinnis mcgin...@ucar.edu wrote: Hi Ellyn, According to CF Trac Ticket #31 (slated for inclusion in the update to CF 1.7), the way to cache minimum maximum values in metadata is to use an attribute named actual_range and store them as a pair.

Re: [CF-metadata] use of _FillValue vs valid_range, and minimum and maximum variable attributes

Seth, On Thu, May 23, 2013 at 9:51 AM, Seth McGinnis mcgin...@ucar.edu wrote: Computing the min max on the fly is cheap, and approximating it is even cheaper, so why introduce the uncertainty? ... but computing min max on the fly can also be very expensive. We have aggregated model output

Re: [CF-metadata] inclusion of GridSpec in CF?

I will pass this along to the UGRID google group also. -Rich On Mon, Nov 26, 2012 at 12:46 PM, Alexander Pletzer plet...@txcorp.com wrote: Hi Jonathan, Let me review this again. I will get back to you next week. --Alex On 11/26/2012 10:02 AM, Jonathan Gregory wrote: Dear Alex Would