You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For every mode, subsequent plotting commands are clipped until the path is explicitly ended. This stateful behavior makes clipping a natural fit for context managers.
This closely mirrors GMT, but requires users to end clipping explicitly and can leave a clip path active after an exception.
A single context-manager method with a mode
with fig.clip(mode="polygon", data=polygon):
...
with fig.clip(mode="land"):
...
with fig.clip(mode="dcw", code="US"):
...
This has a compact API, but each mode wraps a different GMT module and accepts different parameters. Documenting and validating this mixed argument set could become complicated.
A clip namespace
with fig.clip.polygon(data=polygon):
...
with fig.clip.land():
...
GMT supports several related clipping operations:
coast -Gcoast -Qcoast -Scoast -Qclipclip -Cmaskmask -Ccoast -E+ccoast -Qsolar -Gclip -CFor every mode, subsequent plotting commands are clipped until the path is explicitly ended. This stateful behavior makes clipping a natural fit for context managers.
Possible API designs:
Low-level begin/end methods
This closely mirrors GMT, but requires users to end clipping explicitly and can leave a clip path active after an exception.
A single context-manager method with a mode
This has a compact API, but each mode wraps a different GMT module and accepts different parameters. Documenting and validating this mixed argument set could become complicated.
A
clipnamespaceThis groups related functionality neatly, but may be challenging to expose and document correctly. See the proof of concept in POC: Figure.clip: Clip paths by polygons, land or water #3878.
Explicit context-manager methods
This one is much easier to document that option 4. A POC PR is at WIP + POC: Figure.clip_xxx methods #4703.
I feel option 4 is the best API design.