About the future of rpostgis

[basille]

This issue is the central place to report news about the situation of rpostgis.

The package rpostgis is at a crossroad. 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 @dnbucklin 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. We can however oversee a transition to a new model, maintainer or community for rpostgis.

Lastly, there is 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.

Steps to be taken as of now are:

• Contact lucas' maintainer (Momchil Yordanov) to see if they have enough interest in rpostgis to take it over and assure future development and maintenance, or if their use of the package justifies it. → by email
• Raise an issue in the r-spatial repository dedicated to discussion about the status and relevance of rpostgis. To start with, we need to establish whether the purpose of rpostgis is still relevant in the current R spatial ecosystem (in particular, sf has a specific DB architecture and should be able to handle the vector part; it is not so clear for terra and stars for the raster counterpart). If rpostgis is deemed relevant, see if anyone is interested in taking over development and maintenance of the package. → About the relevance and future of rpostgis r-spatial/discuss#58
• Contact ROpenSci and ask pretty much the same question about rpostgis. In the end, see if ROpenSci team and community would like to take over development and maintenance of the package as part of their Geospatial category (access, manipulate, convert geospatial data). → https://discuss.ropensci.org/t/rpostgis-retiring-soon-call-for-maintainers/3483

Of course, @dnbucklin and myself remain available (as much as possible) to support a smooth transition.

[Thorsten-Behrens]

We have a first version of a port of the raster functions to terra, which so far writes single-band rasters to PostGIS and can read them. It is a minimal package. If anyone is interested in developing rpostgis further as a whole, we'll be happy to make our code directly available to you. If not, we will release the code on github in the next weeks in consultation with Mathieu and David.

As a reference to the r-spatial repository: r-spatial/discuss#58

[Cidree]

Hello,

I am writing to inquire about the future of the rpostgis package. As far as I am aware, this package is currently the only tool available for transferring raster data, and I am wondering if there are any updates on its development.

I believe that losing this functionality would be a great loss, and I am curious to know the current state of the package. Could you please provide me with any information you have on this matter?

Thank you for your time.

[basille]

Dear @Cidree, thanks for your message! Nothing happened on the rpostgis front, so the package is quietly going to retire. We actually just released an update of the package, with a single change: A startup message announcing the retirement, and a few alternatives.

You are right that there is (to our knowledge) no solution from other packages to deal with PostGIS rasters. See however the message from @Thorsten-Behrens above.

[dnbucklin]

Hi @Cidree - I wanted to check in and ask about progress on rpostgis. Do you still have interest in maintaining the package? Recall that uses of the retiring packages rgeos, rgdal will need to be removed, and likely all uses as raster in the near future. Since these packages are moving to retirement by end of 2023, these changes need to be made soon to avoid moving towards rpostgis archival.

[Thorsten-Behrens]

Hi all,
I had no time to work on it since January. But I'll check what we have the next couple of weeks and then put the code on GitHub.
Thorsten

[Cidree]

Hello all,

I am sorry for my late reply, but I have good news. I was working on the package, and I almost have a fully transitioned version of the rpostgis package. However, I still need to do some tests. In this link you can find my curren work. I'm currently in the process of implementing some crucial changes, and I promise to keep you updated with any developments.

Cidre

[Thorsten-Behrens]

Great!
Thanks for your efforts!

I'll compare to our stuff, and if there should be some advantages, I'll send you the code.

Cheers,
Thorsten

[barryrowlingson]

I've also been diddling around with this package to make it work for postGIS rasters, in response to a GIS Stack Exchange Q a little while ago. I've got pgWriteTerra working (at least minimally) which also needed some changes to pgSRID to get the CRS in proj format. I've probably not done any more than the other forks mentioned above but thought I'd mention it.
Shame that one of the forks has bloated the dependencies though - this package should be kept as dependency-light as possible given its a fairly low-level interface to the DB. (I'd submit an issue there but the repo doesn't have issue tracker enabled...)

[dnbucklin]

Thanks @barryrowlingson - I've brought up your point about dependencies to @Cidree, who is planning to take over maintenance of rpostgis. We have now merged Cidree's fork to the mablab dev branch. If you have further input you can provide it through this issue board.

[dnbucklin]

An update - thanks to the great work of the new maintainer (@Cidree) rpostgis v1.5 is now on CRAN, and transitions the package to the sf/terra ecosystem. The repository will soon be transferred to Cidree's GitHub page, at which point this issue can be closed.