Re: [CF-metadata] New standard names for satellite obs data
Dear All, I'd just like to reinforce John's last point that the semantics of 'instrument' and 'platform' are becoming blurred in these discussions. From my perspective as one who has to map to CF datasets I would prefer it if the semantics of terms used in Standard Names had a universally understood meaning. Another point that struck me from John's response is that when we do have multiple data streams sharing a single Standard Name, we need to ensure that there are objective criteria (i.e. not plaintext in the longname) that enable each stream to be uniquely identified. Otherwise, even 'common concepts' (which incidentally will be worked during a workshop in November) won't deliver interoperability. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Aleksandar Jelenak Sent: 20 October 2010 01:33 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data Dear Evan, Thanks for your suggestions. Evan Manning wrote on 10/18/10 11:30 PM: The names below mix satellite and instrument differently than I'm used to. I started with satellite_* names but then wanted to generalize since remote sensing instruments are not only carried on satellites. But you brought up an important distinction that the observation geometry of an instrument can be different from the generic one associated with the entire spacecraft. I recommend changing: instrument_zenith_angle - satellite_zenith_angle instrument_azimuth_angle - satellite_azimuth_angle satellite_scan_angle - satellite_view_angle I think the instrument_* names are more applicable as they allow for either instrument-specific or spacecraft-generic geometries. I also think being able to distinguish between the two observation geometries is important and would like to have sets of standard names for both. So a data provider can clearly signal what is given, even for data from the same instrument. To summarize: 1) Use instrument_zenith_angle, instrument_azimuth_angle, and instrument_scan_angle for precise, instrument-specific observation geometry. 2) Use platform_zenith_angle, platform_azimuth_angle, and platform_view_angle for generic satellite (here generalized to platform) observation geometry. 3) Mixing names from these two sets is allowed, whatever is more applicable for the zenith, azimuth, and scan/view angle data. Too complicated? And add: instrument_scan_angle The angle between the line of sight from an instrument and its reference scan position. Agree. -Aleksandar ___ 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] New standard names for satellite obs data
On 19.10.2010 16:27, Seth McGinnis wrote: What about using 'date' for string-valued times? That was my homebrew solution when I was considering a similar problem. If I may butt in and contribute here, I usually prefer names like 'datetime' or 'timestamp' in cases like this, because 'date' is potentially confusing. It may not be immediately obvious to a future reader (or programmer) that a variable called 'date' supports points in time down to for example seconds of accuracy. (Note that string data is a big pain to deal with in NetCDF-3, because you're limited to fixed-length character arrays. You need to use NetCDF-4 / HDF5 to get Strings as a data type.) (It may not be such a practical issue with ISO 8601 strings, as a reasonable max. length can be determined, I presume.) -- Regards, -+-Ben-+- ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New standard names for satellite obs data
Dear All, Do we need to include any reference to instrument, platform or satellite? It seems to me that the complexity arises because the reference lines from which the angle is defined are different in different applications. Wouldn't it be better to use zenith_angle and scan_angle with respect to fixed reference lines and include an attribute that accounts for any offset with respect to that? For instance, scan_angle would be referenced against the nadir of the object. If the instrument is tilted with respect to that line and you want to represent the angle with respect to the reference instrument line of sight, then the offset will be /=0. Cheers, Alejandro -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K Sent: Wednesday, October 20, 2010 8:46 AM To: Aleksandar Jelenak; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data Dear All, I'd just like to reinforce John's last point that the semantics of 'instrument' and 'platform' are becoming blurred in these discussions. From my perspective as one who has to map to CF datasets I would prefer it if the semantics of terms used in Standard Names had a universally understood meaning. Another point that struck me from John's response is that when we do have multiple data streams sharing a single Standard Name, we need to ensure that there are objective criteria (i.e. not plaintext in the longname) that enable each stream to be uniquely identified. Otherwise, even 'common concepts' (which incidentally will be worked during a workshop in November) won't deliver interoperability. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Aleksandar Jelenak Sent: 20 October 2010 01:33 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data Dear Evan, Thanks for your suggestions. Evan Manning wrote on 10/18/10 11:30 PM: The names below mix satellite and instrument differently than I'm used to. I started with satellite_* names but then wanted to generalize since remote sensing instruments are not only carried on satellites. But you brought up an important distinction that the observation geometry of an instrument can be different from the generic one associated with the entire spacecraft. I recommend changing: instrument_zenith_angle - satellite_zenith_angle instrument_azimuth_angle - satellite_azimuth_angle satellite_scan_angle - satellite_view_angle I think the instrument_* names are more applicable as they allow for either instrument-specific or spacecraft-generic geometries. I also think being able to distinguish between the two observation geometries is important and would like to have sets of standard names for both. So a data provider can clearly signal what is given, even for data from the same instrument. To summarize: 1) Use instrument_zenith_angle, instrument_azimuth_angle, and instrument_scan_angle for precise, instrument-specific observation geometry. 2) Use platform_zenith_angle, platform_azimuth_angle, and platform_view_angle for generic satellite (here generalized to platform) observation geometry. 3) Mixing names from these two sets is allowed, whatever is more applicable for the zenith, azimuth, and scan/view angle data. Too complicated? And add: instrument_scan_angle The angle between the line of sight from an instrument and its reference scan position. Agree. -Aleksandar ___ 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 mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New standard names for satellite obs data
Dear All, As others have said, I think this debate is irrelevant as there should be no need for string timestamps in NetCDF. Providing a Standard Name only encourages what I consider to be bad practice. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ben Hetland Sent: 20 October 2010 09:14 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data On 19.10.2010 16:27, Seth McGinnis wrote: What about using 'date' for string-valued times? That was my homebrew solution when I was considering a similar problem. If I may butt in and contribute here, I usually prefer names like 'datetime' or 'timestamp' in cases like this, because 'date' is potentially confusing. It may not be immediately obvious to a future reader (or programmer) that a variable called 'date' supports points in time down to for example seconds of accuracy. (Note that string data is a big pain to deal with in NetCDF-3, because you're limited to fixed-length character arrays. You need to use NetCDF-4 / HDF5 to get Strings as a data type.) (It may not be such a practical issue with ISO 8601 strings, as a reasonable max. length can be determined, I presume.) -- Regards, -+-Ben-+- ___ 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] New standard names for satellite obs data
Dear all I think there are two principles to be kept in mind for CF standard names: * We should try to use words with consistent meanings, and not use synonyms. * We should include enough information in each standard name for it to be self-explanatory. In a given dataset, the standard name should often be enough to distinguish quantities (apart from other standardised CF metadata such as cell_methods and coordinates). That means the standard name should not be too generic, but quite specific if necessary. We should not have to rely on other non-standardised information (such as long_names) to make distinctions. 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 standard names for satellite obs data
On 10/19/2010 12:55 PM, Mike Grant wrote: On 19/10/10 14:21, Aleksandar Jelenak wrote: Actually, I don't think it is possible to use 'time' standard name in such cases. If I correctly interpret CF rules for using standard names, 'time' data can be only in the physically-equivalent units to seconds. Strings, being dimensionless, do not qualify. Out of curiosity, why do you want to store time as strings? It's easy to create those strings from numerical values, and numerical values are easier to handle in code (and in netcdf-3, as Seth said). Cheers, Mike. I made a proposal a few years ago to allow ISO-8601 time strings to be an allowable form of time coordinates, which was not accepted. I would be interested to hear what your reasons are to use this form vs udunits (eg secs since reference)? ISO-8601 time strings are fixed length (21 I think?) so handling in netcdf-3 is not so hard. Your proposal would amount to standardizing how to include ISO-8601 time strings, but the standard udunits time coordinate would still be required. Clarification of your purpose might clarify the name. At first glance, I might prefer time_iso8601 over time_label_iso8601. John ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New standard names for satellite obs data
Hi John, ISO-8601 allows timestamps to any resolution from year to millisecond, so 2010, 2010-10, 2010-10-20 are all valid so the string can be any length from 4 to 27 (e.g. 2010-10-20T14:53:00.000Z-15), unless restricted through an 8601 profile (as many communities do) Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Caron Sent: 20 October 2010 13:36 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data On 10/19/2010 12:55 PM, Mike Grant wrote: On 19/10/10 14:21, Aleksandar Jelenak wrote: Actually, I don't think it is possible to use 'time' standard name in such cases. If I correctly interpret CF rules for using standard names, 'time' data can be only in the physically-equivalent units to seconds. Strings, being dimensionless, do not qualify. Out of curiosity, why do you want to store time as strings? It's easy to create those strings from numerical values, and numerical values are easier to handle in code (and in netcdf-3, as Seth said). Cheers, Mike. I made a proposal a few years ago to allow ISO-8601 time strings to be an allowable form of time coordinates, which was not accepted. I would be interested to hear what your reasons are to use this form vs udunits (eg secs since reference)? ISO-8601 time strings are fixed length (21 I think?) so handling in netcdf-3 is not so hard. Your proposal would amount to standardizing how to include ISO-8601 time strings, but the standard udunits time coordinate would still be required. Clarification of your purpose might clarify the name. At first glance, I might prefer time_iso8601 over time_label_iso8601. John ___ 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] New standard names for satellite obs data
Dear Ben I agree it would be very useful if ncdump could translate times into time strings for readability. In the examples in the CF doc we usually show them like that. ncdump would need to be able to do this with any of the CF calendars. This has been proposed before, it maybe it is on Unidata's to-do list - I don't know but I am sure Russ does. 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 standard names for satellite obs data
Count me in the group of people who are sorry you lost your bid to include ISO-8601 time strings, John. I have voted on the ISO 8601 side myself (although as I recall, more in the spirit of representing multiple times in a single file). I understand it raises complexity considerably to allow ISO-8601 formatted time in place of the regular format of the udunits time. So I can accept not going down that path. With John C's note that this would merely permit the addition of ISO-8601 variables, not the replacement of the standard coordinate, I fail to see how it would be a bad thing. It really is a common data representation and content, for which there is currently no acceptable standard name. Under these conditions, is there a specific bad practice being violated? Here are the advantages of this option as I see them: 1) Readability in native form without conversion. Understandably not a high priority for a binary standard like netCDF, but for auxiliary variables (not the time coordinate) this is a non-trivial benefit. 2) User chooses appropriate resolution, which is unambiguous. My ISO 8601 timestamp can be MMDD, MMDDThhmmss, or many other variations of these, according to my own data set. If I have mixed data in one netCDF file, I can even represent different resolutions within the same file. I am not aware of any equivalent way to represent time precision in netCDF. 3) It can represent date, time, or a combination thereof. It might be argued this is a negative due to the lack of a priori certainty (which kind of value is represented here?). If this is a problem, it can be resolved via slightly finer standard_name selection (e.g., datetime_iso8601 vs timecode_iso8601) 4) It can include rich time zone information. Often this is relevant in time data (that is, timestamps) collected from sensors or computer systems. 5) It gives me a standard_name for storing a quite common encoding of data values (considering time as a data value, which it often is) without transformation. By allocating the max length, all smaller ISO 8601 strings can be accommodated. (Note: because There is no limit on the number of decimal places for the decimal fraction, I'm not sure there is an a priori limit on all ISO 8601 strings -- this would have to be set in the variable definition for the file.) ISO 8601 definitely a string format, mixing encoding format and concept name in the same standard_name. In CF, perhaps that itself is a bad practice. But it is such a commonly used standard for a data value, I wonder if the practice is worth allowing in this case? Or if not, then supporting the use of ISO 8601 via some other, automatically detectable alternative? John On Oct 20, 2010, at 05:35, John Caron wrote: On 10/19/2010 12:55 PM, Mike Grant wrote: On 19/10/10 14:21, Aleksandar Jelenak wrote: Actually, I don't think it is possible to use 'time' standard name in such cases. If I correctly interpret CF rules for using standard names, 'time' data can be only in the physically-equivalent units to seconds. Strings, being dimensionless, do not qualify. Out of curiosity, why do you want to store time as strings? It's easy to create those strings from numerical values, and numerical values are easier to handle in code (and in netcdf-3, as Seth said). Cheers, Mike. I made a proposal a few years ago to allow ISO-8601 time strings to be an allowable form of time coordinates, which was not accepted. I would be interested to hear what your reasons are to use this form vs udunits (eg secs since reference)? ISO-8601 time strings are fixed length (21 I think?) so handling in netcdf-3 is not so hard. Your proposal would amount to standardizing how to include ISO-8601 time strings, but the standard udunits time coordinate would still be required. Clarification of your purpose might clarify the name. At first glance, I might prefer time_iso8601 over time_label_iso8601. John ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata John Graybeal mailto:jgrayb...@ucsd.edu phone: 858-534-2162 System Development 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
Re: [CF-metadata] New standard names for satellite obs data
Hi all - One way in which they are different is precision. A value of x seconds since y has no implied precision - typically in programs we take the precision to be milliseconds, but there's nothing to suggest this in the actual metadata (anyone who tries to populate a GUI from CF metadata struggles with this). Semantically it's a time instant; i.e. an infinitesimal position in a temporal coordinate reference system. However, an ISO8601 string can have various precisions. (The string 2009-10 is not considered equivalent to 2009-10-01T00:00:00.000Z.) The precision in x units since y relies on the units and on the format of y; there seems to me to be plenty of implicit information about the precision of days since 1990-01-01 , vs seconds since 1990-01-01 00:00:00.00. I'm not sure if UDUNITS allows the short format for the reference date, and I haven't been able to find a description of the permitted formats in the UDUNITS docs; there's not much in the CF docs about it either, beyond some examples (which all use a complete date/time). Does anyone know what formats UDUNITS allows in this field? It seems likely that Unidata would want to follow ISO in this convention, but maybe not. Maybe we're all using seconds since a reference date, but there's nothing to prevent us from indicating lower resolution by using minutes since or hours since instead (other than, in my own case, sloppy programming habits). The CF docs warn against using month or year in this field, but it's not illegal and, in some cases, it would probably give a more accurate reflection of the true meaning of the time word than seconds since does. Either of these seems more useful than storing time as a string. Although I always use seconds since, I do write both precision and accuracy as attributes of the time variable in our NetCDF files, mainly to document instrument clock characteristics. If that's not legal in CF, I'm very surprised. We also use the Fortran_format attribute, although I have no idea if that's still used in ncdump. Cheers - Nan From Wikipedia (http://en.wikipedia.org/wiki/ISO_8601): For reduced accuracy, any number of values may be dropped from any of the date and time representations, but in the order from the least to the most significant. For example, 2004-05 is a valid ISO 8601 date, which indicates May (the fifth month) 2004. This format will never represent the 5th day of an unspecified month in 2004, nor will it represent a time-span extending from 2004 into 2005. I've argued before in a previous thread on this list that it would be good to be able to specify the precision of time coordinates in terms of calendar date/time fields (which isn't the same thing as providing a tolerance value on the numeric coordinate value of a time axis). I'm not saying that we should definitely allow time strings in CF, just pointing out that they have some use cases we currently can't fulfil. I'm not sure they are definitively bad practice in all cases. (Regarding a technical point raised below, yes, it's a pain to represent variable length strings in NetCDF, but there is a maximum length for ISO8601 strings.) Hope this helps, Jon -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K Sent: 20 October 2010 10:00 To: Ben Hetland; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data Dear All, As others have said, I think this debate is irrelevant as there should be no need for string timestamps in NetCDF. Providing a Standard Name only encourages what I consider to be bad practice. Cheers, Roy. -- *** * 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] New standard names for satellite obs data
Hi Jon, I prefer handling the precision issue through a format mask attribute. I usually hit this problem in Oracle with the 'date' data type (in say column X), whose format I control by also storing an Oracle date/time format string (say in column Y). Formatted date/time to the appropriate precision is then obtained using the function to_date (X,Y). Something similar should surely be possible in CF with a binary time channel, an ISO-8601 template (parameter attribute?) and an interface function. Cheers, Roy. From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jon Blower [j.d.blo...@reading.ac.uk] Sent: 20 October 2010 14:41 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data Hi all, I haven't followed this debate closely, but I've had cause to do a fair amount of thinking (outside the CF context) on the pros and cons of identifying date/times as strings or numbers. I could probably write a very boring essay on this but in summary, they are not exactly equivalent ways of representing the same information. One way in which they are different is precision. A value of x seconds since y has no implied precision - typically in programs we take the precision to be milliseconds, but there's nothing to suggest this in the actual metadata (anyone who tries to populate a GUI from CF metadata struggles with this). Semantically it's a time instant; i.e. an infinitesimal position in a temporal coordinate reference system. However, an ISO8601 string can have various precisions. (The string 2009-10 is not considered equivalent to 2009-10-01T00:00:00.000Z.) From Wikipedia (http://en.wikipedia.org/wiki/ISO_8601): For reduced accuracy, any number of values may be dropped from any of the date and time representations, but in the order from the least to the most significant. For example, 2004-05 is a valid ISO 8601 date, which indicates May (the fifth month) 2004. This format will never represent the 5th day of an unspecified month in 2004, nor will it represent a time-span extending from 2004 into 2005. I've argued before in a previous thread on this list that it would be good to be able to specify the precision of time coordinates in terms of calendar date/time fields (which isn't the same thing as providing a tolerance value on the numeric coordinate value of a time axis). I'm not saying that we should definitely allow time strings in CF, just pointing out that they have some use cases we currently can't fulfil. I'm not sure they are definitively bad practice in all cases. (Regarding a technical point raised below, yes, it's a pain to represent variable length strings in NetCDF, but there is a maximum length for ISO8601 strings.) Hope this helps, Jon -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K Sent: 20 October 2010 10:00 To: Ben Hetland; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data Dear All, As others have said, I think this debate is irrelevant as there should be no need for string timestamps in NetCDF. Providing a Standard Name only encourages what I consider to be bad practice. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ben Hetland Sent: 20 October 2010 09:14 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data On 19.10.2010 16:27, Seth McGinnis wrote: What about using 'date' for string-valued times? That was my homebrew solution when I was considering a similar problem. If I may butt in and contribute here, I usually prefer names like 'datetime' or 'timestamp' in cases like this, because 'date' is potentially confusing. It may not be immediately obvious to a future reader (or programmer) that a variable called 'date' supports points in time down to for example seconds of accuracy. (Note that string data is a big pain to deal with in NetCDF-3, because you're limited to fixed-length character arrays. You need to use NetCDF-4 / HDF5 to get Strings as a data type.) (It may not be such a practical issue with ISO 8601 strings, as a reasonable max. length can be determined, I presume.) -- Regards, -+-Ben-+- ___ 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
[CF-metadata] New standard names for satellite obs data
To summarize: 1) Use instrument_zenith_angle, instrument_azimuth_angle, and instrument_scan_angle for precise, instrument-specific observation geometry. 2) Use platform_zenith_angle, platform_azimuth_angle, and platform_view_angle for generic satellite (here generalized to platform) observation geometry. 3) Mixing names from these two sets is allowed, whatever is more applicable for the zenith, azimuth, and scan/view angle data. Too complicated? I like platform to include aircraft as well as spacecraft. I don't see any need for instrument zen azi. These are angles to the instrument as seen from the observed location, and they must be equal to the angles for the platform on which the instrument is mounted. Similarly, view angle is a geometric quantity that could apply to all instruments on a given platform. The only instrument-specific angles are scan angles. So I now propose: platform_zenith_angle platform_azimuth_angle platform_view_angle instrument_scan_angle (or sensor_scan_angle) -- Evan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] New standard names for satellite obs data (time as ISO strings)
Hi Jon, Why do you see this as an issue of date-times as ISO strings in particular? The same issues of precision are found in longitudes expressed as a degrees-minutes-seconds string compared to a floating point. Or indeed to a depth expressed as a decimal string of known numbers of digits. (100.00 communicates different precision than 100 though both a represented by the same binary value.) CF provides the bounds attribute and the cell methods/measures to clarify (somewhat) these points. What is your proposal for improved representation of precisions? And wouldn't a general improvement in how to specify coordinate precision be preferable to a solution that applies to time, only? - Steve = On 10/20/2010 9:41 AM, Jon Blower wrote: Hi all, I haven't followed this debate closely, but I've had cause to do a fair amount of thinking (outside the CF context) on the pros and cons of identifying date/times as strings or numbers. I could probably write a very boring essay on this but in summary, they are not exactly equivalent ways of representing the same information. One way in which they are different is precision. A value of x seconds since y has no implied precision - typically in programs we take the precision to be milliseconds, but there's nothing to suggest this in the actual metadata (anyone who tries to populate a GUI from CF metadata struggles with this). Semantically it's a time instant; i.e. an infinitesimal position in a temporal coordinate reference system. However, an ISO8601 string can have various precisions. (The string 2009-10 is not considered equivalent to 2009-10-01T00:00:00.000Z.) From Wikipedia (http://en.wikipedia.org/wiki/ISO_8601): For reduced accuracy, any number of values may be dropped from any of the date and time representations, but in the order from the least to the most significant. For example, 2004-05 is a valid ISO 8601 date, which indicates May (the fifth month) 2004. This format will never represent the 5th day of an unspecified month in 2004, nor will it represent a time-span extending from 2004 into 2005. I've argued before in a previous thread on this list that it would be good to be able to specify the precision of time coordinates in terms of calendar date/time fields (which isn't the same thing as providing a tolerance value on the numeric coordinate value of a time axis). I'm not saying that we should definitely allow time strings in CF, just pointing out that they have some use cases we currently can't fulfil. I'm not sure they are definitively bad practice in all cases. (Regarding a technical point raised below, yes, it's a pain to represent variable length strings in NetCDF, but there is a maximum length for ISO8601 strings.) Hope this helps, Jon -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K Sent: 20 October 2010 10:00 To: Ben Hetland; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data Dear All, As others have said, I think this debate is irrelevant as there should be no need for string timestamps in NetCDF. Providing a Standard Name only encourages what I consider to be bad practice. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ben Hetland Sent: 20 October 2010 09:14 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data On 19.10.2010 16:27, Seth McGinnis wrote: What about using 'date' for string-valued times? That was my homebrew solution when I was considering a similar problem. If I may butt in and contribute here, I usually prefer names like 'datetime' or 'timestamp' in cases like this, because 'date' is potentially confusing. It may not be immediately obvious to a future reader (or programmer) that a variable called 'date' supports points in time down to for example seconds of accuracy. (Note that string data is a big pain to deal with in NetCDF-3, because you're limited to fixed-length character arrays. You need to use NetCDF-4 / HDF5 to get Strings as a data type.) (It may not be such a practical issue with ISO 8601 strings, as a reasonable max. length can be determined, I presume.) ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] New standard names for satellite obs data -- zenith azimuth angles
Bodas-Salcedo, Alejandro alejandro.bo...@metoffice.gov.uk wrote: To: Lowry, Roy K r...@bodc.ac.uk, Aleksandar Jelenak aleksandar.jele...@noaa.gov, cf-metadata@cgd.ucar.edu Do we need to include any reference to instrument, platform or satellite? It seems to me that the complexity arises because the reference lines from which the angle is defined are different in different applications. Wouldn't it be better to use zenith_angle and scan_angle with respect to fixed reference lines and include an attribute that accounts for any offset with respect to that? For instance, scan_angle would be referenced against the nadir of the object. If the instrument is tilted with respect to that line and you want to represent the angle with respect to the reference instrument line of sight, then the offset will be /=0. Typically we talk about solar zenith and azimuth angles and satellite/platform angles. These are angles from the observed location to the sun or to the platform. So we can't use simple zenith_angle etc. view_angle and scan_angle could be used without the qualifier. That's a good suggestion. -- Evan ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Re: [CF-metadata] Seeking new CF standard names (9) for sea surface wave parameters
Hi Jonathon and CF metadata list, Summarising our discussions thus far we propose: 2 new Cell methods: root_mean_square mean_of_upper_decile and these new standard names: sea_surface_wave_height (common concept) sea_surface_wave_mean_crest_period sea_surface_wave_significant_wave_period sea_surface_wave_period_at_second_largest_peak_of_variance_spectral_density sea_surface_wave_variance_spectral_density_zeroth_frequency_moment sea_surface_wave_root_mean_square_amplitude_from_variance_spectral_density The sea_surface_wave_height is a common concept (standard name) which may be qualified by a cell_method attribute to realise the actual variable. The sea_surface_wave_height when combined with a cell method of: time: mean time: maximum time: root_mean_square time: mean_of_upper_decile will describe the statistical wave height variables: sea_surface_mean_wave_height sea_surface_maximum_wave_height sea_surface_root_mean_square_wave_height sea_surface_wave_mean_of_highest_one_tenth_waves respectively. I have attached a spreadsheet which contains the names, descriptions and units of the variables proposed. Looking forward to getting final approval to add these to the CF name lists. Andrew Walsh Data Facilitator AODN - Original Message - From: Jonathan Gregory j.m.greg...@reading.ac.uk To: andrew walsh awa...@metoc.gov.au Cc: cf-metadata@cgd.ucar.edu; Mark Kulmar mark.kul...@mhl.nsw.gov.au Sent: Wednesday, October 13, 2010 20:21 Subject: [CF-metadata] Seeking new CF standard names (9) for sea surface wave parameters Dear Andrew Yes, but depends on the community (list) accepting the idea of having a Good. I think we are agreed then to propose these new cell methods: root_mean_square mean_of_upper_decile and these new standard names: sea_surface_wave_height sea_surface_wave_mean_crest_period sea_surface_wave_significant_wave_period sea_surface_wave_period_at_second_largest_peak_of_variance_spectral_density sea_surface_wave_variance_spectral_density_zeroth_frequency_moment sea_surface_wave_root_mean_square_amplitude_from_variance_spectral_density I agree that the last will avoid confusion with the RMS of wave height. I agree also that this depends on users being comfortable with the concepts being split into two attributes, in accordance with the usual CF practice, but deciding on how to join them up as common_concepts will help. Comments from others would help. It is good that Roy supports this compromise. Best wishes Jonathan Proposed_wave_parm_names_for_CFlist.xls Description: MS-Excel spreadsheet ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
