Well, as I said it's not actually that strange that the smaller polygon
does not lie exactly in the larger. Whenever a vertex is introduced to a
segment, it's highly unlikely that the vertex lies *exactly* on the
original segment (unless the segment is rectilinear - i.e. vertical or
horizontal). The only way to deal with this is to use a snapping tolerance
(which essentially adds an identical vertex back into the original segment).
Good that you have a solution, anyway.
On Mon, Jun 22, 2015 at 11:14 PM, Paul Meems <[email protected]> wrote:
> Thanks Martin for your swift response.
>
> Good to hear it is not a bug in JTS/NTS ;)
> The smaller polygon is created as a single sided buffer from a line. This
> line is a copy from the border of the larger line.
> It is strange that the smaller polygon doesn't lie exactly on the larger
> polygon.
> I'll investigate further, for now I've solved this by using a full buffer.
>
> Thanks,
>
> Paul
>
>
> 2015-06-22 18:42 GMT+02:00 Martin Davis <[email protected]>:
>
>> The reason for the "extra" vertex #12 is that the bottom-right vertex of
>> the L-shaped polygon does not quite lie exactly on the boundary of the
>> larger polygon. It lies slightly inside, and thus the result of the
>> difference contains a spike running down to vertex #12.
>>
>> I was able to resolve this by snapping the larger to the smaller polygon,
>> using GeometrySnapper with distance 1. The snapping introduces a vertex
>> matching the bottom right vertex of the L-shaped polygon, and so the
>> difference does not contain the spike.
>>
>> This isn't really a bug - the code is working as designed. This is just
>> one of those tricky situations where close tolerances and the limitations
>> of finite precision causes some geometric anomalies. The ultimate solution
>> to this is for JTS overlay operations to incorporate snap-rounding to a
>> tolerance - but that has not yet been developed.
>>
>> I'm not sure why there is a difference between the behaviour of
>> single-sided buffer VS normal buffer. You'd have to post the exact inputs
>> and calls to allow seeing if there's anything odd going on. But I suspect
>> that it might be due to "cutting" a line segment to create vertex 13. A
>> vertex computed along a line segment is highly unlikely to lie exactly on
>> the line segment, due to the limitations of finite precision.
>>
>> On Mon, Jun 22, 2015 at 3:37 AM, Paul Meems <[email protected]>
>> wrote:
>>
>>> I'm reposting my question below which I initial posted to the NTS group.
>>> Since QGis is experiencing the same issue Diego (NTS) suggested posting
>>> it to the JTS group.
>>>
>>> The main question is if this is a bug in JTS or not.
>>> The L-shaped polygon was created using a single-sided buffer of a
>>> linestring made of coordinates from the larger polygon.
>>> In this case I can also use a 'normal' buffer. When I do so the
>>> difference is correct.
>>>
>>> Thanks,
>>>
>>> Paul
>>>
>>> ---------- Forwarded message ----------
>>> I have two polygons which I want to subtract from each other.
>>> The field polygon it the larger polygon and overlaps the smaller polygon.
>>>
>>> When I perform the Difference action the remaining part has one
>>> additional point on the smaller point which is not expected.
>>>
>>> This is the WKT:
>>> POLYGON ((194908.68715217288 586962.86751464731, 194881.30215215127
>>> 586952.0195146437, 194879.05315214754 586952.15151464322,
>>> 194877.20115214764 586954.13551464747, 194831.95715210476
>>> 587019.88551468146, 194760.91615204382 587122.9405147346,
>>> 194857.09315212426 587178.23851475632, 194858.9451521278
>>> 587178.63551475492, 194860.26815212792 587177.44451475318,
>>> 194873.10015214139 587158.65951475059, 194925.75215218749 587081.797514704,
>>> 194953.13715220965 587042.10951468861, 194962.79415221984
>>> 587027.42551468522, 194985.68115224215 586994.0885146677,
>>> 194986.21015224193 586991.70651466073, 194985.54815224075
>>> 586989.32551465672, 194908.68715217288 586962.86751464731))
>>>
>>> and
>>>
>>> POLYGON ((194886.66904433916 586975.65752607386, 194901.74579137619
>>> 586981.629866985, 194928.53316474415 586990.85093296878, 194935.04290785809
>>> 586971.94000373222, 194908.68715217288 586962.86751464731,
>>> 194881.30215215127 586952.0195146437, 194879.05315214754
>>> 586952.15151464322, 194877.20115214764 586954.13551464747,
>>> 194831.95715210476 587019.88551468146, 194821.8332618672
>>> 587034.57164674706, 194838.29986314307 587045.92290405277,
>>> 194848.42375338063 587031.23677198717, 194886.66904433916
>>> 586975.65752607386))
>>>
>>> Both geometries are in EPSG:28992 (RD_new/Amersfoort, The Netherlands).
>>>
>>> I hope you can see the screen shot:
>>>
>>>
>>> The blue L-shaped polygon is the small polygon. The grey-brown polygon
>>> is the result of the Difference action. As you can see the 12th point is
>>> unexpected. The border should go from 11 to 13 and so on. Now it passed
>>> point 13 and created point 12 and then goes back to point 13.
>>>
>>>
>>>
>>>
>
------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical & virtual servers, alerts via email & sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
Jts-topo-suite-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
