You are viewing a plain text version of this content. The canonical link for it is here.
Posted to geospatial@apache.org by George Percivall <pe...@ieee.org.INVALID> on 2022/03/29 15:46:26 UTC
DE-9IM in C, Go or Rust?
Hey geo crowd,
Im looking for code doing DE-9IM spatial relations
https://en.wikipedia.org/wiki/DE-9IM <https://en.wikipedia.org/wiki/DE-9IM>
JTS is great for Java, but I need something in C, Go or Rust.
Let me know, thanks,
George
George Percivall
GeoRoundtable <https://www.linkedin.com/company/geo-roundtable/>
percivall@apache.org <ma...@apache.org>
Re: DE-9IM in C, Go or Rust?
Posted by Joshua Lieberman <jl...@tumblingwalls.com>.
I see this: https://pkg.go.dev/github.com/spatial-go/geoos#section-readme <https://pkg.go.dev/github.com/spatial-go/geoos#section-readme>
But haven’t tried it.
—Josh
> On Mar 30, 2022, at 9:46 AM, George Percivall <pe...@gmail.com> wrote:
>
> Thanks to Josh and Martin for your responses.
>
> Anyone know of an open library in Go?
>
>
> George Percivall
> GeoRoundtable <https://www.linkedin.com/company/geo-roundtable/>
>
>> On Mar 29, 2022, at 3:22 PM, Martin Desruisseaux <ma...@geomatys.com> wrote:
>>
>> Hello Georges and all
>>
>> The following article, "How Good Are Modern Spatial Libraries?" (published November 2020) does a comparison between JTS, GEOS and other libraries:
>>
>> https://doi.org/10.1007/s41019-020-00147-9
>>
>> Note: I do not know why the language restriction, but if it is for performance, the reality can be counter-intuitive. GEOS is a port of JTS library from Java to C. So it should be the same algorithms, only in a different language. But according benchmarks in above-cited articles, GEOS is actually… slightly slower than JTS.
>>
>> Martin
>>
>> P.S.: On GEOS benchmark results: the authors attribute that to excessive memory allocations. The malloc and free functions in C/C++ are slower than memory allocation in Java. With a garbage collector, only surviving objects have a cost. In a program where e.g. 90% of objects die young, garbage collector can be more performant than explicit memory allocation (I also saw a benchmark from IBM a long time ago doing similar demonstration with the grep program).
>>
>
>
>> On Mar 29, 2022, at 12:46 PM, Joshua Lieberman <jl...@tumblingwalls.com> wrote:
>>
>> https://libgeos.org <https://libgeos.org/>.
Re: DE-9IM in C, Go or Rust?
Posted by George Percivall <pe...@gmail.com>.
Thanks to Josh and Martin for your responses.
Anyone know of an open library in Go?
George Percivall
GeoRoundtable <https://www.linkedin.com/company/geo-roundtable/>
> On Mar 29, 2022, at 3:22 PM, Martin Desruisseaux <ma...@geomatys.com> wrote:
>
> Hello Georges and all
>
> The following article, "How Good Are Modern Spatial Libraries?" (published November 2020) does a comparison between JTS, GEOS and other libraries:
>
> https://doi.org/10.1007/s41019-020-00147-9
>
> Note: I do not know why the language restriction, but if it is for performance, the reality can be counter-intuitive. GEOS is a port of JTS library from Java to C. So it should be the same algorithms, only in a different language. But according benchmarks in above-cited articles, GEOS is actually… slightly slower than JTS.
>
> Martin
>
> P.S.: On GEOS benchmark results: the authors attribute that to excessive memory allocations. The malloc and free functions in C/C++ are slower than memory allocation in Java. With a garbage collector, only surviving objects have a cost. In a program where e.g. 90% of objects die young, garbage collector can be more performant than explicit memory allocation (I also saw a benchmark from IBM a long time ago doing similar demonstration with the grep program).
>
> On Mar 29, 2022, at 12:46 PM, Joshua Lieberman <jl...@tumblingwalls.com> wrote:
>
> https://libgeos.org <https://libgeos.org/>.
Re: DE-9IM in C, Go or Rust?
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Georges and all
The following article, "How Good Are Modern Spatial Libraries?"
(published November 2020) does a comparison between JTS, GEOS and other
libraries:
https://doi.org/10.1007/s41019-020-00147-9
Note: I do not know why the language restriction, but if it is for
performance, the reality can be counter-intuitive. GEOS is a port of JTS
library from Java to C. So it should be the same algorithms, only in a
different language. But according benchmarks in above-cited articles,
GEOS is actually… slightly slower than JTS.
Martin
P.S.: On GEOS benchmark results: the authors attribute that to excessive
memory allocations. The malloc and free functions in C/C++ are slower
than memory allocation in Java. With a garbage collector, only surviving
objects have a cost. In a program where e.g. 90% of objects die young,
garbage collector can be more performant than explicit memory allocation
(I also saw a benchmark from IBM a long time ago doing similar
demonstration with the grep program).
Re: DE-9IM in C, Go or Rust?
Posted by Joshua Lieberman <jl...@tumblingwalls.com>.
https://libgeos.org <https://libgeos.org/>. ?
> On Mar 29, 2022, at 11:46 AM, George Percivall <pe...@ieee.org.INVALID> wrote:
>
> Hey geo crowd,
>
> Im looking for code doing DE-9IM spatial relations
> https://en.wikipedia.org/wiki/DE-9IM <https://en.wikipedia.org/wiki/DE-9IM>
>
> JTS is great for Java, but I need something in C, Go or Rust.
>
> Let me know, thanks,
> George
>
>
> George Percivall
> GeoRoundtable <https://www.linkedin.com/company/geo-roundtable/>
> percivall@apache.org <ma...@apache.org>
>
>
Re: DE-9IM in C, Go or Rust?
Posted by George Percivall <pe...@ieee.org.INVALID>.
This has come to my attention: https://github.com/georust/geo/pull/639 <https://github.com/georust/geo/pull/639>
George
> On Mar 29, 2022, at 11:46 AM, George Percivall <pe...@ieee.org.INVALID> wrote:
>
> Hey geo crowd,
>
> Im looking for code doing DE-9IM spatial relations
> https://en.wikipedia.org/wiki/DE-9IM <https://en.wikipedia.org/wiki/DE-9IM>
>
> JTS is great for Java, but I need something in C, Go or Rust.
>
> Let me know, thanks,
> George
>
>
> George Percivall
> GeoRoundtable <https://www.linkedin.com/company/geo-roundtable/>
> percivall@apache.org <ma...@apache.org>
>
>