Re: [Geoserver-devel] Clarification on implementation of Rendering Transformation processes

[Martin D. <md...@op...>]

On Tue, Feb 28, 2012 at 11:18 PM, Andrea Aime
<and...@ge...>wrote:

> On Tue, Feb 28, 2012 at 11:51 PM, Martin Davis <md...@op...> wrote:
> > I'm looking for advice on best practices on writing classes which can be
> run
> > as Rendering Transformation processes.   Specifically:
> >
> > - the GeoServerProcess interface extends the GSProcess interface.  Which
> one
> > should be used?
>
> Whatever, those are just marker interfaces (as far as I remember)
> that makes it possible for a spring bound process factory to locate its
> processes in the spring context.
>

Ok.  It would be nice to reduce this to one interface, or document which
one is preferred. (deprecate the other?)

>
> > - there is also a RenderingProcess interface, which can be used to define
> > the invertQuery() and invertGrid() methods.  However, it extends Process,
> > which then requires an execute(Map) method. I would prefer to use the
> > annotation-driven style of process definition, with an execute() method
> > taking explicit typed parameters.  In fact it seems to work fine doing
> this
> > and not using the RenderingProcess interface.  Is RenderingProcess
> obsolete?
>
> It's not, the process world has two levels:
> - the low level api, which is the only true process api, that messes with
> maps
>  and has the RenderingProcess interface that is used to bind between
>  processes and rendering transformations (which are actually filter
> functions,
>  there is a bridge in geotools turning every process with a single output
>  into a filter function, but if you try so hard to make a process that is
> only
>  a rendering transformation then you probably should make it directly
>  a filter function)
> - the annotation driven api, which uses annotation introspection to bind to
>  the lower level api
>
> Annotated processes that do rendering transforms, in particular vector
> to raster ones, are at the moment nothing particularly nice to see,
> they are based on naming conventions, see the raster georectification one
> in GeoServer (the only process that does vector to raster and rendering
> transformation at the same time).
> If you want to propose patches to make that better I'm all for it, the
> current approach was setup in a haste to make the raster georeferencing
> code function under the requirement that the process can work both
> stand-alone and as a rendering transform.
>

Ok, makes sense.


> >
> > Is there any documentation on this (particularly on the annotation-driven
> > way of defining processes)?
>
> None whatsoever, but GeoServer and GeoTools have quite a bit of processes
> implemented to learn from (and improve upon). Contributions welcomed :-)
>

We have some funding to work on this, so I hope to be writing up some docs
soon.

>
> --
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.