The GEOS geometry API is used by many, many projects to do their heavy geometric lifting. But GEOS has always had a bit of a PR problem. Most of those projects provide a more accessible interface to perform GEOS operations. Some offer a high-level language like Python, R, or SQL (and these typically come with a REPL to make things even easier). Or there are GUIs like QGIS, or a command-line interface (CLI) like GDAL/OGR.
But you can't do much with GEOS on its own. It is a C/C++ library, and to use it you need to break out the compiler and start cutting code. It's essentially "headless". Even for GEOS developers, writing an entire C program just to try out a geometry operation on a dataset is painful, to say the least.
There is the GEOS XMLTester utility, of course. It processes carefully structured XML files, but that is hardly convenient. (And in case this brings to mind a snide comment like "2001 called and wants its file format back", XML actually works very well in JTS and GEOS as a portable and readable format for geometry tests. But I digress.)
JTS (on which GEOS is based) has the TestBuilder GUI, which works well for testing out and visualizing the results of JTS operations. JTS also has a CLI called JtsOp. Writing a GUI for GEOS would be a tall order. But a command-line interface (CLI) is much simpler to code, and has significant utility. In fact there is an interesting project called geos-cli that provides a simple CLI for GEOS. But it's ideal to have the CLI code as part of the GEOS project, since it ensures being up-to-date with the library code, and makes it easy to add operations to test new functionality.
This need has led to the development of geosop. It is a CLI for GEOS which performs a range of useful tasks:
- Run GEOS operations to confirm their semantics
- Test the behaviour of GEOS on specific geometric data
- Time the performance of operation execution
- Profile GEOS code to find hotspots
- Check memory usage characteristics of GEOS code
- Generate spatial data for use in visualization or testing
- Convert datasets between WKT and WKB
- Read WKT and WKB from files, standard input, or command-line literals
- Execute GEOS operations on the list(s) of input geometries. Binary operations are executed on every pair of input geometries (i.e. the cross join aka Cartesian product)
- Output geometry results in WKT or WKB (or text, for non-geometric results)
- Display the execution time of data input and operations
- Display a full log of the command processing
- Compute the interior point for each country in a world polygons dataset, and output them as WKT:
geosop -a world.wkt -f wkt interiorPoint
- Determine the time required to compute buffers of distance 1 for each country in the world:
geosop -a world.wkt --time buffer 1
- Compute the union of all countries in Europe:
geosop -a europe.wkb --collect -f wkb unaryUnion
The README gives many more examples of how to use the various command-line options. In a subsequent post I'll give some demonstrations of using geosop for various tasks including GEOS testing, performance tuning, and geoprocessing.
- GeoJSON is a popular format for use in spatial toolchains. Adding GeoJSON reading and writing would allow geosop to be more widely used for geo-processing.
- Adding SVG output would provide a way to visualize the results of GEOS operations.
- Improve support for performance testing by adding operations to generate various kinds of standard test datasets (such as point grids, polygon grids, and random point fields).