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.
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