[geos-devel] Difference operation not always working as expected
kweller at asapwebsoft.com
Fri Nov 30 13:02:13 EST 2007
That's what I thought you'd say...just wanted to make sure before I
blew my changes away. Probably better not to clutter up the API with
unnecessary and confusing functionality, but I figured you'd be a
better judge of that than I. Thanks again for putting up with my
On Nov 30, 2007, at 10:25 AM, Martin Davis wrote:
> The only downside to having the snap operations exposed is that
> clearly they don't work in the way that some would expect them too.
> If this is going to lead to a lot of questions then perhaps it's
> better not to expose them....
> Kevin Weller wrote:
>> To follow up, I can confirm that if I adjust the outer (Northern in
>> this case) edge of the negating polygon so that it is outside the
>> primary polygon, I do indeed get a notch instead of a hole. Thanks
>> for the help!
>> Please let me know if you could imagine a use for the exposure of
>> the snapTo operation via the C API (and SWIG bindings). If not,
>> I'll just revert my local source copies to what's in trunk.
>> I do suspect that my original snap operation might be working as
>> best it can but for the limitations of floating point precision.
>> Oh, and changing the tolerance value in any direction seems to have
>> little effect with my given inputs, which would make perfect sense
>> to me if the edges overlap about as much as their floating point
>> representations allow.
>> - Kevin
>> On Nov 29, 2007, at 10:10 AM, Martin Davis wrote:
>>> Leaving aside the snapping, I'm not too surprised that you're
>>> getting this result. The top edge of the primary is angled
>>> slightly. This makes it pretty much impossible for the top edge
>>> of the negating to lie *exactly* coincident with the primary edge
>>> (due to the finite precision of floating point). So it's going to
>>> either fall short or fall outside - in this particular case, the
>>> negating edge is inside the primary polygon, and hence you get a
>>> hole when you subtract it.
>>> The only way to ensure that you get a notch is to adjust the
>>> negating so that the top edge is definitely outside the primary.
>>> Since you seem to have some degree of control over the
>>> construction, is this possible?
>>> Snapping probably wouldn't be invoked automatically in this case,
>>> since it doesn't trigger a robustness failure.
>>> I'm not sure why manually snapping them doesn't work - AFAIK it
>>> should in this case. Perhaps you need to change the tolerance
>>> value, or it's possible you're calling it incorrectly, or it's
>>> possible it has a bug. It wasn't really designed to be called
>>> outside of the GEOS overlay ops, so it wouldn't surprise me if
>>> there's a problem. If I have some time I'll experiment with this
>>> in and see if there's an obvious problem.
>>> Kevin Weller wrote:
>>>> Hopefully it's not merely due to my own idiocy, but I'm
>>>> experiencing some weird results from difference and snap
>>>> operations that may or may not imply GEOS3 bugs. I'm using the
>>>> latest and greatest from trunk. Here's what I'm trying to do:
>>>> I've got a smaller polygon (which I call the negating polygon)
>>>> which partially covers a larger polygon (which I call the primary
>>>> polygon). The negating polygon is always flush with one side or
>>>> corner of the primary polygon. The goal is to subtract the
>>>> negating polygon from the primary polygon such that there is a
>>>> resulting "notch" in the primary. You can see an example of this
>>>> actually working by looking at http://www.asapwebsoft.com/files/working_primary_and_negating_plot.png
>>>> and http://www.asapwebsoft.com/files/working_result_plot.png
>>>> Sometimes, with only slightly different input (in this case, I
>>>> move the negating polygon to the East), it doesn't work. See http://www.asapwebsoft.com/files/broken_primary_and_negating_plot.png
>>>> and http://www.asapwebsoft.com/files/broken_result_plot.png
>>>> (interior ring not shown on the plot, but I've checked, and it's
>>>> In the latter case, instead of a notch in the resulting polygon,
>>>> I get an interior ring (hole), even though the negating polygon
>>>> is as close to overlapping as I can get it. I've even tried
>>>> using the GeometrySnapper to snap the negating polygon to the
>>>> primary polygon, in case they weren't quite lined up, but no
>>>> luck. In fact, snapTo seems to have no effect for any of the
>>>> inputs I provide, so the function must consider the polygon edges
>>>> in question to be flush already. But I still get holes instead
>>>> of notches.
>>>> I'm scripting this in Ruby, and an excerpt from my Ruby driver
>>>> code is at http://www.asapwebsoft.com/files/geos_client_code_excerpt.rb
>>>> Also, the current output from geos_tests.rb (showing a handful of
>>>> failures, probably not related, but I don't know that for sure)
>>>> is at http://www.asapwebsoft.com/files/test_output.txt
>>>> I'm not exactly sure what to try next, but I'm hoping that
>>>> someone out there has some ideas.
>>>> Oh, in the process of working on this, I've added the snapping
>>>> features to the C API and the SWIG bindings...hopefully
>>>> correctly. I'll be happy to share those changes if the community
>>>> wants them. Since I'm not a committer, what would I do? Send
>>>> patches to the list?
>>>> - Kevin
>>>> geos-devel mailing list
>>>> geos-devel at lists.osgeo.org
>>> Martin Davis
>>> Senior Technical Architect
>>> Refractions Research, Inc.
>>> (250) 383-3022
>>> geos-devel mailing list
>>> geos-devel at lists.osgeo.org
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
> geos-devel mailing list
> geos-devel at lists.osgeo.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3818 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/geos-devel/attachments/20071130/20cf70dd/smime-0001.bin
More information about the geos-devel