Thanks for the test cases, Gabriel.
These errors are almost certainly caused by some shortcoming(s) in the
algorithm for generating a mitred buffer offset curve. The errors seem
to be linked to situations with almost flat angles - that might be part
of the problem. Probably some further heuristics are needed to generate
better quality offset curves in this case.
Gabriel Reid wrote:
Hi Martin,
I've got a few other failure cases here, showing what seems to be a few
different examples of this kind of behaviour:
// Simple five-sided polygon that gets transformed into three triangles
POLYGON ((589300.089821923 4519627.577687806, 589296.6197410262
4519621.834087054, 589292.5450979208 4519615.089809029,
589282.7894421419 4519620.983829066, 589289.8814929381
4519632.722288636, 589300.089821923 4519627.577687806))
// Another example of the same triangle behavior
POLYGON ((588978.2942617612 4519797.499233156, 588989.1612999197
4519792.050291001, 588982.5784094566 4519779.549041149,
588962.0866377753 4519790.334848753, 588967.4026187821
4519802.960530801, 588978.2942617612 4519797.499233156))
// Resulting polygon has a single edge extending off one corner
POLYGON ((589099.8017397423 4518490.719003885, 589097.1198886324
4518486.20858194, 589090.9424687021 4518475.819013388, 589069.8993093553
4518487.1362185385, 589078.7377975255 4518502.093799692,
589081.1515112884 4518509.334764771, 589103.7370954598
4518497.015419995, 589099.8017397423 4518490.719003885))
// Similar behaviour as the original case that was posted, this polygon
// has to points that are very close together
POLYGON ((587854.8616905196 4519121.941123185, 587863.6671614297
4519138.176489661, 587863.9386104685 4519138.676991724,
587880.5408633598 4519129.672513268, 587871.463857397
4519112.9366913745, 587854.8616905196 4519121.941123185))
All of these examples can be demonstrated with the code that I posted
before (creating a mitred buffer with a magnitude of -5.0).
Again, if you don't have time and/or motivation to look into this, I'd
be more than happy to attempt to assist in doing that, especially if you
have a good idea of where to look (I'm trying to have a look anyhow).
Thanks again for the assistance,
Gabriel
-----Original Message-----
From: [email protected] [mailto:jts-devel-
[email protected]] On Behalf Of Martin Davis
Sent: donderdag 26 februari 2009 17:50
To: JTS Topology Suite Development
Subject: Re: [jts-devel] Odd behavior in negative mitred buffer
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
_______________________________________________
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
