[geos-devel] C# Bindings?

[Martin Davis]

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 at geos.refractions.net
>>> http://geos.refractions.net/mailman/listinfo/geos-devel
>>>
>>
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
>

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022