Made a test with the Mercator projection instead of north polar stereographic and the problem is the same. So I guess the problem is for all projections.

Confirming that the transform_vectors algorithm is based on "derivatives of source coordinate system". This is documented at https://scitools.org.uk/cartopy/docs/latest/crs/index.html#cartopy.crs.CRS.transform_vectors, though there is no doubt that it could be made even more explicit (your help would be greatly appreciated there).

I believe there are three cases:

• 1: We have x and y coords, and some u&v in a system invariant form
  • e.g. UTM x&y, with u and v in m/s in northward and eastward directions (which categorically are not aligned to the x and y axes of the projection)
  • we only want to transform x and y, and compute the new direction as a simple "new-Northward" rotation
• 2: We have x and y coords, and u&v giving a direction defined in the same coordinate system as x&y, but not the magnitude
  • e.g. longs & lats, with u and v in m/s in the direction of the projection (not necessarily northward and eastward)
  • we want to use the existing algorithm - it converts the direction, and preserves the original magnitude
• 3: We have x and y coords, and u&v giving a direction and magnitude defined in the same coordinate system as x&y
  • e.g. longs & lats, with u and v in degrees
  • we want to use the existing algorithm + compute the new length of the vector

cc @ajdawson as the original transform_vectors author.

In putting together the summary above, I had the following example:

src = ccrs.PlateCarree()
nx, ny = 6, 5
xs = np.linspace(*src.x_limits, nx+2)[1:-1]
ys = np.linspace(*src.y_limits, ny+2)[1:-1]

# u and v are in the x and y direction of src.
u = 5  # m/s, or some other non-src CRS bound system.
v = 0  # m/s

xs, ys = np.meshgrid(xs, ys)
us = np.tile(u, xs.shape)
vs = np.tile(v, ys.shape)

Which when visualised in the source CRS:

plt.figure(figsize=(10, 10))
ax = plt.axes(projection=src)
ax.coastlines()
ax.quiver(xs, ys, us, vs, angles="xy", color="red")

And in a projected CRS:

plt.figure(figsize=(10, 10))
ax = plt.axes(projection=ccrs.NorthPolarStereo(central_longitude=0))
ax.coastlines()
ax.quiver(xs, ys, us, vs, angles="xy", color="red", transform=src)

Reprojecting that case:

plt.figure(figsize=(10, 10))
ax = plt.axes(projection=ccrs.NorthPolarStereo(central_longitude=0))
ax.coastlines()
ax.quiver(xs, ys, us, vs, angles="xy", color="red", transform=src, regrid_shape=20)

It is quite clear that the magnitude of the vectors is preserved ref and that direction is based on the source grid.

I've thought over this some more, and now wonder if cases 1 and 2 are actually the same thing, and we are looking at a bug that is acute for this projection. In particular, I think the transform_vectors algorithm uses a forward difference to compute the rotation, but a central difference would provide a much better estimation.

Thank you for your answer. Maybe I am missing something in your line of thought but it seems to me that the example you have chosen does not illustrate the problem. The problem comes from the difference between the directions of (u /cos (latitude), v) and (u, v). So if you choose v = 0, there is no difference in direction. That is why I chose : u = -3, v =0.1 and latitude = 89°, in my post above.

Second, thanks for confirming that the transform_vectors algorithm is based on derivatives of source coordinate system. My point is then that I think the public interface of quiver with cartopy is very inconvenient. The majority of use cases of quiver in Cartopy is probably to plot a wind field in some projection, with the wind given by its eastward and northward components. In order to plot this wind field now in Cartopy, I have to do something like:

u_src_crs = u / np.cos(lat[:, np.newaxis] / 180 * np.pi)
v_src_crs = v
magnitude = ma.sqrt(u**2 + v**2)
magn_src_crs = ma.sqrt(u_src_crs**2 + v_src_crs**2)
ax.quiver(lon, lat, u_src_crs * magnitude / magn_src_crs, v_src_crs * magnitude / magn_src_crs,
                transform = src_crs)

I should not have to do all this just to plot a wind field. There should be a one-line command for this, included with cartopy.

+1 for simple way of plotting vectors with starting point given by lat & lon and direction and length given by geographic north & east components in some physical units. In my case this would be geomagnetic and geoelectric fields with north and east components of nT and mV/km respectively.

Ideally there would also be a boolean toggle to choose between making vector lengths depend only on the physical quantity (in addition automatic or user defined global scaling) or also depend on how far they seem to be located from the camera.

Did anyone ever resolve this or find a way of doing something like rotate_vector without Basemap? That was a pretty useful function but it's hard to use this without needing to define the projection with Basemap too...

Using the "angles" keyword in call to quiver seems to work fine.
Edit: using "angles" keyword, with array of angles in degrees seems to work fine.

I do not think it does in a convenient way : that is what I tried to show in submitting this issue. See the example in my post at the top of this issue.

I total agree with @lguez , the current user interface for vector rotation in Cartopy is inconvenient at the least. I don't think this issue is clearly documented so the first time users may not realize they need to rescale the u/v components (like @lguez's code above) before feeding the vectors into transform_vectors . This will end up with wrong vector maps. Can someone add a short example to showcase the correct way to rotate vectors to the documentation before there is a fix for this? I am sure I am not the only one trying to figure out why the wind maps look funny in the polar regions.

+1 for documentation on (optionally simple) way of plotting vectors with starting point given by lat & lon and direction and length given by geographic north & east components in some physical units

I definitely agree that this needs to be better documented at the very least. I would have continued to plot wind vectors in Antarctica incorrectly if I had not accidentally run across this post. In case anyone needs it, here's another example of the issue:

import cartopy.crs as ccrs
import cartopy.feature as cfeature
import numpy as np
from matplotlib import pyplot as plt

lat = np.array([[-87, -87, -87, -87, -87], [-82, -82, -82, -82, -82], [-77, -77, -77, -77, -77]])
lon = np.array([[0, 90, 180, -90, -180], [0, 90, 180, -90, -180], [0, 90, 180, -90, -180]])
u = np.array([[-3, -3, -3, -3, -3], [-3, -3, -3, -3, -3], [-3, -3, -3, -3, -3]]) # wind component pointing East
v = np.array([[0, .1, 1, 3, 1], [0, .1, 1, 3, 1], [0, .1, 1, 3, 1]]) # wind component pointing North

def plot_quiver(lon, lat, u, v):
    plt.figure()

    # Plot in South Polar Stereographic projection
    ax = plt.axes(projection = ccrs.SouthPolarStereo())
   
    # Set the extent of the plot
    ax.set_extent([-180, 180, -90, -65], crs = ccrs.PlateCarree())
    
    # Plot Antartic coastline for reference
    ax.add_feature(cfeature.COASTLINE)
    
    # Plot the arrows
    ax.quiver(lon, lat, u, v, transform = ccrs.PlateCarree(), angles = "xy")
    
    return

# Simply plot the data above without doing anything special
plot_quiver(lon, lat, u, v)

# Rotate and rescale the wind vectors using code from this GitHub issue
u_src_crs = u / np.cos(lat / 180 * np.pi)
v_src_crs = v
magnitude = np.sqrt(u**2 + v**2)
magn_src_crs = np.sqrt(u_src_crs**2 + v_src_crs**2)

plot_quiver(lon, lat, u_src_crs * magnitude / magn_src_crs, v_src_crs * magnitude / magn_src_crs)

The arrows at longitude 0 should point West.
The arrows at longitude 90 should point West and imperceptibly North.
The arrows at longitude 180 should point West and a little North.
The arrows at longitude 270 should point perfectly Northwest.

As you can see in the first figure, without the rotating and rescaling provided by Iguez, the arrows point in the wrong directions. With the rotation and rescaling, the arrows are correct (second figure).

I agree the current situation is less than ideal and there should be a way to handle this easier within Cartopy.

I opened #1920 with a proposed fix for this.

It has been 3 years and this problem still exists, I would like to know if there are plans to improve it in the future. Thank you in advance.

There is a linked PR with a proposed fix that no one has commented on: #1926

Glad I found this after beating my ahead against this for half a day. It looks like the fix is still pending, in the meantime the cartopy quiver doc could probably use an update. Not sure what the mechanism for this is.

I have the same problem. Have you resolved this problem?