-
Notifications
You must be signed in to change notification settings - Fork 26
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
base: main
Are you sure you want to change the base?
Conversation
🚀 Awesome! Your first pull request! Thanks for contributing to |
pre-commit.ci autofix |
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 :
Another common need will be to threshold the mesh before calling 'glyph', to reduce the size of the results. So now I'm aiming to write an example to demonstrate how these various controls work together. |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
src/geovista/common.py
Outdated
|
||
Notes | ||
----- | ||
.. versionadded:: 0.?.? |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 ...
Update :Added a draft code example. I'm hoping the docs build will succeed, and I'll check what it looks like... |
Data coming here : bjlittle/geovista-data#37 When that lands, I will update + take this out of draft. |
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, |
@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 👍 |
pre-commit.ci autofix |
for more information, see https://pre-commit.ci
@tkoyama010 It's probably best to leave the author of the pull-request to merge the latest We can always ask them to do this at then end of a review before merging 👍 |
Thanks. I didn't notice that. |
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:
because it's not too trivial, this probably wants demonstrate how to do some of these things ...
colour arrows by scale (or not)(not needed ?)filter out missing points(not needed?)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.