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

FIX: Change PlateCarree vector handling #1920

Closed
wants to merge 1 commit into from

Conversation

greglucas
Copy link
Contributor

If a PlateCarree projection is used for transforming vectors, users likely have their data in longitude/latitude for the locations and the measurement of the field is in North/South. To handle this situation with PlateCarree requires an additional scaling by the latitude of the point. This also requires some additional care for handling points near the pole when applying this scaling.

I haven't updated the image tests yet, as I thought it might be easiest to leave them failing for now so people can download the diff and see what they look like. Overall, I think this is an improvement, but it comes at the cost of special-casing the PlateCarree transform. We could also add a keyword argument 'latlon=True', or something similar to keep this as an opt-in and not change any of the old behavior.

closes #1179

If a PlateCarree projection is used for transforming vectors, users
likely have their data in longitude/latitude for the locations and
the measurement of the field is in North/South. To handle this
situation with PlateCarree requires an additional scaling by the
latitude of the point. This also requires some additional care
for handling points near the pole when applying this scaling.
@greglucas
Copy link
Contributor Author

Actually, I think this is currently wrong and I'm making a poor assumption here about the generality. I'm pretty sure the angles='uv' default case is working as expected and the only case that is actually not working as expected is the angles='xy', so I think that is where the fix needs to be applied/special-cased somehow. I'm going to close for now until I can think about this some more.

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

Successfully merging this pull request may close these issues.

Quiver with all projections: bad direction of arrows
1 participant