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

Make Intervals responsible for their own Patches #100

Open
rgmyr opened this issue Mar 7, 2019 · 1 comment
Open

Make Intervals responsible for their own Patches #100

rgmyr opened this issue Mar 7, 2019 · 1 comment

Comments

@rgmyr
Copy link

rgmyr commented Mar 7, 2019

I'm working on this to allow for more flexibility in Interval shapes (multi-width Polygons, curved PathPatches) when plotting detailed graphic log / measured section data. This should also make it easy to clean up the Striplog.plot_axis method a bit. Any feedback is appreciated!

My idea at this point is to construct and return different kinds of patches based on type(self.data[width_field]):

  1. Single numeric values create the standard Rectangle patch.

  2. Arrays or iterables create Polygons or PathPatchs, depending on kwargs. If the array/iterable is 1D it's assumed to be evenly spaced samples between self.top and self.base. If it's a 2D array, then we take it to be an array of specific [depth, value] samples.

  3. Dictionaries also create Polygons or PathPatchs depending on kwargs. The case I have in mind is a dataset where beds have a top_gs, a base_gs, and a (weighted) mean_gs. They have a typical "fining up" profile, so these values along with some curve kwargs can be used to fit a path through the top/base values such that interval has the correct weighted mean.

I would also add a Interval.max_field method that returns the appropriate value for whatever datatype is found, and then striplog.max_field would just be the maximum of [iv.max_field(field) for iv in self].

@rgmyr
Copy link
Author

rgmyr commented Mar 7, 2019

Actually I'm torn about whether I should accept 2D arrays at all, or whether those kinds of samples should have to be specified in a dict with e.g., depths and values keys.

@kwinkunks kwinkunks mentioned this issue Apr 22, 2022
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