Can we propose a definition of 'time_offset'? I might want to suggest something a little narrower than time_offset. I can anticipate systems that include a time_offset variable that is not at all the same meaning as the time_offset being proposed here. (Depending, of course, on how generally the definition is worded.)
John > > The standard name alone is sufficient for our case. I agree with you > that we should not add unnecessary complexity to the CF standard. I > think we will use the standard name 'time_offset'. > > Best regards, > Maarten > > > > On 02/02/2011 05:15 PM, Jonathan Gregory wrote: >> Dear Maarten >> >> What you write about pixeltime as an aux coord var (y,x) and your ncdump look >> sensible to me. I think that's all fine. >> >>> The standard_name time_offset (s) seems good to me. In the long name we >>> can add an explanation that this variable deals with the time offset for >>> each pixel. >> >> OK. So that is a definite proposal for a new standard name. >> >> Do you think the standard name alone is sufficient? Proposing a new attribute >> is more work than proposing a standard_name, since it means amending the CF >> standard. I can see there could be value in a relative_to attribute, but it >> might be an unnecessary complexity. I wonder what you and others think. >> >> Best wishes >> >> Jonathan >> > > > -- > Maarten Plieger > KNMI, R&D Information and Observation Technology, De Bilt > (t) +31 30 2206330 > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata John Graybeal <mailto:[email protected]> 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 [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
