[Thread Prev][Thread Next][Index]

Re: Accessing a GDS dataset with the LAS

Hi All,

I believe that Ferret uses double precision values to represent axes, so something else must be going on. Can you release the DODS URL of this dataset? That would help a lot.

Joe W. -- in general, it would be better if GDS used a time origin that is past the date where the calendar changed from Julian to Gregorian as different applications interpret earlier dates differently. For instance, Ferret assumes that 1/1/1 is on a Gregorian calendar, while GrADS assumes that 1/1/1 is on the Julian calendar. It might be convenient to use the Unix epoch instead (January 1, 1970).

At 11:51 AM 2/8/2002 -0700, Dave Brown wrote:

On Fri, 8 Feb 2002, Joe Wielgosz wrote:

> Jennifer M. Adams wrote:
> > Dave Brown wrote:
> >
> >
> >>The original dataset encodes the time dimension as days since the
> >>beginning of the year, in this case 1990. This means the 1 hour
> >>timestep is fractional --  0.0416666666 days. GDS adjusts the
> >>time unit to "days since 1-1-1 00:00:0.0", so the starting time,
> >>as presented by DODS, is 726469.0.
> >>
> >
> > Hi, Dave --
> >
> > My understanding is that the metadata accompanying a GDS
> > dataset is generated by GrADS, so it may be relevant how you
> > describe the original dataset to GrADS in order to serve it
> > with your GDS. It sounds like somewhere in there the time
> > zero got changed from 1-1-1990 to 1-1-1. Can you point me to
> > the DODS URL where this GDS data set is located? Would it be
> > possible for me to access the original data directly with
> > GrADS using my account on motherlode at NCAR?
> >
> Perhaps I can help clarify this part a bit. Nothing is going wrong here.
> In fact, the only time units the GDS knows about are "days since 1-1-1
> 00:00:0.0". Time values extracted from datasets are automatically
> converted to these units in the GDS, before being sent.
> This is an artifact of the way time values are obtained in GrADS - it
> was simpler just to pick a standard set of units rather than trying to
> handle each dataset individually.
> I don't know if that helps, but good luck.
> And please let me know if the GDS needs improvement in this area.
> - Joe

Thanks for you input, Joe. This is what I had surmised from looking at
several datasets served by GDS.

> >
> >>The LAS xml for the time dimension, as generated by the addXml.pl
> >>script using the first file in the dataset as input,
> >>reads as follows:
> >>
> >><h0001_nc_time units="hour" type="t">
> >>  <arange start="1990-01-01 00:00:00" step="1" size="8760"/>
> >></h0001_nc_time>
> >>
> >
> > It's been a while since I've thought about LAS xml coding,
> > but here the units are hours, so that may be one source of
> > error. Are you describing the original data set (in 365
> > separate files) or the GDS data set (1 DODS URL) to the LAS?
> >
> >

Well, the point is that LAS software (specifically ui/perl/LASNetCDF.pm)
automatically made a correct conversion from time specified in the
NetCDF in fractional days into hours in order to generate this xml. The
LAS user interface understands the conversion, and I believe that
Ferret does as well. But my hunch still is that Ferret is treating the
coordinate values as float types, and therefore is only able to resolve
the values to between 6 and 7 digits of precision, not enough in this

> >
> >>LAS 5.0 read the xml and generated the user interface for this
> >>dataset without problems (*), but when I try to access the data I get
> >>this error from Ferret:
> >>
> >> *** NOTE: Coordinates out of order or missing on axis time at
> >>subscript 2163
> >> *** NOTE: A dummy axis of subscripts will be used
> >>...
> >> **ERROR: illegal limits: "FOSSIL" is not in the range T=-8.082E+16
> >>          Axis extremes are T=0.5:8761
> >>
> >>
> >
> > Does it change anything if you skip over the LAS and just
> > try to read the DODS URL with Ferret?
> >
I guess I should try that...

> > Perhaps the LAS and Ferret experts from PMEL will have
> > additional insights...


[Thread Prev][Thread Next][Index]

Dept of Commerce / NOAA / OAR / PMEL / TMAP
Contact Us | Privacy Policy | Disclaimer | Accessibility Statement