Hi all,
I finally took a look yesterday (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 6:06 PM, Don Murray (NOAA Affiliate) <
don.murray@xxxxxxxx> wrote:
> Hi Brian-
>
> Thanks for taking the time to write down your thoughts. These are
> interesting use cases and ones that the current design doesn't support. If
> I can distill it down to how this might be workable, here's what I would
> see:
>
> - You would use the "Match Display Region" to load low resolution data
> into the zoomed out view with PR turned off (somehow) and these would be
> "unchangeable" regions.
> - You would zoom in over florida and use "Match Display Region" with PR
> turned on to load in those views you want to flag as "changeable".
> - As you zoomed around with a projection change and/or rubber banding (or
> asked to load the bundle into a new region), the "changeable" displays
> would fetch data to match the coverage and resolution of the new region,
> but the "unchangeable" ones would remain at the same resolution and
> coverage.
>
> I know it would be a pain if you wanted the same data at both high and low
> resolutions, but you'd just have to have 2 displays of the same data in
> that case.
>
> As for bundles, they would behave the same way, so if you wanted just high
> resolution displays, you'd have to have a high resolution bundle or be able
> to define the region that the bundle would load in and the "changeable"
> displays would be zoomed in, but the "unchangeable" displays would still be
> there at lower resolution.
>
> zidv bundles use the regions set in the data source properties and that
> only applies (right now) to the fixed type of regions. I don't know how
> you would do it for "Match Display Region" because you could have multiple
> views using the same data source.
>
> Yuan and I will ruminate on all this and hopefully we'll here from others
> on how they want it to work.
>
> Don
>
>
> 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
>>
>>
>>
>>
> --
> Don Murray
> NOAA/ESRL/PSD and CU-CIRES
> 303-497-3596
> http://www.esrl.noaa.gov/psd/people/don.murray/
>
