Move functions dependecies to terra

[kauedesousa]

terra is an R package that replaces raster. It has a very similar interface, but it is simpler and much faster. The first (beta-) release was on 20 March 2020.

https://CRAN.R-project.org/package=terra

[andrewmarx]

Some aspects of this aren't trivial. The TransitionLayer class has slots that specifically contain objects defined by the raster package. Changing these to terra equivalents risks breaking a lot of old code dependent on gdistance. A few options are being considered:

1. Completely replace raster with terra. This would effectively break all old code. I'm not really considering this an option, but listing it for completeness.
2. Replace raster with terra, but maintain a method for converting Raster* inputs to terra equivalents. The TransitionLayer slots would all be updated to terra equivalents. I suspect that most old code would still run, as long as it's not trying to access certain components of the TransitionLayer (e.g., the extent)
3. Same as 2, but have the TransitionLayer contain varying types for things (like the extent) that are dependent on the initial input type. This should allow all existing code to run but makes working directly with the TransitionLayer class more complicated because users would have to check if it was created using a Raster* object or a SpatRast object (I would add a new slot specifying this). My main concern is that it potentially adds more burden to downstream packages that might also want to incorporate terra support.

I'm leaning toward option 3 with the main goal of not breaking existing code. It technically adds complexity to accessing data in the TransitionLayer class directly, but only if terra is being used.

[jacobvanetten]

Since you can use S4 'overloading', option 3 should be possible without needing a new slot. You can define what the function does depending on the class that it receives as input. I think you should read up on S4 methods. If you want, we can have a videocall in the first week of May or so for some pointers and to go through the code. I am very happy you are taking this on!

…

On Sat, Apr 22, 2023 at 2:39 PM Andrew Marx ***@***.***> wrote: Some aspects of this aren't trivial. The TransitionLayer class has slots that specifically contain objects defined by the raster package. Changing these to terra equivalents risks breaking a lot of old code dependent on gdistance. A few options are being considered: 1. Completely replace raster with terra. This would effectively break all old code. I'm not really considering this an option, but listing it for completeness. 2. Replace raster with terra, but maintain a method for converting Raster* inputs to terra equivalents. The TransitionLayer slots would all be updated to terra equivalents. I *suspect* that most old code would still run, as long as it's not trying to access certain components of the TransitionLayer (e.g., the extent) 3. Same as 2, but have the TransitionLayer contain varying types for things (like the extent) that are dependent on the initial input type. This should allow all existing code to run but makes working directly with the TransitionLayer class more complicated because users would have to check if it was created using a Raster* object or a SpatRast object (I would add a new slot specifying this). My main concern is that it potentially adds more burden to downstream packages that might also want to incorporate terra support. I'm leaning toward option 3 with the main goal of not breaking existing code. It technically adds complexity to accessing data in the TransitionLayer class directly, but only if terra is being used. — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGF5FIDEW3WVM4ECQTXH4LXCPGOXANCNFSM4OFM24QA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[andrewmarx]

I was actually just looking at coerce.R when you replied. I use S4 a lot in my package but never had a need to do class coercion like that. So I'll probably do that now that I've seen how it works.

When I wrote my last post, I was worried about the scenario where people are accessing slots directly using @ (I've definitely seen it in the wild; a lot of people don't know it's a bad practice). But maybe I'll just not worry about that, and let it be their responsibility if anything breaks (this is something I explicitly warn about in my package's documentation).

[andrewmarx]

So I got around to starting this, but it didn't register with me before that the TransitionLayer class also inherits from the RasterLayer class. So it might not be so simple to support terra to the degree I was hoping. Supporting coercion is doable, but actually replacing raster internally might be more difficult because TransitionLayers are effectively RasterLayers. I would love to decouple the TransitionLayer class from raster, but that's a big, potentially breaking change. Since the person that maintains both raster and terra has been updating raster to use terra internally, I'm less concerned about raster eventually becoming deprecated, so maybe it's best to just stick with raster. I'd be interested in your thoughts @jacobvanetten