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

Kevin Weller 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  
relative newbieness.

- Kevin

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:
>>>> 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
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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/20cf70dd/smime-0001.bin

More information about the geos-devel mailing list