make getDestinationGrid() method available to Velocity templates

[karlmsmith]

Reported by jonathan.s.callahan on 19 Oct 2007 20:04 UTC For the SlideSorter to present appropriate menus for user defined variables it must be aware of the ''destination grid'' of the user defined variable. It would be desirable for Velocity template to be able to access this information through a getDestinationGrid() method.

To figure out the ''destination grid'', the product server must know three things:

• the source grid of the user defined variable
• the axes on which analyses are defined
• which analysis functions result in a ''compressed'' axis

Because this involves a combination of information from

• LASConfig
• LASUIRequest
• ???

it is unclear which of the above classes the getDestinationGrid() method should be attached to in order to make it available to Velocity templates.

It is possible that the best way to handle this might be to run Ferret to figure out what destination grid is and then somehow make that information available to the Velocity templates or (less desirable) through an AJAX call.

Migrated-From: http://dunkel.pmel.noaa.gov/trac/las/ticket/274

[karlmsmith]

Modified by jonathan.s.callahan on 19 Oct 2007 20:07 UTC

[karlmsmith]

Comment by steven.c.hankin on 19 Dec 2007 18:45 UTC There are even deeper subtleties to this problem, beyond what is discussed above. The above strategy would allow slideSorter to recognize that (say) if an XY average has been requested, then the XY menus should not be offered. In an XYT ensemble comparison this approach would address the important use case that Keith Dixon articulated -- comparing the same CY averahe time series from ensemble members. But in a non-ensemble situation an XYT dataset would offer no choices at all -- every slideSorter frame with the identical time series plot. There are very interesting use cases that we haven't captured in this approach

The interesting use cases would allow the user to compare the time series of this XY average, with individual point locations and with averages over other regions. (We know from experience that this is a common sequence of operations in Ferret.) To capture these use cases, instead of suppressing the X and Y menus, we would want to provide range menus that allowed the user to change the averaging region for different frames of the slideSorter.

Bottom line -- to preserve the level of flexibility and control we will ultimately want, we do not want to hide the transformed axes invisibly behind getDestinationGrid(). Instead we want to expose the transformation and let another layer of software (presumably the Velocity template that creates the slideSorter UI) decide what to do with the transformation information.

[karlmsmith]

Modified by @noaaroland on 15 Feb 2008 20:48 UTC

[karlmsmith]

Modified by @noaaroland on 6 Jan 2011 18:05 UTC