cartopy/basemap pcolor plotting not working about proplot HOT 8 CLOSED

Actually it looks like the shapes don't match. With

print(data.TLONG.shape, data.TLAT.shape, data.T.shape)

I get the result (384, 320) (384, 320) (320, 384). What you want is one of the following:

ax.pcolorpoly(data.TLONG.T, data.TLAT.T, data.T) # from lat by lon to lon by lat
ax.pcolorpoly(data.TLONG, data.TLAT, data, rowmajor=True) # restores default matplotlib behavior, y-axis is on rows

However if you had matched your dimensions, you would have run into an actual bug that I just fixed.
I've only been using vector x and y coordinates, so when implementing the new convention that data arrays must be shaped "x-dimension by y-dimension" instead of the matplotlib default "y-dimension by x-dimension", I wasn't transposing the x and y coordinate arrays. See this commit: cb2ded1.

(I also fixed a few other bugs with some of the more finicky colormap features, and fixed some other issues with 2D coordinate arrays in 6df7dbf.)

from proplot.

@lukelbd, oops. I was getting errors with either data.T or data and I think I submitted the wrong one to you, but glad you caught the bug.

So, it's working now, but slow as ever (even without plot.nbsetup()). More cases for you for #4. Thanks for iterating on this difficult issue.

You can get the sample dataset at https://github.com/bradyrx/climpred if you'd like to reproduce it.

You can just run:

from climpred.loadutils import open_dataset
data = open_dataset('MPI-control-3D')

from proplot.

Sure is slow lol. Noticed that. And don't know what the deal is with that missing chunk of data :/.

Will get to the bottom of this.

Also just curious on your opinion -- do you think I should just get rid of that "x-dimension by y-dimension" thing? Maybe it's just more confusing than not, and after all since python is a row-major language the rightmost dimension is technically the "first" dimension. I think I wrote that part because I was used to Matlab's defaults (Matlab is column-major). I find my datasets are usually time by z by y by x, so I end up just transposing them before feeding them into the plot functions.

from proplot.

I respect where the idea comes from (and chuckled at your documentation of it), but I think it makes more sense in the reversed fashion. I.e., default to row-major and give a keyword flag to turn on column-major. If you develop a decent user base (which you should) I would imagine this would be more of a headache and issue-raising thing than it's worth.

from proplot.

Yeah you're probably right. And anyway that whole "x by y" argument comes out of math notation, which so happens to use the column-major convention... so it probably doesn't make much sense. Was one of the first features I developed after switching from Matlab, never thought about it much.

Good idea on keeping a flag for column-major order. Now the options are order='C' and order='F' to match the numpy convention, with 'C' being the default.

Here's the new commit: a383036

from proplot.

Whoops: That commit didn't work; this (efbf859) should fix it (...and without the print statement: 89d1f82).

from proplot.

@lukelbd,

Note that this is broken again. 2D coordinates plotting works with 6df7dbf, and a383036 (and is speedy with my current use case)

However it breaks on efbf859 and 89d1f82.

The error message is similar to before:

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-4-1311c8f0b51f> in <module>
      3                        proj='hammer', proj_kw={'lon_0':0},
      4                        basemap=False)
----> 5 ax.pcolorpoly(ds.TLONG, ds.TLAT, ds)

~/Desktop/ph_example/proplot/proplot/subplots.py in iterator(*args, **kwargs)
     66                 ret = []
     67                 for ax in self:
---> 68                     res = getattr(ax, attr)(*args, **kwargs)
     69                     if res is not None:
     70                         ret += [res]

~/Desktop/ph_example/proplot/proplot/base.py in decorator(order, *args, **kwargs)
    258                     x, y = utils.edges(x), utils.edges(y)
    259             elif Z.shape[1]!=xlen-1 or Z.shape[0]!=ylen-1:
--> 260                 raise ValueError(f'X ({"x".join(str(i) for i in x.shape)}) '
    261                         f'and Y ({"x".join(str(i) for i in y.shape)}) must correspond to '
    262                         f'ncolumns ({Z.shape[1]}) and nrows ({Z.shape[0]}) of Z, or its borders.')

ValueError: X (384x320) and Y (384x320) must correspond to ncolumns (320) and nrows (384) of Z, or its borders.

from proplot.

It should be fixed now... was just a dumb mistake. I had xlen, ylen = x.shape[0], y.shape[-1] in the _check_edges function instead of xlen, ylen = x.shape[-1], y.shape[0].

from proplot.