Isis3: Port ISIS to use Geos C-API

[Kelvinrr]

ISIS version(s) affected: 3.x.x

Description

Geos C++ API is unstable. Specifically, we run into compatibility issues with co-installing other libraries with ISIS in the same environment.

The GEOs C++ interface changes between minor versions, as of ISIS v3.10, ISIS is tied to Geos 3.7.x C++ API and therefore is inflexible to other libraries requirements (e.g. conda-forge Linux build of GDAL requires GEOS 3.7.x but MacOS requires GEOS 3.6.x). To maximize compatibility, the best approach seems to be to port ISIS to use the GEOS C-API as the C-API is stable between minor versions.

How to reproduce

run conda install gdal on an environment with ISIS installed and you will get environment conflicts. Changing GEOS version will cause library resolution errors in ISIS.

Possible Solution

C-API Code: https://github.com/libgeos/geos/tree/master/capi
geos_c.h.in contains all the documentation available on the C-API.

Some details to take note of (mostly implied in "C-API" but worth explicitly pointing out):

1. The GEOS C-API has a stand-up/tear-down process. We need to run initGEOSbefore calling any other C-API function as the handle it returns must be passed in as the first argument in every function. finishGEOS has to be called before the end of the program.
   
   
   
   1. We have access to some basic objects: GEOSGeom_t, GEOSPrepGeom_t, GEOSCoordSeq_t, GEOSSTRtree_t, GEOSBufParams_t. They are basically typedef-struct-ed geos::geom objects. No Polymorphism to differentiate between Geometry types.
   
   
   2. Seems most if not all geometry manipulation and IO operations are present including reading writing WKT/WKB
   
   
   3. No Exceptions, error codes/null pointers are returned instead.
   
   

Fact 1 requires that we need to determine the best location to initialize GEOS + run atexit(finishGeos) or similar.

Fact 2 implies potential API-breaking changes to:

• RubberBandTool
• Shape
• SpatialPlotTool
• MeasureTool
• Image
• MosaicSceneItem
• HistogramTool
• SpectralPlotTool
• HiJitCube
• InterestOperator
• PolygonTools
• GisGeometry
• Chip
• ImageOverlap
• ProcessPolygons
• StripPolygonSeeder
• GisTopology
• PolygonSeeder
• GridPolygonSeeder
• LimitPolygonSeeder
• ProcessGroundPolygons
• ImageOverlapSet
• ImagePolygon
• CsvWriterStrategy
• CamTools

Additionally, we will need to make a decision about whether we want to encapsulate GEOS geometry objects somehow to re-enable ISIS-flavored polymorphic Geometry or if we want to use low-level Geometries directly. Additionally, we will need an answer to removing geos::geom::GeometryFactory with something similar powered by the C-API.

Fact 4 requires us to consider error-code-to-exception coversions.

Overall, transitioning to the C-API will require us to re-design ISIS's geometry backbone to a ISIS C++ API powered by the GEOS C-API in place of the GEO C++ API.

Alternatively, we can support multiple versions of the C++ API through #defines.

Additional context

[KrisBecker]

@Kelvinrr please check out GisTopology and GisGeometry. Both make strict use of the GEOS C-API. GisTopology is a singleton that handles initialization/destruction of the GEOS system. It also handles reading, writing and conversion of GEOS geometries such as WKT and WKB types. GisGeometry is a generic geometry container that implements many of the GEOS operators.

These classes can provide a starting point for this work. See the Strategy, GisOverlapStrategy, GisUnionStrategy and GisIntersectStrategy classes for how they are used.

[ascbot]

I am a bot that cleans up old issues that do not have activity.

This issue has not received feedback in the last six months. I am going to add the inactive label to
this issue. If this is still a pertinent issue, please add a comment or add an emoji to an existing comment.

I will post again in five months with another reminder and will close this issue on it's birthday unless it has
some activity.

[scsides]

This is being looked at as an import piece for an FY22 task and should not be closed as inactive