| • |
|
|
|
|||
|
||||
This most recent discussion parallels deliberations over conventions to drive
CDF applications at NASA/GSFC that took place over 6 years ago. I did post
some comments about this to the netCDF group on 10/30/90 (attached below).
Epoch-based time as a double (for ms) and calenderic utilities are part of the
CDF distribution (for both portable -IEEE- and native encoding). This was
decided back then for the same and additional reasons that others have
outlined yesterday and today. CDF-based visualization tools certainly
take advantage of the precision and flexiblity of this approach. But it's
not required. When it is used it can be mapped to a specific dimension.
Applications can break up the double for separate (dimension-like) manipulation
of time in more convenient chunks (e.g., year, hours, etc.) especially in
making plots to match display and data resolution.
Lloyd Treinish
------------------- stuff from 10/30/90 posting ------------------------------
As just a point of information, CDF Version 1 (as well as subsequent versions)
at NASA/GSFC-NSSDC has NO specific requirements or conventions for time. There
are specific CDF-based data analysis and visualization applications at NSSDC
that require a time convention for specific temporal manipulation utilities.
That convention is the one that Russ referenced. The specific choice of
"units" was based on the need to support historical data as well as space-borne
observations with a single "absolute" epoch reference. Nothing in CDF or
netCDF precludes the use of other time conventions. Many time-dependent data
sets have been created in CDF without the msec since 0 AD convention, or with
an additional temporal variable (e.g., a running time such as "time since
launch"). CDF as well as the NSSDC CDF utilities can handle those alternate
forms for time. It's just that there are specific utilities for that time
representation, which are optional for a user. I hope that clarifies the
point. I certainly have a number of ideas on time representation based
upon applications or storage form, which netCDF can easily support. But Russ'
approach is fine from the netCDF perspective. Specific netCDF-based software
may require something less flexible, but that's an exercise left up to the
netCDF user.
| Contact Us • Site Map • Search • Terms and Conditions • Privacy Policy • Participation Policy | ||||||
|
||||||
