geom_sf() adds (empty) borders between adjacent polygons even with colour=NA

[chris31415926535]

geom_sf() now seems unable to plot filled polygons without any gap or border between them. Now it always adds a thin border (sometimes one pixel wide) between them.

What I expected, and what geom_sf() has done in the past (unfortunately I don't know the version), was to plot adjacent filled polygons without any space between them. This was possible, and it's helpful for plotting choropleths with many small regions. With borders between every region, it's very visually distracting.

I've looked through the docs, blogs, stackoverflow, etc., and the received wisdom is that setting colour=NA removes borders. And I guess it does, but previously the fill would go right out to the edge and now it does not.

Here is the code to reproduce the bug:

# overbuilt function to make a unit square
  st_square <- function(x, y) {
    sf::st_polygon(
      x = list(
        matrix(
          data = c(x, y, x, y + 1, x + 1, y + 1, x + 1, y, x, y),
          ncol = 2,
          byrow = TRUE
        )
      )
    )
  }

# create a set of 100x100 unit squares
  many_squares <- purrr::map(1:100, \(x) {
    purrr::map(1:100, \(y) {
      st_square(x, y)
    })
  }) |>
    unlist(recursive = FALSE) |>
    sf::st_sfc(crs = 32189)

# plot the squares filled with black and no colour. There should be lines between all of them
  many_squares |>
    ggplot2::ggplot() +
    ggplot2::geom_sf(fill = "black", colour = NA)

Image output:

Session info:

> sessionInfo()
R version 4.5.0 (2025-04-11)
Platform: x86_64-pc-linux-gnu
Running under: Ubuntu 22.04.5 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.10.0 
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.10.0  LAPACK version 3.10.0

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8   
 [6] LC_MESSAGES=en_US.UTF-8    LC_PAPER=en_US.UTF-8       LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

time zone: Etc/UTC
tzcode source: system (glibc)

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] ggplot2_4.0.1

loaded via a namespace (and not attached):
 [1] gtable_0.3.6       dplyr_1.1.4        compiler_4.5.0     maps_3.4.3         reprex_2.1.1       tidyselect_1.2.1   Rcpp_1.1.0        
 [8] clipr_0.8.0        unigd_0.1.2        systemfonts_1.1.0  scales_1.4.0       textshaping_0.4.0  R6_2.6.1           labeling_0.4.3    
[15] generics_0.1.3     classInt_0.4-11    sf_1.0-16          tibble_3.2.1       units_0.8-1        DBI_1.2.3          pillar_1.9.0      
[22] RColorBrewer_1.1-3 rlang_1.1.6        utf8_1.2.3         fs_1.6.6           S7_0.2.1           viridisLite_0.4.2  cli_3.6.5         
[29] withr_3.0.2        magrittr_2.0.4     class_7.3-23       grid_4.5.0         rstudioapi_0.14    lifecycle_1.0.4    vctrs_0.6.5       
[36] KernSmooth_2.23-26 proxy_0.4-27       glue_1.8.0         farver_2.1.2       ragg_1.3.3         httpgd_2.0.2       fansi_1.0.4       
[43] e1071_1.7-13       purrr_1.0.1        tools_4.5.0        pkgconfig_2.0.3   

[teunbrand]

Thanks for the report! This seems like an anti-aliasing artefact to me, which depends on the graphics device that is used to render the plot. The graphics devices are two steps removed from how ggplot2 works, with the {grid} package in between, so there isn't a lot that ggplot2 may do to influence the behaviour of graphics devices.

[chris31415926535]

Thanks! Not asking you to do my homework for me, but would you have any advice on where I could look next? I may be misunderstanding, but the issue also persists when I save the plot with ggplot2::ggsave() as a png, jpg, or even svg.

[EvaMaeRey]

Does doing color mapping same as fill mapping solve for your application - to close up the gaps?

library(ggplot2)
nc <- sf::st_read(system.file("shape/nc.shp", package = "sf"), quiet = TRUE)

ggplot(nc) +
  geom_sf(aes(fill = AREA))

last_plot() + 
  aes(color = AREA)

^{Created on 2026-01-16 with reprex v2.1.1}

[teunbrand]

I'm not sure if the grid-like polygons were merely an illustrative example or close to your real use case.
If you really do have a grid of evenly sized cells, wrangling the data to fit geom_raster() will likely get rid of the edge artefacts.
Alternatively, I recommend the approach indicated above, where you assign the fill value to the color aeshetic too, and set non-blank linetype and non-zero linewidth (like 0.3 is fine I suppose).

[chris31415926535]

This is very helpful!

My real use case is with geographic boundaries, but I set up the grid of perfect squares to convince myself it wasn't an issue related to projections or CRS transformations or slightly-mismatched boundaries in real-world datasets.

@EvaMaeRey I was also testing with the nc dataset before creating the squares, and if you look at the example you posted above you can see that there are still faint lines between similar regions. It looks okay for this dataset, but I have a big dataset with lots of tiny regions (map of Ontario using the smallest census region) and I'm trying to prepare a figure for a publication, and in my case the faint outlines drown out the fill in large cities.

So I guess the answer is to set colour and fill aesthetics to be the same, and then to experiment with linewidth and file export options until the results look good?

Thanks for your help and your work on this great package 🙂

[Breeze-Hu]

Is this related to the choice of rendering engine? Cairo seems to be performing better.

I'm encountering anti-aliasing artifact in the raster data.
eliocamp/ggnewscale#77 (comment)

[chris31415926535]

@Breeze-Hu THANK YOU! I couldn't get a big difference from different devices, but @teunbrand 's comment here gives the best solution I've found, which is to use this mapping in geom_sf():

 ggplot2::geom_sf(
    mapping = ggplot2::aes(fill = .data$fill_var,
    colour = ggplot2::after_scale(fill), linewidth = I(0.3)
    ) 

For clarity, fill_var is the column in your data you want to use and should be changed for your use case, but fill in ggplot2::after_scale(fill) is magic and should not be changed 🙂

I can't attach the data here, but here's simplified code with examples showing the problem before, and the better output after:

Setting colour = NA gives lots of unsightly borders:

The borders are especially obvious in the top part of the plot where there are many small regions.

theplot <-  ggplot2::ggplot(data = my_data) +
    ggplot2::geom_sf(
    mapping = ggplot2::aes(fill = .data$fill_var),
    colour = NA
    ) # + other styling & scaling omitted here

ggplot2::ggsave(theplot, filename = "test_colourna.png", height=4, width=6, dpi=300)

Using ggplot2::after_scale with linewidth = I(0.3) fixes the problem:

 ggplot2::ggplot(data = my_data) +
    ggplot2::geom_sf(
    mapping = ggplot2::aes(fill = .data$fill_var,
    colour = ggplot2::after_scale(fill), linewidth = I(0.3)
    )  # + other styling & scaling omitted here

ggplot2::ggsave(theplot, filename = "test_afterscale.png", height=4, width=6, dpi=300)

I had been trying other linewidths and colours, but this is by far better.

I believe this last result is very close to what colour = NA used to give. I say this without knowing quite what's involved, but it might be worth making this the actual result when setting colour = NA, or otherwise letting folks know that this is the preferred way to plot filled regions with invisible boundaries.

[Breeze-Hu]

Thank you for the additional details! This method is indeed effective at present.