Re: [CF-metadata] New CoordinateType: Spectral?
Dear Randy With the growing interest in the CF conventions around the world by the satellite CF data producer and user communities coupled with the ubiquitous nature of wavelength-based satellite CF data sets, does it make sense to add a paragraph to Section 4 Coordinate Types to discuss Spectral Coordinates ? As Roy pointed out, spectral is a word with several meanings. In principle it should not be necessary add anything, because CF already permits coordinate variables in any quantity. However, perhaps this is not stated clearly enough. My suggestion would be * Delete the sentence, Coordinate types other than latitude, longitude, vertical, and time are allowed at the start of the third para of section 4. * Insert new text at the start of the section: The commonest use of coordinate variables is to locate the data in space and time, but coordinates may be provided for any other continuous geophysical quantity (e.g. density, temperature, radiation wavelength, zenith angle of radiance, sea surface wave frequency) or discrete category (see Section 4.5, Discrete axis, e.g. area type, model level number, ensemble member number) on which the data variable depends. continuing with the existing text, Four types of coordinates Would that help? Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New CoordinateType: Spectral?
Jonathan: Yes, that would be helpful as it would make it clear that radiation wavelength can indeed be a coordinate variable. very respectfully, randy From: Jonathan Gregory j.m.greg...@reading.ac.uk Sent: Thursday, April 11, 2013 3:45 PM To: rho...@excaliburlabs.com rho...@excaliburlabs.com Cc: cf-satell...@unidata.ucar.edu, cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New CoordinateType: Spectral? Dear Randy With the growing interest in the CF conventions around the world by the satellite CF data producer and user communities coupled with the ubiquitous nature of wavelength-based satellite CF data sets, does it make sense to add a paragraph to Section 4 Coordinate Types to discuss Spectral Coordinates ? As Roy pointed out, spectral is a word with several meanings. In principle it should not be necessary add anything, because CF already permits coordinate variables in any quantity. However, perhaps this is not stated clearly enough. My suggestion would be * Delete the sentence, Coordinate types other than latitude, longitude, vertical, and time are allowed at the start of the third para of section 4. * Insert new text at the start of the section: The commonest use of coordinate variables is to locate the data in space and time, but coordinates may be provided for any other continuous geophysical quantity (e.g. density, temperature, radiation wavelength, zenith angle of radiance, sea surface wave frequency) or discrete category (see Section 4.5, Discrete axis, e.g. area type, model level number, ensemble member number) on which the data variable depends. continuing with the existing text, Four types of coordinates Would that help? Cheers Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] New CoordinateType: Spectral?
Jonathan: With the growing interest in the CF conventions around the world by the satellite CF data producer and user communities coupled with the ubiquitous nature of wavelength-based satellite CF data sets, does it make sense to add a paragraph to Section 4 Coordinate Types to discuss Spectral Coordinates ? very respectfully, randy Dear Aleksandar I know this will likely end up as a trac ticket but would like first to gauge the community's opinion about defining a new coordinate type. Satellite data originates as measurements at a number of intervals of the electromagnetic spectrum. These intervals are commonly referred to as bands or channels. Deciding on how to store the band information is one of the key issues toward a standardized representation for satellite data.The convention seems to allow storing of band information either as a numerical coordinate variable or as a string auxiliary coordinate variable. Yes, the CF standard could handle both of those, without any modification. A trac ticket may not be needed. I certainly think there is no problem at all for a numerical coordinate of band wavelength. You need only to propose a new standard name for it, if one is needed. There is already a generic standard name of radiation_wavelength, included for use as a coord variable just as in your first example. If you need something more specific, I would suggest sensor_radiation_wavelength. The coord values for this would be the central wavelengths, and you could also supply bounds specifying the range of wavelengths covered by the sensor. Although string-valued auxiliary coordinate variables are possible already, as used in your second example, I would argue they are less useful as metadata than numerical ranges. That is because the main use of CF is to support intercomparison of datasets, which is better-defined if numbers are used. If there are widely used definitions of named wavelength bands, required for intercomparison of many datasets, a standard_name could be defined with a number of permitted string values. I think this extension could probably be seen as a new standard_name, not requiring a change to the conventions, although it could be explicitly mentioned in section 6 like Roy is proposing for biological taxa. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New CoordinateType: Spectral?
Hello Randy, If doing this, please make it clear that by 'Spectral' you mean 'wavelength spectral'. There are other types of spectra, such as frequency (used for wave spectra) and size (used optical plankton counters and other particle sizers). Cheers, Roy. Please note that I now work part-time from Tuesday to Thursday. E-mail response on other days is possible but not guaranteed! From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of rho...@excaliburlabs.com Sent: 10 April 2013 14:20 To: cf-satell...@unidata.ucar.edu; cf-metadata@cgd.ucar.edu Subject: [CF-metadata] New CoordinateType: Spectral? Jonathan: With the growing interest in the CF conventions around the world by the satellite CF data producer and user communities coupled with the ubiquitous nature of wavelength-based satellite CF data sets, does it make sense to add a paragraph to Section 4 Coordinate Types to discuss Spectral Coordinates ? very respectfully, randy Dear Aleksandar I know this will likely end up as a trac ticket but would like first to gauge the community's opinion about defining a new coordinate type. Satellite data originates as measurements at a number of intervals of the electromagnetic spectrum. These intervals are commonly referred to as bands or channels. Deciding on how to store the band information is one of the key issues toward a standardized representation for satellite data. The convention seems to allow storing of band information either as a numerical coordinate variable or as a string auxiliary coordinate variable. Yes, the CF standard could handle both of those, without any modification. A trac ticket may not be needed. I certainly think there is no problem at all for a numerical coordinate of band wavelength. You need only to propose a new standard name for it, if one is needed. There is already a generic standard name of radiation_wavelength, included for use as a coord variable just as in your first example. If you need something more specific, I would suggest sensor_radiation_wavelength. The coord values for this would be the central wavelengths, and you could also supply bounds specifying the range of wavelengths covered by the sensor. Although string-valued auxiliary coordinate variables are possible already, as used in your second example, I would argue they are less useful as metadata than numerical ranges. That is because the main use of CF is to support intercomparison of datasets, which is better-defined if numbers are used. If there are widely used definitions of named wavelength bands, required for intercomparison of many datasets, a standard_name could be defined with a number of permitted string values. I think this extension could probably be seen as a new standard_name, not requiring a change to the conventions, although it could be explicitly mentioned in section 6 like Roy is proposing for biological taxa. Best wishes Jonathan 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] New CoordinateType: Spectral?
Dear Aleksandar I know this will likely end up as a trac ticket but would like first to gauge the community's opinion about defining a new coordinate type. Satellite data originates as measurements at a number of intervals of the electromagnetic spectrum. These intervals are commonly referred to as bands or channels. Deciding on how to store the band information is one of the key issues toward a standardized representation for satellite data. The convention seems to allow storing of band information either as a numerical coordinate variable or as a string auxiliary coordinate variable. Yes, the CF standard could handle both of those, without any modification. A trac ticket may not be needed. I certainly think there is no problem at all for a numerical coordinate of band wavelength. You need only to propose a new standard name for it, if one is needed. There is already a generic standard name of radiation_wavelength, included for use as a coord variable just as in your first example. If you need something more specific, I would suggest sensor_radiation_wavelength. The coord values for this would be the central wavelengths, and you could also supply bounds specifying the range of wavelengths covered by the sensor. Although string-valued auxiliary coordinate variables are possible already, as used in your second example, I would argue they are less useful as metadata than numerical ranges. That is because the main use of CF is to support intercomparison of datasets, which is better-defined if numbers are used. If there are widely used definitions of named wavelength bands, required for intercomparison of many datasets, a standard_name could be defined with a number of permitted string values. I think this extension could probably be seen as a new standard_name, not requiring a change to the conventions, although it could be explicitly mentioned in section 6 like Roy is proposing for biological taxa. Best wishes Jonathan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] New CoordinateType: Spectral?
Dear All, I know this will likely end up as a trac ticket but would like first to gauge the community's opinion about defining a new coordinate type. Satellite data originates as measurements at a number of intervals of the electromagnetic spectrum. These intervals are commonly referred to as bands or channels. Deciding on how to store the band information is one of the key issues toward a standardized representation for satellite data. The convention seems to allow storing of band information either as a numerical coordinate variable or as a string auxiliary coordinate variable. When I open such a file in Unidata's ToolsUI software (the CoordSys tab) and select Parse Info, this is reported: userAdviceCoordinate Axis band does not have an assigned AxisType/userAdvice Following this advice I have two questions: 1) What would be the benefits of having a coordinate type for describing satellite bands? Let's call this new type spectral for now. 2) Can the same coordinate type be assigned to both numerical and string variables? Such variables will not appear in the same file. String band information will cover cases where purely numerical band information is not sufficient to describe different bands, like for passive microwave instruments. I have included two examples in the P.S. section below to illustrate the concept. -Aleksandar P.S. Variant #1: Band information as a numerical coordinate variable dimensions: along_track = integer ; across_track = integer ; band = integer ; variables: short along_track(along_track) ; along_track:axis = Y ; short across_track(across_track) ; across_track:axis = X ; float band(band) ; band:standard_name = “sensor_band_central_wavelength” ; // proposed standard name in Nov 2012 band:units = “um” ; float lat(along_track, across_track) ; lat:standard_name = latitude ; lat:units = degrees_north ; float lon(along_track, across_track) ; lon:standard_name = longitude ; lon:units = degrees_east ; double time(along_track) ; time:standard_name = time ; time:units = units since datetime string ; time:calendar = gregorian ; float swath_band_data(along_track, across_track, band) ; swath_band_data:coordinates = lon lat time band ; Variant #2: Band information as a string auxiliary coordinate variable dimensions: along_track = integer ; across_track = integer ; band_enum = integer ; band_strlen = integer ; variables: short along_track(along_track) ; along_track:axis = Y ; short across_track(across_track) ; across_track:axis = X ; char band(band_enum, band_strlen) ; band:standard_name = “sensor_band_identifier” ; // proposed standard name in Nov 2012 float lat(along_track, across_track) ; lat:standard_name = latitude ; lat:units = degrees_north ; float lon(along_track, across_track) ; lon:standard_name = longitude ; lon:units = degrees_east ; double time(along_track) ; time:standard_name = time ; time:units = units since epoch ; time:calendar = gregorian ; float swath_band_data(along_track, across_track, band_enum) ; swath_band_data:coordinates = lon lat time band ; ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New CoordinateType: Spectral?
Aleksander: This has come up before on CF-satellite. checkout: http://www.unidata.ucar.edu/mailing_lists/archives/cf-satellite/2011/msg00025.html very respectfully, randy From: Aleksandar Jelenak - NOAA Affiliate aleksandar.jele...@noaa.gov Sent: Thursday, April 04, 2013 3:09 PM To: cf-metadata@cgd.ucar.edu cf-metadata@cgd.ucar.edu Subject: [CF-metadata] New CoordinateType: Spectral? Dear All, I know this will likely end up as a trac ticket but would like first to gauge the community's opinion about defining a new coordinate type. Satellite data originates as measurements at a number of intervals of the electromagnetic spectrum. These intervals are commonly referred to as bands or channels. Deciding on how to store the band information is one of the key issues toward a standardized representation for satellite data. The convention seems to allow storing of band information either as a numerical coordinate variable or as a string auxiliary coordinate variable. When I open such a file in Unidata's ToolsUI software (the CoordSys tab) and select Parse Info, this is reported: userAdviceCoordinate Axis band does not have an assigned AxisType/userAdvice Following this advice I have two questions: 1) What would be the benefits of having a coordinate type for describing satellite bands? Let's call this new type spectral for now. 2) Can the same coordinate type be assigned to both numerical and string variables? Such variables will not appear in the same file. String band information will cover cases where purely numerical band information is not sufficient to describe different bands, like for passive microwave instruments. I have included two examples in the P.S. section below to illustrate the concept. -Aleksandar P.S. Variant #1: Band information as a numerical coordinate variable dimensions: along_track = integer ; across_track = integer ; band = integer ; variables: short along_track(along_track) ; along_track:axis = Y ; short across_track(across_track) ; across_track:axis = X ; float band(band) ; band:standard_name = sensor_band_central_wavelength ; // proposed standard name in Nov 2012 band:units = um ; float lat(along_track, across_track) ; lat:standard_name = latitude ; lat:units = degrees_north ; float lon(along_track, across_track) ; lon:standard_name = longitude ; lon:units = degrees_east ; double time(along_track) ; time:standard_name = time ; time:units = units since datetime string ; time:calendar = gregorian ; float swath_band_data(along_track, across_track, band) ; swath_band_data:coordinates = lon lat time band ; Variant #2: Band information as a string auxiliary coordinate variable dimensions: along_track = integer ; across_track = integer ; band_enum = integer ; band_strlen = integer ; variables: short along_track(along_track) ; along_track:axis = Y ; short across_track(across_track) ; across_track:axis = X ; char band(band_enum, band_strlen) ; band:standard_name = sensor_band_identifier ; // proposed standard name in Nov 2012 float lat(along_track, across_track) ; lat:standard_name = latitude ; lat:units = degrees_north ; float lon(along_track, across_track) ; lon:standard_name = longitude ; lon:units = degrees_east ; double time(along_track) ; time:standard_name = time ; time:units = units since epoch ; time:calendar = gregorian ; float swath_band_data(along_track, across_track, band_enum) ; swath_band_data:coordinates = lon lat time band ; ___ 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
