tile_blocksize() may fail with multi-layer rasters

[Aariq]

https://github.com/njtierney/geotargets/blob/ea1f9fe737ebcc64a9e6bd88f589e7554e87f17f/R/tar_terra_tiles.R#L289C5-L289C76

Not sure how I missed this, but getTileExtents() expects 1 or 2 numbers and fileBlocksize() appears to return two number per layer as a matrix. Need to add a test to confirm and then fix this.

Would the blocksize ever differ among layers of the same raster? Seems like they shouldn't, since they are required to have the same resolution and projection. If that is true, I'll just take the first row.

[njtierney]

Good catch on this!

Would the blocksize ever differ among layers of the same raster? Seems like they shouldn't, since they are required to have the same resolution and projection. If that is true, I'll just take the first row.

I'm not sure about this, but I'm wondering if @mdsumner, @anthonynorth, and @paleolimbot might have thoughts?

[Aariq]

I also noticed that if a raster source is memory and not a file, then fileBlocksize() returns 0,0 and tile_blocksize() errors uninformatively. Fortunately, I don't think that'll be an issue for us as long as tar_terra_tiles() is given a target name in the raster argument rather than creating a raster on the fly. On the other hand, it might be good to add an actually helpful error message just to be safe?

[mdsumner]

At the margins there might be a "dangle", an overlap where a whole block isn't filled by the actual extent of the raster, so there's a concept of "actual block size". Afaik that's only for the last row and/or last column, usually the right and bottom. Other variants would be a bit nasty I think, and definitely not common.

[mdsumner]

When talking about layers we're really talking bands in a 2D raster, ie multivariable or time series (kinda).

I think different block sizes there would be pathological, but actually possible given VRT descriptions. I'll have an explore to see if there's anything there to worry about 🙏