Pcolormesh update for interpolation with wrapped coordinates #1646
Conversation
greglucas
force-pushed
the
pcolormesh_updates
branch
from
a8badb6 to
5d8644c
Compare
| args = (X, Y, args[2]) | ||
| return args | ||
|
|
||
| def _wrap_quadmesh(self, collection, **kwargs): |
There was a problem hiding this comment.
This looks nice - is it clear that it covers changing the central longitude while preserving as much data as possible?
There was a problem hiding this comment.
Good question. central_longitude or any center point shouldn't come into play here. This "wrapping" function works on the transformed coordinates, identifying when those are large, so, just how wide the x_limits are to identify the masked areas.
For the other new function to do the edge interpolation:
We are identifying which direction the subtraction should be with the modulo arithmetic. i.e. is 1 -> 359 a difference of 358 or 2. Before it was 358 and a large jump, now we're saying it is 2. So again, no worries about central longitude. The central longitude is handled in the CRS/PROJ routines.
|
I think this is a pretty important PR to get in if anyone has the time for a review on it. |
|
This looks good and does solve my issue. |
greglucas
force-pushed
the
pcolormesh_updates
branch
from
5d8644c to
f70e61f
Compare
|
Yeah, I was hoping to get this in the last release :( The new shading will be the default in MPL 3.5, so it would be good to get a fix in for the next release. This needs a review from someone on @SciTools/cartopy-devs still. |
|
Could you merge master/ rebase so I can test if #1845 would be solved by this? |
greglucas
force-pushed
the
pcolormesh_updates
branch
from
f70e61f to
da22d67
Compare
|
@mathause, I just rebased this, but I think your issue was a separate bug! |
greglucas
force-pushed
the
pcolormesh_updates
branch
from
da22d67 to
1297f01
Compare
|
@QuLogic, I would also call this a critical update to get in before MPL 3.5. It removes the QuadMesh constructor calls, which were changed in 3.5 and throw a lot of warnings because of that. This defers all of that creation to MPL's pcolormesh instead. |
greglucas
force-pushed
the
pcolormesh_updates
branch
from
1297f01 to
d8902d9
Compare
This removes building the Quadmesh within Cartopy and pushes that up to Matplotlib directly. It also adds the logic to wrap the Quadmesh cells as a Cartopy specific private method that is called after the Quadmesh is generated.
MPL 3.3 added a new interpolation routine to automatically create edges for the grids when the input X/Y are the same shape as the color data. This causes issues with map data due to the possiblity of jumps in the coordinate arrays. This adds a modulo wrap to the input arguments to do the interpolation in Cartopy before sending the arguments on to Matplotlib.
Moves the list of wrappable projections up into the Projection classes as a private attribute.
greglucas
force-pushed
the
pcolormesh_updates
branch
2 times, most recently
from
cc0a3ef to
8d214a5
Compare
greglucas
force-pushed
the
pcolormesh_updates
branch
from
8d214a5 to
6272f9e
Compare
Fixes #1638
Rationale
The new shading keyword argument in MPL 3.3 causes an interpolation that creates new edges. With coordinates that could potentially be wrapped, as in map projections, this could cause new erroneous interpolation points to be inserted into the coordinates.
Implications
A big refactor of pcolormesh to avoid calling private MPL functions. We still have to use the private
_coordinatesQuadmesh attribute to get the coordinates, I couldn't find a way around that for now.We also now calculate some edges in Cartopy, meaning more code to maintain.