CF Standard Name folks,
To support the addition of two new dimensionless vertical coordinate
specifications for s coordinate ocean models (CF ticket 93)
(https://cf-pcmdi.llnl.gov/trac/ticket/93), I would like to propose
the addition of their standard_names to the CF standard_name list:
"ocean_s
Heiko,
We worked with John Caron several years ago to get these into the CDM
in the NetCDF-Java library, so if you have g1 or g2 coordinates they
will work with codes that use NetCDF-java (like the Matlab NCTOOLBOX
and Unidata's IDV), and I remember we drafted up some documentation
to submit to
1:50 PM, Steve Hankin wrote:
>
>
> On 3/29/2012 10:11 AM, Rich Signell wrote:
>
> Folks,
>
> I'm confused now. Are we proposing that we could have CF-compliant
> files that have no valid coordinate data, with the justification that
> somebody may figure the coord
t; My concern is that we shouldnt make a file "non CF compliant" just because
>> the data provider would like to store data values where there arent
>> coordinate values. But telling them that standard software _will_ ignore
>> them seems good.
>>
>>
>>
Jonathan,
+1 on your idea of only identifying variables as aux coordinate
variables once they have valid values at valid data locations.
-Rich
On Thu, Mar 29, 2012 at 11:32 AM, Jonathan Gregory
wrote:
> Dear Jim
>
> We are discussing auxiliary coordinate variables. They do not have to be
> 1D
Folks,
There certainly are a fair number of "grid" featureTypes that also
would benefit from FillValues being allowed on aux coordinate
variables.
Consider this NOAA coastal ocean model grid for Chesapeake Bay:
http://screencast.com/t/Humzu7F69
and a zoom in on one of the tributaries:
http://scree
Minor note: The "official" GMT documentation for this is at:
http://gmt.soest.hawaii.edu/gmt/html/GMT_Docs.html#x1-224000K.3
On Tue, Nov 29, 2011 at 1:20 PM, Russ Rew wrote:
>
>> Is there a way to store outline information in NetCDF/CF? =
>>
>>
>> I am looking for a way to store e.g. glacier outl
http://www.unidata.ucar.edu/staff/caron/public/CFch9-may10.pdf
On Tue, Nov 29, 2011 at 7:15 AM, Jonathan Gregory wrote:
> Dear Chris
>
> > >I think its time to start using netcdf-4 for large collections of point
> > >data which need to be compressed. Instead of first making a standard, we
> > >n
Chris,
I took a look at
http://hfrnet.ucsd.edu:8080/thredds/dodsC/HFRNet/USEGC/6km/hourly/RTV.html
I agree that "site_code" should not have units.
The CF document states: "Units are not required for dimensionless
quantities. A variable with no units attribute is assumed to be
dimensionless. Howeve
;s CI software we may want to capture ISO metadata in the Common Data
> Model, so the resolution of this question will be of some interest.
> John
> On Feb 21, 2011, at 04:27, Rich Signell wrote:
>
> Martin,
>
> Ted Habermann & Dave Neufeld at NOAA and Ethan Davis at Unidata
Martin,
Ted Habermann & Dave Neufeld at NOAA and Ethan Davis at Unidata have been
making great strides in this department.I'm sure they'll chime in with
more info, but to get going, check this out:
https://geo-ide.noaa.gov/wiki/index.php?title=NcISO
-Rich
On Mon, Feb 21, 2011 at 5:52 AM, Sc
John & Co,
> Also, they are wondering what to use for the default ellipsoid when these
> are not specified. It seems to me the obvious candidates are 1) spherical
> earth with a standard radius, or 2) WGS84 ellipsoid.
I imagine the vast majority of netcdf datasets fall into this camp. I
had an i
Jonathan,
Even better. I would vote to support this proposal.
-Rich
On Tue, Jan 4, 2011 at 6:40 AM, Jonathan Gregory
wrote:
> Dear all
>
> In standard names I think CF has generally followed Roy's no (2):
>
>> 1) Create an idealised model with everything normalised and harmonised to
>> the nth
name = "Zonal Velocity" ;
> U:units = "meters/sec" ;
> U:binary_mask = "U_MASK";
> float U_MASK(AX002, AX003) ;
> U_MASK:coordinates = "LAT_U LON_U" ;
> U_MASK:standard_name = "binary_mask" ; // "1" indic
Chris,
On Mon, Jan 3, 2011 at 12:57 PM, Christopher Barker
wrote:
> On 1/2/11 6:11 PM, Rich Signell wrote:
>>
>> But they are not the same thing. They are the inverse.
>
> yes, of course, but they carry exactly the same information, do they not.
Yes, one could be in
CF Standard Name Team:
I would like to request a new standard_name="sea_binary_mask" defined as
sea_binary_mask X_binary_mask has 1 where condition X is met, 0
elsewhere. 1 = sea, 0 = land.
This is used by the popular ROMS ocean model, and perhaps others.
The new "sea_binary_mask" would j
But that doesn't negate points (1), (2) and (3).
-Rich
On Thu, Dec 30, 2010 at 7:39 AM, Rich Signell wrote:
> Roy, Nan & CF-ers,
>
> I imagine Nan would be okay with her ADCP currents to be type
> "timeSeriesProfile" as long as:
> 1) both "timeSeriesProfile&q
Roy, Nan & CF-ers,
I imagine Nan would be okay with her ADCP currents to be type
"timeSeriesProfile" as long as:
1) both "timeSeriesProfile" and "timeSeries" featureTypes can exist
in the same dataset. (as Roy points out)
2) she had a function to extract a featureType "timeSeries" from a
featu
Jonathan,
>> Typical producers of this kind of data are numerical particle tracking
>> models. These codes step through time, following the (x,y,t) or
>> (x,y,z,t) trajectories of individual particles. At each time step,
>> more particles may be introduced to be tracked, while other particles
>>
re printing
>
> -Original Message-
> From: John Caron [mailto:ca...@unidata.ucar.edu]
> Sent: Dienstag, 12. Oktober 2010 19:31
> To: Rich Signell
> Cc: Ute Brönner; Jonathan Gregory; cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] point observation data in CF 1.4
>
>
d) etc.
>
> Thanks anyway,
> Ute
>
> Ute Brönner
> www.sintef.com/marine_environment
>
> Consider the environment before printing
>
> -Original Message-
> From: rsign...@gmail.com [mailto:rsign...@gmail.com] On Behalf Of Rich Signell
> Sent: Freitag, 8. Oktober 2010
Ute,
On this page:
https://cf-pcmdi.llnl.gov/trac/wiki/PointObservationConventions
It appears that your case *might* be handled by:
9.3.2 Ragged array (contiguous) representation
I'm pretty sure that this "ragged_row_count" feature *is* included in
NetCDF-Java, but John Caron (cc'd here) could
Seth,
Is there a "best practices" page for creating NetCDF files that are
readable by ArcGIS 9.3?
And could you point us toward some examples of NetCDF files that
ArcGIS 9.3 can read?
Thanks,
Rich
On Thu, Jun 18, 2009 at 2:45 PM, Seth McGinnis wrote:
> One anecdotal point about lat-lon grids an
Stephane,
One additional thing I should have mentioned. My Suggestion #2:
".. just add a new CF-compliant sigma variable to your NetCDF
file. Then add the "standard_name = ocean_sigma_coordinate" to this
new variable (and assign it values that are one less than in your old
variable)."
could b
ate2" to the CF standards committee.
Good luck,
-Rich Signell
On Fri, Oct 10, 2008 at 1:28 PM, Stephane TAROT
<[EMAIL PROTECTED]> wrote:
> Dear all,
>
> For a french project of coastal oceanography (Previmer :
> http://www.previmer.org/en), I have to define
> a netcdf file
CF folks,
I wanted to revisit some discussion we had on the CF mailing list back
in 2004 concerning conventions for unstructured grid data. When I
google searched on "conventions for unstructured grid data" I got back
hits like:
http://www.cgd.ucar.edu/pipermail/cf-metadata/2004/000503.html
but
Jon,
Vertical datums were originially going to be handled by CF Trac ticket 18:
http://cf-pcmdi.llnl.gov/trac/ticket/18
but then were excluded in the interest of moving forward on the
horizontal datum issues. I think we would need a new ticket for the
vertical datum issues (and of course, someon
27 matches
Mail list logo
