[python #PXA-368178]: pcolormesh and contours are offset by half a grid cell?
- Subject: [python #PXA-368178]: pcolormesh and contours are offset by half a grid cell?
- Date: Tue, 20 Feb 2018 16:06:09 -0700
You are correct, there *is* an offset...for complicated reasons. Let me start
by pointing you to the docs for pcolor (pcolormesh is just a fast version of
So what that's saying is that you're *supposed* to be passing in the *corners*
of the grid cells, NOT the centers (that makes pcolor very useful for oddly
shaped grids, like radar data); for that to be the case, you need to be passing
in X and Y arrays that have an extra row and column compared to the data array.
Unfortunately (at least in my opinion), matplotlib copied some poor behavior
from MATLAB; if you pass in X, Y, and data arrays that have dimensions of
matching size, pcolor will silently drop the last row and column of the data
I wish it didn't do this, but alas, that's the behavior we have--blame MATLAB!
So to fix this properly, you need to convert the grid centers to grid edges;
I'm happy to help you work that out. Any chance the original data files have 1D
lons and lats?
> My treasured Unidata Python mavens,
> It seems like pcolormesh and contour are misaligned: the contours are on the
> lower left corners of the pixels. Apparently the contours agree with the map
> (Brian says), so itâs all about pcolormesh being offset.
> We have resorted to manually subtracting 0.5 degrees latitude, but it remains
> a discomfort:
> cf1= plt.pcolormesh((lon_2d-0.5), (lat_2d-0.5), pcp, cmap='Greens',
> norm=norm_global, transform=ccrs.PlateCarree())
> at https
> Any suggestions? Ring any bells?
Ticket ID: PXA-368178
Department: Support Python
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata
inquiry tracking system and then made publicly available through the web. If
you do not want to have your interactions made available in this way, you must
let us know in each email you send to us.