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

[IDV #DYZ-614356]: McIDAS-V inquiry #502 updated

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [IDV #DYZ-614356]: McIDAS-V inquiry #502 updated
  • Date: Mon, 01 Feb 2010 09:28:06 -0700
Hi Rick-

This is Don.

> Looks like this one fell through the cracks, could you take another look
> at the mail below and let me know what you think. Please try the
> procedure below.

The saving happens at a real low level where basically the list of image 
datasets and the prefix/suffix info is passed of to a helper application that 
is agnostic about what it is saving.  It would require some restructuring that 
I don't think we want to do at this point.

Don
 
> > Tom Whittaker wrote:
> > I believe that the data must be re-read because it has already
> > been converted into a VisAD data object, but needs to be put into the
> > bundle in its more "native" format.  The issue is that if the VisAD
> > object is put into the bundle, that implies that the version of the
> > classes that would be stored must forever be the same as the ones
> > running in McV -- and if the code changes, the "serialized" VisAD data
> > object would not longer be usable.
> 
> > On Fri, Nov 6, 2009 at 10:56 AM, Rick Kohrs <address@hidden> wrote:
> >> > Hi Jeff,
> >> >
> >> > I'm way over due sending a response to this ticket, but I'm able to
> >> > reproduce the error in McIDAS-V and IDV (thanks Jess).
> >> >
> >> > 1) Add the dataset POES on sos.ssec.wisc.edu
> >> > 2) Select 5 most recent images
> >> > 3) Center point 90 -165
> >> > 4) Temperature for the parameter
> >> > 5) Lalo navigation
> >> > 6) Add data source
> >> > 7) Image Display
> >> > 8) Create Display
> >> > 9) Try to save as a zipped bundle
> >> > Should see an error.
> >> >
> >> > In this case, not all the images were loaded (one did not contain the 
> >> > center
> >> > point requested).  If IDV/MCV re-requests the data you'll get an error 
> >> > and
> >> > the bundle save fails.
> >> >
> >> > This is why we are wondering why the data has to be re-requested - in
> >> > theory, all the data is already there.
> >> >
> >> > Note, this is also the same as:
> >> >
> >> > http://dcdbs.ssec.wisc.edu/inquiry-v/?inquiry=579
> >> >
> >> > I'll probably close inquiry 502 and make reference to it in 579 (which is
> >> > worded more generically).
> >> >
> >> > Rick
> 
> 
> 
> Unidata McV Support wrote:
> >> Appears that the problem occurs because the data is being requested a 
> >> second time before saving the bundle. Does this have to be done?
> >>
> >> ----==== Inquiry ====----
> >> 502
> >>
> >> ----==== Summary ====----
> >> Saving a zipped bundle with polar orbiting data with multiple times loaded 
> >> in using Lat/Lon gives an error.
> >>
> >
> >
> > Yes, that is how this works. We don't keep around past requests for data 
> > coming from the displays. When we make the data source local or save it to 
> > a zidv bundle it requests its data.
> >
> > What is the problem that is occuring?
> >
> > -Jeff
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: DYZ-614356
> > Department: Support McV
> > Priority: Normal
> > Status: Closed
> >
> 
> 


Ticket Details
===================
Ticket ID: DYZ-614356
Department: Support McV
Priority: Critical
Status: Open