[udig-devel] OSS and UI + Service Chaining

[Jody Garnett <jgarnett@xxxxxxxxxxxxxxx>]

Repost now that we have a list ...

Paul Ramsey wrote:

> http://www.actsofvolition.com/archives/2004/april/theriseof
>
> This points to where I want to go with the next iteration of JUMP.  
> While adding capabilities, stripping back UI complexity and banishing 
> oddball functionality to external modules.  Combined with a decent, 
> built-in search/download capability for the external module library, 
> the result could be very elegant.

Quite so Paul,

On a related note, I am finally doing my catch up reading on the various
specifications.

Looks like we may have a code collapse if we can get the metadata
right.  That is several of our services WFS/WRS/GCE all depend on the
Catalog/Metadata model. The geotools2 Filter provides a reference
implementation on the Metadata query model (I did not before release it
was a direct derivative).  The trick will be reflecting a code collapse
with a user interface collapse in a manner similar to the GAIN from your
article.

Back to the reading ... one thing that is troubling is the nature of the
chaining the "Intergrated Client for Multiple OGC-complient Services
Architecture, Design, and Experience" interoptablity program report
seems to expect of a client service.

They provide a nice series of Client use cases...

5.1 D) Assembling Service Chains to provide data layers for the clinet

The first example is of a WMS being used to visualize the contents of a
WFS. This is a apprently set up be the client based on "a WMS that
supports external feature rendering" and the client "queries the WMS,
passing all of the data required to retrieve feature information from
the WFS".

The second is to set up the chain:

Web Coverage Service -> Coordinate Transformation Service -< Coverage
Portrayal Service.

And to run both a thumbnail and finally the full image through the chain.

5.2 a) Retrieving Imagery from an Imagery Archive
- references a "well known" Imagry Metadata Model employed by the Image
Catalog
- interestingly the "client formulates the request to the archive,
stipulating where the data are to be delivered for the client to exploit".

The grand theme of all this is that "intergrated clients ... will never
be able to render every possible data source.  Therefore, additional
servies may be required to generate an appropriate data layer".

These ideas of setting up "out of client service chains" go considerably
beyond what I had in mind  for the client aquiring data, particullary
the offline notificaiton usecase.

I would not mind talking with any/all about these ideas ....

My current though involves having the user set up a model of what they
want .

And having the program decide how to relize a model ...

Such as example 5.2 B) "Assembling a Service Chain"view, filter, and
interact with feature data rendered according to client defined styles
and client specified parameters":
- User creates a SLD using a Style Editor
- SLD is registered with a Style Management Service (SMS)
- User selectes the previously constructed SLD from the SMS
- WMS getMap request causes SLD-enabled WMS to grab the user's SLD for
rendering

or WFS content reprojected and SLD rendered on screen:
- WFS -> WMS (w/ WMS reprojection + WMS styled) -> Raster
- WFS -> Reprojected on the Client -> SLD Rendered on Client -> Raster

It seems that we should assume a default dynamically (if we are editing
we need the client side route for example), and allow the user more
service chaining later. At least a couple use-cases (like 5.2 B) we need
to plan for.

The pointing being to separate out the model from the actual relized
request from the start. And work towards workflows with "offline"
components like 5.2 B as time goes on.

Cheers,
Jody