rpostgis retiring soon, call for maintainers

General Q&A
,
1

Hi everyone,

This is a copy of our call for maintainers on r-spatial, in case there is people interested here that we may have missed so far. Please feel free to respond here or on the GitHub issue linked above as you see fit.

The main purpose of rpostgis is to provide an interface between R and PostGIS to transparently transfer spatial data (both vectors and rasters) — secondarily, rpostgis also provides convenience functions to execute common procedures in PostGIS.

rpostgis was however developed (by David Bucklin and myself) at a time when both sp and raster were the de facto reference packages for spatial data (first stable release of rpostgis in August 2016). Since then, R as seen an incredibly active development of the spatial ecosystem, most notably the packages sf, terra and stars. To stay relevant, rpostgis would need to switch to these modern classes of spatial objects, and thus support sf, terra and stars. In addition, packages rgdal, rgeos and maptools will retire by the end of 2023, which also means that rpostgis not only need to support the modern packages mentioned above, but also remove dependencies to rgeos (see this issue on rpostgis repository).

Altogether, this would require a major overhaul of rpostgis. Unfortunately, as our positions have evolved, neither @dnbucklin or myself have the time and resources to take care of this. If nothing happens, rpostgis will thus simply retire by the end of 2023 as well (note: we have just released a new version that simply display a startup message about the upcoming retirement).

Relevance

But before this happens, we would like to first evaluate the relevance of the purpose of rpostgis, i.e. providing a connection to a PostGIS DB, and most importantly allowing bi-directional transfer between PostGIS to R of both vector and raster data. The first question is thus: Is this purpose still relevant?

  • For vector data, my understanding is that sf has its own DB vector reading architecture (including with queries). Is that also true for writing?
  • What about raster data? Can stars and terra handle PostGIS rasters? (and if they do, does it work bi-directionally?)

Need

If the answers are negative above, then there are still gaps in the bidirectional transfer of spatial data between R and PostGIS. This leads me to the second question: Is there actually a need for such a tool?

One way to answer this is to look at the dependency network or rpostgis: There is currently a single package that relies on rpostgis: lucas (on CRAN) (package to download and create the DB of LUCAS Data Harmonized), in the form of an import.

Second, looking a little bit at available download statistics (e.g. at https://cranlogs.r-pkg.org/badges/rpostgis or through Hadley’s CRAN download app) shows a relatively stable number of downloads over the years (around 500–1000/month).

Development and maintenance

If both the relevance and need for a tool like rpostgis are high, then comes the human problem. As said above, neither David or myself can commit to rpostgis anymore. We remain available (as much as possible) to support a smooth transition though. The call is thus open as to whether anybody is interested in taking over rpostgis and commit to a sustained future of the package.

PS: Note sure this should be posted here — don’t hesitate to move this post to another category that would be more relevant.