It is not really a problem to represent this in CF, just less than pretty.
time becomes a function of more than one dimension.
So, if by "local time" you mean that time is such that noon local time
has the sun directly overhead, i.e. local time before the railroads
established time zones, then we have
time(longitude,time)
i.e. two dimensions time, longitude, and a variable time which gives
UTC for each raster point. (Unless, of course, my physics is a bit
off).
On the other hand, if you mean local time as in local time zone, then
time(longitude,latitude,time)
because time zones have a big political component to them (which is
time dependent).
You can, of course, use two different names for time dimension and
time variable, would make things easier to understand.
Given that this analyis, while valid, is a bit unusual, seems
appropriate that CF can represent it, though not as simply as an image
which is uniform in UTC.
Benno
On Fri, Oct 22, 2010 at 12:32 PM, Julia Collins <collinsj at nsidc.org> wrote:
> Hi,
>
> On Fri, 22 Oct 2010, Lowry, Roy K wrote:
>>
>> I wonder how many existing CF data files would have the meaning of their
>> time channel changed were this suggestion to be adopted.
>
> I am sure many. In some cases it might even make them accurate. :-) At some
> level, it's a tradeoff between "breaking" existing data descriptions and
> creating a more robust standard. Whether my suggestion creates a more
> robust standard or not is up for debate. It does align it more closely with
> the ISO standard, and I think there's something to be said for that.
>
>> If I were Julia I would be reworking my data so that the time channel was
>> true UT. ?I've had so many problems in the past with local time
>> co-ordinates........
>
> It's not data I'm generating, but rather data provided by a PI who has
> determined that this is how he wants to present his data. I believe the
> idea is to be able to view a wide geographic area over the same effective
> local time. It's a composite image. If you can tell me how to represent
> these multiple UTC times for one variable using the existing CF
> conventions, then I'll try to do so. ?I believe CF limits me to specifying
> one time zone for a particular time dimension. Re-working the data so that
> it's broken up into separate time zones would, as I understand it, mean
> splitting up the data variable into multiple variables, each with their own
> time dimension, which is not what the data provider wants to do. Splitting
> the variable would require the user to put the pieces back together in
> order to see the image as the data provider intended. As far as I can tell,
> following the ISO interpretation of the time zone indicator does exactly
> what I need without ambiguity. I'd like to describe the data in a way
> that's perfectly compliant with the CF convention, but in this case I don't
> see a way to do so.
>
> Thanks,
> Julia
> --
> Julia Collins
> National Snow and Ice Data Center
> http://nsidc.org/
> collinsj at nsidc.org
> +1 303.492.6405
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Dr. M. Benno Blumenthal? ? ? ? ? benno at iri.columbia.edu
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000?? (845) 680-4450
Received on Fri Oct 22 2010 - 11:46:53 BST
