Thanks for the thoughts. A quick look at the NTS sourceforge page seems
to suggest that it hasn't really been worked on in about a year, but
maybe it includes the things I need... Anybody know how it compares
performance wise with GEOS?
Another option would be to add the isValid() member to the OGR bindings
- I might try that and see whether the OGR people want it in there. Of
course the question then is what do I actually do if the geometry turns
out to be "invalid" when I know that the methods I used to create it
should have produced a correct geometry...
BTW, does anyone know what a "side location conflict" actually is? I
looked at the code but it wasn't obvious to me...
Cheers,
Sy
Martin Davis wrote:
A couple of things:
You might also try looking at the Net Topology Suite, which is a port
of JTS to C# (just like GEOS is a port to C++). HOWEVER, this is a
fork of JTS, and I don't know how current or active it is. (It might
be nice thing for JTS to offer an official .NET compatible version....)
You can also try compiling JTS under J#. It mostly all works - there
might be a few simple utility classes you have to supply.
As for your topology problems, this might be cause by invalid input
data, or it might be caused by robustness errors in the computation
itself. The most recent version of GEOS has some substantial
improvements in robustness for overlay ops, so you should try it and
see if it fixes your problem. (At a very high level this is doing
something similar to your concept of "cleaning up" the geometries to
avoid the problems - but it's probably not something you want to try
at home 8^)
Another note - if you are unioning many polygons together, JTS is just
adding an optimized function to do this efficiently, and hopefully
this will make it in GEOS in due course.
Simon Perkins wrote:
Hi,
Are there any C# bindings for GEOS out there?
We've been using the OGR interface to GEOS (which are exposed by the
OGR C# bindings), but are running into some strange topology
exceptions (side location conflicts and non-nodal intersections) and
I'd like to use the GEOS isValid() method which is not exposed by
OGR, AFAIK. Might using the GEOS library directly be more efficient
than going through OGR as well?
In general, is there an easy way to "clean up" a geometry so it won't
raise these kinds of exceptions? The geometries in question are all
generated by the union of (many) simple polygons.
Anyway, I could go off and roll PInvoke stubs for the GEOS functions
I need in not much time, but I figured I'd see what other people have
already before I do that. Any interest in adding such bindings to
geos? I could also take a look at SWIG, but it always scares me for
some reason...
Cheers,
Sy
_______________________________________________
geos-devel mailing list
geos-devel@geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
_______________________________________________
geos-devel mailing list
geos-devel@geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
