Rafael Schouten

~~The difference with `crop` is the combination of forcing treatment as pixel area, and setting `touches=true`. ~~ ~~We should probably make `touches=true` the default to standardise with R/Python~~ No its...

The main difference in `aggregate` is that the type is UInt16 and we are getting overflow in the sum. If we force Float64 the answer is the same as terra...

Same for ndvi, its just overflow or underflow adding UInt16 in the benchmark implementation. Converting to Int64 on the fly (with multiplication by 1) fixes it: ```julia julia> get_ndvi(red, nir)...

Im bugfixing aggregate mean and sum as they should convert internally I just implemented them badly. But NVDI is just a base Julia broadcast not Rasters.jl in really any way,...

Its approximate like the other packages. Now I've seen exactextractr is exact I'll add that option in a few months! But I think it will be even faster after that...

Well, Rasters wont benefit from faster gdal rasterize as we only use gdal for i/o and for gdalwarp. But it would be good to have detailed comparisons of these algorithms....

I imagined we can do that in the line burning phase and get coverage for each pixel the line touches instead of burning. But `zonal` is doing a lot very...

Yeah I think @asinghvi17 has reused the Makie.jl code from the vector benchmarks

@asinghvi17 might also be nice to call it "Rasters.jl" in the label rather than "rasters_jl" ? People I have shown were confused by that

Kinda weird that the other timings got worse, I'm not sure what changed if anything (nvdi especially, that's just a broadcast) And aggregate was far faster than resample but maybe...