pcolormesh bug: edgecolor ignored

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()

@bblay

@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.

Note the difference: "edgecolor" and "edgecolors"

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".

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.

@mdboom

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.

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.

punting (again)

@pelson

@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.

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.

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

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.

Navigation Menu

Repository navigation

pcolormesh bug: edgecolor ignored #1302

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

pcolormesh bug: edgecolor ignored #1302

Description

Activity

dmcdougall commented on Sep 24, 2012

WeatherGod commented on Sep 24, 2012

WeatherGod commented on Sep 24, 2012

WeatherGod commented on Sep 24, 2012

pelson commented on Sep 25, 2012

tacaswell commented on Jan 16, 2014

tacaswell commented on Apr 27, 2014

efiring commented on Apr 27, 2014

pelson commented on Apr 28, 2014

doylejg commented on Nov 27, 2015

efiring commented on Nov 27, 2015

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions