Convert all `raster` functionality to `terra` about quadtree HOT 4 CLOSED

I'd probably prefer just storing it as a .TIF. It won't be as convenient as data(habitat), but when compared to using wrap()/unwrap() or storing it as a RasterLayer and converting to SpatRaster, I feel like the .TIF option is the most straight-forward.

from quadtree.

I started to dig into this just to scope out how big of a job it would be. I think most things should port 1:1 with not much trouble. I would be happy to submit a PR with some ideas on using all terra internals. Initially just as a target to compare against and see where issues may be

One possible wrinkle I see is the habitat dataset.

Internal package RasterLayer objects have been a thorn in the side of folks converting to terra SpatRaster because of the need to wrap()/unwrap() SpatRaster objects to store in .Rda.

• On one hand, it is simple enough to call terra::rast() to convert the existing habitat dataset, leaving it unchanged as far as how it is stored in the package.

• For alternate options, I know Robert has suggested to folks that they just store a .TIF file in inst/extdata, rather than wrap/unwrap. The data would then be then accessed as a path via system.file(, package="quadtree"). That works, but not quite a full replacement for current data(habitat) calls.

from quadtree.

Sounds good to me! I have made all the initial conversions and implemented storage as .TIF. This causes some slight differences in the floating point values stored, which in turn affects (minor I think) the costs and other values coming out of find_lcp(). See #19 for more on this.

One new wrinkle that this new PR introduces (but does not address in any way) is now SpatRaster is the main object of interest--which is a somewhat more broad definition than RasterLayer. Notably it can contain multiple layers.

from quadtree.

Completed with PR #19.

from quadtree.