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

[Kevin Weller]

I do indeed have some control over the construction of the negating  
polygon.  Though figuring out what adjustments to make in the general  
case might be a bit of a challenge, I think I can manage.  I'll work  
on it.

Never dug into the GEOS guts enough to realize that snapping is  
automatically invoked internally by the overlay operations...I just  
saw the snapper in the API docs and thought, "That's what I  
need!" :-)  But if I'm understanding you correctly, my modifications  
to expose snapTo via the C API and the SWIG bindings may not be all  
that useful to anyone.  And I thought I was contributing something  
cool. <sigh>

- 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:
>> 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
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3818 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/geos-devel/attachments/20071129/246f3dd5/smime.bin