Thanks for the kind words about LAS.
Our goal with LAS is to provide a customizable framework that will allow you to do what you need to do. We provide several levels of customization; each level provides a different trade off between versatilty and ease-of-use. As experience with usage patterns for LAS "customers" grows, we may move certain tasks from one level to an "easier" level. For instance, users often use a Ferret init_script only to issue a Ferret set mem command; future LAS releases may support a XML property tag for the same function. It's up to the LAS data provider to determine which level of customization is best for them
Following is a summary of the various customization levels that are (and/or will be) available in LAS:
For the data server:
1) Property based customization
2) Custom Ferret scripts
3) Custom Perl code
4) Customization of the LAS visualization connector
The first is the simplest and the easiest for LAS data providers to implement; it pertains to customizations that aren't algorithmic in nature. It is also the least flexible. It is appropriate when a value is a function of a given dataset and/or variable. 'do_contour' (but not for individual slices) is an example of this type of customization (by the way, you can use the undocumented <do_contour> property to turn on/off contouring for all views).
The second category allows you to customize the Ferret back end. The <init_script> and <script_prefix> properties determine which Ferret scripts/templates are run. This allows you to run any set of Ferret scripts/templates that you want bug; unfortunately, you have no control over the arguments passed to the Ferret scripts (it might be worthwhile to modify the Ferret Perl code to allow any properties to be passed to templated Ferret scripts). The second category offers more flexibility than the first category, but you are limited by the Ferret scripting language. Templated scripts help minimize the problems with the Ferret language (especially with string manipulation), but they are more difficult to debug.
The third category includes custom LAS operations and/or other Perl customizations, requires greater programming skills, is more difficult to debug, but gives you great flexibility. It includes new LAS operations, branching based on variable URLs, etc. The custom code framework in LAS 5.0 allows you to avoid hacking Ferret.pl or any of the other Perl modules; just add the required code in the custom.pl module; you can also override existing code.
Finally, you don't have to use Ferret to visualize data -- any program that has a command line interface and that can output a GIF/PNG/JPEG file (or even just text) can be used with LAS.
These are all customizations provided for the data visualization component
of LAS. The next release of LAS will support customization of the user
interface through a XML configuration file. This will allow you to specify
what images are to be used in the map applet, what views and products should
be displayed for a given LAS variable, and what operations should be associated
with given LAS products. It will also allow you to specify a custom HTML
page to display when a user selects the "Get Data" button (an example of
this is available in the Tsunami Propagation Database at http://ferret.wrc.noaa.gov/FACTS/).
This could be used, in your example, to warn users that a given visualization
is going to be slow...
Andrew Woolf wrote:
In the process of customising LAS for our data and have a question on
philosophy. LAS is an excellent, sophisticated package that is clearly
in a state of development. The documentation for current release
describes customisations at various levels - from the XML files
to hacking javascript and perl. Is there a sense developing of the level
at which customisations should be applied?I ask because one might like, for instance, to be able to specify contouring
parameters by variable and view.LAS v5 allows you to specify contour levels
in the XML (ferret properties), but not 'do_contour'. So if I want to
do contour overlays for a yz slice, I need to use script_prefix and adapt
draw_2d.tmpl (even though I can specify the levels in XML).Similarly, if I want to vary the plot based on the region
selected (this is something that is useful, for instance, with curvilinear
grids, which I have), that info is not passed to the ferret template
scripts (setup_region was moved to Ferret.pl "to allow embedded quotes"), and
I suspect I might need to hack Ferret.pl!One further example - we have a very large set of data (150GB gzipped), which
LAS accesses via DODS in order to handle decompression. It would be nice
to be able to display a message to the user if a compressed DODS file
is selected, that decompression will take a minute. This will presumably
require some combination of perl and javascript hacking.I'm not sure I have a well-posed question here, but am really just wondering
whether there is a set of canonical customisations developing that will
be supported at a high level, in order to avoid having to understand and
fiddle with LAS throughout its layers.Thanks to the LAS team for a very impressive piece of e-engineering!
Raegards,
- Andrew-----------------------------------------------------
Andrew Woolf (awo@mail.nerc-essc.ac.uk)
Environmental Systems Science Centre (ESSC)
Reading University
3 Earley Gate
Whiteknights
Reading RG6 6AL
UNITED KINGDOM
Phone: +44 (0)118 931 8741 Fax: +44 (0)118 931 6413
-----------------------------------------------------
-- Joe Sirott