NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
HP- > Final re.port on this issue. further experimenting with the data > retireval has shown the following. > > 1. The sub-area I retrieve is from along a border (eastern) of the full > disc. IDV does not digest a sub-area starting right from the border > inward (on the eastern border this is pixel 1), but only when stepping > in by some pixels (e.g. 70). This skips the few pixels outside the data. > By reduing the sub-area in this way I can read any retrieved sequence of > time slots. Can you recreate this problem with realtime data or is it solely with the archive data. > 2. There is an obvious difference in the handling of this case between > IDV and McIDAS. The error in IDV occurs from the Image Display. Depending on the data, it uses a different way of rendering. Something in the logic is not picking up the fact that it can't use the special rendererer, which produces the error. If you would, could you try using the Omni control as the display instead of Image Display for the images that cause you problems? If so, when it comes up, click on the Mappings and send in the MathType and the CoordinateSystems references. > 3. I am still puzzled however, why IDV can handle the full sub-area when > it comes from a single-slot retrieval. How does IDV know that? I'm just as puzzled. > For me the case is closed, but I do not knw whether you find it > worthwhile to do more research. If you could send the info from the Omni control, that would help me track it down. Thanks. Don Ticket Details =================== Ticket ID: NXU-741396 Department: Support IDV Priority: Normal Status: Open