Re: [CF-metadata] the use of two different unlimited dimensions in two data variables
Hi Randy, well, if you want to stick to the _classic_ data model, then I think you will have to stick with a single unlimited dimension only. As I understand the netcdf FAQ (http://www.unidata.ucar.edu/software/netcdf/#fv18) you would have to use the enhanced NetCDF-4 format to be able to include multiple unlimited dimensions - and this will break compatibility with the NetCDF-3 format. I'm not really sure about implications regarding CF-conformity. There are some paragraphs that refer to the unlimited dimension concerning dimension order of variables for example. So multiple unlimited dimensions might break this requirement... Regards, Michael On 28.08.2012 22:59, Randy Horne wrote: For the GOES-R product files, the plan is to use the NetCDF4 file format and the classic data model. Is it CF compliant if a NetCDF dataset/file uses two different unlimited dimensions in two data variables ? very respectfully, randy ..End of Message ...-- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Michael Decker Forschungszentrum Jülich Institut für Energie- und Klimaforschung - Troposphäre (IEK-8) Tel.: +49 2461 61-3867 E-Mail: m.dec...@fz-juelich.de Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt smime.p7s Description: S/MIME Cryptographic Signature ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] the use of two different unlimited dimensions in two data variables
Hi. If each variable uses only one of the unlimited dimensions, then I think you are CF compliant. Grace and peace, Jim 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 On Aug 30, 2012, at 2:43 AM, Michael Decker m.dec...@fz-juelich.de wrote: Hi Randy, well, if you want to stick to the _classic_ data model, then I think you will have to stick with a single unlimited dimension only. As I understand the netcdf FAQ (http://www.unidata.ucar.edu/software/netcdf/#fv18) you would have to use the enhanced NetCDF-4 format to be able to include multiple unlimited dimensions - and this will break compatibility with the NetCDF-3 format. I'm not really sure about implications regarding CF-conformity. There are some paragraphs that refer to the unlimited dimension concerning dimension order of variables for example. So multiple unlimited dimensions might break this requirement... Regards, Michael On 28.08.2012 22:59, Randy Horne wrote: For the GOES-R product files, the plan is to use the NetCDF4 file format and the classic data model. Is it CF compliant if a NetCDF dataset/file uses two different unlimited dimensions in two data variables ? very respectfully, randy ..End of Message ...-- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Michael Decker Forschungszentrum Jülich Institut für Energie- und Klimaforschung - Troposphäre (IEK-8) Tel.: +49 2461 61-3867 E-Mail: m.dec...@fz-juelich.de Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ___ 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] the use of two different unlimited dimensions in two data variables
I agree. I cannot find anything in CF that would be violated if you only use one unlimited dimension per variable. Michael On 30.08.2012 15:44, Jim Biard wrote: Hi. If each variable uses only one of the unlimited dimensions, then I think you are CF compliant. Grace and peace, Jim 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 On Aug 30, 2012, at 2:43 AM, Michael Decker m.dec...@fz-juelich.de mailto:m.dec...@fz-juelich.de wrote: Hi Randy, well, if you want to stick to the _classic_ data model, then I think you will have to stick with a single unlimited dimension only. As I understand the netcdf FAQ (http://www.unidata.ucar.edu/software/netcdf/#fv18) you would have to use the enhanced NetCDF-4 format to be able to include multiple unlimited dimensions - and this will break compatibility with the NetCDF-3 format. I'm not really sure about implications regarding CF-conformity. There are some paragraphs that refer to the unlimited dimension concerning dimension order of variables for example. So multiple unlimited dimensions might break this requirement... Regards, Michael On 28.08.2012 22:59, Randy Horne wrote: For the GOES-R product files, the plan is to use the NetCDF4 file format and the classic data model. Is it CF compliant if a NetCDF dataset/file uses two different unlimited dimensions in two data variables ? very respectfully, randy ..End of Message ...-- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu mailto:CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Michael Decker Forschungszentrum Jülich Institut für Energie- und Klimaforschung - Troposphäre (IEK-8) Tel.: +49 2461 61-3867 E-Mail: m.dec...@fz-juelich.de mailto:m.dec...@fz-juelich.de Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu mailto: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 -- Michael Decker Forschungszentrum Jülich Institut für Energie- und Klimaforschung - Troposphäre (IEK-8) Tel.: +49 2461 61-3867 E-Mail: m.dec...@fz-juelich.de Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt smime.p7s Description: S/MIME Cryptographic Signature ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] the use of two different unlimited dimensions in two data variables
Thanks for the input. My thinking is that despite the fact that it is not supported by the classic data model (according to the NetCDF users guide), it is hard to understand why there would be an issue from a CF standpoint to take advantage of a netCDF4 file format capability. One could argue that the constraint is really associated with the NetCDF3 file format rather than the classic data model. very respectfully, randy On Aug 30, 2012, at 9:49 AM, Michael Decker wrote: I agree. I cannot find anything in CF that would be violated if you only use one unlimited dimension per variable. Michael On 30.08.2012 15:44, Jim Biard wrote: Hi. If each variable uses only one of the unlimited dimensions, then I think you are CF compliant. Grace and peace, Jim 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 On Aug 30, 2012, at 2:43 AM, Michael Decker m.dec...@fz-juelich.de mailto:m.dec...@fz-juelich.de wrote: Hi Randy, well, if you want to stick to the _classic_ data model, then I think you will have to stick with a single unlimited dimension only. As I understand the netcdf FAQ (http://www.unidata.ucar.edu/software/netcdf/#fv18) you would have to use the enhanced NetCDF-4 format to be able to include multiple unlimited dimensions - and this will break compatibility with the NetCDF-3 format. I'm not really sure about implications regarding CF-conformity. There are some paragraphs that refer to the unlimited dimension concerning dimension order of variables for example. So multiple unlimited dimensions might break this requirement... Regards, Michael On 28.08.2012 22:59, Randy Horne wrote: For the GOES-R product files, the plan is to use the NetCDF4 file format and the classic data model. Is it CF compliant if a NetCDF dataset/file uses two different unlimited dimensions in two data variables ? very respectfully, randy ..End of Message ...-- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu mailto:CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Michael Decker Forschungszentrum Jülich Institut für Energie- und Klimaforschung - Troposphäre (IEK-8) Tel.: +49 2461 61-3867 E-Mail: m.dec...@fz-juelich.de mailto:m.dec...@fz-juelich.de Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu mailto: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 -- Michael Decker Forschungszentrum Jülich Institut für Energie- und Klimaforschung - Troposphäre (IEK-8) Tel.: +49 2461 61-3867 E-Mail: m.dec...@fz-juelich.de Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata Randy C. Horne (rho...@excaliburlabs.com) Principal Engineer, Excalibur Laboratories Inc. voice fax: (321) 952.5100 url:
Re: [CF-metadata] the use of two different unlimited dimensions in two data variables
I'm not sure that CF requires you to have only one unlimited dimension per variable, but if you create a netCDF-4 file with the classic option enabled, the API may not allow you to do so. 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 On Aug 30, 2012, at 11:04 AM, Randy Horne rho...@excaliburlabs.com wrote: Thanks for the input. My thinking is that despite the fact that it is not supported by the classic data model (according to the NetCDF users guide), it is hard to understand why there would be an issue from a CF standpoint to take advantage of a netCDF4 file format capability. One could argue that the constraint is really associated with the NetCDF3 file format rather than the classic data model. very respectfully, randy On Aug 30, 2012, at 9:49 AM, Michael Decker wrote: I agree. I cannot find anything in CF that would be violated if you only use one unlimited dimension per variable. Michael On 30.08.2012 15:44, Jim Biard wrote: Hi. If each variable uses only one of the unlimited dimensions, then I think you are CF compliant. Grace and peace, Jim 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 On Aug 30, 2012, at 2:43 AM, Michael Decker m.dec...@fz-juelich.de mailto:m.dec...@fz-juelich.de wrote: Hi Randy, well, if you want to stick to the _classic_ data model, then I think you will have to stick with a single unlimited dimension only. As I understand the netcdf FAQ (http://www.unidata.ucar.edu/software/netcdf/#fv18) you would have to use the enhanced NetCDF-4 format to be able to include multiple unlimited dimensions - and this will break compatibility with the NetCDF-3 format. I'm not really sure about implications regarding CF-conformity. There are some paragraphs that refer to the unlimited dimension concerning dimension order of variables for example. So multiple unlimited dimensions might break this requirement... Regards, Michael On 28.08.2012 22:59, Randy Horne wrote: For the GOES-R product files, the plan is to use the NetCDF4 file format and the classic data model. Is it CF compliant if a NetCDF dataset/file uses two different unlimited dimensions in two data variables ? very respectfully, randy ..End of Message ...-- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu mailto:CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Michael Decker Forschungszentrum Jülich Institut für Energie- und Klimaforschung - Troposphäre (IEK-8) Tel.: +49 2461 61-3867 E-Mail: m.dec...@fz-juelich.de mailto:m.dec...@fz-juelich.de Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu mailto: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 -- Michael Decker Forschungszentrum Jülich Institut für Energie- und Klimaforschung - Troposphäre (IEK-8) Tel.: +49 2461 61-3867 E-Mail: m.dec...@fz-juelich.de Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: [CF-metadata] example of sea_surface_wave_directional_variance_spectral_density
Hi Roy, There are some fairly explicit statements in chapter 9 that mean treating 'z' as frequency would break the convention. From 9.1: profile = an ordered set of data points along a vertical line ... The spatial coordinate z refers to vertical position. And it's not clear that you could add an additional dimension for the frequency. (That said, it's also not completely clear that you shouldn't.) Looks like CF would benefit from your BODC feature types. Regards, Richard Hattersley AVD Iris Technical Lead Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom Tel: +44 (0)1392 885702 Fax: +44 (0)1392 885681 Email: richard.hatters...@metoffice.gov.uk Website: www.metoffice.gov.uk -Original Message- From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K. Sent: 29 August 2012 16:26 To: Ellyn Montgomery Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] example of sea_surface_wave_directional_variance_spectral_density Hi again, Within BODC, we address your concerns by having a much richer set of feature types that include concepts like timeSeriesSpectrum to indicate that the z-axis is non-spatial and so give display clients a bit more help. However, I think that with the right parameter attribute semantic information and the CF feature types we should be OK in SeaDataNet. My thinking so far has been confined to non-directional spectra. I can't see how directional spectra could be handled in CF without specification of an additional feature type, but (not for the first time) I might be misunderstanding something in John's view of feature types. Cheers, Roy. -Original Message- From: Ellyn Montgomery [mailto:emontgom...@usgs.gov] Sent: 29 August 2012 15:47 To: Lowry, Roy K. Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] example of sea_surface_wave_directional_variance_spectral_density Roy- I'm glad that it's on your plate! Conceptually, I am a bit uncomfortable with having frequency as Z since many of us think of Z as depth/altitude. Having frequency as Z fits the shapes allowed, but I wonder what confusion it would start. Are there ways for clients to identify Z as a non-depth content? Is it as simple as calling the Z coordinate frequency instead of depth, and then clients would be able to know what to do? Then of course the direction component would need to be wedged into the coordinate system somehow. Such fun! Looking forward to the discussion! Ellyn On 08/29/2012 09:54 AM, Lowry, Roy K. wrote: Hi Ellyn, Encoding wave spectra in a CF-compliant manner is an issue that I plan to address on behalf of SeaDataNet in the next month or so. The point I'd reached in thinking this through was to use the timeSeriesProfile feature type with frequency as the z co-ordinate. I think this OK, but if not I'm sure somebody on this list will shout. I prefer single-value vectors rather to scalars because it opens the way to packaging multiple instances into a single NetCDF file. Cheers, Roy. -Original Message- From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ellyn Montgomery Sent: 28 August 2012 15:04 To: cf-metadata@cgd.ucar.edu Subject: [CF-metadata] example of sea_surface_wave_directional_variance_spectral_density Hello folks- We want our wave data observations to be CF compliant, with the dimensions and representation of time correct. I believe the data we collect fits somewhere under Discrete Samples, since we end up with a time series of wave spectra from our stationary, bottom-mounted acoustic instruments. I couldn't find how the file might look in the 1.6 conventions document or appendices, so could someone please direct me to an example dataset that includes some wave spectra? Help with which featureType should be used would also be appreciated. The Standard Name table says the dimension order should be S(t,x,y,f,theta). Since our data is from a point observation (lat and lon are size (1)), can the X,Y dimensions be dropped, or are they needed as place-holders? Thanks very much for the help! Ellyn -- Ellyn T. Montgomery, Oceanographer and Data Manager U.S. Geological Survey Woods Hole Coastal and Marine Science Center 384 Woods Hole Road, Woods Hole, MA 02543-1598 (508)457-2356 -- 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] example of sea_surface_wave_directional_variance_spectral_density
Hi Richard, I had a feeling it might. The reason I've got frequency and profile depth linked together in my mind is because of the structural similarity between plots of moored ADCP data and 1D wave spectra (just a change of axis label). Cheers, Roy. -Original Message- From: Hattersley, Richard [mailto:richard.hatters...@metoffice.gov.uk] Sent: 30 August 2012 16:52 To: Lowry, Roy K.; Ellyn Montgomery Cc: cf-metadata@cgd.ucar.edu Subject: RE: [CF-metadata] example of sea_surface_wave_directional_variance_spectral_density Hi Roy, There are some fairly explicit statements in chapter 9 that mean treating 'z' as frequency would break the convention. From 9.1: profile = an ordered set of data points along a vertical line ... The spatial coordinate z refers to vertical position. And it's not clear that you could add an additional dimension for the frequency. (That said, it's also not completely clear that you shouldn't.) Looks like CF would benefit from your BODC feature types. Regards, Richard Hattersley AVD Iris Technical Lead Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom Tel: +44 (0)1392 885702 Fax: +44 (0)1392 885681 Email: richard.hatters...@metoffice.gov.uk Website: www.metoffice.gov.uk -Original Message- From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K. Sent: 29 August 2012 16:26 To: Ellyn Montgomery Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] example of sea_surface_wave_directional_variance_spectral_density Hi again, Within BODC, we address your concerns by having a much richer set of feature types that include concepts like timeSeriesSpectrum to indicate that the z-axis is non-spatial and so give display clients a bit more help. However, I think that with the right parameter attribute semantic information and the CF feature types we should be OK in SeaDataNet. My thinking so far has been confined to non-directional spectra. I can't see how directional spectra could be handled in CF without specification of an additional feature type, but (not for the first time) I might be misunderstanding something in John's view of feature types. Cheers, Roy. -Original Message- From: Ellyn Montgomery [mailto:emontgom...@usgs.gov] Sent: 29 August 2012 15:47 To: Lowry, Roy K. Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] example of sea_surface_wave_directional_variance_spectral_density Roy- I'm glad that it's on your plate! Conceptually, I am a bit uncomfortable with having frequency as Z since many of us think of Z as depth/altitude. Having frequency as Z fits the shapes allowed, but I wonder what confusion it would start. Are there ways for clients to identify Z as a non-depth content? Is it as simple as calling the Z coordinate frequency instead of depth, and then clients would be able to know what to do? Then of course the direction component would need to be wedged into the coordinate system somehow. Such fun! Looking forward to the discussion! Ellyn On 08/29/2012 09:54 AM, Lowry, Roy K. wrote: Hi Ellyn, Encoding wave spectra in a CF-compliant manner is an issue that I plan to address on behalf of SeaDataNet in the next month or so. The point I'd reached in thinking this through was to use the timeSeriesProfile feature type with frequency as the z co-ordinate. I think this OK, but if not I'm sure somebody on this list will shout. I prefer single-value vectors rather to scalars because it opens the way to packaging multiple instances into a single NetCDF file. Cheers, Roy. -Original Message- From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ellyn Montgomery Sent: 28 August 2012 15:04 To: cf-metadata@cgd.ucar.edu Subject: [CF-metadata] example of sea_surface_wave_directional_variance_spectral_density Hello folks- We want our wave data observations to be CF compliant, with the dimensions and representation of time correct. I believe the data we collect fits somewhere under Discrete Samples, since we end up with a time series of wave spectra from our stationary, bottom-mounted acoustic instruments. I couldn't find how the file might look in the 1.6 conventions document or appendices, so could someone please direct me to an example dataset that includes some wave spectra? Help with which featureType should be used would also be appreciated. The Standard Name table says the dimension order should be S(t,x,y,f,theta). Since our data is from a point observation (lat and lon are size (1)), can the X,Y dimensions be dropped, or are they needed as place-holders? Thanks very much for the help! Ellyn -- Ellyn T. Montgomery, Oceanographer and Data Manager U.S. Geological Survey Woods Hole Coastal and Marine Science Center 384 Woods Hole Road, Woods
