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
[email protected]
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
geos-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/geos-devel
------------------------------------------------------------------------
_______________________________________________
geos-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/geos-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
geos-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/geos-devel
