Thanks for the feedback, Michael.
The results for points are expected - there is no change in how point
buffers are computed.
The slight difference in buffer polygon shape between old and new is
expected too - that is a result of the simplification. The change due
to the simplification should be much less than the error due to the
discretization of the arcs, so should not be considered to be
significant (at least, that's my working hypothesis!).
As for linestrings, in fact the simplification was not enabled for
linestrings in the version I posted (due to some issues with the
algorithm). I've resolved these, and I've posted a new version of the
library (same URL). So you might like to retry the linestring test and
see if the results improve.
Martin
Michael Michaud wrote:
Hi Martin
I obtained good performance with the new buffer
Here are some extensive tests :
* Old buffer New buffer*
308 polygons - buffer 10 : 4 s --> 5 s 308 polygons - buffer
100 : 51 s --> 10 s
20507 linestrings - b 10 : 23 s --> 21 s
20507 linestrings - b 10 : 367 s --> 70 s
6444 points - 10/100/1000 : 3 s --> 2 s
Performance are constant for point buffer (old, new, small buffers,
large buffers)
Performance do not change much between old and new buffer for small
buffers
Performance improve greatly for large buffer (considering Larry's
test, I think the ratio is even higher for larger buffers)
I compared total resulting surfaces with the jump plugin (statistic
for the layer)
For linestring, I did not notice any difference
same area +/- 0.000005 m2 for a total of 2 000 000 000 m2 (let's say
the same)
For polygon, I noticed a small difference
same area +/- 23000 m2 for a total of 5 000 000 000 m2
The image show how the new buffer has simplified the geometry (the old
buffer is marked ith big points, distance between the two buffers are
about 0.3 m for a buffer of 100 m)
Michaël
Martin Davis a écrit :
Good to hear, Larry - thanks for testing this.
Larry Becker wrote:
Congratulations Martin! Buffering 41 complex aircraft features
took 83 seconds with your old algorithm, and only 2 seconds using
your new one. I could find no anomalies.
regards,
Larry Becker
On Wed, Oct 8, 2008 at 4:23 PM, Martin Davis
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
JTS'ers,
As you may have experienced, buffering in JTS currently has some
performance challenges in situations involving large buffer
distances. I'm excited to say that I've implemented some code
enhancements which *dramatically* improve buffer performance in
these cases (as well as providing an overall improvement).
I've tested this code as extensively as I can, and am pretty
confident that it is robust and accurate. But it's always good to
have other people beat on it as well!
So, is anyone out there ready, able and willing to test out the
new buffering code? Ideally this would be someone who has a
application which uses buffering in a significant way, and which
allows determining the performance and correctness characteristics
effectively. I'm looking for feedback to either confirm that this
really is an improvement, or some test cases which reveal issues
if there are any.
If you're able to help out, you can either download and build the
codebase from CVS, or I've built an alpha release of JTS 1.10
which is available here:
http://tsusiatsoftware.net/jts/files/jts-1.10-alpha.zip
Thanks - Martin
-- Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
jts-devel mailing list
[email protected]
<mailto:[email protected]>
http://lists.refractions.net/mailman/listinfo/jts-devel
--
http://amusingprogrammer.blogspot.com/
------------------------------------------------------------------------
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
