Hi all,
I finally took a look today (wrote this email before Don's came in, can't
keep up). Brian has raised so many important issues that it is hard to keep
track of them all! From reading the thread I see that some things have been
clarified. Maybe during a go-to-meeting we could figure out which issues
remain that require action?
First two nuts and bolts things I noticed:
1. I tried turning PD off in a view window and then loading in a satellite
image. It seemed to me that PD was still active. Has anyone tried this?
Upon further inspection, I found that when I turned PD off in the view
window, and then loaded in a new dataset PD was indeed off but to get the
full data I had to slide the magnification bar over in the Advanced tab in
the field selector. I think if PD is off, it should automatically be at
full res. Also, I shouldn't have to load in the dataset again to turn PD
off. I could be off here, but this was my experience.
2. Does PD ever turn on for gridded data? I haven't noticed it doing so. If
it does, I think gridded datasets should have the magnification listed in
the display legend like it does for satellite.
I was able to load in satellite, model, and surface data and then move
around by changing the projection. I thought this worked just fine as
intended.
I agree that it would be useful to be able to save a bundle and then be
able to change where it displays. We have discussed this in the past. I
also agree with Brian's use-case for current weather. This is also how I
would want to use it. I guess the problem here is saving some things that
use PD in a bundle and other things that do not? Brian, I am not entirely
sure why you face so many challenges with data subsetting? I have not had
the need to use it much, and I would just try to get away with loading in
the whole dataset if it were possible and more convenient. This does slow
things down, of course.
I also see Brian's point about use of PD in case studies. I would not want
to save bundles with PD for this purpose, as when I assess the students
evaluation of the cases I need to be sure that I am seeing exactly what
they were seeing.
The last point about just what exactly can we be doing with IDV is a good
one. The IDV has really come into its own as a teaching and research tool
(along with RAMADDA), but I don't think many in the MET community are
really using it to its full capability. At the last Usercomm meeting I
brought up the idea of holding a conference where people present how
they've been using the IDV to enhance teaching and research. As am sure
you're aware, NCAR puts on a WRF conference with this same purpose. There
didn't seem to be any support for this idea.
Marty
_____________________________
Martin A. Baxter, Ph.D.
Associate Professor of Meteorology
Department of Earth and Atmospheric Sciences
Central Michigan University
Currently on sabbatical at North Carolina State University in Raleigh, NC
NC State Phone: (989) 854-3930
http://people.cst.cmich.edu/baxte1ma
On Thu, Mar 6, 2014 at 4:21 PM, Jim Steenburgh <jim.steenburgh@xxxxxxxx>wrote:
> 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
>>
>>
>>
>>
>
