Hi Brian-
On 2/24/14 4:41 PM, Brian Mapes wrote:
Ability to move a bundle easily would be great!
I agree and think this needs to be implemented before the 5.0 release.
I spend way too much time subsetting individual datasets
manually to be the same. And it's tedious to explain how to others.
How should this option be presented to the user? As you've stated,
sometimes you want to do this, sometimes not. 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. 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? Is
there another way you think this should be handled?
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. ;-)
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. 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.
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.
Only for very high res data is the subsampling (stride) to coarsen the fields
really used, I find -- In the long run, as a user I would wish for something
like this --
averages, not pixel striding, when looking at a dataset at coarsened scales.
https://www.vapor.ucar.edu/docs/vapor-data-preparation/vapor-data-collection
I don't see on that page where they are doing averages. Maybe I missed
it. However, that would mean that you would have to preprocess all your
data before using it. That would defeat the ability of the IDV to point
to a dataset hosted elsewhere (e.g. MERRA).
Some more comments on PR/PD/whatever it is called:
* Somebody should check how it fails near longitude seams. Currently,
one is forbidden to select data across seams, since the selector window
RBB has constraints on it. But the display area is not constrained that way.
It's too much to hope that the longitude seam problem will be fixed,
but it seems like an obvious place to check for a graceful failure mode at
least.
Yes, that's too much to hope. ;-)
* Somebody should check how this performs in sphere view. And near seams there.
Seams will always be a problem.
* I still get a lot of error messages when opening old (legacy) bundles with
this 5.0 alpha.
Most involve satellite images it appears, and appear right away, first thing.
Sometimes the satellite clouds then appear anyway, though.
These errors are unreadable to me, and distressing to users not used to
just clicking "OK" a lot to mysterious errors.
Will there be a backward compatibility problem with 5.0?
Is it easy to remove the displays and datasets and have them really be gone?
Over the past 10 years, we've made great effort to make sure the IDV can
read old bundles. That said, any bundles created with "alpha" or test
releases are not totally supported because these versions are under
development and some of the persistence information in a bundle may
change. If you have a bundle that was created with version 4.1 or
older, then 5.0 should be able to read it. If you are getting errors in
that case, you should send a message and the bundle to
support-idv@xxxxxxxxxxxxxxxx.
I may test some of these things myself, but maybe you will also want to.
Good luck!
Got a target date for 5.0 beta or whatever comes next?
How I dream of getting beyond dataset-by-dataset longitude seams.
You are on the Policy Committee (or whatever it is called these days).
You have some power to get Unidata to make it a priority as does the
User's and IDV Steering committee.
Don
--
Don Murray
NOAA/ESRL/PSD and CU-CIRES
303-497-3596
http://www.esrl.noaa.gov/psd/people/don.murray/
