search

ecohealthalliance / fasterize

High performance raster conversion for modern spatial data 🚀🌏▦
https://ecohealthalliance.github.io/fasterize/
Other
182 stars 15 forks source link

stars output #22

Open noamross opened 6 years ago

noamross commented 6 years ago

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.
mdsumner commented 5 years ago

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?

jmburgos commented 1 year ago

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.

mdsumner commented 1 year ago

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.