I think you might have found a bug (but your solution wouldn't be technically correct, however). Looks like we create a list of indices based on the length of the internal "levels" array. But it is the internal "cvalues" that actually gets used. These don't have to be the same size.

The cvalues change is fine, but the real problem here is that clabel is fundamentally only for line contours, not for filled contours. clabel needs to trap and report that as an error condition. That can be handled in a separate pull request.

The main problem I see with this pull request is that the hatching does not extend to the colorbar. It looks like changing that would be very difficult; it is not just a matter of the colorbar grabbing a hatch attribute from the ContourSet, because hatching is implemented through the Collection, and Colorbar is using pcolormesh, not a set of collections. Although it could do so, in principle, as a special case, that would add quite a bit more complexity to an already-complex object.

So, how important is the hatch functionality for filled contours?
If it is important enough to add, then how bad is it to have it absent from the Colorbar?
And, will adding a hatch option to filled contours simply trigger a flood of complaints that the hatching is not sufficiently customizable, say as to line thickness, density, etc?

So, how important is the hatch functionality for filled contours?

It is useful for grayscale paper publication. Others have asked for such functionality in the past:

• http://old.nabble.com/cross-hatching-in-contours--td32471646.html
• http://old.nabble.com/Fill-Patterns-in-matplotlib--td3329389.html

As you pointed out, it seems that there would be value in providing capability to produce a colorbar with hatching too, but this wasn't trivial due to the use of pcolormesh in Colorbar. Additionally I looked at the potential for adding a legend for a given ContourSet (since typically n levels is very low with hatching), but there seems to be a limitation of one legend entry per object (there may be workarounds for this, but I didn't find them too quickly).

I would be happy to look into a Collection colorbar for this case, but while I am at it, it seems to me that a Collection is a better fit for implementing a colorbar, where n is sufficiently small, in all cases. Before I go ahead and make any changes, do you have any thoughts on that?

In the contourf_demo, it probably would be better to use a separate figure to illustrate the hatching, with no colorbar, and with colors=('none',) to illustrate hatching alone on a white background.

Regarding a colorbar and/or legend:

1. I think that the legend can be handled with proxy artists, so you could use patch.Rectangle.
2. It does look like it would not be too difficult or disruptive to allow the colorbar to be drawn with a collection. The boundaries could be extracted using a helper like _edges. I think I would be inclined to have it use that mode only when it needs to, that is, when there is hatching, rather than have it switch based on the number of colors.

Crazy thought... What if we merely considered a colorbar to be a pcolomesh with hatching on top? But, by default, the hatchings are blank?

As with all good reviews, your recommended changes sucked me in to implement the colorbar and legend capabilities.
I think the two new examples are looking great (obviously biased!)...

I think I would be inclined to have it use that mode only when it needs to, that is, when there is hatching, rather than have it switch based on the number of colors.

I followed this approach, although should we change our minds (now or in the future) it is a trivial, and hopefully non-intrusive, change to always produce a ColorbarPatch for contoursets.

As far as I can see, I have one remaining action to document which backends currently support hatching. I will implement this shortly. Any other issues, please let me know.

Thanks,

I merged your changes and added a few cleanups in ec1cd25.

| I merged your changes and added a few cleanups in ec1cd25.

Your changes make good sense and am pleased that this has made it onto master.
Thanks Eric.