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 prompt
the 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 data
when 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/
