# Future of the space package? **URL:** \ **Category:** Request For Comments\ **Created:** [July 22, 2024, 3:11pm UTC](https://swi-prolog.discourse.group/t/future-of-the-space-package/7622 "2024-07-22T15:11:57Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [July 22, 2024, 3:11pm UTC](https://swi-prolog.discourse.group/t/future-of-the-space-package/7622/1 "2024-07-22T15:11:57Z")
The [space](https://www.swi-prolog.org/pack/list?p=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 ☹ - Rewrite it to use the C API - … And related, who depends on this? ---
**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\ **Post date:** [July 22, 2024, 6:15pm UTC](https://swi-prolog.discourse.group/t/future-of-the-space-package/7622/2 "2024-07-22T18:15:39Z")
There’s also the [HDT](https://www.swi-prolog.org/pack/list?p=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](https://www.swi-prolog.org/pack/list?p=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?). ---
**Author:** ![abaljeu](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/abaljeu/32/136_2.png) [@abaljeu](https://swi-prolog.discourse.group/u/abaljeu)\ **Post date:** [July 30, 2024, 6:15pm UTC](https://swi-prolog.discourse.group/t/future-of-the-space-package/7622/3 "2024-07-30T18:15:37Z")
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? ---
**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\ **Post date:** [July 30, 2024, 8:00pm UTC](https://swi-prolog.discourse.group/t/future-of-the-space-package/7622/4 "2024-07-30T20:00:15Z")
> [@abaljeu](#): > > 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](https://github.com/JanWielemaker/space/tree/master/c) … `wc` gives 827 lines of \*.h and 4082 lines of \*.cc, for a total of 4467 lines (including all comments except the copyright boilerplate). ---
**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\ **Post date:** [July 30, 2024, 11:00pm UTC](https://swi-prolog.discourse.group/t/future-of-the-space-package/7622/5 "2024-07-30T23:00:58Z")
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. ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [July 31, 2024, 9:36am UTC](https://swi-prolog.discourse.group/t/future-of-the-space-package/7622/6 "2024-07-31T09:36:04Z")
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. What do you think? ---
**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\ **Post date:** [July 31, 2024, 5:15pm UTC](https://swi-prolog.discourse.group/t/future-of-the-space-package/7622/7 "2024-07-31T17:15:01Z")
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).