Waiting to see what kind of destruction this wreaks upon our suite of image tests...

And for the historians, the previous implementation came in with 15a35dc and is the original, predating matplotlib 0.98.4.

In Cartopy, we used np.isclose(path_verts[0, :], path_verts[1:, :], rtol=1e-10, atol=1e-13) because those tolerances match Matplotlib's path tolerances ffaf302; we probably want to use that here too, for consistency.

Can we instead fix the contour generator to make it output exactly matching endpoints for contour lines? (AFAICT this is not intended as a general purpose function, but only to detect whether contour lines are closed)
Edit: Indeed, I would like to see a case where the contour generator does does not generate an exactly closed curve.

@anntzer This issue has held up a bugfix release for me for over a month (trying to get passing tests), so I'm not inclined to search for the pure solution right now, nor am I likely to have cycles any time soon to do so. Then again, I've now already monkey-patched this (internal 😬) function in my MetPy tests, so maybe it doesn't matter.

For reference, here's a sample where it makes a difference--stock matplotlib:

With my change:

The change is in the closed 268 contour a third-ways from the right side of the image centered vertically, over Kansas and Oklahoma.

I'll also note that this really only matters in practicality because the inline labelling algorithm takes a different approach for closed vs. open contours. In fact, that function is only used in the process of generating labels, nowhere else.

Updated to use tighter tolerances as suggested by @QuLogic. Also now using np.allclose as suggested by @jklymak and @timhoffm .

fair enough