pcolormesh bug: edgecolor ignored

[bblay]

I believe the following code should produce grey edges but they have colour.

import numpy as np
import matplotlib.pyplot as plt

plt.pcolormesh(np.arange(12).reshape(4, 3), edgecolor='#888888', facecolor='none')
plt.show()

[dmcdougall]

@bblay Thanks for pointing this out.

pcolormesh(np.arange(12).reshape(4, 3), edgecolors='b', facecolor='g') produces faces that are not all green, but all the edges are blue.

[WeatherGod]

Note the difference: "edgecolor" and "edgecolors"

[WeatherGod]

In other words, the bug probably is that we aren't triggering an error for passing in "edgecolor", since the documentation states that it should be "edgecolors".

[WeatherGod]

Also, I would imagine that "facecolor" makes no sense for the pcolor family of functions, but that is just my own opinion. "facecolor" is not mentioned in the documentation for those functions, AFAICT.

[pelson]

Confirmed. The following code fails to produce a quadmesh with red edges:

c = plt.pcolormesh(np.arange(12).reshape(4, 3), edgecolors='red', facecolors='none')

(they are colored by the data).

Workaround:

c._is_stroked = False

There are some fundamental flaws with the way this has been implemented, and fixing them will break existing code.
It doesn't appear that this has worked since at least 1.0 (unable to test before then).

I suggest that this goes into the known bugs milestone for 1.2, and we address it in 1.3.

@mdboom & @efiring : I think you two have most exposure to the QuadMesh collection; do you agree with this, or would you like me to fix this and slip it in to 1.2? (I could have a PR ready in <24 hrs)

Full disclosure: @bblay and I are colleagues.

[tacaswell]

This is still an issue on master. Tagged an 1.4, but this is a candidate to slip to 1.5 as it never seems to have worked.

[tacaswell]

punting (again)

[efiring]

@pelson do you remember what your proposed fix was, and what it would break? And what were the "fundamental flaws"? I suspect we should have taken you up on your offer to generate a PR.

[pelson]

Unfortunately I don't. Logically it seems that an edgecolor of 'none', 'face', a specific color or an array are all supportable behaviour which should work. It might be worth investigating again and putting forward a proposed solution.

[doylejg]

Just confirming this bug in 1.4.3, has this been fixed in 1.5.0?

[efiring]

Both pcolormesh and pcolor use colormapping based on the input array for the edges when the facecolor='none', regardless of the setting of edgecolors. I note that 'facecolor' is not in the docstrings; it is simply being passed on the Collection. It sounds like the desired behavior would be for the facecolor='none' case to be trapped and used to defeat the colormapping of edges when edgecolors is also specified.