Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow cropping "buffer" as a customisable parameter #367

Open
robbibt opened this issue Nov 26, 2024 · 1 comment
Open

Allow cropping "buffer" as a customisable parameter #367

robbibt opened this issue Nov 26, 2024 · 1 comment

Comments

@robbibt
Copy link
Contributor

robbibt commented Nov 26, 2024

Currently the automated buffer that is used when crop=True is hard-coded as 4 model pixels on either side of the analysis extent, e.g.: https://github.com/tsutterley/pyTMD/blob/main/pyTMD/io/FES.py#L263

This works well for most cases, but in certain circumstances it can lead to problems with extrapolating from data located outside the clipped bounds: #366

It would be valuable to be able to customise the buffer used to crop constituents, either by specifying the number of model pixels to use for the buffer, or perhaps as an absolute distance in degrees (I realise that bounds does exist, but this requires users to calculate a full bounding box for each analysis, rather than using the built-in bounds calculation). This would allow users to specify a larger buffer, to ensure data is available for valid extrapolation.

@robbibt
Copy link
Contributor Author

robbibt commented Nov 26, 2024

Another possible option could be to overload bounds for this - e.g. pass a four-item tuple to use a custom bounding box (current functionality), or pass a single value to use as the buffer distance?

tsutterley added a commit that referenced this issue Nov 27, 2024
* feat: expose buffer distance to crop tide model data for #367

* test: add constituent parameter test
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant