Simon Perkins wrote:
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?
No idea. It might well be faster - GEOS suffers from C's slow memory
allocation, I think.
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...
Well, if your *input* data is invalid according to isValid, you *have*
to fix your process that is producing the input data. GEOS has to have
correct data (according to its model) to work.
BTW, does anyone know what a "side location conflict" actually is? I
looked at the code but it wasn't obvious to me...
It means that during the GEOS processing something caused the
topological data structures that are used to become internally
inconsistent. This could be due to invalid input, or often it's due to
the noding process used internally not quite computing a fully correct
noding (which is surprisingly difficult to guarantee...)
In any case, it doesn't matter to you - it doesn't really give you any
information which can help you.
One thing that does cause this sometimes is input data with too much
precision. If your input numbers look like this: 1234.2345678934
rather than this: 1234.67 then you are probably carrying far more
precision than the accuracy of your data. If you can round off your
inputs to a reasonable level of precision (eg. 8 digits rather than 16)
you may get better results. Unfortunately, tis is not always easy to
do, since rounding often introduces topology collapses, which cause the
rounded geometry to be invalid. (This is why JTS/GEOS provide the
option of specifying a precision model for computation, to avoid
creating too many digits of precision every time two lines are intersected).
HTH - Martin
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
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
geos-devel mailing list
geos-devel@geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
