On Tue, Feb 28, 2012 at 11:18 PM, Andrea Aime
<[email protected]>wrote:
> On Tue, Feb 28, 2012 at 11:51 PM, Martin Davis <[email protected]> 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.
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
