Re: [CF-metadata] Ancillary Data
Hi Nan I think I understand you approach, it seems logical and helpful to me. It feels like all your examples are in my category b: b. reference a subset of the file dimensions referenced by the data variable with the ancillary_variables attribute and thus relate to the data variable in the same way auxiliary_coordinates do, just with different inferred semantics. many thanks for the feedback mark -Original Message- From: CF-metadata on behalf of Nan Galbraith Sent: Wed 13/02/2013 19:55 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] Ancillary Data I use a singleton variable to record the magnetic correction that's been applied to my wind and/or current variables; it's dim(1) and is listed as an ancillary to any variables that have been affected by the rotation. It could be an attribute of each of those variables, but making it a free-standing variable lets me give it units and attributes. That's important because I record the model name and version date, the URL of the NGDC calculator site, the inputs to the model (date and location for which the calculation was done) and the estimated rate of change. Maybe this is just a technicality - but I also use an empty 'container' variable for instruments, which has ancillary variables with a depth dimension for manufacturer, model, serial number, and reference URL. The instrument variable is tied to 'obs data' variables via NODC's 'instrument' attribute, but has no dimensions of its own; the individual component variables (like serial number) have a dimension that matches the depth dimension of the obs data variables. - Nan On 2/13/13 12:15 PM, Hedley, Mark wrote: Hello CF community I have been perusing the CF conventions again, particularly the section on Ancillary Data http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/ch03s04.html The conventions make the statement: The nature of the relationship between variables associated via ancillary_variables must be determined by other attributes. The example given provides data variables which reference the same dimensions in the file: thus they data arrays are the same size. However, the conventions do not seem to mandate this. I am interested in the use of the ancillary_variables attribute in real world datasets. Do people have examples they can share of ancillary datasets which: a. reference the same file dimensions as the data variable with the ancillary_variables attribute references b. reference a subset of the file dimensions referenced by the data variable with the ancillary_variables attribute c. reference file dimensions which are not referenced by the data variable with the ancillary_variables attribute I am particularly interested in examples of case c, as I feel this is markedly different from cases a and b and requires a different kind of support if it is in use. many thanks mark ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- *** * Nan GalbraithInformation Systems Specialist * * Upper Ocean Processes GroupMail Stop 29 * * Woods Hole Oceanographic Institution* * Woods Hole, MA 02543 (508) 289-2444 * *** ___ 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] any convention for variables abbreviation ?
SeaDataNet has standardized short names - currently 429 names, and as far as I know all the CF terms are included. It's available at tinyurl.com/SDNp021 The long url for the p021 list is seadatanet.maris2.nl/v_bodc_vocab/browse.asp?order=entrykeyformname=searchscreen=0l=P021v0_0=v1_0=entrykey%2Centryterm%2Centrytermabbr%2Centrytermdef%2Centrytermlastmodv2_0=0v0_1=v1_1=entrykeyv2_1=3v0_2=v1_2=entrytermv2_2=3v0_3=v1_3=entrytermabbrv2_3=3v0_4=v1_4=entrytermlastmodv2_4=9v0_5=v1_5=entrytermlastmodv2_5=10x=49y=12v1_6=v2_6=v1_7=v2_7= or you can just google SeaDataNet Parameter Discovery Vocabulary You can export the list from that page into an xml file, or search for individual terms. - Nan On 2/13/13 7:28 PM, Steve Hankin wrote: Hi Nicolas, Various organizations enforce their own standards for abbreviated names in CF files -- OceanSites, Argo, WMO, CF, itself, does not. The reason that CF does not attempt to standardize the names of variables (which is how the abbreviations are used in the above cases), is to leave open the possibility that a single file may contain multiple variables representing the same quantity. For example, SST as measured by satellite and as measured in situ could potentially be in the same file. The long_name attribute can be used to differentiate how multiple representations of the same variable were derived. - Steve === On 2/13/2013 3:00 PM, Nicolas BALDECK - OpenMeteoData wrote: Dear, I'm designing a webservice for broadcasting some meteorological data. I will use the CF naming convention for variables names, but I also have to use small ( or = 6 letters) abbreviations. Do you have advices about that ? Is there any abbreviation convention ? Regards ___ 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 -- *** * Nan Galbraith(508) 289-2444 * * Upper Ocean Processes GroupMail Stop 29 * * Woods Hole Oceanographic Institution* * Woods Hole, MA 02543* *** ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] any convention for variables abbreviation ?
Hi Nan, Slight misunderstanding I fear. The p021 vocabulary is a vocabulary that MAPS to the CF Standard Names, but it doesn't include the Standard Names themselves. What I think Nicolas is after is something slightly different, namely a standardised 6-byte representation for each Standard Name. We do maintain opaque codes for Standard Names in our server, but unfortunately these are 8 bytes long, not 6 so I didn't offer them. Cheers, Roy. From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Nan Galbraith [ngalbra...@whoi.edu] Sent: 14 February 2013 13:58 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] any convention for variables abbreviation ? SeaDataNet has standardized short names - currently 429 names, and as far as I know all the CF terms are included. It's available at tinyurl.com/SDNp021 The long url for the p021 list is seadatanet.maris2.nl/v_bodc_vocab/browse.asp?order=entrykeyformname=searchscreen=0l=P021v0_0=v1_0=entrykey%2Centryterm%2Centrytermabbr%2Centrytermdef%2Centrytermlastmodv2_0=0v0_1=v1_1=entrykeyv2_1=3v0_2=v1_2=entrytermv2_2=3v0_3=v1_3=entrytermabbrv2_3=3v0_4=v1_4=entrytermlastmodv2_4=9v0_5=v1_5=entrytermlastmodv2_5=10x=49y=12v1_6=v2_6=v1_7=v2_7= or you can just google SeaDataNet Parameter Discovery Vocabulary You can export the list from that page into an xml file, or search for individual terms. - Nan On 2/13/13 7:28 PM, Steve Hankin wrote: Hi Nicolas, Various organizations enforce their own standards for abbreviated names in CF files -- OceanSites, Argo, WMO, CF, itself, does not. The reason that CF does not attempt to standardize the names of variables (which is how the abbreviations are used in the above cases), is to leave open the possibility that a single file may contain multiple variables representing the same quantity. For example, SST as measured by satellite and as measured in situ could potentially be in the same file. The long_name attribute can be used to differentiate how multiple representations of the same variable were derived. - Steve === On 2/13/2013 3:00 PM, Nicolas BALDECK - OpenMeteoData wrote: Dear, I'm designing a webservice for broadcasting some meteorological data. I will use the CF naming convention for variables names, but I also have to use small ( or = 6 letters) abbreviations. Do you have advices about that ? Is there any abbreviation convention ? Regards ___ 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 -- *** * Nan Galbraith(508) 289-2444 * * Upper Ocean Processes GroupMail Stop 29 * * Woods Hole Oceanographic Institution* * Woods Hole, MA 02543* *** ___ 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
[CF-metadata] Fwd: [galeon] Fwd: [Tc] OGC Approves Climate and Forecast (CF) extension to NetCDF Core data model standard
fyi -- CF adopted as an OGC standard (sorry for double postings) ---BeginMessage--- -- Forwarded message -- From: annou...@opengeospatial.org Date: Thu, Feb 14, 2013 at 1:18 PM Subject: [Tc] OGC Approves Climate and Forecast (CF) extension to NetCDF Core data model standard To: t...@lists.opengeospatial.org FOR IMMEDIATE RELEASE Contact: i...@opengeospatial.org mailto:i...@opengeospatial.org *OGC Approves Climate and Forecast (CF) extension to NetCDF Core data model standard* 14 February 2013 - The Open Geospatial Consortium (OGC®) membership has adopted the OGC CF-netCDF Data Model extension to the existing OGC Network Common Data Form (NetCDF) Core Encoding Standard version 1.0. The CF-netCDF Data Model is a flexible data model widely used in climate and weather forecast systems and in other geoscience communities. The CF conventions define metadata that provide a definitive description of what the data in each netCDF variable represents, and the spatial and temporal properties of the data. This enables users of data from different sources to decide which quantities are comparable, and facilitates building applications with powerful extraction, regridding, and display capabilities. The candidate CF-netCDF Data Model extension to the existing OGC Network Common Data Form (NetCDF) Core Encoding Standard version 1.0 is the latest step in a longer-term plan for establishing CF-netCDF as an OGC standard for binary encoding. This will enable standard delivery of data in binary form via several OGC service interface standards, including the OGC Web Coverage Service (WCS), Web Feature Service (WFS), and Sensor Observation Service (SOS) Interface Standards. The OGC CF-netCDF encoding supports electronic encoding of geospatial data, specifically digital geospatial information representing space- and time-varying phenomena. NetCDF (network Common Data Form) is widely used internationally to communicate and store many kinds of multidimensional data, although it was originally developed for the Earth science community. The NetCDF data model is particularly well suited to providing data in forms familiar to atmospheric and oceanic scientists: namely, as sets of related arrays. NetCDF was developed and is maintained and actively supported by the Unidata Program Center of the University Corporation for Atmospheric Research (UCAR) (www.unidata.ucar.edu http://www.unidata.ucar.edu/ ), and UCAR is the OGC member that submitted this candidate standard to the OGC. The OGC NetCDF Core Encoding Standard has been formally recognized by US Government NASA and NOAA standards bodies. UCAR and other OGC members introduced the first NetCDF specification as a candidate OGC standard to encourage broader international use and greater interoperability among clients and servers interchanging data in binary form. The CF-netCDF Data Model extension to the existing OGC Network Common Data Form (NetCDF) Core Encoding Standard version 1.0 is available along with other netCDF standards and a netCDF Primer at http://www.opengeospatial.org/standards/netcdf . The OGC is an international consortium of more than 480 companies, government agencies, research organizations, and universities participating in a consensus process to develop publicly available geospatial standards. OGC Standards support interoperable solutions that geo-enable the Web, wireless and location-based services, and mainstream IT. OGC Standards empower technology developers to make geospatial information and services accessible and useful with any application that needs to be geospatially enabled. Visit the OGC website at http://www.opengeospatial.org/contact . -- If you do not want to receive any more messages, please visit http://lists.opengeospatial.org/lists/?p=unsubscribeuid=95b724f0363676f9f8f0a7d04519e388 To update your preferences and to unsubscribe visit http://lists.opengeospatial.org/lists/?p=preferencesuid=95b724f0363676f9f8f0a7d04519e388 To forward a message to someone you may use http://lists.opengeospatial.org/lists/?p=forwarduid=95b724f0363676f9f8f0a7d04519e388mid=153 ___ Tc mailing list t...@lists.opengeospatial.org https://lists.opengeospatial.org/mailman/listinfo/tc All OGC members are strongly encouraged to maintain a subscription to this list. -- Ben ___ galeon mailing list gal...@unidata.ucar.edu For list information, to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/ ---End Message--- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Ancillary Data
Hi Mark, We are using the ancilliary_variables attribute in a real world case for CTD profile data (1 netCDF per CTD profile). Not sure if our use case fits with with your examples a,b,c but here is a abbreviated CDL version:- dimensions: pressure = UNLIMITED ; // (9 currently) variables: double time ; time:standard_name = time ; byte time_qc_flag; time_qc_flag:long_name = quality control flag for time (Level 1 flag) ; double latitude ; latitude:standard_name = latitude ; ... double longitude ; longitude:standard_name = longitude ; ... byte position_qc_flag; position_qc_flag:long_name = quality control flag for position (Level 1 flag) ; double pressure(pressure) ; pressure:standard_name = sea_water_pressure ; ... double temperature(pressure) ; temperature:_FillValue = -99.99 ; temperature:standard_name = sea_water_temperature ; temperature:units = degrees_C ; temperature:valid_min = -2 ; temperature:valid_max = 40 ; temperature:ancillary_variables = temperature_whole_profile_flag temperature_qc_flag temperature_sd_test ; temperature:coordinates = time latitude longitude pressure ; byte temperature_whole_profile_flag ; temperature_whole_profile_flag:long_name = qc flag for whole temperature profile (primary L1 flag) ; temperature_whole_profile_flag:quality_control_convention = Proposed IODE qc scheme March 2012 ; temperature_whole_profile_flag:valid_min = 1 ; temperature_whole_profile_flag:valid_max = 9 ; temperature_whole_profile_flag:flag_values = 1b, 2b, 3b, 4b, 9b ; temperature_whole_profile_flag:flag_meanings = good not_evaluated_or_unknown suspect bad missing ; byte temperature_qc_flag(pressure) ; temperature_qc_flag:long_name = quality control flag for temperature (primary Level 1 flag) ; temperature_qc_flag:standard_name = sea_water_temperature status_flag ; temperature_qc_flag:quality_control_convention = Proposed IODE qc scheme March 2012 ; temperature_qc_flag:valid_min = 1 ; temperature_qc_flag:valid_max = 9 ; temperature_qc_flag:flag_values = 1b, 2b, 3b, 4b, 9b ; temperature_qc_flag:flag_meanings = good not_evaluated_or_unknown suspect bad missing ; temperature_qc_flag:coordinates = time latitude longitude pressure ; byte temperature_sd_test(pressure) ; temperature_sd_test:long_name = qc flag for monthly temperature standard deviation test (secondary L2 flag) temperature_sd_test:quality_control_convention = Proposed IODE qc scheme March 2012 ; temperature_sd_test:valid_min = 0 ; temperature_sd_test:valid_max = 2 ; temperature_sd_test:flag_values = 0b, 1b, 2b ; temperature_sd_test:flag_meanings = passed failed unknown ; temperature_sd_test:coordinates = time latitude longitude pressure ; double salinity(pressure) ; salinity:_FillValue = -99.99 ; salinity:standard_name = sea_water_practical_salinity ; salinity:units = psu ; salinity:valid_min = 0 ; salinity:valid_max = 45 ; salinity:ancillary_variables = salinity_whole_profile_flag salinity_qc_flag salinity_sd_test salinity:coordinates = time latitude longitude pressure ; byte salinity_whole_profile_flag ; salinity_whole_profile_flag:long_name = qc flag for whole salinity profile (primary L1 flag) ; salinity_whole_profile_flag:quality_control_convention = Proposed IODE qc scheme March 2012 ; salinity_whole_profile_flag:valid_min = 1 ; salinity_whole_profile_flag:valid_max = 9 ; salinity_whole_profile_flag:flag_values = 1b, 2b, 3b, 4b, 9b ; salinity_whole_profile_flag:flag_meanings = good not_evaluated_or_unknown suspect bad missing ; byte salinity_qc_flag(pressure) ; salinity_qc_flag:long_name = quality control flag for salinity (primary Level 1 flag) ; salinity_qc_flag:standard_name = sea_water_practical_salinity status_flag ; salinity_qc_flag:quality_control_convention = Proposed IODE qc scheme March 2012 ; salinity_qc_flag:valid_min = 1 ; salinity_qc_flag:valid_max = 9 ; salinity_qc_flag:flag_values = 1b, 2b, 3b, 4b, 9b ; salinity_qc_flag:flag_meanings = good not_evaluated_or_unknown suspect bad missing ; salinity_qc_flag:coordinates = time latitude longitude pressure ; byte salinity_sd_test(pressure) ; salinity_sd_test:long_name = qc flag for monthly salinity standard deviation test (secondary L2 flag) salinity_sd_test:quality_control_convention = Proposed IODE qc scheme March 2012 ; salinity_sd_test:valid_min = 0 ; salinity_sd_test:valid_max = 2 ; salinity_sd_test:flag_values = 0b, 1b, 2b ; salinity_sd_test:flag_meanings = passed failed unknown ; salinity_sd_test:coordinates = time latitude longitude pressure ; int profile ; //Unique integer to identify each profile profile:long_name = profile identifier Andrew Walsh - Original Message - From: Hedley, Mark mark.hed...@metoffice.gov.uk To: ngalbra...@whoi.edu; cf-metadata@cgd.ucar.edu Sent: Thursday, February 14, 2013 10:40 PM Subject: Re: [CF-metadata] Ancillary Data Hi Nan I think I understand you approach, it seems logical and helpful to
