Ok, Gabriel. It sounds like some progress, at least.
Please post the other failure cases when you have isolated them.
Perhaps the next problem will be as easy to solve as the last one... 8^)
Gabriel Reid wrote:
Hi Martin,
Thanks a lot for the quick support!
I just tested this on the full dataset that I've been working with, and
there are still some cases coming out; I'll try to isolate what the
situation is with those cases and see if there is a pattern (or if I can
do something further with data cleaning).
I'll keep you posted.
Gabriel
-----Original Message-----
From: [email protected] [mailto:jts-devel-
[email protected]] On Behalf Of Martin Davis
Sent: donderdag 26 februari 2009 2:22
To: JTS Topology Suite Development
Subject: Re: [jts-devel] Odd behavior in negative mitred buffer
Good news! I looked into this problem, and found a minor bug in the
buffer input simplification algorithm. With this fix the situation
you
provided is no longer a problem.
This is commited to CVS.
Can you try this out on to see if it solves the other problems you
have
encountered?
Martin Davis wrote:
This is probably due to some sort of limitation with the mitring
algorithm. However, I notice that the 7th and 8th points of your
geometry are almost identical. If I remove one of these, the mitred
buffer looks fine. Can you clean the points of your geometries
somehow to avoid this situation?
Gabriel Reid wrote:
Hi,
I'm trying to create a negative mitred buffer on a (simple) polygon
with
JTS 1.10, and I'm getting strange results very occasionally. For
example, the following code gives me an output geometry that
actually
extends outside the original geometry (even though a negative
buffer is
used).
WKTReader wktReader = new WKTReader();
String geom = "POLYGON ((588736.6028960398 4518922.914991864, "
+ "588736.1060708747 4518922.061957178,
588718.6830715544 "
+ "4518930.620699637, 588712.0102834741
4518933.8985304395, "
+ "588722.7612465625 4518964.956739423,
588755.2073151038 "
+ "4518948.2420851765, 588750.2892019567
4518938.490656119, "
+ "588750.2892047082 4518938.490654858,
588741.1098934844 "
+ "4518920.290260831, 588736.6028960398
4518922.914991864))";
Geometry inputGeometry = wktReader.read(geom);
BufferParameters bufferParameters = new BufferParameters();
bufferParameters.setJoinStyle(BufferParameters.JOIN_MITRE);
Geometry bufferedGeometry = BufferOp.bufferOp(
inputGeometry, -5.0,
bufferParameters);
I've tried using a few different strategies in investigating this,
such
as reducing the coordinate precision, offsetting the x and/or y
coordinates by a constant offset, or iteratively buffering the
geometry
(for example, buffering it five times by -1.0). All of these
strategies
have had limited success, and none seem to work in all cases that
I'm
encountering.
Does this situation spring out to anyone, or is there any advice on
how
to get around this (or is this the expected behaviour for some
reason?).
I would be happy to *attempt* to fix this in JTS if someone can
point
me
in the general direction of where the issue probably is.
Thanks in advance for any information,
Gabriel Reid
_______________________________________________
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
_______________________________________________
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
