> Yuan, Julian, etc., > > I'm using IDV v4.1 on an iMac running Mac OS X v.10.8.5. > > I'm loading and plotting geographic data, including topographic elevations, > for a domain generated locally by the WRF Preprocessing System (WPS). I'm > loading the data via one of our local RAMADDA servers > (http://virga.sfsu.edu:8080/repository/thredds). The file is a NetCDF file > (geo_em.CenCal_BayArea.nc<http://virga.sfsu.edu/data/wrf/geo_em.CenCal_BayArea.nc>). > I can load and plot this just fine (a bundle is attached: > Dempsey_SFBayAreaTopography_RAMADDA.xidv.) > > However, a problem arises when I create a new geographic data set with the > same size and containing the same types of fields but shifted in location, > and overwrite the previous NetCDF file with the new data, keeping the same > file name. To plot this geographically shifted data set in the IDV after > plotting the original one, I first remove the original displays and loaded > data by selecting Edit > Remove All Displays and Data. Then I access and load > the new file (which has the same name as the old, overwritten file), and plot > the result using exactly the same plotting specifications as the original one. > > Unfortunately, the plot that I get is identical to the original one. This is > true even though the contents of the files are not the same (I checked to > make sure)--the location metadata in each of the two files are exactly what I > want them to be (not the same). Hence, the IDV still appears to be plotting > the original data, not the new data, even though I've presumably removed the > original data and loaded the new data. > > I get the same results if I first remove the original data source by > <Command>-clicking on the data source in the Dashboard > Field Selector > > Data Sources, and selecting "Remove Data Source". Ditto if I remove the data > from the IDV by either means, then quit the IDV, restart, and try again. > Ditto if I refresh the listing of files offered by RAMADDA after overwriting > the original file but before selecting and loading the new version. Ditto if > I don't remove the display of the original plot, or don't remove either the > display or the data source before loading the replacement data and plotting > it. > > On the other hand, if I give the new file a different name from the original > one, load it, and plot it, I get a plot of the shifted domain, just as I > expect. > > On the third hand, if I access and load the new data using HTTP or as a local > file instead of via RAMADDA, I get a plot of the shifted domain, as desired. > > On the fourth hand, if I put the two different data sets in files with the > same name but in two different directories (e.g., SFSU Weather Data > wrf and > in SFSU Weather Data > wrf > temp_demo), and plot the second one after > removing the data and displays created from plotting the first one, then the > second plot is successful. > > And finally, if I access the original file via HTTP or as a local file, then > remove the data and display from the IDV, then overwrite the original data > with the new data (keeping the file name the same), and finally access and > load the new file via RAMADDA, the new plot is correct. > > To summarize: Using RAMADDA, there is a problem when loading and plotting two > different sets of data in succession stored files that have the same file > name and reside in the same directory. The second plot is identical to the > first plot, even when the data and display from the first plot are removed > before loading the replacement data. > > A final note: when I refresh the listing of the directory containing the data > in RAMADDA (SFSU Weather Data > wrf), RAMADDA jumps back to a parent > directory (containing SFSU Weather Data) two levels higher up, though when I > navigate back down to the directory I want (wrf), the listing is indeed > refreshed. This is annoying behavior, though! > > -- Dave > > P.S. Yuan, you're probably fully engaged responding the significant feedback > being provided about the new image plotting enhancements, to this probably > feels like a distraction! (I wonder if Jeff McWhirter is ultimately going to > have to deal with it, if it turns out to be primarily a RAMADDA problem.) > Dave, I am going to close this ticket since Jeff provided a fixed in this morning's email. We can reopen this ticket if his new release doesn't fix your problem. Yuan > > *************************************************************** > * Dr. Dave Dempsey | ^ ___ \|/ > * > * Dept. of Earth & Climate Sciences | ) ^ /||_||\ --0-- * > * San Francisco State University | ) ) / ||_|| \ /|\ * > * 1600 Holloway Ave. | ) ) / ||_|| \ > * > * San Francisco, CA 94132 | ) ) / ||_|| \ ^ * > * | ) ) ) > ||_|| \ * > * Phone: (415) 338-7716 | ) ) )~||~||~~~~ \~~* > * FAX: (415) 338-7705 | ) ) ) ) ~ ~ ~ ~ ~ ~* > * Email: address@hidden<mailto:address@hidden> | ) ) ) ) > ) ~ ~ ~ ~ * > *************************************************************** > > > > > > Ticket Details =================== Ticket ID: HAU-717700 Department: Support IDV Priority: Normal Status: Closed
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.