Open vlandau opened 2 years ago
Thanks, that makes sense.
So it's making a perfectly fine copy of the object, but the copy actually points at the same file. And that's kind of weird for how people think about cpoy/deepcopy
. I guess copy
and deepcopy
should be the same here?
So maybe copy
/deepcopy
:
Rasters.isdisk(A) == true
) then follow copy/deepcopy
wtih read
it to move to memory? (btw you can use read
to move to memory as you do with indexing)
We will have to go through and manually copy/deepcopy
the dims/metadata etc fields if we override copy/deepcopy
, and rebuild the object.
Ah yes, looks like copy works just fine. I'm still slightly unsure about when to use copy vs deepcopy in general...
I think your proposal above makes sense.
I'm wondering if this needs a warning if the file is disk-based?
"Warning: this raster is disk based. If you mean to copy the file, use cp(src, dst)
. For this operation, raster read to memory with read
.
Also, we could actually define cp
:
cp(src::Raster, dst::AbstractString; kw...)` = `Raster(copy(filename(src), dst; kw...)`
And have a similar warning if it isn't disk-based.
I think that makes sense -- could do a warning or even an error
This code doesn't work
Ouput:
It looks like the problem is due to the Raster being entirely disk-backed as of the call of
copy
.The code below does work
To be clear, I recognize at this time this may be expected behavior, but it may be user-friendly to add new methods to copy and deepcopy that first read the raster into memory (if it isn't already), and then return a fully memory-backed copy, so the user can skip that step?
Of course, this is a major edge case, and therefore low priority. I can use the workaround above in the mean time!
Thanks for all your work to provide GIS functionality in Julia @rafaqz!
EDIT: Simplified code for clarity