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:
--------------
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
