On Thu, Oct 18, 2012 at 9:53 AM, apmartins <antonioppmart...@gmail.com>wrote:
>
> I've tested with wfs intersects and the response is almost instant.
> However it doesn't have the result that I want which is the percentages of
> each area intersected by the buffer.
>
> is there a way to do this without "damaging" the performance?
>
A very good question. I don't have a definitive answer, but here's a few
ideas;
- The IntersectionFeatureCollection process is quite sensitive to the order
of the inputs. I think it is fastest if the smallest input (the buffer
polygon, in your case) is the *second* input. It would be great if you can
try this and report back
- Computing the areas and percentages may carry a significant amount of
overhead. It would be interesting to know how long the operation takes if
they are not requested
- Another alternative is to use the Clip process, and compute the areas &
percentages as a subsequent step
Apart from this, there are probably some improvements possible in the code
for the IntersectionFeatureCollection process, of varying levels of
difficulty.
- The process always densifies and reprojects the input data. It would be
nice to be able to disable this if is not needed (ie if both inputs are
already in the same planar CRS)
- A much longer term fix is to improve the JTS intersection computation to
allow caching the primary input geometry. It would be great to have some
time to work on this... 8^)
> --
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
