cran-task-views/Spatial

Seeking new maintainer for gdistance

Closed this issue · 7 comments

kauedesousa commented

Dear Spatial Task View,

As you may know, package gdistance has been fruitfully serving the community over the last 12 years. In 2020 I temporarily took over the maintenance from Jacob van Etten as he was not able to keep this task anymore. The package is yet among some important packages in ecology (with >4k downloads per month) but is receiving some issue reports that I am not able to solve. I would like to open this search for a new maintainer among the R Spatial Community in case someone wants to keep this package alive. And maybe even explore its integration with new packages and new advances that you have done within R Spatial. Any comments/suggestions? Thanks in advance.

andrewmarx commented

I'll put it out there that I'm considering it. I've already reimplemented the transition code in my package to be more memory efficient (as part of something else) and was considering cleaning it up and releasing it as a dedicated function. And I was also considering eventually reimplementing some of the other functions from gdistance in my package. Just taking on and maintaining gdistance instead probably wouldn't be too much more overhead over that, and it might be nice to keep certain concepts contained in different packages. I'll spend some time thinking about it over the next week or so.

  • 👍2
DemetriosG commented

That would be great Andrew. I am one of those who reported gdistance::transition() issues with large rasters representing impedance surfaces. I would be willing to test any code you write or modify, if that would assist your efforts.

andrewmarx commented

@kauedesousa I've decided that I'm willing to take it on

  • 👍1
DemetriosG commented

Great! Many thanks Andrew.

kauedesousa commented

Hi @andrewmarx thanks for the willingness to accept the task. I'll proceed with the formalities. But I also want to inform that I ended up having a parallel conversation with @rhijmans who is considering to improve gdistance capabilities to become faster like terra, putting it in C++. Maybe you can discuss to see if this could be done in collaboration.

andrewmarx commented

That was an option I was considering as well, but first, I wanted to do what I did with my package:

  • Add support for terra by replacing all the raster code and having it convert Raster* objects to the terra equivalents for backward compatibility
  • Update the transition() and geocorrection() functions to be memory efficient; their code is very clean and elegant at the cost of performance and memory. I have my package creating more complex transition matrices on the order of 100-500M cells using just a regular desktop computer in a reasonably short amount of time without C++
  • Having a few common built-in functions like "1/mean(x)". Removing the overhead from calling user-defined R functions has a huge impact on speed.

After doing those things, then I would look at profiling things to figure out existing bottlenecks and the best way to address them (either with R or C++).

I also want to implement more thorough unit testing first before making any big changes to make sure nothing gets broken in the process.

  • 👍1
Nowosad commented

It is great that the new maintainer was found. Thanks @kauedesousa and @andrewmarx