GoToMeeting may work, although I'm not sure how it well it handles
animation.
Jim
On 3/6/14 11:29 AM, Brian Mapes wrote:
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
