Good conversation, Don, thanks for refining my concerns/questions. Here are
some responses.
>> Ability to move a bundle easily would be great!
>
> I agree and think this needs to be implemented before the 5.0 release.
Terrific!
> 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.
Can one turn on and off the "reload upon reprojection status of a display in
the Properties?
I don't see a checkbox there:
[cid:19a7072d-0b9e-46f7-96bb-a791955e6186@amazon.rsmas.miami.edu]
I think more than one piece of functionality has been added, from a user
pesrspective.
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.
Turning it off should make IDV5.0 100% backward compatible, right?
> 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...
Would that subset the datasets? Or just the individual displays?
If I go to create a new display carelessly with defaults, what will I get?
> 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.
It would only serve for a whole new use style: always navigate the map before
loading anything.
Who does that? No current user.
> 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.
(By the way, these From Displays projections are not helpful, could the menu
show
%shortname% instead of %displayname%? ) screenshot:
[cid:bbb501d1-3f3f-439c-b6ee-a72571b9dad6@amazon.rsmas.miami.edu]
>> 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"
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.
Sorry my proposed function names are so long. What do others think?
>> 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?
[cid:b29fe276-b63a-49de-ae5e-76157b4704ec@amazon.rsmas.miami.edu]
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?
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.
> 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?
>> 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.
Gotta go. Hope this is clear.
Brian
![PNG image](pngU79vvivoyM.png)
![PNG image](pngggtI9ot_rm.png)
![PNG image](pngTd9eO8LZ7u.png)