The space package provides an interface to the spatialindex and geos libraries to create indexes in multi-dimensional spaces and reason about shapes (distance, inside, overlap, …) It was written long ago by Willem van Hage and has been part of the SWI-Prolog Docker image for a long time. @peter.ludemann has modernized the C++ interface.
Unfortunately though, the package binds to the C++ interface of these libraries and the documentation says that, while the C API is stable, the C++ API is not. We are faced every couple of years with issues This time, version 3.12 dropped CoordinateArraySequence What shall we do?
Remove it from the Docker
Keep fixing it (several people have contributed fixes)
Bundle the sources and build them as part of the package. This fixes our compatibility issues, but we’ll fall behind and sooner or later we need to update anyway
There’s also the HDT package, which depends on a repo that seems to be no longer maintained (unlike geos, which is maintained), and the solution for that was to create a fork and apply fixes, while also making PRs against the original repo in case someone picks up maintenance.
For rocksdb, we clone the repo and build it as a static (.a) library instead of a dynamic (.so) one and link it into the foreign code. This could also be done with the “space” package. (The HDT package also is built as a static (.a) library.)
There’s a general problem with anything that uses C++ … it’s quite tricky to maintain ABI compatibility (maintaining ABI compatibility is much easier with C APIs), which is one reason that SWI-cpp2.h isn’t distributed as an object library but only as source. So, it might be easier in the long run to embed the sources (which the rocksdb and hdt packages already do). This might also make it easier to distribute the package on MacOS (and also Windows?).
I was not aware of these libraries. They are things I might consider using, but I don’t use it. I would aim to Rewrite it to use the C API. How big is the SWI prolog wrapper for this?
The code is in space/c at master · JanWielemaker/space · GitHub … wc gives 827 lines of *.h and 4082 lines of *.cc, for a total of 4467 lines (including all comments except the copyright boilerplate).
Assuming that we keep the space package as part of the Docker image, it seems to be tied to libgeos3.11.1, which is what Debian “bookworm” has, and possibly a few point releases before and after (the latest releases are 3.10.6, 3.11.4 and 3.12.2; so the choice of 3.11.1 puzzles me).
I tried installing libgeos 3.11.4 and 3.12.2 and compiling the pack with those; both compilations failed; so it seems that the C++ API is quite unstable.
Anyway, if we just want to make a Docker release, is it so bad to add “geos” as a submodule and compile it as a .a file and link it with the pack? (This appears to be fairly easy to do by setting -DBUILD_SHARED_LIBS=OFF in the cmake command; it would also require cmake for installing space.) (For pack(rocksdb), we use a submodule; but rocksdb has a very stable C++ API, although its ABI is less stable.)
It seems that the immediate choice is between a somewhat out-of-date package and no space in the Docker image. (Removing space from the Docker image would, of course, be the least work.) And if anyone tries to use space in its present form, they need to install a specific version of libgeos.
A bit more status report. As is, the space package is not in the Docker because the libgeos++ version of Debian Bookworm is broken (unless it is fixed since).
I worked on a C wrapper for the spatialindex library. That is close to finished (if I recall correctly, the code is complete, but mostly untested) and only deals with the spatial index, not more general reasoning about shapes. The project was abandoned due to changing priorities. It might however be the correct approach to have an indexing library for objects and a separate library for reasoning about shapes based on libgeos.
I have no opinion because I don’t use space.
I’m here only because @jan asked me to upgrade space to use SWI-cpp2.h so that it would compile for making a Docker image.
I notice that there’s fairly minimal testing in space/test/test_space.pl despite a fair bit of code (over 4000 lines), and the test mainly (only?) checks space_nearest/4 (demo_space.pl also seems to only exercises space_nearest/4). So, I would vote for a minimal wrapper that doesn’t need much testing. (Yes, I’m a big fan of testing, probably because I so often make mistakes.)
Note that in addition to the 4000+ lines of C++, there are another 3400 lines of Prolog.
Does the C wrapper for spatialindex support something like space_nearest/4? Or does that require libgeos?
If the objective is to get a Docker image that builds, you will probably have problems with space as it currently exists, because space appears to build only with a fairly small set of releases of libgeos++-dev (libspatialindex-dev doesn’t appear to be a problem). So, for the Docker images, I see two options: remove space from the image, or include libgeos as a submodule and build it statically as part of the install process (this appears to be not difficult, but I’ve wrong about such things before).
This time, version 3.12 dropped 