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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.