Vector support in bridge.Transform.from_points

[pp-mo]

POC for an API extension to gv.Transform.from_points to accept wind-like vectors and convert to xyz vectors stored on the mesh, so they can be usedwith ".glyph()" and ".arrows" usage. (cf. PyVista glyphs examples )

~I have a couple of draft exercises for this working,~ ~but I don't (yet) have permission to share the data.~ Now includes a gallery example, loading data from geovista-data (already added).

TODO:

• [x] provide suitable test data via geovista-data and pantry routine
• [x] provide example showing arrows plotting. because it's not too trivial, this probably wants demonstrate how to do some of these things ...
  • [x] scale arrows or not (i.e. direction-only)
  • [x] ~colour arrows by scale (or not)~ (not needed ?)
  • [ ] ~filter out missing points~ (not needed?)
• [ ] work out whether/how data with extra dimensions might be supported (cf. #554)
  • spoiler : in this case, I don't see how "from_points" really extends to multi-dimensional 'xs' and 'ys',
    • so maybe it's not realistic for this routine, or we can accept any shape but will simply flatten
    • the existing docstring seem to leave it open as a possibility, but that could be just a copy+paste carryover

N.B. I've found that, to get the control you want over appearance, you will want to combine the feature with controls in ".glyph()" and ".add_mesh()" calls.

[welcome[bot]]

🚀 Awesome! Your first pull request! Thanks for contributing to geovista! 🚀

[tkoyama010]

pre-commit.ci autofix

[pp-mo]

Mini status update :

it's really noticable that I have now removed several of the extra controls I originally wrote into this (like a "vectors_scaling" keyword), since I found that the facilities needed were already available in the standard PyVista calls.

There are now basically 3 separate steps, where you get to control different aspects :

1. in the 'from_points' call : keywords vectors + vectors_array_name and vectors_z_scaling
2. in the glyph call, you control scaling, factor and tolerance
3. in the add_mesh call, you control color and cmap

Another common need will be to threshold the mesh before calling 'glyph', to reduce the size of the results. For that, we may want to add our own "vectors Magnitude" array -- I think this is generated by the 'glyph' call, but it is also --frustratingly-- exactly what we needed to threshold on.

So now I'm aiming to write an example to demonstrate how these various controls work together. Possibly 2 examples, if it's too complicated for one.

[pp-mo]

Update :

Added a draft code example. The cutdown source data is stored in a temporary path -- once this is solid I'll work on moving it to geovista-data, and use that here (via pooch + the cache)

I'm hoping the docs build will succeed, and I'll check what it looks like...

[pp-mo]

Data coming here : https://github.com/bjlittle/geovista-data/pull/37

When that lands, I will update + take this out of draft.

[pp-mo]

Ok we now have a functioning example in the docs build, and I consider that ready to review.

However, there are some outstanding comments above, and we have some CI problems to address -- (not clear if those were all triggered by mergeback from main, or incomplete merges from the same ?)

[bjlittle]

@pp-mo The CI failures are due to image test failures.

All examples will automatically undergo image testing to ensure that they are not broken.

We simple need to add an expected image for the tests. I can do that for you, and then talk you through the steps so that you know next time.

Ultimately, such things will all be captured in developer documentation ... but we need to let the dust settle first before doing that 👍

[tkoyama010]

pre-commit.ci autofix

[bjlittle]

@tkoyama010 It's probably best to leave the author of the pull-request to merge the latest main branch changes into their branch, just incase it breaks things for them.

We can always ask them to do this at then end of a review before merging 👍

[tkoyama010]

@tkoyama010 It's probably best to leave the author of the pull-request to merge the latest main branch changes into their branch, just incase it breaks things for them.

We can always ask them to do this at then end of a review before merging 👍

Thanks. I didn't notice that.