fasterize
fasterize copied to clipboard
stars output
Per https://github.com/r-spatial/stars/issues/2, We do want stars object outputs. This shouldn't take too much work, as I said over in that issue, we need to:
- Add code to transfer CRS and other appropriate metadata from the sf object to an empty stars object. From a quick look this is basically
st_as_star.bbox
.- Break up the
rasterize()
core function to separate out rasterization logic from raster/stars container-creation logic, and just pass a pointer to the data slot of the raster/stars object the rasterization function. (This should be even easier than with raster because you don't have to go through figuring out how to access S4 sub-slots from C++)- Add the logic to update the stars object metadata after rasterizing (the equiv. of this. I guess this is basically adding the metadata for the third(+) dimension(s), which you don't know before rasterization because the # of unique layers is determined as you go.
Beating a dead horse maybe, but this would follow trivially from the index-abstraction option - you wouldn't need any internal handling of raster or stars types, but simply format the output based on the scan line index.
Does that make it more compelling?
Is there any progress in increasing the compatibility with the stars package? It would be good to a) use a stars object as a template for the raster ouput, and b) produce a stars object as output.
I'd rather encourage someone else to write a wrapper to do that, if you need assistance I'll show how to do it. Format-specific wrappers belong in format-specific packages, so I'd expect stars to provide that. I'm confused why the request is made here.
Fwiw, the only job of raster here is to provide a container for extent, dimension, crs - six numbers and a string. Work here will target removing depending other libraries (we now depend on terra because of the curious trajectory of r/spatial). If stars worked with an agreed protocol available for development I'd simply use that, but with stars as a *dependency" here we'd pull in a whole raft of useless heavy software requirements.