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.
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.
Hi Brian- On 2/26/14 12:15 PM, Brian Mapes wrote:
Good conversation, Don, thanks for refining my concerns/questions. Here are some responses.
I hope others will chime in.
Ability to move a bundle easily would be great!I agree and think this needs to be implemented before the 5.0 release.Terrific!
Right now, if you load in a bundle that was created with matching the display region and progressive resolution, after it's done loading you can move it to a different region by changing the projection or using the rubberband box. So, if I redo my boulder bundle using the match region option and have progressive resolution turned on, then I can easily move it over Florida. However, there are caveats with this. My boulder bundle uses the GINIEAST dataset for satellite imagery (e.g. GOES-East). If I want to display it over the west coast, I'm out of luck for the satellite data because it doesn't extend that far west.
How should this option be presented to the user? As you've stated, sometimes you want to do this, sometimes not.Yes, and sometimes for all displays (move the whole bundle), but sometimes for only special displays (usually of high-res data, which is really what all this is being driven by) within a fixed backdrop of synoptic fields on larger scales.
That's going to be tricky.
Can one turn on and off the "reload upon reprojection status of a display in the Properties? I don't see a checkbox there:
It's not in the Display Properties (but could be). In discussions with SSEC, clicking OK/Apply on the Properties causes lots more things to happen than just changing a property. So, we put it under the View menu.
I think more than one piece of functionality has been added, from a user pesrspective.
Agreed, although they are kind of linked.
So it may call for more than one named checkbox or "feature." Or if that is code-impossible, if it is just One Thing in the code, then all we can do is name it well, document it well, and hopefully illustrate a "best practices" culture around how to use it effectively and not shoot yourself in the foot with it.
I'd rather keep it as one thing to avoid confusion. But then you are confused already, no?
Turning it off should make IDV5.0 100% backward compatible, right?
Theoretically.
One option I've considered is that the user can check a box in the load bundle dialog that would say "Match Display Region" or something like that. If it was checked, then the projection information in the bundle would be ignored and it would use the existing display region. However, if you've turned off the function to promptthe user when loading a bundle, you wouldn't get that option. This seems useful in some cases, and conflicts with nothing else, so why not? A little more verbose: "Import All Displays to Match Current Display Region" or shorter: "Override Subsetting to Match Display Region". or shorter...
Good suggestions. I'll play with the wording.
Would that subset the datasets? Or just the individual displays?
Individual displays.
If I go to create a new display carelessly with defaults, what will I get?
Whatever the defaults are set to. It would only affect displays in the bundle. Any new displays would act as new displays normally would.
Should this be a global preference, so that any bundle automatically uses the display region if it is set? Should the default be to always match the display region when loading in a bundle?No, and No way! It's too specialzed a functionality.
I tend to agree, but had to ask.
It would only serve for a whole new use style: always navigate the map before loading anything. Who does that? No current user.
That's the default behavior in NMAP2 - subset and load data into the projection of the currently displayed region.
Is there another way you think this should be handled?I think of reloading in a new Display Region as a big operation, to be undertaken rarely, Reproject With Reloading perhaps it is called. Maybe it should be buried in the Projection menu, and require both a checkbox to be set (default off) -- "Reload Data to Match New Projection Area" -- and a scary click buried safely at least one menu down in the Projection menu.
Here's my use case. I make a bundle over Colorado of satellite, radar, observations and model data. I use that for looking at the weather over my area on a daily basis. On a particular day, there is some interesting weather (e.g. a Cat 5 hurricane hitting Miami). I want to look at the weather over Florida using the same displays I have over boulder. I could load in the boulder bundle, and then change the projection to florida and that would work, but I'd be loading data twice. Or, I could set my display projection to Florida, and load in my bundle and somehow tell it to use the Florida projection. To me, I need to tell the bundle what to do, not the display (because it knows nothing about what's coming at it).
(By the way, these From Displays projections are not helpful, could the menu show %shortname% instead of %displayname%? ) screenshot:
That's for Unidata to decide/implement.
That is actually much MORE than just "progressive disclosure," so again the name is not a good fit to the functionality.That's why we're asking the committee to figure out the best name. ;-)Right, I think we need at least 2 names for the at least 2 functionalities. One is redefining the spatial subsetting (moving displays), as above. Done somewhat rarely, and the Projecton menu seems like the place for it. 1. "Reload Data to Match New Display Area"
I agree that there can be confusion between Progressive Resolution with the rubberband box and changing projections.
The other is what this thing initially started out as. 2. "Auto-stride and Auto-crop to Match Display Area" during the moment of display creation, based on display area.
I think this is covered pretty well with the Match Display Area function in the data subset panel.
Sorry my proposed function names are so long. What do others think?
The silence is deafening. ;-)
I notice that only newly-created displays have movable domains by this Projections change method. Will that always be true?It depends on how you created the display. If you selected to match the display region, it sets the initial region to match the display. If you have the Use Progressive Disclosure option selected on either the View (under Projections) it also sets the property on the display to progressively disclose higher/lower resolution datawhen there is a projection change or you use the rubberband box. The way I have used it is to create an ADDITIONAL display of high resolution data in some area, without deleting all the larger-area, coarser-gid displays. So - to avoid the auto-reload, do I need to uncheck the box during display creation? (TOO HARD TO REMEMBER EVERY TIME) Or can I just need to create a display without using the Match Display Region?
That's what I would do. Then it will always be at the resolution you picked when you loaded it in.
If this creation-moment choice is the key determinant of whether a display is auto-reloading-upon-reprojection, then why even have a global check box to turn the whole functionality off and on?
Because another set of users wanted a global way to turn things off. ;-)
Imagine this use case: I am studying some convective event with satellite, radar, HRRR data, for which I use UPD as Auto-Crop. I would constantly be forgetting to turn a checkbox off when I zoom out to create a synoptic model grid context display around my convective storm area. Then it's D'oh!! (palm to forehead) every time I do a refresh in a zoomed area and lose all my synoptic context fields.
A good use case. We'll have to think about this.
For each display, that can be turned off (or on) under the View menu of the display control. You can disable this feature for all displays by unchecking the option under the Projections Menu.And all of this hinges on having it enabled in global Preferences? Or is that just where my default status is set?
The global preference sets the default on any view created. Each display gets it's preference from the view it is being loaded into. If you turn off PR before you create the displays, they will not be reloaded if you change projections or use the RBB.
Legacy display bundles will never have this property, and will have to be rebuilt again? Or could some .xml-adjusting sed script update old bundles to work with the new portable reloading (PR)?You could turn it on for each display and resave the bundle. Maybe Yuan can figure out a way to do ti on the fly.Yes, how to I turn it on for an existing display? In Properties menu? But there is no option there.
In the View menu by checking/unchecking "Use Progressive Disclosure"
Gotta go. Hope this is clear.
Me too. I hope others can play with this and chime in. Now's your chance! Don -- Don Murray NOAA/ESRL/PSD and CU-CIRES 303-497-3596 http://www.esrl.noaa.gov/psd/people/don.murray/
idvdevelopers archives: