Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUGFIX: This change fixes #2475, where contour labels added manually #2843

Merged
merged 4 commits into from Jul 10, 2014

Conversation

tacaswell
Copy link
Member

produce ugly spikes in the contours. The problem was that screen
coordinates were being passed as data coordinates when the contour was
split to add room for the label.

Incorporate @bwkeller fix and @miili's #2806 change

See long comment on #2818 for why this is the correct fix.

… manually

produce ugly spikes in the contours.  The problem was that screen
coordinates were being passed as data coordinates when the contour was
split to add room for the label.

Incorporate my fix and miili's matplotlib#2806 change
This exercises with input in both display and data units.
@tacaswell
Copy link
Member Author

This bug took far to long for me to understand.....

@tacaswell
Copy link
Member Author

fixes #2475

@tacaswell
Copy link
Member Author

@efiring @mdboom Can one of you take a look at this?

@efiring
Copy link
Member

efiring commented Apr 27, 2014

@tacaswell, as you noted, all this is hard to follow; but it looks plausible. Would it be worth adding a few brief comments to the code, while you are in the middle of it?
In looking at the test and test image, I wondered which labels are the ones being added. It seems like it should be possible to use the add_label_near() method to specify all of the labels one wants; in other words, it should be possible to tell clabel not to add any labels automatically or via manual clicking, so that all would be added via add_label_near(). I don't think this is possible now.

@tacaswell
Copy link
Member Author

I has been a while sense I looked at this so it would take me a while to sort out what was going on again.

I don't follow what you are asking about add_label_near, iirc, add_label_near is what both the interactive labels and clabel use to actually put the labels on the plot. The api on the transform kwargs is just a bit annoying.

@efiring
Copy link
Member

efiring commented Apr 27, 2014

My point is that add_label_near would be more useful if the whole clabel API would allow you to, for example, make your test image include only the labels that you explicitly added via your calls to add_label_near. This is not intended as a criticism of your PR; it is just that the test in your PR reveals a strange limitation of the clabel machinery.

@efiring
Copy link
Member

efiring commented Jun 3, 2014

@tacaswell, Since it looks like there will be no more 1.3.x releases, would you rebase this against master, please? I think it is important that this go into 1.4.

@tacaswell
Copy link
Member Author

I agree it should go in 1.4. I left it against 1.3.x just in case someone makes a good case that we should do a 1.3.2 and merging is easier for my brain than cherry-picking merges.

@@ -576,10 +576,7 @@ def add_label_near(self, x, y, inline=True, inline_spacing=5,
# be a vertex in the path. So, if it isn't, add a vertex here
paths = self.collections[conmin].get_paths()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if the path object from the collection has a different transform than what we are expecting? Otherwise, this all makes sense, albeit it could use some more commenting

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the assumption is that the points in the path are in data space as iirc everything returned by find_nearest_contour is working in screen space. The bug was in the case were you wanted to specify the location of the label in screen-units, but when the location never got converted back to data-space units when adding a point to the path which is what generated the huge spikes.

I think the issue you are bring up is if points in the path are not specified in data units so instead of self.ax.transData.inverted() in should be paths[segmin].get_transform().inverted()? Presumably that transform should be passed back in on line 585/582 when the new path is created.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that is exactly what my concern is. The transforms framework can have a lot of redundant parts, which can mask incorrect usage. We shouldn't assume that we know the transform of the path object, that is known only by the path object itself, so we should use it here.

Admittedly, my brain does mini-explosions reading through some of these code parts because I easily lose track of the coder's intent and expectation.

 - added some in-line comments to explain what is going on
@tacaswell
Copy link
Member Author

@WeatherGod Turns out Path objects don't know about transforms.

@efiring Added some explanatory comments

@@ -562,26 +562,38 @@ def add_label_near(self, x, y, inline=True, inline_spacing=5,
exact for labels at locations where the contour is
straight, less so for labels on curved contours.
"""

# if 'do the default thing' use the axes data transform
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this comment is not helping; the nearby docstring and the code are readable as they are.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second thought, the docstring could be made clearer:
"Add a label near the point (x, y). If transform is None (default), (x, y) is in data coordinates; if transform is False, (x, y) is in display coordinates; otherwise, the specified transform will be used to translate (x, y) into display coordinates."

Maybe something like that would be clearer.

disp_units = [(216, 177), (359, 290), (521, 406)]
data_units = [(-2, .5), (0, -1.5), (2.8, 1)]

CS.clabel()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to leave out this clabel call, so we could see the labels specified directly below?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember there was some reason that I I had this call first, but I don't remember what it was. The test shows the sum of the labels plus the ones added manually.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also note that the location of the added labels does not overlap with where the default labels are placed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, but from simply looking at the plot, or the code, I can't easily see which are which. Since you have verified that everything is in its place, this doesn't matter much; the test will still do its job.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will try to get to this today

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that the call to clabel sets up a bunch of data-structure that the add_label_near depends on.

@tacaswell
Copy link
Member Author

So, I have no idea what is going on with travis. 3.2 decided to install again and both of the 2.x decided they don't pass pep8 (but the 3.x's do).

efiring added a commit that referenced this pull request Jul 10, 2014
BUGFIX:  This change fixes #2475, where contour labels added manually
@efiring efiring merged commit d1d464c into matplotlib:v1.3.x Jul 10, 2014
@tacaswell tacaswell deleted the contour_fix branch July 11, 2014 00:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants