[Opengeoscience-developers] long live CLT!

[David E DeMarle]

From:
{ "_id" : ObjectId("52152cd35c01af00ce90dfdf"), "name" : "clt", "variables"
: [         {       "units" : "%",    "dim" : [ ],    "range" : [     0,
   100 ],  "name" : "clt",         "tags" : [ ] } ], "timeInfo" : {
"numSteps" : 120, "dateRange" : [        [       1979.0849315068492,
1.0333333333333334,     1 ],      [       1988.8657534246574,
10.533333333333333,     16 ] ], "nativeRange" : [ 0, 119 ], "nativeDelta" :
1, "rawTimes" : [     0,      1,      2,      3,      4,      5,      6,
   7,      8,      9,        10,     11,     12,     13,     14,     15,
  16,     17,     18,     19,     20,     21,     22,       23,     24,
25,     26,     27,     28,     29,     30,     31,     32,     33,     34,
    35,       36,     37,     38,     39,     40,     41,     42,     43,
  44,     45,     46,     47,     48,       49,     50,     51,     52,
53,     54,     55,     56,     57,     58,     59,     60,     61,
62,     63,     64,     65,     66,     67,     68,     69,     70,     71,
    72,     73,     74,       75,     76,     77,     78,     79,     80,
  81,     82,     83,     84,     85,     86,     87,       88,     89,
90,     91,     92,     93,     94,     95,     96,     97,     98,     99,
    100,      101,    102,    103,    104,    105,    106,    107,    108,
   109,    110,    111,    112,    113,      114,    115,    116,    117,
 118,    119 ], "stdDelta" : 30, "units" : "months since 1979-1-1 0",
"nativeUnits" : "months", "stdTimeRange" : [ 722366, 725936 ] }, "basename"
: "clt.nc", "spatialInfo" : [ -180, 175, -90, 90, 0, 0 ] }

The interesting stuff is:
 "timeInfo" : {
    "rawTimes" : [ ...], # once GUI doesn't use this we can remove from db,
we just have to make sure VTK gets a time from within this native system.
We can convert in vtk_reader from rest if necessary.

   "units" : "months since 1979-1-1 0", #keep around to rebuild converters
from

   "numSteps" : 120,

   "nativeUnits" : "months", # in case we need to work in native system for
better precision
   "nativeDelta" : 1,
   "nativeRange" : [ 0, 119 ],

    #stdUnits defined to be days
    "stdDelta" : 30,  # for usual case when we work in standardize system
(days since 0-0-0)
    "stdTimeRange" : [ 722366, 725936 ]

    #human readable Y-M-D when we put cdtime or udunits in, these will be
prettier
    "dateRange" : [ [ 1979.0849315068492, 1.0333333333333334, 1 ],
                          [ 1988.8657534246574, 10.533333333333333, 16 ] ],

  }

It is valid for most of the above to not exist when we import a non-time
varying data set. It is also valid to have a single timestep, in which case
numSteps=1 and *Delta == 0.

Not going to put something like cdtime in just yet. When we do we'll have
more time meta data (which calendar etc) and may end up switching what unit
and basis "std" means. This though should be enough for rough comparisons
of most data sets at hand now.

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/opengeoscience-developers/attachments/20130821/ed775cc1/attachment.html>