Re: [CF-metadata] New standard names for satellite obs data (time as ISO strings)
Hi Jon, Full ISO8601 does carry time zone expressed in hours relative to UT in the syntax Zx where x is the offset from Zulu at the right-hand end of the string. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jon Blower Sent: 21 October 2010 23:28 To: Benno Blumenthal Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data (time as ISO strings) Hi Benno, No one I know beyond the age of four thinks Sep 2009 is ambiguous Do you mean beyond the age of precisely 4.000... years or beyond the age of 4.999... years? Or is the ambiguous temporal metadata concept of the age of four sufficient? ;-) All ISO8601 dates (year, month or day resolution) are inherently ambiguous because they carry no time zone information (your precise bounds are likely to be 5 hours different from mine, or something more complex if daylight saving is involved). So with ISO8601 alone I don't think there's such a thing as the preciseSep2009 in your argument below, unless I've misunderstood what you mean, in which case apologies. Hmm... come to think of it, this might actually argue *against* using ISO8601 strings alone as indicators of time resolution. If we really *do* mean that data are representative of a 24-hour period starting at midnight UTC on the first of September, we can't represent this unambiguously as 2009-01-01 because of the time zone problem. (I think that 2009-01-01Z is illegal.) In this case we would be better off representing this period as a nominal value plus explicit bounds, or a nominal value plus time zone plus some additional information that we can discard any precision greater than 1 day. *However*, it's still very useful to know the resolution of the time axis by some means other than inspecting the coordinate bounds. An application (e.g. automatically generating a time selector widget in a GUI) will probably not want to look at all the bounds of all the time coordinates to infer the time resolution: apart from being generally tedious, it would be very difficult for monthly data (because months are different lengths, and vary between calendars). Additionally, this inference would be complicated if floating-point numbers were used to represent time coordinates, since these are usually slightly inaccurate (dangerous to compare floats for equality, etc. etc.) So, I'm starting to like the idea of an additional (and optional) CF attribute to specify time coordinate resolution. This could be specified in precise numeric terms (e.g. instrument precision of 0.12 ms) or in less-precise human calendar terms for certain kinds of data (e.g. P1M for monthly resolution). It would be additional to the coordinate bounds: data providers could specify one or the other, or both if they are consistent (or neither if appropriate?) This would not require or preclude the use of ISO8601 strings to represent time coordinate values. Best wishes, Jon -Original Message- From: bennoblument...@gmail.com [mailto:bennoblument...@gmail.com] On Behalf Of Benno Blumenthal Sent: 21 October 2010 21:44 To: Jon Blower Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data (time as ISO strings) Hi Jon, Sorry, I am not buying it. No one I know beyond the age of four thinks Sep 2009 is ambiguous, and I don't read your examples as needing vagueness on the time specifically. Suppose, for a moment, that you succeed beyond your wildest dreams, and it is possible to express in CF some relationship to a vague notion of Sep2009, i.e. data hasADataRelationshipWith vagueSep2009. I would say there is another relationship vagueSep2009 isAVagueVersionOf preciseSep2009 And you could have just as easily coded in CF data hasADataRelationshipWithAVaugeVersionOf preciseSep2009 i.e. there is no reason why the vaugeness cannot be coded as a dependent data property. Which is what CF is currently set up to do, with a possible extension of the cell_methods vocabulary Futhermore, you said You *could* modify CF so that to represent data that are representative of September 2010, you specify a nominal date half-way through September and set the bounds to the first and last instants of September. And perhaps use a new cell_methods of representative. But the half-way point and the bounds would be quite (very) tedious to compute in the general case (months and years are of variable length for example and depend on the calendar system). That is not a modification of CF -- that is the way it is currently encoded in CF (though there is no meaning to the nominal value, so you can set it to whatever). And yes, you have to generate the edges, which you have to do anyway if you are going to sensibly handle computations with the data. And let me repeat my main original point, so that it does not get completely buried
Re: [CF-metadata] New standard names for satellite obs data (timeas ISO strings)
On Fri, Oct 22, 2010 at 6:27 AM, Jon Blower j.d.blo...@reading.ac.uk wrote: Hi Roy, Yes, but *only* if the ISO string contains time information. If it only contains a date (e.g. 2009-09-01) you can't add a time zone as I understand it. Furthermore, there's no default to UTC - in fact the default is local time. This is true, but one can always write out the time in explicit intervals 2009-9-01T00:00Z/24:00Z One does, of course lose all the elegance of the ISO8601 abbreviation, particularly with respect to months, rendering it somewhat pointless. Given that ISO defaults to local time, it behooves CF to specify what that local time is (if CF is where we are). As it currently stands, time zone can be encoded in the units. Also the CF document states Note: if the time zone is omitted the default is UTC, and if both time and time zone are omitted the default is 00:00:00 UTC. If we take that to constrain ISO8601 as well, we have made progress. If we can do such a thing. Benno (And I'm not sure your syntax is right - I think you use +5:00, not Z5. I think Z is only used on its own to indicate Zulu/UTC. Might be wrong though.) Cheers, Jon -Original Message- From: Lowry, Roy K [mailto:r...@bodc.ac.uk] Sent: 22 October 2010 09:06 To: Jon Blower; Benno Blumenthal Cc: cf-metadata@cgd.ucar.edu Subject: RE: [CF-metadata] New standard names for satellite obs data (timeas ISO strings) Hi Jon, Full ISO8601 does carry time zone expressed in hours relative to UT in the syntax Zx where x is the offset from Zulu at the right-hand end of the string. Cheers, Roy. -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jon Blower Sent: 21 October 2010 23:28 To: Benno Blumenthal Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data (time as ISO strings) Hi Benno, No one I know beyond the age of four thinks Sep 2009 is ambiguous Do you mean beyond the age of precisely 4.000... years or beyond the age of 4.999... years? Or is the ambiguous temporal metadata concept of the age of four sufficient? ;-) All ISO8601 dates (year, month or day resolution) are inherently ambiguous because they carry no time zone information (your precise bounds are likely to be 5 hours different from mine, or something more complex if daylight saving is involved). So with ISO8601 alone I don't think there's such a thing as the preciseSep2009 in your argument below, unless I've misunderstood what you mean, in which case apologies. Hmm... come to think of it, this might actually argue *against* using ISO8601 strings alone as indicators of time resolution. If we really *do* mean that data are representative of a 24-hour period starting at midnight UTC on the first of September, we can't represent this unambiguously as 2009-01-01 because of the time zone problem. (I think that 2009-01-01Z is illegal.) In this case we would be better off representing this period as a nominal value plus explicit bounds, or a nominal value plus time zone plus some additional information that we can discard any precision greater than 1 day. *However*, it's still very useful to know the resolution of the time axis by some means other than inspecting the coordinate bounds. An application (e.g. automatically generating a time selector widget in a GUI) will probably not want to look at all the bounds of all the time coordinates to infer the time resolution: apart from being generally tedious, it would be very difficult for monthly data (because months are different lengths, and vary between calendars). Additionally, this inference would be complicated if floating-point numbers were used to represent time coordinates, since these are usually slightly inaccurate (dangerous to compare floats for equality, etc. etc.) So, I'm starting to like the idea of an additional (and optional) CF attribute to specify time coordinate resolution. This could be specified in precise numeric terms (e.g. instrument precision of 0.12 ms) or in less-precise human calendar terms for certain kinds of data (e.g. P1M for monthly resolution). It would be additional to the coordinate bounds: data providers could specify one or the other, or both if they are consistent (or neither if appropriate?) This would not require or preclude the use of ISO8601 strings to represent time coordinate values. Best wishes, Jon -Original Message- From: bennoblument...@gmail.com [mailto:bennoblument...@gmail.com] On Behalf Of Benno Blumenthal Sent: 21 October 2010 21:44 To: Jon Blower Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data (time as ISO strings) Hi Jon, Sorry, I am not buying it. No one I know beyond the age of four thinks Sep 2009 is ambiguous, and I don't read your examples as needing
Re: [CF-metadata] New standard names for satellite obs data
Hi all, OK, I had four replies to my email concerning ISO8601 time strings and precision so I'm going to respond briefly to them all simultaneously, without the aid of a safety net. I hope I'm capturing the important points: 1. Steve and Roy both asked (I think) why we can't have a more general notion of precision that applies to all coordinate axes, not just time. I argue that precision in time *can be* (but is not always) different semantically. When I say these data are representative of June 2009 I don't mean these data were collected on the 15th of June 2009, plus or minus 15 days. The concept of data representative of a time period is very different from data collected at an uncertain time. Representative data is commonly found in high-level analysed products, not so much in instrument records I guess. 2. Also (still replying to Steve), there's nothing to stop me interpreting 100.0 and 100.00 as exactly the same value - there's no *explicit* precision, although a human *might* infer one. (Anyway, when numbers are represented as binary there's no way of telling the difference.) In ISO8601, the truncation is defined to imply precision (I think). 3. Nan said: ...there's nothing to prevent us from indicating lower resolution by using minutes since or hours since instead There's nothing in the CF conventions that says that minutes since implies a precision of minutes, *although perhaps it could* (a topic for a proposal?). AFAIK, 60.0 seconds since X is currently treated by the conventions as exactly the same as 1.0 minute since X. But what if the actual precision is nanoseconds? An axis defined as y nanoseconds since x would have some pretty big numbers, maybe that's not a problem. I can see another couple of disadvantages to using ISO8601 strings though: i. UDUNITS strings are not ISO8601 strings, although they are close. Would it be confusing to have two different syntaxes for specifying time? ii. ISO8601 strings are defined to be in the Gregorian calendar (although it could be sensible to relax this assumption and just take the string to indicate year/month/day etc in a specified calendar, as long as the new calendar has the same concepts of fields.) Jon -Original Message- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Graybeal Sent: 20 October 2010 20:00 To: John Caron Cc: cf-metadata@cgd.ucar.edu Subject: 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
Re: [CF-metadata] New standard names for satellite obs data
John Caron said the following on 10/20/2010 8:35 AM: I would be interested to hear what your reasons are to use this form vs udunits (eg secs since reference)? Dear John and a few others who asked similar question, We have a few data users who prefer ASCII format and we would like to keep our data only in netCDF. So we thought to provide time data as ISO-8601 strings in addition to the numerical version. I did not know about ncdump's -t option so that may be an option for us now. Another request from some of our data users is that they don't have the skills or the time to deal with UDUNITS and reference time string in the 'units' attribute and prefer to pass timestamp strings to their software which then converts them to numerical values. ISO-8601 time strings are fixed length (21 I think?) so handling in netcdf-3 is not so hard. We are currently producing netCDF-3 files but plan to migrate to netCDF-4 Classic format so working with strings is not going to be an issue. Your proposal would amount to standardizing how to include ISO-8601 time strings, but the standard udunits time coordinate would still be required. Yes. At first glance, I might prefer time_iso8601 over time_label_iso8601. Or timestamp_iso8601 who worry that just time_ may be too reminiscent to string-valued time coordinate. -Aleksandar ___ 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
Evan, Evan Manning said the following on 10/20/2010 5:40 PM: 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. When we discussed initially these standard names in my office a few radar guys argued there could be instrument configurations where platform's and instrument's locations are deliberately not the same. And as a more general approach we settled on proposing instrument_* names. You are correct for vast majority of satellite instruments. So I now propose: platform_zenith_angle platform_azimuth_angle platform_view_angle instrument_scan_angle (or sensor_scan_angle) The above standard names satisfy my immediate requirements. What others think of including the instrument_zenith_angle and instrument_azimuth_angle or prefer to have a real-life use case first? -Aleksandar ___ 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)
While expressing precision in CF is an interesting issue, in this case the Wikipedia quote is using the term in a different sense than I (hopefully we) usually mean -- ISO8601 lets one express time intervals succinctly in a single string, e.g. 2010-09 to mean all of september 2010, which is not an accuracy issue, it is a precise specification of a larger interval. It lets you write 2010-09-01/10-05 as well, i.e. it is not limited to intervals that involve special notational boundaries. As Steve points out CF expresses this using a bounds coordinate, i.e. giving the precise edges of each interval. Of course, how the data is actually related to that interval is where the notion of precision might come in, which cell methods/measures addresses, perhaps inadequately for the purpose at hand. ISO8601 is quite neat in the sense that it forces one to always specify an interval, and CF software reading time bounds data and rendering ISO8601 strings would do us all a lot of good. Benno On Wed, Oct 20, 2010 at 6:34 PM, Steve Hankin steven.c.han...@noaa.gov wrote: 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
Re: [CF-metadata] New standard names for satellite obs data
Nan Galbraith said the following on 10/20/2010 11:18 AM: Is it implicit in the proposal that, if there is orientation information only at the instrument level, it's absolute, but if there's also platform orientation, they need to be considered together? My idea is that both orientations are absolute, with the instrument-level being considered more accurate. Thus if a file would ever contain both instrument_* and platform_* standard names, better quality data would be in instrument_* names variables. One more idea that we discussed in my office was whether or not was worthwhile to indicate platform attitude-corrected data (roll/yaw/pitch). Something like appending _with_attitude_correction to the standard names. In the end we decided not go with that because this approach would require new names for latitude and longitude data and I did not think that would be accepted. -Aleksandar ___ 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 Benno, 2010-09 is not necessarily a precise specification of a month - time zones make it a little fuzzy for one thing. Separate to this, there are parallel conversations going on in the ISO/OGC community about what time strings actually mean. A metadata person might say that 2010-09 is simply a shorthand for the fuzzy concept of September 2010 and does not represent a precise interval (i.e. a square-wave function that is 1 during September and 0 outside). Apart from the time zone issue which blurs the boundaries, this square-wave is simply not what humans mean when, for example, they tag a report as having been written in September 2010. It just distinguishes it from version 2 of the report, which was written in November. In this context, it's just a label with some temporal meaning. These metadata guys are in discussion with the positioning guys who view date/times as precisely-defined positions within a temporal CRS. You may (or may not!) like to look at the GeoAPI mailing list, in which we are trying to figure out whether we can actually use the same Java types for both of these subtly-different views of date/times (we hope we can but haven't agreed). One might think that they are obviously the same thing, but I don't think so. You *could* modify CF so that to represent data that are representative of September 2010, you specify a nominal date half-way through September and set the bounds to the first and last instants of September. And perhaps use a new cell_methods of representative. But the half-way point and the bounds would be quite (very) tedious to compute in the general case (months and years are of variable length for example and depend on the calendar system). Of course, how the data is actually related to that interval is where the notion of precision might come in Actually, you've probably gathered that I also consider the notion of precision to apply to the interval itself, not just how the data relates to it. This discussion repeats a bit of the previous discussion on this list entitled bounds/precision for time axis. I like Jonathan's distinction between the concepts of temporal resolution and representivity: http://www.mail-archive.com/cf-metadata@cgd.ucar.edu/msg01341.html. And just for completeness we should not that ISO8601 strings are not fixed-length, nor do they have a maximum length (in contrast to what I said before, sorry). So I can see some implementation challenges in NetCDF. Cheers, Jon -Original Message- From: bennoblument...@gmail.com [mailto:bennoblument...@gmail.com] On Behalf Of Benno Blumenthal Sent: 21 October 2010 15:43 To: Steve Hankin Cc: Jon Blower; cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data (time as ISO strings) While expressing precision in CF is an interesting issue, in this case the Wikipedia quote is using the term in a different sense than I (hopefully we) usually mean -- ISO8601 lets one express time intervals succinctly in a single string, e.g. 2010-09 to mean all of september 2010, which is not an accuracy issue, it is a precise specification of a larger interval. It lets you write 2010-09-01/10-05 as well, i.e. it is not limited to intervals that involve special notational boundaries. As Steve points out CF expresses this using a bounds coordinate, i.e. giving the precise edges of each interval. Of course, how the data is actually related to that interval is where the notion of precision might come in, which cell methods/measures addresses, perhaps inadequately for the purpose at hand. ISO8601 is quite neat in the sense that it forces one to always specify an interval, and CF software reading time bounds data and rendering ISO8601 strings would do us all a lot of good. Benno On Wed, Oct 20, 2010 at 6:34 PM, Steve Hankin steven.c.han...@noaa.gov wrote: 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
Re: [CF-metadata] New standard names for satellite obs data
Hi Jon, Thanks for the helpful summary :) We have had similar issues with handling data that represents time periods, and it'd certainly be good to find some way to address that. On 21/10/10 15:28, Jon Blower wrote: 1. Steve and Roy both asked (I think) why we can't have a more general notion of precision that applies to all coordinate axes, not just time. I argue that precision in time *can be* (but is not always) different semantically. When I say these data are representative of June 2009 I don't mean these data were collected on the 15th of June 2009, plus or minus 15 days. The concept of data representative of a time period is very different from data collected at an uncertain time. Representative data is commonly found in high-level analysed products, not so much in instrument records I guess. That raises an interesting point - perhaps accuracy and representativeness are getting bundled together into precision in this discussion, and should instead be considered separately? For example, a satellite might pass over an area once a day, taking about 10mins to cover it. The accuracy of a seconds-since-epoch timestamp at the center point might then be +/- 5mins (with a precision of 1 second) but the data for that timestamp might be considered to be representative of the whole day as there is no more coverage. This accuracy / representativeness split would apply equally to other coordinate types as well as time - for example, a satellite pixel coordinate has a accuracy based on the quality of the geolocation (e.g. 100m) but represents a much larger area (e.g. 1km square). One could encode both accuracy and representativeness in one field by making the precision of a timestamp imply representativeness, but that loses some of the semantics above. Without wishing to get into too much of a tangle on the issue, perhaps there's a case for improving CF's description of both accuracy and representativeness [of coordinates]? Cheers, Mike. Plymouth Marine Laboratory Registered Office: Prospect Place The Hoe Plymouth PL1 3DH Website: www.pml.ac.uk Registered Charity No. 1091222 PML is a company limited by guarantee registered in England Wales company number 4178503 This e-mail, its content and any file attachments are confidential. If you have received this e-mail in error please do not copy, disclose it to any third party or use the contents or attachments in any way. Please notify the sender by replying to this e-mail or e-mail fori...@pml.ac.uk and then delete the email without making any copies or using it in any other way. The content of this message may contain personal views which are not the views of Plymouth Marine Laboratory unless specifically stated. You are reminded that e-mail communications are not secure and may contain viruses. Plymouth Marine Laboratory accepts no liability for any loss or damage which may be caused by viruses. ___ 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
For many (most in my world, which is more observational) applications, the information about the instrument orientations will not be absolute (most instruments can't measure their orientation that way because they don't know what the platform orientation is). So not specifying whether it is absolute or relative in the name will lead to ambiguity (partially resolved by the definition, perhaps) and error. I suggest the desired concept be reflected by the standard name, to minimize long term confusion. john On Oct 21, 2010, at 08:19, Aleksandar Jelenak wrote: Nan Galbraith said the following on 10/20/2010 11:18 AM: Is it implicit in the proposal that, if there is orientation information only at the instrument level, it's absolute, but if there's also platform orientation, they need to be considered together? My idea is that both orientations are absolute, with the instrument-level being considered more accurate. Thus if a file would ever contain both instrument_* and platform_* standard names, better quality data would be in instrument_* names variables. One more idea that we discussed in my office was whether or not was worthwhile to indicate platform attitude-corrected data (roll/yaw/pitch). Something like appending _with_attitude_correction to the standard names. In the end we decided not go with that because this approach would require new names for latitude and longitude data and I did not think that would be accepted. -Aleksandar ___ 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 (time as ISO strings)
Hi Benno, No one I know beyond the age of four thinks Sep 2009 is ambiguous Do you mean beyond the age of precisely 4.000... years or beyond the age of 4.999... years? Or is the ambiguous temporal metadata concept of the age of four sufficient? ;-) All ISO8601 dates (year, month or day resolution) are inherently ambiguous because they carry no time zone information (your precise bounds are likely to be 5 hours different from mine, or something more complex if daylight saving is involved). So with ISO8601 alone I don't think there's such a thing as the preciseSep2009 in your argument below, unless I've misunderstood what you mean, in which case apologies. Hmm... come to think of it, this might actually argue *against* using ISO8601 strings alone as indicators of time resolution. If we really *do* mean that data are representative of a 24-hour period starting at midnight UTC on the first of September, we can't represent this unambiguously as 2009-01-01 because of the time zone problem. (I think that 2009-01-01Z is illegal.) In this case we would be better off representing this period as a nominal value plus explicit bounds, or a nominal value plus time zone plus some additional information that we can discard any precision greater than 1 day. *However*, it's still very useful to know the resolution of the time axis by some means other than inspecting the coordinate bounds. An application (e.g. automatically generating a time selector widget in a GUI) will probably not want to look at all the bounds of all the time coordinates to infer the time resolution: apart from being generally tedious, it would be very difficult for monthly data (because months are different lengths, and vary between calendars). Additionally, this inference would be complicated if floating-point numbers were used to represent time coordinates, since these are usually slightly inaccurate (dangerous to compare floats for equality, etc. etc.) So, I'm starting to like the idea of an additional (and optional) CF attribute to specify time coordinate resolution. This could be specified in precise numeric terms (e.g. instrument precision of 0.12 ms) or in less-precise human calendar terms for certain kinds of data (e.g. P1M for monthly resolution). It would be additional to the coordinate bounds: data providers could specify one or the other, or both if they are consistent (or neither if appropriate?) This would not require or preclude the use of ISO8601 strings to represent time coordinate values. Best wishes, Jon -Original Message- From: bennoblument...@gmail.com [mailto:bennoblument...@gmail.com] On Behalf Of Benno Blumenthal Sent: 21 October 2010 21:44 To: Jon Blower Cc: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data (time as ISO strings) Hi Jon, Sorry, I am not buying it. No one I know beyond the age of four thinks Sep 2009 is ambiguous, and I don't read your examples as needing vagueness on the time specifically. Suppose, for a moment, that you succeed beyond your wildest dreams, and it is possible to express in CF some relationship to a vague notion of Sep2009, i.e. data hasADataRelationshipWith vagueSep2009. I would say there is another relationship vagueSep2009 isAVagueVersionOf preciseSep2009 And you could have just as easily coded in CF data hasADataRelationshipWithAVaugeVersionOf preciseSep2009 i.e. there is no reason why the vaugeness cannot be coded as a dependent data property. Which is what CF is currently set up to do, with a possible extension of the cell_methods vocabulary Futhermore, you said You *could* modify CF so that to represent data that are representative of September 2010, you specify a nominal date half-way through September and set the bounds to the first and last instants of September. And perhaps use a new cell_methods of representative. But the half-way point and the bounds would be quite (very) tedious to compute in the general case (months and years are of variable length for example and depend on the calendar system). That is not a modification of CF -- that is the way it is currently encoded in CF (though there is no meaning to the nominal value, so you can set it to whatever). And yes, you have to generate the edges, which you have to do anyway if you are going to sensibly handle computations with the data. And let me repeat my main original point, so that it does not get completely buried -- CF software really needs to render time bounds as ISO8601 conveniently and universally (both directions seems to be essential, i.e. reading and writing), so the the CF convention can be easily used in this regard. Sorry I couldn't be more helpful, Benno On Thu, Oct 21, 2010 at 11:57 AM, Jon Blower j.d.blo...@reading.ac.uk wrote: Hi Benno, 2010-09 is not necessarily a precise specification of a month - time zones make it a little fuzzy for one thing. Separate
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 http
[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] 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
Re: [CF-metadata] New standard names for satellite obs data
Cameron-smith, Philip wrote on 10/19/10 7:44 PM: Sometimes these instruments are also flown on aircraft, so do we want to hardwire 'satellite' into the standard_name? Yes, that is the reason why I went with instrument_. It is a bit of a mouthful, but would 'remote_sensing_instrument_' work? I am fine with remote_sensing_instrument_ if using just instrument is deemed too generic. I thought that combining instrument with zenith/azimuth/scan terms is enough to indicate what kind of instrument is in question. -Aleksandar ___ 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
Sometimes these instruments are also flown on aircraft, so do we want to
hardwire 'satellite' into the standard_name? It is a bit of a mouthful, but
would 'remote_sensing_instrument_' work?
According to the definition, there is nothing related to the satellite in
instrument_scan_angle: The angle between the line of sight from an instrument
and its reference scan position. We don't know whether the reference scan
position is defined relative to the host platform, to the earth, to the sky, or
to the instrument's frame. It would only be appropriate to add a platform
reference if the relationship to it is clear in the context of the definition.
More generally, there is another concern, with the definition of line of sight.
If the 'instrument_x_angle is changed to satellite_x_angle or platform_x_angle
(or 'y_x_angle' :-), the question becomes, how is the line of sight of the
satellite (platform, y) defined? Some satellites/platforms have multiple
instruments with different lines of sight, so it is not always obvious. A
recommendation here is to define the line of sight in CF as the primary
viewing direction, or a defined primary reference axis for the system, and
expect that to be defined for the hardware item in question in the description
of the variable.
More generally still, from OGC Sensor Web Enablement (and other) work, it is
apparent there can be multiple instances nested within each other -- a sensor
within an instrument within another instrument within a platform, to pick an
example. A more systematic approach references all of these with a single term
('system' is used in SWE, and works reasonably well). Alas, if you want all of
those in one data set, you will have multiple variables with the same
standard_name. But that will also be true if sensor, instrument, platform are
the 3 prefixes (since at least two of those concepts nest).
But (hopefully I recall this correctly) there is nothing that says a
standard_name can only be used once in a data set, so from that perspective I
would propose 'system' as the noun, backfilled by 'sensor', 'instrument', or
'platform' if particular communities need/want that.
Bear in mind that, to the extent we want CF to represent data that is readily
interoperable, the use of any of these standard names will not promise
interoperability for the corresponding data, since my sensor may be your
instrument, and someone else's platform, just by virtue of our own already
divergent use of those terms. But they are quite useful in context, so I hope
we still get to use them.
john
On Oct 19, 2010, at 16:44, Cameron-smith, Philip wrote:
Hi Jonathan,
Sometimes these instruments are also flown on aircraft, so do we want to
hardwire 'satellite' into the standard_name?
It is a bit of a mouthful, but would 'remote_sensing_instrument_' work?
Best wishes,
Philip
---
Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
---
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-
boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: Tuesday, October 19, 2010 6:40 AM
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] New standard names for satellite obs data
Dear Evan et al.
I agree with this:
instrument_zenith_angle - satellite_zenith_angle
instrument_azimuth_angle - satellite_azimuth_angle
satellite_scan_angle - satellite_view_angle
And add:
instrument_scan_angle
The angle between the line of sight from an instrument and its
reference scan position.
Could you put satellite in there too as well somehow? Instrument is
a very
general word and it may not obvious what the phrase refers to without
mentioning satellite.
Cheers
Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://BLOCKEDmailman.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
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
Dear Aleksandar, That sounds interesting because you are suggesting to introduce different quantities whether they are collocated or not. I've got two comments: · Are you sure you need a standard name such as time_label_iso8601? I mean: isn't it possible to use time standard name instead? (And put somewhere that it is ISO 8601 compliant information, like in 'long name' attribute) · In principle, you could consider that a collocated quantity is the same geophysical quantity that a non collocated one. But it is also true that identifying collocated quantities with CF attributes could ease some processes, when comparing temporal series. If we suppose that, how would you identify two quantities like eg toa_outgoing_spectral_radiance_mean_within_collocation_target that are defined by two different collocation targets? Thanks Aleksandar! Best regards, Olivier. -Message d'origine- De : cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] De la part de Aleksandar Jelenak Envoyé : jeudi 7 octobre 2010 16:40 À : cf-metadata@cgd.ucar.edu Objet : [CF-metadata] New standard names for satellite obs data Dear all, I am submitting 13 new standard names for acceptance in the official list. I have tried to follow the convention's guidelines and used the current standard names as examples. The new names are developed to represent some common types of satellite obs data. I welcome any suggestion on how to improve them. 1) instrument_channel_identifier [dimensionless] Alphanumeric identifier of instrument's channel. 2) time_label_iso8601 [dimensionless] String containing date-time information in one of the ISO 8601 formats. 3) instrument_zenith_angle [degree] The angle between the line of sight to the instrument and the local vertical. 4) satellite_scan_angle [degree] The angle between the line of sight from the satellite and the nadir line. Nadir is the direction given by the vertical from the satellite looking towards the center of the Earth. 5) instrument_azimuth_angle [degree] The horizontal angle between the line of sight to the instrument and a reference direction which is often due north. The angle is measured clockwise. 6) relative_instrument_azimuth_angle [degree] Difference between two instrument_azimuth_angle values. 7) toa_outgoing_spectral_radiance [mW m-2 sr-1 (cm-1)-1] toa means top of atmosphere; outgoing means emitted toward outer space; spectral means per unit wavenumber or as a function of wavenumber. Radiance is the radiative flux in a particular direction, per unit of solid angle. 8) collocation_time [s] A time line of events used as the temporal reference during collocation processing. Collocation is grouping of at least two observation events based on a set of criteria (typically spatial and temporal). 9) collocation_time_difference [s] The temporal difference between the monitored event and the reference event being collocated. Collocation is grouping of at least two observation events based on a set of criteria (typically spatial and temporal). 10) toa_outgoing_spectral_radiance_mean_within_collocation_target or average_of_toa_outgoing_spectral_radiance_within_collocation_target [mW m-2 sr-1 (cm-1)-1] An average of toa_outgoing_spectral_radiance observations from instrument's adjacent field of views within a collocation target. Collocation target is an area on the Earth's surface at which observations from at least two instruments are collected. Its size is defined by the instrument with the largest field of view footprint. 11) toa_outgoing_spectral_radiance_stdev_within_collocation_target or stdev_of_toa_outgoing_spectral_radiance_within_collocation_target [mW m-2 sr-1 (cm-1)-1] Standard deviation of toa_outgoing_spectral_radiance observations from instrument's adjacent field of views within a collocation target. Collocation target is an area on the Earth's surface at which observations from at least two instruments are collected. Its size is defined by the instrument with the largest field of view footprint. 12) toa_outgoing_spectral_radiance_mean_within_collocation_scene or average_of_toa_outgoing_spectral_radiance_within_collocation_scene [mW m-2 sr-1 (cm-1)-1] An average of toa_outgoing_spectral_radiance observations within a collocation scene. Collocation scene is a grouping of instrument's adjacent field of views (FOVs) centered on a collocation target. Collocation target is an area on the Earth's surface at which observations from at least two instruments are collected. Its size is defined by the instrument
[CF-metadata] New standard names for satellite obs data
Dear all, I am submitting 13 new standard names for acceptance in the official list. I have tried to follow the convention's guidelines and used the current standard names as examples. The new names are developed to represent some common types of satellite obs data. I welcome any suggestion on how to improve them. 1) instrument_channel_identifier [dimensionless] Alphanumeric identifier of instrument's channel. 2) time_label_iso8601 [dimensionless] String containing date-time information in one of the ISO 8601 formats. 3) instrument_zenith_angle [degree] The angle between the line of sight to the instrument and the local vertical. 4) satellite_scan_angle [degree] The angle between the line of sight from the satellite and the nadir line. Nadir is the direction given by the vertical from the satellite looking towards the center of the Earth. 5) instrument_azimuth_angle [degree] The horizontal angle between the line of sight to the instrument and a reference direction which is often due north. The angle is measured clockwise. 6) relative_instrument_azimuth_angle [degree] Difference between two instrument_azimuth_angle values. 7) toa_outgoing_spectral_radiance [mW m-2 sr-1 (cm-1)-1] toa means top of atmosphere; outgoing means emitted toward outer space; spectral means per unit wavenumber or as a function of wavenumber. Radiance is the radiative flux in a particular direction, per unit of solid angle. 8) collocation_time [s] A time line of events used as the temporal reference during collocation processing. Collocation is grouping of at least two observation events based on a set of criteria (typically spatial and temporal). 9) collocation_time_difference [s] The temporal difference between the monitored event and the reference event being collocated. Collocation is grouping of at least two observation events based on a set of criteria (typically spatial and temporal). 10) toa_outgoing_spectral_radiance_mean_within_collocation_target or average_of_toa_outgoing_spectral_radiance_within_collocation_target [mW m-2 sr-1 (cm-1)-1] An average of toa_outgoing_spectral_radiance observations from instrument's adjacent field of views within a collocation target. Collocation target is an area on the Earth's surface at which observations from at least two instruments are collected. Its size is defined by the instrument with the largest field of view footprint. 11) toa_outgoing_spectral_radiance_stdev_within_collocation_target or stdev_of_toa_outgoing_spectral_radiance_within_collocation_target [mW m-2 sr-1 (cm-1)-1] Standard deviation of toa_outgoing_spectral_radiance observations from instrument's adjacent field of views within a collocation target. Collocation target is an area on the Earth's surface at which observations from at least two instruments are collected. Its size is defined by the instrument with the largest field of view footprint. 12) toa_outgoing_spectral_radiance_mean_within_collocation_scene or average_of_toa_outgoing_spectral_radiance_within_collocation_scene [mW m-2 sr-1 (cm-1)-1] An average of toa_outgoing_spectral_radiance observations within a collocation scene. Collocation scene is a grouping of instrument's adjacent field of views (FOVs) centered on a collocation target. Collocation target is an area on the Earth's surface at which observations from at least two instruments are collected. Its size is defined by the instrument with the largest FOV footprint. Collocation scene's size is typically about an order of magnitude larger than its collocation target. 13) toa_outgoing_spectral_radiance_stdev_within_collocation_scene or stdev_of_toa_outgoing_spectral_radiance_within_collocation_scene [mW m-2 sr-1 (cm-1)-1] Standard deviation of toa_outgoing_spectral_radiance observations within a collocation scene. Collocation scene is a grouping of instrument's adjacent field of views (FOVs) centered on a collocation target. Collocation target is an area on the Earth's surface at which observations from at least two instruments are collected. Its size is defined by the instrument with the largest FOV footprint. Collocation scene's size is typically about an order of magnitude larger than its collocation target. -Aleksandar ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
