Re: [CF-metadata] new TEOS-10 standard names
Hi Please do not use the word bulk when referring to sst. The correct term is SSTdepth. This was extensively discussed previously Regards Craig Sent from my iPhone -- Dr Craig Donlon Principal Scientist for Oceans and Ice ESA/ESTEC (EOP-SME) Keplerlaan 1, 2201 AZ Noordwijk The Netherlands t: +31 (0)715 653687 f: +31 (0)715 655675 e: craig.don...@esa.int m:+31 (0)627 013244 Skype ID:crazit On 26 Nov 2011, at 04:59, John Graybeal jbgrayb...@mindspring.com wrote: Alison, You do impressive work. On Nov 25, 2011, at 12:03, alison.pamm...@stfc.ac.uk alison.pamm...@stfc.ac.uk wrote: (b) sea_water_temperature There is agreement to retain the standard name sea_water_temperature as this is useful particularly for observations. It currently has no explanatory text. In response to the discussion I propose to add the following sentence: 'Sea temperature is the in situ (bulk) temperature of the sea water, not the surface or skin temperature.' In the proposed definition, do you mean to say 'Sea water temperature is ...' ? Regarding the existing salinity quantities, the straightforward conclusion (though not implementation) is to make parallel changes to those quantities, and add parallel quantities at least for sea_water_practical_salinity, on the assumption that the users of the original quantities would need the replacement and practical is a likely replacement (I'm guessing here). However, to a degree this violates the 'wait for demand' principal of CF. A solution might be to put out the question, for each original quantity together with each new salinity (practical, absolute, preformed) Do you need this value, and if so, would you suggest a correction to the definition? Those with the needs could check the appropriate boxes, and you could backfill any others that are needed later. John John Graybeal mailto:jgrayb...@ucsd.edu phone: 858-534-2162 Product Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org ___ 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] new TEOS-10 standard names
Hi John, I have a concern with your exclusion of the surface from the term sea_water_temperature. What Standard Name would you use for the temperature data stream in a CTD profile that extends from the surface to depth? I'm more comfortable with the idea of keeping sea_water_temperature vague so it can include a mixture of surface and within water body measurements, but making the SST terms explicitly exclude temperatures within the water body. Cheers, Roy. From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Graybeal [jbgrayb...@mindspring.com] Sent: 26 November 2011 03:59 To: Alison Pamment Cc: CF Metadata List Subject: Re: [CF-metadata] new TEOS-10 standard names Alison, You do impressive work. On Nov 25, 2011, at 12:03, alison.pamm...@stfc.ac.uk alison.pamm...@stfc.ac.uk wrote: (b) sea_water_temperature There is agreement to retain the standard name sea_water_temperature as this is useful particularly for observations. It currently has no explanatory text. In response to the discussion I propose to add the following sentence: 'Sea temperature is the in situ (bulk) temperature of the sea water, not the surface or skin temperature.' In the proposed definition, do you mean to say 'Sea water temperature is ...' ? Regarding the existing salinity quantities, the straightforward conclusion (though not implementation) is to make parallel changes to those quantities, and add parallel quantities at least for sea_water_practical_salinity, on the assumption that the users of the original quantities would need the replacement and practical is a likely replacement (I'm guessing here). However, to a degree this violates the 'wait for demand' principal of CF. A solution might be to put out the question, for each original quantity together with each new salinity (practical, absolute, preformed) Do you need this value, and if so, would you suggest a correction to the definition? Those with the needs could check the appropriate boxes, and you could backfill any others that are needed later. John John Graybeal mailto:jgrayb...@ucsd.edu phone: 858-534-2162 Product Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata-- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] FW: netcdf for particle trajectories
Hi Ute:
On 11/25/2011 6:01 AM, Ute Brönner wrote:
Hi folks,
I kind of lost track of our latest discussions and had the feeling that this
was partly outside the mailing group; so I will try to sum up what we were
discussing.
My latest try was to produce NetCDF for particle trajectory trying to write out
the concentration grid which resulted in a 11GB netFCDF3 file :-(
So we have different motivations for discussion particle trajectory and netcdf4.
First question:
Does anybody know if and if yes, when writing netCDF4 will be incorporated into
the NetCDF Java library? Or will we use Python with the help of Jython etc.
(http://www.slideshare.net/onyame/mixing-python-and-java) to write netCDF4?
Im intending to incorporate the netcdf-4 C library into the netcdf-java
library using JNI. Im hoping to have something working in the next few
months, but we'll see. This will be an optional component, and will
obviously make portability an issue. If you want to use Python, probably
the one to use is Jeff Whittaker's at
http://code.google.com/p/netcdf4-python/, which is also an interface to
the netcdf-4 C library.
Second question:
Is there a de facto standard / proposal for writing Particle Trajectory Data which
could be CF:featureType:whatever we agree on? The suggestion below is not
suitable because:
1) we don't track a particle the whole time, it may disappear and show up again
later, but if I have 1000 particles in time step 1 and 1000 in time step 2 we
cannot be sure these 1000 are the same as before.
2) I cannot know the number of time steps in advance.
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
need to try out the possibilities and see how it performs. I think you
want to use Structures, as well as multiple unlimited dimensions. With
netcdf, we dont need the ragged array mecahnism - thats only needed to
overcome the limitations of the classic model.
Has anyone started down this path? If so, can you post example netcdf-4
files?
I would like sth. like
dimensions:
particle = UNLIMITED; //because it may change each time step
time = UNLIMITED; // because I don't know
then every variable is like
latitude (particle, time)
longitude (particle, time)
and I might have
int number_particles_per_timestep(time);
:units = 1;
:long_name = number particles per current timestep;
:CF:ragged_row_count = particle;
That some of you need to know which spill a particle came from, may be solved
with a 3rd dimension spill
dimensions:
spill = 3; // or how many one has
particle = UNLIMITED; //because it may change each time step
time = UNLIMITED; // because I don't know
particle (spill, time)
then every variable is like
latitude (particle)
longitude (particle)
how would one write this? With coordinates or as hierarchical data structure?
At least we need the ability to use several unlimited dimensions and the
ragged-array feature.
Third question:
How can we compress big netCDF3 files? Or is it smarter to go for netCDF4
directly with hierarchical data. As in my example above I would need to write
out a 11 GB file and then deflate it like described here
http://www.unidata.ucar.edu/mailing_lists/archives/netcdf-java/2010/msg00095.html
or with Rich's script; but is that really necessary?
Hoping to get up the discussion again and that we agree on a standard quite
soon!
Have a nice weekend!
Best,
Ute
Original Message
Subject: [CF-metadata] Particle Track Feature Type (was: Re: point observation
data in CF 1.4)
Date: Fri, 19 Nov 2010 04:15:35 +0100
From: John Caronca...@unidata.ucar.edu
To: cf-metadata@cgd.ucar.educf-metadata@cgd.ucar.edu
Im thinking that we need a new feature type for this. Im calling it
particleTrack but theres probably a better name.
My reasoning is that the nested table representation of trajectories is:
Table {
traj_id;
Table {
time;
lat, lon, z;
data;
}
}
but this case has the inner and outer table inverted:
Table {
time;
Table {
particle_id;
lat, lon, z;
data;
data2;
}
}
So, following that line of thought, the possibilities in CDL are:
1) If avg number of particles ~ max number of particles at any time step, then
one could use multdimensional arrays:
dimensions:
maxParticles = 1000 ;
time = ; // may be UNLIMITED
variables:
double time(time) ;
int particle_id(time, maxParticles) ;
float lon(time, maxParticles) ;
float lat(time, maxParticles) ;
float z(time, maxParticles) ;
float data(time, maxParticles) ;
attributes:
:featureType = particleTrack;
note maxParticles is the max number of particles at any one time step, not
total particle tracks. The particle trajectories have to be found by examining
the values of particle_id(time, maxParticles).
2) The CDL of the ragged case would
