Great ask Don.
Now some nice high-level questions are bubbling up, clarifying my view of UsePD.
One conclusion of this long email:
http://www.unidata.ucar.edu/software/idv/docs/workshop/dev/arch/Overview.html
A video conversation with things this up on a screen could be so much more
fruitful than all this text emailing, or a telecon.... could we have a VidCon?
--------------
Yes, for current weather bundles, the person opening it doesn't see exactly
what was saved, because the data have changed.
But does one always want to see all the displays smothering the region of every
bundle that is saved and reopened? I don't think so.
I imagine my dream current-weather "Favorite": It would be something with
hemispheric height contours, contiental or basin scale satellite and
finer-grain types of fields, and then little patches of high-res HRRR and radar
around, say, Florida (but easily movable).
After it loads, I might zoom in and out looking at it to see the whole "funnel"
of information. (Fast).
Sometimes I might move the highr-res patches with a rubberband. (Slower).
I would have to build that by having the hemispheric and continental datasets
subset by hand the old way (including the satellite, ug).
Then I could use UsePD solely for the HRRR and radar (oh but not for 3D HRRR
displays - yet).
I would have to make sure it was zoomed all the way in to Florida when I save
it, if I want it to open with the data I usually look at, like a Favorite
should.
Then the high-res datasets (but not the satellite image, for which I want the
whole continent as backdrop) would be movable by rubberband.
But that zoomed-in save view is not what I would want for an ISL script to make
movies for a weather kiosk, for example.
So I would have to rebuild another bundle, totally without using UsePD at all,
if I want the same set of Florida-patch displays on a wider context to be
showing in a zoomed-out view as an ISL-generated realtime movie.
Or I could kill the HRRR and radar on my zoomed-out movies, they just won't
have the little high-res patches on them (which may be showing in other loops
on adjacent screens) for orientation. Those visual cues to the connections
across scales will be lost, unless I do a lot of building of bundles using the
traditional klunky subsetting tools.
----------
So yes, one can disable the new UsePD functionality and just do what we have
always done, presumably (or at least that is a design goal!).
But I desire the new functionality.
Cropping and sub-striding of large hi-res datasets has been a confusing tedium,
especially for the satellite imagery.
Autocrop and autostride features of UsePD are very desirable for all users of
such data. That's what drove this, right?
Autocrop-only would be a desirable convenience for coarser grids too (for which
Autostride won't get activated).
But in that case, just having a thumbnail image of the displays to guide
rubber-banding in the Dataset and Display level Spatial Subset dialogs (instead
of merely a little continental outlines map) would be almost as good.
Does McIDAS-V already have this, maybe it would not be too hard to add? Or is
it only for imagery (not data displays)?
(Aside: whats up with the wacky white vs. gray shading in those dialogs, I have
always wondered?) See screen shot:
[cid:80dfca0b-c7c0-4db3-ad6e-7c46390207ef@amazon.rsmas.miami.edu]
--------------
I build a lot of historical case studies.
I want these to open to the viewer just as I intended: I have loaded different
data over broader vs. local areas specifically to focus attention, but within
the context of larger scales.
Building thess, I always wish the spatial subsetting were more nimble, less
awkward -- and driven by the data as I explore it by rubberbanding ove a
display, rather than in tedious efforts in a cramped little map-only region
selecter.
And then I often wish to make more case studies with the same displays
(template), by adjusting the time driver and moving the spatial domains.
Doable, but I dearly wish I were spending that time drawing rubberbands on
backdrop displays for the new case (again, interacting with data), not typing
in lat-lon values into forms or rubberbanding on blank continent maps like the
above.
Perhaps this is a boutqiue or specialty use that will not drive the design
choices here -- the curent user and steering community may be more
current-weather oriented.
But I wanted to make clear the lens through which I see the proposals.
--------------
>>
>> And what happens when a UsePD display is saved as a .zidv?
>
> I think you should test this and let us know. ;-)
The whole world of seems to get saved at full resolution. Slooowww.
This is my general sense of .zidv functionality: it grabs the outermost
hypercube, very conservative. Already it doesn't respect dataset stride choices
for example.
-------------
As a matter of habitual practice (and there is a LOT of this involved in
effective IDV usage), I am starting to think I would have to disable UsePD and
almost never use it.
This makes me sad, because it is neat and fun during an exploration stage.
But if that exploration leads to accumulation, as it does for me (Data
Integration = display accumulations), and if using UsePD means that I will
later have to remake all aspects of those more complex bundles again the old
way in order to use them -- for ISL scripts that make regular products that
look like what I am seeing, for effective generalizability to other cases times
and regions, for differential bounding of different fields and displays -- then
the initial minor conveniences of UsePD are only really good for fairly shallow
little couple-of-displays type bundles. For those, it is wonderful though, and
those are what many users do much of the time.
It may help entrain more casual users at the front end.
---------
As a matter of training, I think these "habits of effective use" are a huge
part of IDV's issue.
Yes you can do this or that or a million other things. It is "powerful,
flexible" software.
But shooting yourself in the foot is what a great many of those flexibilites
lead to.
I'm not sure where this "upper-middleware" of user practices pathways and
tactics fits in, or how it can become well integrated into entraining and
training of the future user community -- which I still think could be much
bigger and livelier than the current community, depending partly on some of
these choices we are debating.
Not that sheer numbers are the goal: the uniqueness of IDV is the things other,
simpler software doesn't do. To me, that is multi-display integration. I guess
I am seeing that UsePD is not necessarily going to be helpful in that
dimension, sadly.
-------------
Don or Yuan, could you give a thumbnail sketch of the structural constraints on
what UsePD can and can't easily be made to do?
Are there architectural tiers or levels of function that can be explained to
steering and advanced users who know too little about the code end?
Could that cut through all this imagined-use-case level discussion that feels
like it could be endless?
I suppose I should study things like this.
http://www.unidata.ucar.edu/software/idv/docs/workshop/dev/arch/Overview.html
A video conversation with this up on a screen might be so much more fruitful
than all this text emailing, or a telecon....
could we have a VidCon?
Brian
On Mar 6, 2014, at 11:22 AM, Don Murray wrote:
> Hi Brian-
>
> On 3/3/14 7:15 PM, Brian Mapes wrote:
>> On further thought, I think even UsePD displays should have their spatial
>> bounds saved and restored in the .xidv file.
>
> Then what's the point of having it use the view area? I'm not saying it
> couldn't be done, but if you ask the IDV to use the view area, then that is
> what it will do when it loads back in from a bundle.
>
>> To me it is a principle or tenet of IDV that the opener of a bundle sees
>> exactly what the saver of that bundle saw. Not worth sacrificing that for
>> the conveniences (autocrop, autostride) of UsePD.
>
> I understand this, but in this new paradigm, especially if we support moving
> a bundle to a new region on load, the user doesn't get to see what the
> orginal user saw except having the same types of displays.
>
> What do others think?
>
>> And what happens when a UsePD display is saved as a .zidv?
>
> I think you should test this and let us know. ;-)
>
> Don
> --
> Don Murray
> NOAA/ESRL/PSD and CIRES
> 303-497-3596
> http://www.esrl.noaa.gov/psd/people/don.murray/
Brian Mapes
bmapes@xxxxxxxxxxxxxxx or mapes@xxxxxxxxx
