feature request: option to avoid leader line crosses and/or label overlaps

[danstrobridge-Weston]

Hi there. I love your package and have been using it for years. I'd like to use it for a non-traditional application though.

I don't have a reprex, but have attached a simple pdf that is illustrative of my request. My job often requires me to make "table maps" (aka. chembox or callout table maps) that are ugly but, unfortunately, are also a regulatory requirement. We essentially build small tables from data associated with a given location and then try to squeeze these "table labels" into the blank spaces between the locations. I've developed R code that builds them as sf objects and then exports them shapefiles for use in GIS so that I can at least apply conditional formatting (e.g heatmap) to make them slightly more useful and less ugly.

My code makes an attempt to "spread" the tables by pushing them toward the centroids of a Thiessen/Voronoi tesselation of the points. However, I'd like to upgrade my code to use a ggrepel-like approach. My initial thought was to simply build a placeholder "stacked label" (as in the attached pdf) and pump it through ggplot with geom_label_repel. The various pages in this pdf show the results using different values for the force argument. This approach would require me to somehow extract the ggrepel anchor points for the labels and attach those to my input dataframe for moving the sf objects. I'm assuming this can be done but have not looked into exactly how at this point.

My main question/feature request is whether ggrepel has an argument (or would consider adding one) for preventing both: a) leader line crossings, and b) overlaps between the leader lines and the labels. With shorter labels, I'm assuming the label box rarely overlaps its own (or other) leader lines. This is a common phenomenon with "table labels" though. In the example attached, all the tables are the same size, but that's not always the case. I've been thinking on different strategies for identifying placement voids by size and prioritizing placement of larger tables first, but I'd like to see if ggrepel can solve my problem faster/easier first.

As an alternative to making these stacked labels as placeholders for my actual sf objects, I was wondering if there's a way to simply specify the dimensions (height and width) of the labels to be placed using fields that aggregate the data for a given location into box sizes (both in page inches and real-world dimensions based on the reference scale of the map).

ggrepeltest.pdf

[slowkow]

Thanks for the kind words, and thanks for opening an issue! I tried to reply to each point:

My main question/feature request is whether ggrepel has an argument (or would consider adding one) for preventing both: a) leader line crossings, and b) overlaps between the leader lines and the labels.

This sounds like issues we've previously discussed in #110 (follow the links to other related issues). In short, I don't know how to solve this problem but I'm willing to review pull requests from any contributors who'd like to try! There might be a way... but I am not sure.

This approach would require me to somehow extract the ggrepel anchor points for the labels and attach those to my input dataframe for moving the sf objects. I'm assuming this can be done but have not looked into exactly how at this point.

If I understand correctly, you would like to repel arbitrary grobs from each other, not just text labels. That way, whatever is inside the grob (table, pie chart, other graphics) would be repelled away from other grobs. I think it should be possible to modify ggrepel to do this, and there are some examples in #24 that are related to this. I think it'd be very interesting to make something like geom_grob_repel() where you can specify your own list of grobs. Pull requests are more than welcome, because I likely won't have time for this.

By the way, after glancing at your attachment, I might suggest trying to increase the number of iterations for the physical simulation with geom_label_repel(..., max.iter = 1e5, max.time = 0.5, verbose = TRUE) to improve the layout a little bit. Instead of the default values 1e5 (iterations) and 0.5 (seconds) you might try 2e5 or 3e5 iterations and 2 or 3 seconds (or higher numbers if you have patience). The verbose option might help to see whether the physical repulsion simulation is working. I have a hunch that this might slightly improve the placements for some of the labels, but it will not resolve the label/line intersections.

[danstrobridge-Weston]

Thanks so much for your consideration. I will employ your suggestions re: repel options and review your referenced prior requests to see if they provide further insights. Even if these strategies don't yield perfect results, they are certainly much better than my prior attempts with code of my own. I'll investigate the gginnards package to see if it will help me with extracting anchor points.