Add option to deterine chipping `size` and `stride` by specifying `size` and `buffer`

[youngdjn]

I'd like to be able to analyze predictions in "focal tiles" which have no overlap with their neighbors (solid lines in the figure). But to obtain these tiles, I'd like to perform inference for larger tiles surrounding the focal tiles (based on a user-specified buffer) ("actual tiles", dashed lines in figure), then (in post-processing) clip off the buffer region to obtain the inference from the "focal tiles" only...and ultimately stitch them together. If this makes sense...could you please implement a way for the user to specify the size and buffer (in pixels or meters) and convert this internally to size and stride?

I'm not sure whether the size provided for this alternate approach should be the size of the focal (smaller) square or the actual (larger) tile. I'm thinking actual tile, so that we can standardize the size of the tile that is actually supplied to the model.

I believe it's as simple as computing stride as size-2*buffer, but please confirm you agree.

This issue has two parts:

• [ ] Implement buffer specification during chipping (pre-processing)
• [ ] Implement option to remove the buffer region predictions when reassembling chips during post-processing

The latter step will require somehow storing information on the buffer width from pre-processing so that it can be accessed during post-processing.

[russelldj]

I agree that the size should be the size of the full tile, since that is consistent with the other methods of specifying the size/stride. I think your math is right, assuming you want the buffer in spatial units and not percent. I think you can handle the logic for computing the stride here.

One option for implementing the operation to remove the buffer would be add a new method to the RegionDetections class, called remove_buffer or something similar. It could take the amount to buffer and use the prediction_bounds_in_CRS attribute to compute a buffered region. Then, you could return a copy of the original object with the updated bounds (buffered in) and the detections attribute cropped to the new bounds. It looks like gpd.clip should allow you to do the later operation. You can follow the logic in subset_detections for returning an updated version of the object.