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

[Martin Davis]

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