Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6
Hi. Here's my best understanding (which could be flawed, so I look forward to finding out if I have missed something). Assuming that your time, latitude, and longitude are all proper coordinate variables (no fill values), either choice for the shape of your salinity variable works. If you use the more complex shape, then you don't need to have the coordinates attribute, as the relationships are declared through the shape. Speaking of that, the coordinates attribute doesn't need to have PRESSURE in it. Doesn't hurt anything, but it isn't necessary. Having said all that, I find myself wondering why you are storing each salinity profile in a separate file. Would you mind sharing what went into deciding to take this approach? Grace and peace, Jim On Mon, Apr 2, 2012 at 2:51 AM, andrew walsh awa...@metoc.gov.au wrote: Hi CF list, We are working on coding up some 1000's netCDF files off CTD instruments and want to make usre we are following the latest netCDF conventions (v1.6) OK. As background the CTD records a profile pressure, temperature and salinity. Here is a summarised CDL version (not all attributes+variables+qc flags there, just majors for now) of what we propose: dimensions: TIME=1 PRESSURE=729 LATITUDE=1 LONGITUDE=1 variables: double TIME(TIME) ; TIME:standard_name = time ; TIME:units = days since 1950-01-01 00:00:00Z ; TIME:axis = T ; TIME:valid_min = 0. ; TIME:valid_max = 99. ; double LATITUDE(LATITUDE) ; LATITUDE:standard_name = latitude ; LATITUDE:units = degrees_north ; LATITUDE:axis = Y ; LATITUDE:valid_min = -90. ; LATITUDE:valid_max = 90. ; double LONGITUDE(LONGITUDE) ; LONGITUDE:standard_name = longitude ; LONGITUDE:units = degrees_east ; LONGITUDE:axis = X ; LONGITUDE:valid_min = -180. ; LONGITUDE:valid_max = 180. ; double PRESSURE(PRESSURE) ; PRESSURE:standard_name = sea_water_pressure ; PRESSURE:units = decibars ; PRESSURE:axis = Z ; PRESSURE:valid_min = 0. ; PRESSURE:valid_max = 12000. ; PRESSURE:positive = down ; double TEMPERATURE(PRESSURE) ; TEMPERATURE:standard_name = sea_water_temperature ; TEMPERATURE:units = degrees_C ; TEMPERATURE:_FillValue = -99.99 ; TEMPERATURE:valid_min = -2. ; TEMPERATURE:valid_max = 40. ; TEMPERATURE:coordinates=TIME LATITUDE LONGITUDE PRESSURE double SALINITY(PRESSURE) ; SALINITY:standard_name = sea_water_salinity ; SALINITY:units = psu ; SALINITY:_FillValue = -99.99 ; SALINITY:valid_min = 0. ; SALINITY:valid_max = 40. ; SALINITY:coordinates=TIME LATITUDE LONGITUDE PRESSURE // global attributes: :conventions = CF-1.6 ; :featureType = profile :cdm_data_type = profile + several other attributes later for ISO19115 metadata generation I am not sure if I should have TEMPERATURE and SALINITY arrays with 4 dimensions like TEMPERATURE(TIME,LATITUDE,**LONGITUDE,PRESSURE) or just 1 dimension like I have above i.e. TEMPERATURE(PRESSURE). ? Any feedback on the above is greatly appreciated. Andrew Walsh __**_ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/**mailman/listinfo/cf-metadatahttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Jim Biard Research Scholar Cooperative Institute for Climate and Satellites Remote Sensing and Applications Division National Climatic Data Center 151 Patton Ave, Asheville, NC 28801-5001 jim.bi...@noaa.gov 828-271-4900 ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] CF-1.6 Conformance Requirements/Recommendations
On 4/2/2012 4:52 AM, Jim Biard wrote: I like Jonathan's suggestion. Fine w/ me. - Steve On Sat, Mar 31, 2012 at 4:19 PM, Jonathan Gregory j.m.greg...@reading.ac.uk mailto:j.m.greg...@reading.ac.uk wrote: Dear all John Caron proposed Applications should treat the data as missing where the auxiliary coordinates are missing and Steve proposed (an hour later, I think) Application writers should be aware that under some (rare) circumstances data auxiliary coordinate values may be missing, while other parameters at the corresponding indices remain valid. While special purpose applications may be able to glean useful information at these indices, most applications will want to regard data as missing where the auxiliary coordinates are missing I could agree to either of these. I prefer John's, because it is simpler, but it's more severe than Steve's. A compromise might be possible, e.g. Generic applications should treat the data as missing where any auxiliary coordinate variables have missing values; special-purpose applications might be able to make use of the data. Any good? Cheers 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 -- Jim Biard Research Scholar Cooperative Institute for Climate and Satellites Remote Sensing and Applications Division National Climatic Data Center 151 Patton Ave, Asheville, NC 28801-5001 jim.bi...@noaa.gov mailto:jim.bi...@noaa.gov 828-271-4900 ___ 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] Ocean CTD data following CF Conventions v1.6
Hi Andrew, Either way it should be okay as far as CF compliance is concerned. But the dimensions - latitude, longitude and time are not really required. If it is required to indicate that there is only one station(profile) in the file, there could be a dimension for number of stations instead, with a value of 1. Also, using a station dimension is the way to go if storing a collection of profiles in a single file. Here at NODC, we took the approach that we would use the same consistent representation whether there is a single instance or a collection in a file. Upendra On Mon, Apr 2, 2012 at 2:51 AM, andrew walsh awa...@metoc.gov.au wrote: Hi CF lis We are working on coding up some 1000's netCDF files off CTD instruments and want to make usre we are following the latest netCDF conventions (v1.6) OK. As background the CTD records a profile pressure, temperature and salinity. Here is a summarised CDL version (not all attributes+variables+qc flags there, just majors for now) of what we propose: dimensions: TIME=1 PRESSURE=729 LATITUDE=1 LONGITUDE=1 variables: double TIME(TIME) ; TIME:standard_name = time ; TIME:units = days since 1950-01-01 00:00:00Z ; TIME:axis = T ; TIME:valid_min = 0. ; TIME:valid_max = 99. ; double LATITUDE(LATITUDE) ; LATITUDE:standard_name = latitude ; LATITUDE:units = degrees_north ; LATITUDE:axis = Y ; LATITUDE:valid_min = -90. ; LATITUDE:valid_max = 90. ; double LONGITUDE(LONGITUDE) ; LONGITUDE:standard_name = longitude ; LONGITUDE:units = degrees_east ; LONGITUDE:axis = X ; LONGITUDE:valid_min = -180. ; LONGITUDE:valid_max = 180. ; double PRESSURE(PRESSURE) ; PRESSURE:standard_name = sea_water_pressure ; PRESSURE:units = decibars ; PRESSURE:axis = Z ; PRESSURE:valid_min = 0. ; PRESSURE:valid_max = 12000. ; PRESSURE:positive = down ; double TEMPERATURE(PRESSURE) ; TEMPERATURE:standard_name = sea_water_temperature ; TEMPERATURE:units = degrees_C ; TEMPERATURE:_FillValue = -99.99 ; TEMPERATURE:valid_min = -2. ; TEMPERATURE:valid_max = 40. ; TEMPERATURE:coordinates=TIME LATITUDE LONGITUDE PRESSURE double SALINITY(PRESSURE) ; SALINITY:standard_name = sea_water_salinity ; SALINITY:units = psu ; SALINITY:_FillValue = -99.99 ; SALINITY:valid_min = 0. ; SALINITY:valid_max = 40. ; SALINITY:coordinates=TIME LATITUDE LONGITUDE PRESSURE // global attributes: :conventions = CF-1.6 ; :featureType = profile :cdm_data_type = profile + several other attributes later for ISO19115 metadata generation I am not sure if I should have TEMPERATURE and SALINITY arrays with 4 dimensions like TEMPERATURE(TIME,LATITUDE,**LONGITUDE,PRESSURE) or just 1 dimension like I have above i.e. TEMPERATURE(PRESSURE). ? Any feedback on the above is greatly appreciated. Andrew Walsh __**_ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/**mailman/listinfo/cf-metadatahttp://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] CF-1.6 Conformance Requirements/Recommendations
I think that the important factor in the text posted by Jonathan: '''Generic applications should treat the data as missing where any auxiliary coordinate variables have missing values; special-purpose applications might be able to make use of the data.''' is that it puts the onus on interpretation on the downstream application, with some advice; this is better than requiring the data provider to I feel that having the capability to have missing data stored in auxiliary coordinates is important. Whilst the interpretation of the meaning of such encoding needs some care, I feel that the specification should not be too restrictive on this. I have a use case to consider: Phenomena as Auxiliary Coordinates The distinction between a data variable and an auxiliary coordinate can often be quite an arbitrary one. A data variable may be used as an auxiliary coordinate for another data variable which shares the same coordinate variables. Consider - coordinates x, y, z and t - relative humidity data with respect to x, y, z and t: - pressure data with respect to x, y, z and t I would not want to alter the specific humidity data in any way as a result of adding the pressure data as an auxiliary coordinate. A post processing application may choose: - to interpret the pressure data auxiliary coordinate missing data as missing data indicators for the relative humidity data to enable data regridding onto specified pressure levels; - to compute the variability of the humidity measurements, ignoring the pressure data; these are operational choices, made by the software. I think CF should enable data to be stored to enable such processes to take place, and not mandate that one or other storage method is correct. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu on behalf of Jonathan Gregory Sent: Sat 31/03/2012 21:19 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] CF-1.6 Conformance Requirements/Recommendations Dear all John Caron proposed Applications should treat the data as missing where the auxiliary coordinates are missing and Steve proposed (an hour later, I think) Application writers should be aware that under some (rare) circumstances data auxiliary coordinate values may be missing, while other parameters at the corresponding indices remain valid. While special purpose applications may be able to glean useful information at these indices, most applications will want to regard data as missing where the auxiliary coordinates are missing I could agree to either of these. I prefer John's, because it is simpler, but it's more severe than Steve's. A compromise might be possible, e.g. Generic applications should treat the data as missing where any auxiliary coordinate variables have missing values; special-purpose applications might be able to make use of the data. Any good? Cheers 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
Re: [CF-metadata] CF-1.6 Conformance Requirements/Recommendations
Dear all Thanks for your postings. There seems to be a consensus on this. I have therefore changed my existing trac ticket 85 accordingly https://cf-pcmdi.llnl.gov/trac/ticket/85 to record this consensus. Note that this means we have to amend section 9.6 as well, which explicitly disallowed missing data in aux coord vars (except for nonexistent elements). We have to change this, or else it would not be legal for Nan to store her profiles with missing pressure in discrete sampling geometries following sect 9, for instance. I hope I've got this right. Ticket 85 is a defect ticket, intended to correct mistakes uncontroversially! Therefore if anyone isn't happy with this, they should object on the ticket, and we'll need to open a different one to discuss another way to modify the convention. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] CF-1.6 Conformance Requirements/Recommendations
HI all, following my previous email. I think the rules for discussed in ticket 85 should apply only to discrete sampling geometries. Karl On 4/2/12 1:00 PM, Jonathan Gregory wrote: Dear all Thanks for your postings. There seems to be a consensus on this. I have therefore changed my existing trac ticket 85 accordingly https://cf-pcmdi.llnl.gov/trac/ticket/85 to record this consensus. Note that this means we have to amend section 9.6 as well, which explicitly disallowed missing data in aux coord vars (except for nonexistent elements). We have to change this, or else it would not be legal for Nan to store her profiles with missing pressure in discrete sampling geometries following sect 9, for instance. I hope I've got this right. Ticket 85 is a defect ticket, intended to correct mistakes uncontroversially! Therefore if anyone isn't happy with this, they should object on the ticket, and we'll need to open a different one to discuss another way to modify the convention. 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
Re: [CF-metadata] CF-1.6 Conformance Requirements/Recommendations
My previous email might have been blocked so here it is again: Dear all, I support the first paragraph, but concerning the last paragraph below, I would suggest being more explicit about the difference between a data void and simply when there is no valid data for an element. Also do the rules given in that paragraph apply only to Representations of collections of features in data variables? As written, it seems like someone reading this paragraph wouldn't know what to do when they were working with a dataset, which was a function of latitude and height in meters with an auxiliary coordinate of say height in feet. Suppose all the data were missing at one height. If missing data implies missing auxiliary coordinate value, as a read the current text, then you would be required to keep the height in meters (the coordinate), but indicate missing for the height in feet (the auxiliary coordinate). Also, what is one to do if it is missing only a one latitude? Is this what is called for? Does it make sense? I would vote no to the 2nd question. regards, Karl On 4/2/12 3:03 PM, Karl Taylor wrote: HI all, following my previous email. I think the rules for discussed in ticket 85 should apply only to discrete sampling geometries. Karl On 4/2/12 1:00 PM, Jonathan Gregory wrote: Dear all Thanks for your postings. There seems to be a consensus on this. I have therefore changed my existing trac ticket 85 accordingly https://cf-pcmdi.llnl.gov/trac/ticket/85 to record this consensus. Note that this means we have to amend section 9.6 as well, which explicitly disallowed missing data in aux coord vars (except for nonexistent elements). We have to change this, or else it would not be legal for Nan to store her profiles with missing pressure in discrete sampling geometries following sect 9, for instance. I hope I've got this right. Ticket 85 is a defect ticket, intended to correct mistakes uncontroversially! Therefore if anyone isn't happy with this, they should object on the ticket, and we'll need to open a different one to discuss another way to modify the convention. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edumailto: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] Ocean CTD data following CF Conventions v1.6
Hi Roy/All, Agree totally it would be good to get this CTD netCDF done in an interoperable way. Regarding having pressure vs. depth. We liked to use pressure because: 1) It is the thing that is measured, let us store just that and calculate depth if needed. 2) Depth can later be easily be calculated on the fly using the 'Pressure to Depth' algorithm in UNESCO (1983) Techinical Papers in Marine Science 44, Algorithms for Computation of fundamental properties of Seawater. One can use the python seawater library (see http://packages.python.org/seawater/ ) and seawater.csiro.depth(p, lat) to get depth from pressure and seawater.csiro.pres(depth, lat) to get pressure from depth. 3) I noted that the ARGO project (1's CTD like profiles) and others like CSIRO Oceanography in Aust. make data available with just pressure. 4) It makes our processing and QC a whole lot simpler. We don't have to worry about calculating and managing the extra 'depth' variable. Is there any problem with having the pressure as a co-ordinate which isn't really a dimensional quantity like depth (z) in the 4-D sense i.e x,y,z,t ? However I note that pressure (decibar) is allowed as a vertical axis e.g see section 4.3. Vertical (Height or Depth) Coordinate of CF v1.6 conventions document which says: A vertical coordinate will be identifiable by: . units of pressure; or . the presence of the positive attribute with a value of up or down (case insensitive). AND section 4.3.1. Dimensional Vertical Coordinate which says: The units attribute for dimensional coordinates will be a string formatted as per the udunits.dat3 file. The acceptable units for vertical (depth or height) coordinate variables are: . units of pressure as listed in the file udunits.dat. For vertical axes the most commonly used of these include include bar, millibar, decibar, atmosphere (atm), pascal (Pa), and hPa. ... ...¶ Regards, Andrew - Original Message - From: Lowry, Roy K. To: andrew walsh Cc: Jim Biard ; Upendra Dadi ; cf-metadata@cgd.ucar.edu ; Luke Callcut ; g...@metoc.gov.au ; sdn2-t...@seadatanet.org Sent: Tuesday, April 03, 2012 2:16 PM Subject: RE: [CF-metadata] Ocean CTD data following CF Conventions v1.6 Hi Andrew, SeaDataNet will very soon be considering how it is going to encode data, including single CTD casts, in CF-compliant NetCDF and so I think the time is ripe for agreeing how the significant numbers of us who indulge in this practice for whatever reason do it. That way we'll end up with interoperable data. I think there are a number of people on this list who have already encoded single CTDs into NetCDF and so it would be useful to start by asking for descriptions (like Andrew's examples) of how this has been done and what tools are dependent upon that encoding. The z co-ordinate parameter (pressure/depth) is also an issue worth resolving. Whilst interconversions are relatively straightforward, agreement would make life much easier. My preference leans dowards having depth as the dimension with pressure as an optional variable. That way we interoperate with other kinds of oceanographic profile data such as bottle data. If we can get that far, we can then look at how to aggregate multiple CTDs into a file according to the CF point data conventions. Cheers, Roy. From: andrew walsh [awa...@metoc.gov.au] Sent: 03 April 2012 04:39 To: Lowry, Roy K. Cc: Jim Biard; Upendra Dadi; cf-metadata@cgd.ucar.edu; Luke Callcut; g...@metoc.gov.au Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6 Hello Roy, Upendra, Jim and CF list, Thanks for all your feedbacks. My proposal relates to single CTD profile data (a vertical profile of pressure, Temp. Salinity) not a trajectory in x,y,z,t and I have put :featureType = profile as recommended in the global attributes section. As Roy has mentioned to Jim CTD data is usually processed and QC'ed as a single profile per netCDF file so that's why I am doing it this way. Aggregations using multiple CTD profiles per netCDF file may be constructed later at say national/international data centres and these aggregrations would follow the CF conventions v1.6, Chapter 9 - Discrete Sampling geometries and also the new netCDF templates provided by NODC, thanks NODC -:) Roy, The recent NODC netCDF templates don't have an aggregation example for CTD however the Profile/World Ocean Database Observed Level example comes close (see http://www.nodc.noaa.gov/data/formats/netcdf/) and click on Profile/World Ocean Database Observed Level link. This example appears to be for ocean station/bottle samples with vertical dimension of depth (z) (m) rather than case of CTD which would use pressure (dbar) as the vertical (z) dimension. It would be useful I think to have a NODC netCDF template for an aggregation of CTD casts. Upendra, Based on your responses and what I have seen at NODC and other places it seems there are 2 methods to do
Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6
Hi again, The reason that I prefer depth to pressure as the dimension for CTD is that the information required for pressure to depth conversion is virtually always present in the CTD data. However, in other oceanographic profiles - say nutrient bottle data - it is quite possible to have depth present without temperature and salinity, making the conversion to pressure impossible. Calculating depth from pressure at the time of standardised formatting of CTD data is as you say is trivial. So, why not make the CTD data more compatible with bottle data for very little cost? SeaDataNet already mandate inclusion of depth in their other data formats for CTD data delivery and so I can't see them switching to pressure for the dimension in NetCDF. Cheers, Roy. From: andrew walsh [awa...@metoc.gov.au] Sent: 03 April 2012 06:15 To: Lowry, Roy K. Cc: Jim Biard; Upendra Dadi; cf-metadata@cgd.ucar.edu; Luke Callcut; g...@metoc.gov.au; sdn2-t...@seadatanet.org Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6 Hi Roy/All, Agree totally it would be good to get this CTD netCDF done in an interoperable way. Regarding having pressure vs. depth. We liked to use pressure because: 1) It is the thing that is measured, let us store just that and calculate depth if needed. 2) Depth can later be easily be calculated on the fly using the 'Pressure to Depth' algorithm in UNESCO (1983) Techinical Papers in Marine Science 44, Algorithms for Computation of fundamental properties of Seawater. One can use the python seawater library (see http://packages.python.org/seawater/ ) and seawater.csiro.depth(p, lat) to get depth from pressure and seawater.csiro.pres(depth, lat) to get pressure from depth. 3) I noted that the ARGO project (1's CTD like profiles) and others like CSIRO Oceanography in Aust. make data available with just pressure. 4) It makes our processing and QC a whole lot simpler. We don't have to worry about calculating and managing the extra 'depth' variable. Is there any problem with having the pressure as a co-ordinate which isn't really a dimensional quantity like depth (z) in the 4-D sense i.e x,y,z,t ? However I note that pressure (decibar) is allowed as a vertical axis e.g see section 4.3. Vertical (Height or Depth) Coordinate of CF v1.6 conventions document which says: A vertical coordinate will be identifiable by: . units of pressure; or . the presence of the positive attribute with a value of up or down (case insensitive). AND section 4.3.1. Dimensional Vertical Coordinate which says: The units attribute for dimensional coordinates will be a string formatted as per the udunits.dat3 file. The acceptable units for vertical (depth or height) coordinate variables are: . units of pressure as listed in the file udunits.dat. For vertical axes the most commonly used of these include include bar, millibar, decibar, atmosphere (atm), pascal (Pa), and hPa. ... ...¶ Regards, Andrew - Original Message - From: Lowry, Roy K. To: andrew walsh Cc: Jim Biard ; Upendra Dadi ; cf-metadata@cgd.ucar.edu ; Luke Callcut ; g...@metoc.gov.au ; sdn2-t...@seadatanet.org Sent: Tuesday, April 03, 2012 2:16 PM Subject: RE: [CF-metadata] Ocean CTD data following CF Conventions v1.6 Hi Andrew, SeaDataNet will very soon be considering how it is going to encode data, including single CTD casts, in CF-compliant NetCDF and so I think the time is ripe for agreeing how the significant numbers of us who indulge in this practice for whatever reason do it. That way we'll end up with interoperable data. I think there are a number of people on this list who have already encoded single CTDs into NetCDF and so it would be useful to start by asking for descriptions (like Andrew's examples) of how this has been done and what tools are dependent upon that encoding. The z co-ordinate parameter (pressure/depth) is also an issue worth resolving. Whilst interconversions are relatively straightforward, agreement would make life much easier. My preference leans dowards having depth as the dimension with pressure as an optional variable. That way we interoperate with other kinds of oceanographic profile data such as bottle data. If we can get that far, we can then look at how to aggregate multiple CTDs into a file according to the CF point data conventions. Cheers, Roy. From: andrew walsh [awa...@metoc.gov.au] Sent: 03 April 2012 04:39 To: Lowry, Roy K. Cc: Jim Biard; Upendra Dadi; cf-metadata@cgd.ucar.edu; Luke Callcut; g...@metoc.gov.au Subject: Re: [CF-metadata] Ocean CTD data following CF Conventions v1.6 Hello Roy, Upendra, Jim and CF list, Thanks for all your feedbacks. My proposal relates to single CTD profile data (a vertical profile of pressure, Temp. Salinity) not a trajectory in x,y,z,t and I have put :featureType = profile as recommended in the global attributes section. As Roy has mentioned to Jim CTD data is usually processed and QC'ed
