On Wed, Feb 29, 2012 at 1:56 PM, Andrea Aime
<[email protected]>wrote:
> On Wed, Feb 29, 2012 at 8:53 PM, Martin Davis <[email protected]> wrote:
> > The invertQuery method in Rendering transformation processes is very
> useful
> > (in fact, essential). But I've just realized a Catch-22 with it.
> >
> > I need to expand the bounding box of the query (to capture more features
> for
> > accurate surface generation). I want the user to be able to specify the
> > size of the expansion. The obvious place to do this is in the process
> > parameters. But - the invertQuery method is called *before* the
> parameters
> > are supplied to the execute method! So for the first call at least, the
> > query is not expanded by the correct amount. (The process class saves
> the
> > expandBy parameter in an instance variable, so subsequent calls operate
> > correctly).
> >
> > Is there a better way to do this?
>
> A stateful transformation is dangeours business, as you have just one
> instantiated,
> ever (styles are cached, and so is whatever is inside of them),
> and it serves all concurrent requests for all possible requests, maybe
> for different
> maps or with different parameters.
>
Hmmm... do you mean there is a single copy of the process object shared
across all styles which reference that process? Or is there a separate one
created for each style which uses it? If the former, then yes, I have a
problem!
> Long story short, do whatever you need to in order to make the
> transformation
> stateless.
>
> The rendering transformation framework was setup, proposed and accepted
> by the community in this geotools improvement proposal:
> http://docs.codehaus.org/display/GEOTOOLS/Rendering+transformations
>
> I see you are struggling with the current design, all you can do to
> make it better
> is to follow the same road I walked when setting up rendering
> transformations:
> check your needs, propose a design, setup a improvement proposal, discuss
> it
> and get it approved
>
> My main driver were vector to vector and raster to vector transformations,
> with a focus on making it possible and making it reusable as WPS processes
> and transformations at the same time.
> Your setup is different, you are trying to walk the opposite direction,
> want it
> to be easier, and it seems, setup in such a way that you don't need to care
> about thread safety. The improvement proposal is the only way to revise an
> existing API (or to roll new API), so that's really your only option.
>
I totally agree stateless is best. And I'm certainly not criticizing the
original design - Rendering Transformations are very powerful and extremely
useful!
I am just not seeing how I can take advantage of the inveryQuery method to
alter the query window as needed (and as the original proposal stated as a
design goal).
At this point I'm not looking for easiness - just a workable solution! 8^)
--
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
