[geos-devel] Difference operation not always working as expected

[Martin Davis]

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:
> All,
>
> 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 there)
>
> 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
> http://lists.osgeo.org/mailman/listinfo/geos-devel

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022