Fixed bug in find_nearest_contour

[andrew-fennell]

PR Summary

The find_nearest_contour function was defined incorrectly. I fixed the bug and added a simple test, based on the original issues test.

Thank you @jhelmboldt for finding this issue and offering a solution to it.

Closes #22762

PR Checklist

Tests and Styling

• Has pytest style unit tests (and pytest passes).
• Is Flake 8 compliant (install flake8-docstrings and run flake8 --docstring-convention=all).

[oscargus]

Power cycling to trigger the tests.

[andrew-fennell]

I think this PR is ready for further review.

Let me know if any changes need to be made to the testing.

[tacaswell]

I have a slight preference to change this to

Suggested change

	indices = range(len(self.layers))
	indices = range(len(self.collections))

as that is the data structure that we need to match?

[andrew-fennell]

I think this change makes sense. I outlined some issues below that I'd like you to look at.

[tacaswell]

I have not chased this through enough to answer this my self, but is this method implemented in a way that makes sense for filled contours? With line contours you know that each path is at the same level and lines never intersect. With a filled contour the whole patch is "at the same level" with discontinuities at the boundaries (that is there are two patches that share and edge that are different values).

In the case of filled shouldn't we be saying "which collection does this fall in?" instead?

[andrew-fennell]

is this method implemented in a way that makes sense for filled contours?

Upon further testing, I'm not sure that the current function is a completely suitable for filled contours. Regardless of the indices being defined by then length of layers/collections.

I marked the input point and the output point (of the nearest contour) on each of the following filled contour examples with a red dot.

Is this expected behavior of this function? The output for line contours makes logical sense, but the 3rd example shows (from my understanding) that this method isn't working on filled contours.

Test 1 - Good

Filled contour, where point given is not on a layer:

Call: contourf.find_nearest_contour(1.5, 7, pixel=False)
Output: (2, 1, 3, 2.3, 7.4, 0.7999999999999999)

Test 2 - Good

Filled contour, where point given is on a layer:

Call: contourf.find_nearest_contour(3.6, 8.8, pixel=False)
Output: (2, 1, 3, 2.3, 7.4, 0.7999999999999999)

Test 3 - Bad

This all fails on a plot like this though:

Call: contourf.find_nearest_contour(1,1,pixel=False)
Output: (0, 0, 57, 1.3436129813210376, 0.13677814070781982, 0.8632218592921803)

[andrew-fennell]

If this function should only support contour (line contours), it should probably be documented that way.

#22762 highlights that currently, when the function is called on contourf (filled contours) it crashes. That would be fixed with this PR, but I'm not convinced the outputs are correct in every situation.

[QuLogic]

Sorry, didn't see @tacaswell's additional questions; I won't merge until he's satisfied with the answers.

[jklymak]

I am not sure what use there is in choosing the nearest "contour" on a filled contour. My tendency would be to raise on contourf collections and if users need to know the "nearest contour" they can make an unfilled contour to go with the filled one (perhaps hiding it if they don't want itvnisually there).

[tacaswell]

The consensus of the discussion is that the correct fix here is to :

• document that this only works on unfilled contours
• make it raise a better error on filled contours

[andrew-fennell]

I agree with the consensus! Thanks for all of the input.

I will make these changes soon. I need to get through a few other things first.

Completely different approach now.

[QuLogic]

@meeseeksdev backport to v3.5.x