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

Vector support in bridge.Transform.from_points #676

Draft
wants to merge 18 commits into
base: main
Choose a base branch
from

Conversation

pp-mo
Copy link
Collaborator

@pp-mo pp-mo commented Jan 26, 2024

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:

  • provide suitable test data via geovista-data and pantry routine
  • provide example showing arrows plotting.
    because it's not too trivial, this probably wants demonstrate how to do some of these things ...
    • scale arrows or not (i.e. direction-only)
    • 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. Allow an additional dimension for data in geovista.Transform.from_1d etc. #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.

Copy link

welcome bot commented Jan 26, 2024

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

@tkoyama010
Copy link
Collaborator

pre-commit.ci autofix

@pp-mo
Copy link
Collaborator Author

pp-mo commented Jan 29, 2024

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.

@bjlittle bjlittle changed the title Vector frompoints Vector support in bridge.Transform.from_points Jan 29, 2024
Copy link
Collaborator

@stephenworsley stephenworsley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good so far, just a couple odd comments to make here.

zz = vectors[2] if n_vecs > 2 else np.zeros_like(xx)

if vectors_z_scaling is not None:
zz = zz * vectors_z_scaling
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that there is a case for vectors_to_cartesian to be used in other transforms like from_unstructured, would it be worth considering if this code (from line 659 to here) would be suitable to exist inside vectors_to_cartesian? It doesn't seem to me like this code is specific to from_1d and I don't believe there's anything here which wouldn't work with the other transforms from what I've seen of them.

Copy link
Collaborator Author

@pp-mo pp-mo Jan 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting...
I'm actually doubting right now whether we may not remove this keyword altogether, since it's so obvious how the user would do it.
I already removed an overall scaling operation for the same reason, and also because it can be done in the 'glyph' call.


Notes
-----
.. versionadded:: 0.?.?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this gets gets fixed once the PR is completed/approved.


"""
# TODO @pp-mo: Argument checking ???
lons, lats = (np.deg2rad(arr) for arr in lons_lats)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be outside the scope of this PR, but it occurs to me that the documentation of these functions could be a bit clearer on the fact that, unless a crs is specified, units are expected to be in degrees. Though I suppose this may be implicit in the default crs being WGS 84.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I felt that all the existing docs of Transform methods are missing any statement of this, so it just didn't seem an appropriate place to mention it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, not true I see : in the dosctring here for from_points, it does say that xs and ys are in crs units.
However, this routine absolutely will not work with non-latlon coordinates.
So perhaps I can improve on the checking for that ...

@pp-mo
Copy link
Collaborator Author

pp-mo commented Jan 30, 2024

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...

src/geovista/pantry/data.py Outdated Show resolved Hide resolved
@pp-mo
Copy link
Collaborator Author

pp-mo commented Jan 30, 2024

Data coming here : bjlittle/geovista-data#37

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

@github-actions github-actions bot added type: examples Auto-labelled for ex/*, example/* and examples/* branches type: cache Auto-labelled labels Jan 30, 2024
@pp-mo
Copy link
Collaborator Author

pp-mo commented Jan 30, 2024

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 ?)

@pp-mo pp-mo marked this pull request as ready for review January 30, 2024 17:32
@bjlittle
Copy link
Owner

bjlittle commented Jan 30, 2024

@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
Copy link
Collaborator

pre-commit.ci autofix

@bjlittle
Copy link
Owner

bjlittle commented Feb 5, 2024

@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
Copy link
Collaborator

@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.

@bjlittle bjlittle marked this pull request as draft February 9, 2024 22:13
@HGWright HGWright assigned bjlittle and unassigned pp-mo Jun 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: cache Auto-labelled type: examples Auto-labelled for ex/*, example/* and examples/* branches
Projects
Status: 🚧 Blocked
Development

Successfully merging this pull request may close these issues.

4 participants