-
Notifications
You must be signed in to change notification settings - Fork 87
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
avoid crossing of the connector lines #182
Comments
How did you generate the picture above? At the moment there is no explicit way to have this constraint (and I don't see where in the ggrepel example it's explicitly set to avoid crossings? I think it just worked that way with the chosen arguments), but usually in practice there is a way to minimize the crossings... For example, if you switch off explode ( |
Thanks for your message.
|
Can you share your data and code? |
OK, the main solution is actually switching off the pull force in this case (the force that tries to pull the labels back to their original positions, often useful to make sure they don't end up too far from them), and finding the right value for force_text. This works well for me:
|
nice, however it seems that if the y axis is limited to the extend of the data i.e. 'ax.set_ylim(0, 105)' the crossing happens again. |
Yeah I guess that's because of ensure_inside_axes=True - it will force the labels outside axes limits inside the Axes, and then the crossing can occur. |
Or maybe there something else going on... Idk there is not specific mechanism to ensure this (yet - I have thought about adding something, but it's not trivial), so there is always tweaking involved, unfortunately. |
sure, no problem. thanks for your support. I think I'll relax the y-axis limits on my plots for now :-) ps: I'm not sure about the optimisation algorithm, but I was thinking in 1D application the constraint is to keep the order of distance from origin the same between the original and adjusted labels, and in 2D keep the order of distance (r) from origin and azimuth (alpha) the same. For example, in the figure below, the adjusted labels should satisfy the following conditions pps: maybe the midpoint (center of gravity) of labels is a better choice than origin .... |
Generally wider axes limits give more space and usually the result of label placement looks better. Seems like a nice idea, I'm not sure how to implement it with the current algorithm though... I was thinking something more naive like directly checking whether there are any overlaps between the lines connecting labels to their targets and if so, swapping the labels. It can get tricky since it's a lot of comparisons for all pairwise combinations, and there might be weird cases when more than two lines all overlap each other or smth... not sure how to deal with that, maybe a smarter approach like you suggest would work better... |
So I actually gave it a go, and I think it works... In the master branch the arrows shouldn't cross anymore, but it's not tested with complicated cases - i.e. not sure what will happen if multiple arrows all cross each. |
Thanks for both the question and script! This was super helpful. Quick question. Changing the angle of text breaks it though. Is there a way to prevent this? Couple examples:
|
Sorry for the late reply, I was on vacation. Did you install the version from github master branch to check the crossings? It's not perfect, but seems to generally work... Anyway, I am working on some improvements to that code too. For the second point - there is just not enough space in the plot to accommodate such tall labels! So it breaks down trying to push them out of the Axes, while also ensuring they are inside the Axes limits... The result could be better, but I think it's simply impossible to expect a good result from such a setup. |
(It's also possible something about rotated texts causes issues in general, it's not something I have tested...) |
Thanks for the response!
|
The code that explicitly removes overlaps is only available in the master branch so far, because it's very experimental. In this case since you limit movement to only Y axis, you need to increase the Y axis limits, not X. |
Ah, that makes sense! Thanks! |
is it possible to constrain the optimization further to avoid crossing of the connector lines? its practical application is shown below where the current setup (allowing to move along y only) dose not preserve the order of the original labels along the y direction.
ggrepel appears to have such a constraint?
https://ggrepel.slowkow.com/articles/examples#align-labels-on-the-left-or-right-edge
The text was updated successfully, but these errors were encountered: