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 initGEOS before 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.
2. 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.
3. Seems most if not all geometry manipulation and IO operations are present including reading writing WKT/WKB
4. 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

[github-actions]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.

[github-actions]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.

[oleg-alexandrov]

It is not possible for either ISIS (or ASP) to move to a new version of GDAL because one is held hostage to Geos 3.7.

Current version of Geos is 3.11. I know they are notorious for not keeping compatibility, but is there a chance things got broken in just a few places, and perhaps with a couple of days of work one could upgrade to the latest?

Any hope this will be prioritized somehow? Or at least to be added to some work plan, say, for the current fiscal year?

[AustinSanders]

@oleg-alexandrov I'll add this to the support backlog. No guarantees that it'll be worked during the next sprint, but it will at least get prioritized among other issues during the next prioritization meeting.

[oleg-alexandrov]

Thank you for that.

A couple of notes when it comes to GDAL and Geos. The latest ISIS (7.1.0) depends on very modern PROJ 9.1.0. I built a conda GDAL package (very recent version, 3.5) compatible with these, which still uses Geos 3.7. These will be shipped with the upcoming ASP conda package.

GDAL has the very stable OGR interface for polygons, and it calls Geos under the hood. ASP uses OGR for polygons (also for shapefile i/o). (https://gdal.org/api/ogrgeometry_cpp.html)

I think the community will be very grateful whichever way you proceed on this. The hope is that Geos didn't break the API so bad that maybe catching up with it could be little work. Longer term, you could write your abstraction layer on top of Geos, or make use of GDAL/OGR which would take care of keeping up with Geos.

[dshean]

Just offering my +1 to prioritize support for latest PROJ/GDAL (and GEOS). ISIS and ASP have fallen pretty far behind on this, and the environment conflicts are going to continue to affect users in both planetary and terrestrial geospatial communities.

[amystamile-usgs]

Current test failures with GEOS 3.9 update:

1. FunctionalTestFindimageoverlapsNoOverlap

• REASON: geos::io::WKTWriter write function segfaulting in ImagePolygon::toBlob()

2. TempTestingFiles.UnitTestImagePolygonCross
3. isisminer_app_test_gisoverlap
4. isisminer_app_test_stereopair
5. isisminer_app_test_stereopair2
6. pixel2map_app_test_lonboundary
7. pixel2map_app_test_pole

(will continue to update)