Error when combine `facet_wrap` with `coord_radial`

[Yunuuuu]

---

I found a problem with facet_wrap and coord_radial

Here is the code to reproduce the bug:

library(ggplot2)
ggplot(mtcars, aes(disp, mpg)) +
    geom_point() +
    facet_wrap(
        vars(cyl),
        nrow = 1L, scales = "free_x", space = "free_x",
        strip.position = "top"
    ) +
    coord_radial(start = -0.4 * pi, end = 0.4 * pi, inner.radius = 0.3)
#> Error in vapply(idx, function(i) diff(ranges[[i]]$x.range), numeric(1)): values must be length 1,
#>  but FUN(X[[1]]) result is length 0

^{Created on 2025-03-13 with reprex v2.1.0}

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.4.2 (2024-10-31)
#>  os       Ubuntu 24.04.1 LTS
#>  system   x86_64, linux-gnu
#>  ui       X11
#>  language en
#>  collate  C.UTF-8
#>  ctype    C.UTF-8
#>  tz       Asia/Shanghai
#>  date     2025-03-13
#>  pandoc   3.1.3 @ /usr/bin/ (via rmarkdown)
#> 
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version    date (UTC) lib source
#>  cli           3.6.3      2024-06-21 [1] CRAN (R 4.4.0)
#>  colorspace    2.1-1      2024-07-26 [1] CRAN (R 4.4.2)
#>  digest        0.6.37     2024-08-19 [1] CRAN (R 4.4.2)
#>  dplyr         1.1.4      2023-11-17 [1] CRAN (R 4.4.0)
#>  evaluate      1.0.1      2024-10-10 [1] CRAN (R 4.4.2)
#>  fansi         1.0.6      2023-12-08 [1] CRAN (R 4.4.0)
#>  farver        2.1.2      2024-05-13 [1] CRAN (R 4.4.0)
#>  fastmap       1.2.0      2024-05-15 [1] CRAN (R 4.4.0)
#>  fs            1.6.5      2024-10-30 [1] CRAN (R 4.4.2)
#>  generics      0.1.3      2022-07-05 [1] CRAN (R 4.4.0)
#>  ggplot2     * 3.5.1.9000 2025-03-12 [1] Github (tidyverse/ggplot2@1800a9a)
#>  glue          1.8.0      2024-09-30 [1] CRAN (R 4.4.2)
#>  gtable        0.3.6      2024-10-25 [1] CRAN (R 4.4.2)
#>  htmltools     0.5.8.1    2024-04-04 [1] CRAN (R 4.4.0)
#>  knitr         1.49       2024-11-08 [1] CRAN (R 4.4.2)
#>  labeling      0.4.3      2023-08-29 [1] CRAN (R 4.4.0)
#>  lifecycle     1.0.4      2023-11-07 [1] CRAN (R 4.4.0)
#>  magrittr      2.0.3      2022-03-30 [1] CRAN (R 4.4.0)
#>  munsell       0.5.1      2024-04-01 [1] CRAN (R 4.4.0)
#>  pillar        1.9.0      2023-03-22 [1] CRAN (R 4.4.0)
#>  pkgconfig     2.0.3      2019-09-22 [1] CRAN (R 4.4.0)
#>  purrr         1.0.2      2023-08-10 [1] CRAN (R 4.4.0)
#>  R.cache       0.16.0     2022-07-21 [1] CRAN (R 4.4.0)
#>  R.methodsS3   1.8.2      2022-06-13 [1] CRAN (R 4.4.0)
#>  R.oo          1.26.0     2024-01-24 [1] CRAN (R 4.4.0)
#>  R.utils       2.12.3     2023-11-18 [1] CRAN (R 4.4.0)
#>  R6            2.5.1      2021-08-19 [1] CRAN (R 4.4.0)
#>  reprex        2.1.0      2024-01-11 [1] CRAN (R 4.4.0)
#>  rlang         1.1.4      2024-06-04 [1] CRAN (R 4.4.0)
#>  rmarkdown     2.29       2024-11-04 [1] CRAN (R 4.4.2)
#>  scales        1.3.0      2023-11-28 [1] CRAN (R 4.4.2)
#>  sessioninfo   1.2.2      2021-12-06 [1] CRAN (R 4.4.0)
#>  styler        1.10.3     2024-04-07 [1] CRAN (R 4.4.0)
#>  tibble        3.2.1      2023-03-20 [1] CRAN (R 4.4.0)
#>  tidyselect    1.2.1      2024-03-11 [1] CRAN (R 4.4.0)
#>  utf8          1.2.4      2023-10-22 [1] CRAN (R 4.4.0)
#>  vctrs         0.6.5      2023-12-01 [1] CRAN (R 4.4.0)
#>  withr         3.0.2      2024-10-28 [1] CRAN (R 4.4.2)
#>  xfun          0.49       2024-10-31 [1] CRAN (R 4.4.2)
#>  yaml          2.3.10     2024-07-26 [1] CRAN (R 4.4.2)
#> 
#>  [1] /home/yun/Rlibrary/4.4
#>  [2] /usr/local/lib/R/site-library
#>  [3] /usr/lib/R/site-library
#>  [4] /usr/lib/R/library
#> 
#> ──────────────────────────────────────────────────────────────────────────────

[Yunuuuu]

It seems we should add following codes before passing the ranges to the $init_gtable() method when detecting a CoordRadial

ranges <- lapply(ranges, function(range) {
            switch(coord$theta,
                x = rename(
                    range,
                    c(theta.range = "x.range", r.range = "y.range")
                ),
                y = rename(
                    range,
                    c(theta.range = "y.range", r.range = "x.range")
                )
            )
})

But I don't know where is the best place

[aboudiallo21]

Hello. I am new to the package and together with @ChirraneZakariya and under the supervision of @katossky we are willing to solve this issue, as part of an assignment at the ENSAI school of statistical engineering (France). We have read trend figure in readme and we will try to be as autonomous as possible but we may ask for guidance from now and then. We have a solid background in statistics and a reasonable one in computer science. If any maintainer thinks this issue is too ambitious for a beginner, please tell us so and - if you have time - guide us to a project / issue were our help may be more useful.

[teunbrand]

We're happy to receive contributions on this issue. The issue doesn't strike me as the most beginner friendly at a first impression, but whether the issue is too ambitious is hard to tell without playing around with it. Of course you're welcome to try!

Re @Yunuuuu's proposed solution: that would make sense for Cartesian coordinates, but the panel aspect ratio for polar coordinates is not dependent on the x/y ranges, but on the bounding box around the arc.

[teunbrand]

I'm also a little bit unsure what space = "free_x" would mean for polar coordinates. Of course it shouldn't throw an error, but what exactly is being requested here?

[aboudiallo21]

Alright, thanks! We'll start working on this shortly, and we're excited to contribute.

[Yunuuuu]

Thanks, @teunbrand I'm working on this feature #6262 based on the implement of FacetWrap, I want the theta in each panel to depend on the range of the x-axis, so I added the argment space = "free_x" (Although I won’t use the $draw_panels method in FacetWrap that triggers this error, I ran it for comparison with the new facet I’m developing)

After further testing, I found I can still reproduce the figure above even without this argument (Haha, thanks!).

@aboudiallo21, I also really appreciate your enthusiasm in tackling this issue!

[teunbrand]

@aboudiallo21 I think I found a solution for this issue. Are you still interested in preparing a PR? If you still are, do you want to puzzle around and find a solution yourself or do you want me to suggest a solution I found?