feat: lithology track with pattern

[karbor]

Added functionality to have discrete tracks with both color, pattern and name. Structured input a bit different, the new track type (lithologyTrack) has it's own spec (and not e.g. using color maps from a generic colormap input) as we see this as more intuitive when used.

[codecov-commenter]

Codecov Report

Merging #1500 (fbb3a36) into master (4d1070a) will decrease coverage by 0.45%.
The diff coverage is 5.22%.

@@            Coverage Diff             @@
##           master    #1500      +/-   ##
==========================================
- Coverage   33.57%   33.13%   -0.45%     
==========================================
  Files         153      154       +1     
  Lines        8938     9067     +129     
  Branches     2390     2420      +30     
==========================================
+ Hits         3001     3004       +3     
- Misses       5906     6032     +126     
  Partials       31       31              

Impacted Files	Coverage Δ
...src/lib/components/WellLogViewer/SyncLogViewer.tsx	37.98% <ø> (ø)
...omponents/WellLogViewer/components/WellLogView.tsx	40.29% <ø> (ø)
...onents/WellLogViewer/components/LithologyTrack.tsx	1.00% <1.00%> (ø)
...t/src/lib/components/WellLogViewer/utils/tracks.ts	44.75% <17.64%> (-1.70%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[hkfb]

@karbor there should already be support for color, label and patterns in the discrete plots. If you think the interface is unintuitive, then perhaps we could try to improve the interface? Adding duplicate code for roughly the same functionality will reduce maintainability of the code.

CC @Midtveit @mirisb @t0oF-azpn @Vladimir-Kokin

Snapshot for reference, with the new track on the right:

[karbor]

As far as I could see from the storybook and understand from the code, patterns are only possible for wellpicks, i.e. they will cover the entire area across all tracks for a well. What we need is a track with that possibility - i.e. pattern(and later image), color and labels in a single track. If I'm wrong and this is possible in the existing code, could you provide an example?

[hkfb]

As far as I could see from the storybook and understand from the code, patterns are only possible for wellpicks, i.e. they will cover the entire area across all tracks for a well. What we need is a track with that possibility - i.e. pattern(and later image), color and labels in a single track. If I'm wrong and this is possible in the existing code, could you provide an example?

I see your point, and I agree it looks like your use case is not supported.

Is the only thing missing a mapping from discrete code / value to a pattern or image?

If so would it make sense to add to individual plots or tracks the pattern mapping shown in this example, ie. the patternsTable and patterns props? https://equinor.github.io/webviz-subsurface-components/storybook-static/?path=/story/welllogviewer-demo-synclogviewer--default

@Midtveit @Vladimir-Kokin

[karbor]

I considered reusing the patternsTable/patterns from the existing interface also. Ended up with this as a proposal/start of maybe a more intuitive interface(and just keep it on the side of the existing to start with)? I am new to both webviz and front-end programming so I don't know it this is a good proposal for the interface. But we have seen working from the python-side with the component for a while, that there could be beneficial to look into if the interface to the component could be more intuitive and flexible. Maybe we could have more general discussion around that (in a meeting)?

[hkfb]

I considered reusing the patternsTable/patterns from the existing interface also. Ended up with this as a proposal/start of maybe a more intuitive interface(and just keep it on the side of the existing to start with)? I am new to both webviz and front-end programming so I don't know it this is a good proposal for the interface. But we have seen working from the python-side with the component for a while, that there could be beneficial to look into if the interface to the component could be more intuitive and flexible. Maybe we could have more general discussion around that (in a meeting)?

Would be good to have a discussion on the API design. I think there is already planned a discussion on the WellLogViewer around the end of the month @anders-kiaer although I'm on leave the next couple of weeks, so I probably won't attend.