You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the coordinates of a Quadmesh, returned from pcolormesh, are not available to the end-user. They are stored internally in the coordinates attribute. This is an issue for Cartopy, when we need to know where the MPL calculated coordinates are located to know whether we should mask some cells for users.
Proposed fix
Add a .get_coordinates() method that returns the private attribute to Quadmesh. This would be minimally invasive, and only ensures that Cartopy isn't relying on a private attribute.
That would be fine with me. I only went with coordinates because that is what it is called internally :)
The other question is what we should return _coordinates is internally stored as shape (nx+1, ny+1, 2). That would be my preference, but there are a lot of legacy raveled data too so I could see [(nx+1)*(ny+1), 2] or similar forms.
Activity
dopplershift commentedon Sep 10, 2020
Should this instead be
get_xydata()to mirror the API name onLine2D?greglucas commentedon Sep 11, 2020
That would be fine with me. I only went with coordinates because that is what it is called internally :)
The other question is what we should return
_coordinatesis internally stored as shape (nx+1, ny+1, 2). That would be my preference, but there are a lot of legacy raveled data too so I could see [(nx+1)*(ny+1), 2] or similar forms.jklymak commentedon Sep 11, 2020
I'd return as x,y and x and y have shape
(nx+1, ny+1).greglucas commentedon Sep 11, 2020
get_xydatareturns (N, 2) apparently:matplotlib/lib/matplotlib/lines.py
Lines 1015 to 1021 in d9214de
Quadmesh
get_array()returns a flattened array (nx*ny, )Too many options :)
greglucas commentedon Sep 14, 2020
I just opened up #18472 with the basic implementation. I figured we can continue the discussion about the API under the review over there.