Package go-geos provides an interface to GEOS.
$ go get github.com/twpayne/go-geosYou must also install the GEOS development headers and libraries. These are
typically in the package libgeos-dev on Debian-like systems, geos-devel on
RedHat-like systems, and geos in Homebrew.
- 
Fluent Go API.
 - 
Low-level
Context,CoordSeq,Geom,PrepGeom, andSTRtreetypes provide access to all GEOS methods. - 
High-level
geometry.Geometrytype implements all GEOS functionality and many standard Go interfaces:database/sql/driver.Valueranddatabase/sql.Scanner(WKB) for PostGIS database integration.encoding/json.Marshalerandencoding/json.Unmarshaler(GeoJSON).encoding/xml.Marshaler(KML).encoding.BinaryMarshalerandencoding.BinaryUnmarshaler(WKB).encoding.TextMarshalerandencoding.TextUnmarshaler(WKT).encoding/gob.GobEncoderandencoding/gob.GobDecoder(GOB).
See the PostGIS example for a demonstration of the use of these interfaces.
 - 
Concurrency-safe.
go-geosuses GEOS's threadsafe*_rfunctions under the hood, with locking to ensure safety, even when used across multiple goroutines. For best performance, use onegeos.Contextper goroutine. - 
Caching of geometry properties to avoid cgo overhead.
 - 
Optimized GeoJSON encoder.
 - 
Automatic cleanup of GEOS objects.
 
go-geos objects live mostly on the C heap. go-geos sets cleanup functions on
the objects it creates that free the associated C memory. However, the C heap is
not visible to the Go runtime. The can result in significant memory pressure as
memory is consumed by large, un-freed geometries, of which the Go runtime is
unaware.
Returned sub-geometries (e.g. polygon rings or geometries in a collection) and coordinate sequences are owned by the geometry and are only valid for as long as the original geometry exists. If you need to persist a sub-geometry for longer than the original geometry you must clone it.
go-geos uses the stable GEOS C bindings. These bindings catch exceptions from
the underlying C++ code and convert them to an integer return code. For normal
geometry operations, go-geos panics whenever it encounters a GEOS return code
indicating an error, rather than returning an error. Such panics will not
occur if go-geos is used correctly. Panics will occur for invalid API calls,
out-of-bounds access, or operations on invalid geometries. This behavior is
similar to slice access in Go (out-of-bounds accesses panic) and keeps the API
fluent. When parsing data, errors are expected so an error is returned.
github.com/twpayne/go-geom is a pure Go
library providing similar functionality to go-geos. The major differences are:
go-geosuses GEOS, which is an extremely mature library with a rich feature set.go-geosuses cgo, with all the disadvantages that that entails, notably expensive function call overhead, more complex memory management and trickier cross-compilation.go-geomuses a cache-friendly coordinate layout which is generally faster than GEOS for many operations.
go-geos is a good fit if your program is short-lived (meaning you can ignore
memory management), or you require the battle-tested geometry functions provided
by GEOS and are willing to handle memory management manually. go-geom is
recommended for long-running processes with less stringent geometry function
requirements.
go-geos is tested to work with the versions of GEOS tested on CI.
See here.
Calling functions unsupported by the underlying GEOS library will result in a panic.
Users can use VersionCompare
to be sure that a function exists.
Please check CONTRIBUTING.md for instructions before you open a pull-request!
MIT