[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[IDV #ETX-669397]: problem saving cached data in zipped bundle

Tom-

> Thanks for discussing this.  Don's original idea of isolating the
> single level by displaying it and then saving the displayed data as a
> netcdf file seems quite workable, and easy to explain.

Okay.  I don't think it's the best way to do it, but it's the
only game in town at this point.

> I'll have to admit, though, that my "mental model" of the "Level"
> tabbed pane in the Field Selector was that if I pick a level (or a
> time in that tab, or a stride in that one), that this was the _only_
> data that was brought from the server....which, then, when I save a
> bundle of the "state" of the session, I thought would define the data
> that would be saved (rather than fetching and saving all levels).  I
> did, of course, look at the Data Source properties, but no "level"
> option is offered there.

When you select a level, only the data for that level is downloaded
and displayed and if you cache the data, it is stored in the cache.
However, the bundle saving saves at the Data Source level, not at
the per display level.  It does preselect those variables that are
displayed as a convenience, but at the data source level, 
we do not currently have a way in the "saving" phase to specify
a single level (although it does maintain the lat/lon
subset that has been set at the data source level).   The file
writer takes an entire dataset, a list of variables and the
spatial subset information.  I though one hack would be
to set the Z stride to be larger than the number of levels and if
1000 is the first level, that's all you'd get.  However, that's 
non-deterministic and Z stride is ignored in the NetcdfCFWriter
anyway (I'll talk to John about the latter).

We could go the route of using the serialized VisAD object from a
cached data source, but that is prone to breaking if the classes
change.

I think for the upcoming 2.7 release, we'll have to keep things
as they are and attack this after the release.

Don

> On Thu, May 14, 2009 at 6:21 AM, Unidata IDV Support
> <address@hidden> wrote:
> >
> > Hi Tom (and Don),
> >
> >> There are only certain data sources that we know how to write out
> >> and read back in.  Since we don't have a generic VisAD Data writer,
> >> the cached dataset doesn't show up in the list of data sources that
> >> we know how to save.
> >>
> >
> > The CachedDataSource can writes its data to disk but we never hooked it 
> > into the zidv facility.
> > We could do that but the .iser (IDV Serialized) format it writes to just 
> > uses Java serialization
> > of the VisAD data structures which as we know does not necessarily last 
> > indefinitely.
> >
> > -Jeff
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: ETX-669397
> > Department: Support IDV
> > Priority: Normal
> > Status: Closed
> >
> >
> 
> 
> 
> --
> Tom Whittaker
> University of Wisconsin-Madison
> Space Science & Engineering Center (SSEC)
> Cooperative Institute for Meteorological Satellite Studies (CIMSS)
> 1225 W. Dayton Street
> Madison, WI  53706  USA
> ph: +1 608 262 2759
> 
> 


Ticket Details
===================
Ticket ID: ETX-669397
Department: Support IDV
Priority: Normal
Status: Open