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
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
stars. To stay relevant,
rpostgis would need to switch to these modern classes of spatial objects, and thus support
stars. In addition, packages
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
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).
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
sfhas its own DB vector reading architecture (including with queries). Is that also true for writing?
- What about raster data? Can
terrahandle PostGIS rasters? (and if they do, does it work bi-directionally?)
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
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.