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

GeoServer GeoServer Developer
1

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?

  • 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?

Is there any documentation on this (particularly on the annotation-driven way of defining processes)?

–

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

2

On Tue, Feb 28, 2012 at 11:51 PM, Martin Davis <mdavis@anonymised.com> 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.

- 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.

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 :slight_smile:

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

3

On Tue, Feb 28, 2012 at 11:18 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Feb 28, 2012 at 11:51 PM, Martin Davis <mdavis@anonymised.com> 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 :slight_smile:

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.

4

On Wed, Feb 29, 2012 at 8:41 PM, Martin Davis <mdavis@anonymised.com> wrote:

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

Nope, each factory has one marker interface. I'm implementing custom
processes for customers and each customer has its own factory, with
its own namespace, and specific marker interface.

For the specific case of the geoserver ones there was just one in origin,
Jody created the duplication when doing the backport of many processes
to Geotools. The interface in geotools is very likely to be redundant, feel
free to post patches to remove it.

None whatsoever, but GeoServer and GeoTools have quite a bit of processes
implemented to learn from (and improve upon). Contributions welcomed :slight_smile:

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

That would be great :slight_smile:
Having no funding towards documentation I cannot help much, but I can
try to review the docs during the weekends

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

5

Hi martin:

The process api is currently unsupported in geotools; but I would like to nail it down prior to 8.0 being released. You should find the javadocs on the base classes fairly detailed - as I was prepare to make this one stable.

The GeoServer application context has a setting to pick up all extensions of GSProcess - that is its only significance as a marker interface.

The RenderingProcess is an extension that Andrea created in order to hold inventQuery etc as you describe; I think I made a naming convention or annotation for invertQuery and invertGrid let me check …

Okay found it in the AnnotationDrivenProcessFactory:

lookupInvertGridGeometry(Object targetObject, String methodName)

Used to recognise RenderingProcess implementations; returns a non null method for RenderingProcess.invertGridGeometry(Map, Query, GridGeometry).

Used to look up the method to use for “invertGridGeometry”; if a specific method name is not provided “invertGridGeometry” will be used.

  • For null method name “invertGridGeometry” will be used.
  • For “execute” method name “invertGridGeometry” will be used.
  • For “buffer” method name “bufferInvertGridGeometry” will be used
Parameters:
**targetObject** Target object; may be null for static method lookup
**methodName** method to use for "invertGridGeometry"
Returns:
method to use for RenderingProcess "invertGridGeometry", or null if not a RenderingProcess

Same deal for invert query:

lookupInvertQuery(Object targetObject, String methodName)

Used to recognise RenderingProcess implementations; returns a non null method for RenderingProcess.invertQuery(Map, Query, GridGeometry).

Used to look up the method to use for “invertQuery”; if a specific method name is not provided “invertGridGeometry” will be used.

  • For null method name “invertQuery” will be used.
  • For “execute” method name “invertQuery” will be used.
  • For “buffer” method name “bufferInvertQuery” will be used
Parameters:
**targetObject** Target object; may be null for static method lookup
**methodName** method to use for "invertQuery"
Returns:
method to use for RenderingProcess "invertQuery", or `null` if not a RenderingProcess
-- Jody Garnett

On Wednesday, 29 February 2012 at 8:51 AM, Martin Davis 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?

  • 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?

Is there any documentation on this (particularly on the annotation-driven way of defining processes)?

–

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

Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

Jody,

It will be great to see the Process API move to supported. It would also be good to see it get a bit better documentation and perhaps a bit of refinement too in conjunction with that.

Is GeoServerProcess now obsolete? Might be worth deprecating if so.

The GSProcess Javadoc could perhaps be clarified a bit? Say (per Andrea) something like “Used by Spring-bound process factories to locate their processes in the Spring context” ? (And maybe put a @see ProcessFactory ) Is it the case that every process should implement this interface - in which case could say that too?

I still think it would be nice to split the invert* methods out into a separate interface, so that they can be used in annotation-driven processes. Perhaps called “RenderingTransformationInitialization”? Unfortunately “RenderingTransformation” is already used for the interface which overloads the invert* methods, apparently for internal use in RenderingProcessFunctions. Perhaps it should simply be repurposed for use by rendering transformation processes themselves. (Or perhaps I’m misreading the intent of all this design - maybe Andrea can offer advice here?)

I was unaware of the “bufferInvertQuery” etc methods - are they of general use? If so would be nice to have them explicitly defined in an interface (which provides a good place to document their semantics, too).

On Sun, Mar 4, 2012 at 1:00 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hi martin:

The process api is currently unsupported in geotools; but I would like to nail it down prior to 8.0 being released. You should find the javadocs on the base classes fairly detailed - as I was prepare to make this one stable.

The GeoServer application context has a setting to pick up all extensions of GSProcess - that is its only significance as a marker interface.

The RenderingProcess is an extension that Andrea created in order to hold inventQuery etc as you describe; I think I made a naming convention or annotation for invertQuery and invertGrid let me check …

Okay found it in the AnnotationDrivenProcessFactory:

lookupInvertGridGeometry(Object targetObject, String methodName)

Used to recognise RenderingProcess implementations; returns a non null method for RenderingProcess.invertGridGeometry(Map, Query, GridGeometry).

Used to look up the method to use for “invertGridGeometry”; if a specific method name is not provided “invertGridGeometry” will be used.

  • For null method name “invertGridGeometry” will be used.
  • For “execute” method name “invertGridGeometry” will be used.
  • For “buffer” method name “bufferInvertGridGeometry” will be used
Parameters:
**targetObject** Target object; may be null for static method lookup
**methodName** method to use for "invertGridGeometry"
Returns:
method to use for RenderingProcess "invertGridGeometry", or null if not a RenderingProcess

Same deal for invert query:

lookupInvertQuery(Object targetObject, String methodName)

Used to recognise RenderingProcess implementations; returns a non null method for RenderingProcess.invertQuery(Map, Query, GridGeometry).

Used to look up the method to use for “invertQuery”; if a specific method name is not provided “invertGridGeometry” will be used.

  • For null method name “invertQuery” will be used.
  • For “execute” method name “invertQuery” will be used.
  • For “buffer” method name “bufferInvertQuery” will be used
Parameters:
**targetObject** Target object; may be null for static method lookup
**methodName** method to use for "invertQuery"
Returns:
method to use for RenderingProcess "invertQuery", or `null` if not a RenderingProcess
-- Jody Garnett

On Wednesday, 29 February 2012 at 8:51 AM, Martin Davis 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?

  • 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?

Is there any documentation on this (particularly on the annotation-driven way of defining processes)?

–

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

Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

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