Something for the future - too early while the API is still in flux
There are quite a lot of parameters that appear in MANY operations, because they are needed by something deeper in the call stack. Examples include: radius/zlevel/zscale and rtol/atol. This creates a lot of bloat and duplication across the public API.
I think it would be good if we could come up with alternative solutions so that we can simplify the signatures of a lot of GeoVista operations. The solution will depend on the circumstance, but here are some examples:
Move more obscure tweaks into **kwargs, which could be documented in a single place
Contain linked arguments (e.g. rtol and atol) in a named tuple of settings
Activate settings using a context manager instead
Restructure to make greater use of classes so that the settings become class attributes
Something for the future - too early while the API is still in flux
There are quite a lot of parameters that appear in MANY operations, because they are needed by something deeper in the call stack. Examples include:
radius/zlevel/zscaleandrtol/atol. This creates a lot of bloat and duplication across the public API.I think it would be good if we could come up with alternative solutions so that we can simplify the signatures of a lot of GeoVista operations. The solution will depend on the circumstance, but here are some examples:
**kwargs, which could be documented in a single placertolandatol) in a named tuple of settings