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

[Kevin Weller]

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:
>> 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/20071130/b46003c6/smime.bin