On Tue, Feb 28, 2012 at 11:09 PM, Andrea Aime <email@example.com>
In my mind a process is first and foremost a WPS process, its
On Tue, Feb 28, 2012 at 11:32 PM, Martin Davis <firstname.lastname@example.org
> So these need to be defined as parameters to the RenderingTransformation
> process, and then specified in the SLD with values provided by calls to the
> "env" function?
> Hmm... I think I like the invertQuery way better - more explicit, and fewer
> lines of code for users to screw up.
> I can see that having access to rendering parameters in the SLD could be
> very useful, however.
ability is something added on top, the process has to work even outside of
that rendering context (when called striaight from WPS the rendering
methods are _not_ going to get called).
A process that does vector to raster transformation obviously needs to know
how big the output raster will be, thus it needs to have some simple and
WPS bindable way to do that, the grid to world transformation is not a obvious
candidate there, width and height are more natural.
I see you are thinking about the process as something that makes sense
to be used only as a rendering transformation instead, so hopefully it
is not build as
a process (since you'd have around a WPS process that cannot be used)
but as a straight filter function?
I did not cover that use case, but if you want to propose API changes that
would make both approaches work I'm all ears :-)
These are all good points, Andrea, and I agree with your reasoning that it's nice to have a single implementation which can be used as both a standalone process and as a rendering transformation.
I don't have any great ideas about another way of doing things at this point. It does seem to me like it would be nice to avoid having all that ugly boilerplate code in the SLD to pass in the rendering context information. I guess there are various ways this might be done:
- well-known parameters that the Rendering pipeline could fill in automatically
- a RenderingTransform-specific method on the process class to pass in this information (but this would require ThreadLocal storage again, or creating a new process object for each rendering use)
Anyway, for now I'll look at switching over to using the explicit parameters.