[ESP] asking for feedback on LAS

[Steve Hankin]

Hi Bryan,

Sorry for the slow response.  The LAS planning meeting that I spoke of had to be
postponed and only just occurred two weeks ago.  For the last two weeks of delay
you can blame me :-}

Responses below ...

Bryan Lawrence wrote:

> Hi Steve
>
> Sorry about the slow reply; in part because I wanted to get some feedback
> locally, and in part because I hoped Andrew Woolf would get a chance for a
> chat with you during the opendap meeting ...
>
> > At the December ESP meeting in Boulder I said I would follow
> > up with a request for feedback on LAS: what needs to be
> > added or modified in order to fill the needs that you see in
> > the ESP portal design.   Our next LAS design meeting will be
> > in early April so feedback in the next couple of weeks would
> > be very timely
>
> Anyway I think for us the key issues for LAS are web-services, modularisation,
> security, and graceful support for java-challenged browsers. I know that most
> of these are things you are thinking about (or actually doing) anyway, so I
> suspect there will be no surprises here.

> In slightly more detail, from my perspective the modularisation and
> web-service issues are nearly the same, in so far as it would be nice to
> break up the components into browse, visualise, deliver, with independent
> web-services with well-defined (simple) interfaces. OK, so that's probably a
> little unfair as I know that you have got a large degree of modularisation
> but I understand that it's not as clean as it could be (you understand that I
> haven't done any of this myself, so feel free to shoot me as the messenger if
> I'm getting it wrong). (And apologies if this sounds carping, it's very
> obvious that a lot of work has gone into making it as good as it is now, not
> only in what it can do, but in terms of the existing modularisation).

LAS does have an XML protocol by which you can query the server and can request
products.  My question to you:  how great is the importance that this protocol
conform strictly to the SOAP specification? The current XML protocol is documented
at http://www.ferret.noaa.gov/Ferret/LAS/Documentation/manual/reqapi.html.  It is
used by the standard LAS UI and also used to provide the "batch" Unix command line
access to LAS (see
http://tmap.pmel.noaa.gov/~hankin/GODAE/Biarritz/LAS/batch.html)

Both visualization of data and delivery of formatted data subsets utilize the same
protocol, but I don't see this as a limitation.  Visualizations and files are both
regarded as "operations".  The LAS request protocol allows you to specify
customization options that may be distinct for each operation -- for example
setting the contour levels on a plot, or specifying the delimiter character on an
ASCII output file.  So I suspect there is enough generality to meet your needs.

On the topic of modularization (or "modularisation" to be more international) a
further consideration is the adaptability of the standard LAS UI for different
applications.  Version 6.2 has added a lot of new flexibility there.  You can
customize the look and feel of how data sets and variables are presented (e.g. the
collection of model runs at http://www.ferret.noaa.gov/GODAE/servlets/dataset).
You can also enter the user interface either at the top (where the user first
picks the data set of interest); at a named data set (where the user first picks
the variable of interest); or at a named variable (where the user is ready to
specify a region and request output).  This allows you to link into LAS from, say,
a document that discusses a particular satellite SST field.  A further "nice" idea
would be to be able to enter LAS with a pre-specified region and time, but no one
has given this as a strict requirement, so it has not risen onto our top
priorities.

> I have heard that you are planning on making it possible to put IDL in the
> backend, this would be a good thing (TM), and hopefully the process of doing
> that might make the back-end visualisation separation even cleaner.

This idea has come up on several occasions but is not yet a "requirement" in our
projects.  It would definitely enhance the ability of LAS to handle high-res
satellite fields.  If you have an IDL expert in your group and you'd like to work
in partnership on this lets definitely follow up!

> The security issue is still important to us; currently we use cookies to do
> this, but it's clumsy ... if you do go down the web-service route, then a
> certificate-based approach would be very helpful for us ... (although the
> sand isn't very firm underfoot for doing this as far as I can tell).

I assume that when you mention security your focus is on access control, rather
that non-specific concerns that LAS may have security holes through which a system
break-in might be possible, right?  Access control is another of those topics
that, while often discussed, is not a top priority for any of the projects that
pay our bills.  Is there a way that we can approach this in partnership?  We would
be happy to make (reasonable) changes in the LAS architecture to help support an
access control layer.  Can we work something out from that starting point?

> Our last issue is java related. We have a number of folk who are mac based and
> have in the past grumbled, it might be that things are better now (it seems
> that time may solve this and you may not have to do anything). However, a
> clean failure mode is important. I haven't tested this myself, it maybe that
> there is one at V6 and later?

Improving robustness in funky browsers is a top priority for us.  Here's where LAS
V6.2 is today, and where we are headed:

Today: As of V6.1 LAS has a "graceful fail-over" mode.  On a funky browser LAS
still works, but it lacks a clickable map interface.  That's an improvement at
least over V5 ...

Pretty soon: We are just beginning work a server-side support for a clickable
map.  That should provide a nice solution -- not quite as nice as the Java map,
but pretty good.  At this time I'd say that functionality is still 4 to 6 months
away.

> Well, I had hoped to provide you with more info. We may do that over the next
> six months as we do have an internal project to try and use LAS V6+ (&CDAT)
> as one interface to most of our numerical model data, but it rumbles on as we
> have relatively little staff effort for that.
>
> Why web-services and modularisation? In the slightly longer term, clearly we
> want to be able to have metadata services which return a URI which points to
> a LAS enabled service for a single dataset. (I think this is really the only
> way to avoid the existing browsing interface which is a very big problem for
> large systems). This might require the ability to dynamically generate a LAS
> service and populate the metadata backend with templated visualisation
> information and dynamic data information. If this were possible then it would
> be possible for different organisations to deal with their own metadata
> idiosnycracies and browsing concepts without imposing the LAS standard.
> We could also offer a wider variety of delivery mechanisms.

I think that you can do all of this with the pieces that already exist today.

> Oh, and while I'm on pie-in-the-sky, OGC Web-Mapping Server compatability?

Ah, that would be nice, wouldn't it?  From my reading on the subject the WMS image
output and WCS coverage outputs should be quite straightforward -- essentially LAS
just needs to understand a slightly different (alternative) request protocol and
respond to some new queries and the LAS installer needs to configure in operations
(products) that conform to OGC expectations.  The WFS feature output will require
that we learn our way around the GML specification.  Discussions of OGC always
come up against a chicken-and-egg problem:  where are the client applications that
are going to *use* these servers?  So as a practical matter it is another of those
topics that don't quite make it to the "requirements" list.

> OK, enough. Thanks for the opportunity to comment, and thanks also for a great
> piece of software as it is. People will always want more from a good thing!

I have my fingers crossed that you may take us up on offers for partnerships --
esp. access control and IDL back end.

    - steve (for the LAS development group)

>
> Bryan
> --
> Bryan Lawrence, Head NCAS/British Atmospheric Data Centre
> web: www.badc.nerc.ac.uk  phone: +44 1235 445012
> CLRC: Rutherford Appleton Laboratory, Chilton, Didcot, OX110QX, UK

--

Steve Hankin, NOAA/PMEL -- Steven.C.Hankin@noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744