Data wrangling is separate to plotting

ggauto is designed to choose the best chart type, based on the type of data that you have. That means that you need to pre-process your data into the correct type before plotting it. This is a requirement to make ggauto possible, but is more generally a good idea because it forces you to understand what your data is before you plot it.

Tasks like ordering data, converting to correct date formats, or computing summary statistics should be performed before passing into a plotting function from ggauto. For example, if you have data collected over years, encoded as numeric values 2021, 2022, and so on then you should either convert these to a category or a date object first.

ggauto also assumes that all data is in long format, and can currently create plots with up to three different variables.

Accessible default styling

The default styling for charts should be as accessible as possible. In terms of styling, the defaults differ from ggplot2 in the following ways:

• Colours:
  • Chart colours that are more likely to be accessible, using Paul Tol’s palettes.
  • The use of a white background (rather than grey) to improve contrast.
  • Combined use of either shapes or direct labels alongside colour to improve accessibility.
• Text:
  • Larger default text sizes
  • Text is aligned horizontally to improve readability, including axis titles and category labels.
  • Improved styling for title and subtitle, including automatic text wrapping for long text.
  • Some processing to default axis titles, to make them into sentence case instead of simply using column names.
• Axes:
  • Unless the data is a factor where a specific order is defined, categorical variables are arranged by magnitude instead of alphabetically.
  • For some chart types, if 0 is included in the range of the data, the axis is set to be symmetric about 0.

Some chart types are better than others

ggauto tries to choose the best chart type based on:

• the type of data e.g. continuous, discrete, or date
• the values in the data e.g. number of categories

There is no automatically perfect chart type for a given data type, but some are better than others. The main aim of ggauto is to make it easier to make better charts.

Visualising distributions

If you have only continuous variable and you want to visualise the distribution, for example:

penguins |>
  ggauto(bill_dep)

You can pass the data directly instead of using the pipe:

ggauto(penguins, bill_dep)

Or pass it in as a vector:

ggauto(penguins$bill_dep)

If you have multiple categories, and you want to visualise the distribution for each of them, i.e., you have one discrete variable, and one continuous variable, then multiple raincloud plots are produced.

penguins |>
  dplyr::filter(species == "Adelie") |>
  ggauto(island, flipper_len)

Visualising data over time

If you have a single variable to show over time, i.e., one date variable, and one continuous variable, a line chart is produced.

economics_long |>
  dplyr::filter(variable == "unemploy") |>
  ggauto(date, value)

If you need to show how multiple variables change over time, i.e., one date variable, continuous variable, and one discrete variable, the type of chart will depend on how many categories (unique values in the discrete variable) you have.

If you have 6 or fewer categories, a multi-line chart is created, with colours and symbols identifying the categories. Category labels are added at the end of each line automatically.

txhousing |>
  dplyr::filter(city %in% c("Houston", "Fort Worth", "San Antonio", "Austin")) |>
  dplyr::mutate(date = lubridate::ymd(paste0(year, "/", month, "/01"))) |>
  ggauto(date, sales, city)

If you have more than 6 categories, the plot type changes to a faceted line chart, with one category highlighted on each facet:

txhousing |>
  dplyr::filter(city %in% c(
    "Houston", "Fort Worth", "San Antonio", "Austin",
    "Bay Area", "Dallas", "Paris", "San Angelo"
  )) |>
  dplyr::mutate(date = lubridate::ymd(paste0(year, "/", month, "/01"))) |>
  ggauto(date, sales, city)

Visualising magnitudes and ranks

If you have a single discrete variable, a bar chart showing the counts of each category is created:

diamonds |>
  ggauto(cut)

If you have pre-computed the counts or some other summary statistics, i.e., if you have one discrete variable, and one continuous variable with only a single value for each discrete variable, a bar chart of the values is created:

diamonds |>
  dplyr::group_by(cut) |>
  dplyr::summarise(med_price = median(price)) |>
  ggauto(cut, med_price)

As you can see, when the discrete variable is a factor (i.e. cut), the desired order is respected. If the discrete variable is not a factor, the bars are ordered from highest to lowest instead of the default alphabetical ordering:

diamonds |>
  dplyr::group_by(cut) |>
  dplyr::summarise(med_price = median(price)) |>
  dplyr::mutate(cut = as.character(cut)) |>
  ggauto(cut, med_price)

There was a small bug in version 0.0.1 affecting the ordering of categorical variables. This has now been fixed in the development version as of 27 March, 2026.

If you have two discrete variables, then a heatmap is created showing the count of each combination of categories. Labels are added showing the count.

mpg |>
  dplyr::mutate(cyl = as.character(cyl)) |>
  ggauto(cyl, drv)

If there are more than 6 categories on either axis, labels are replaced with a legend:

txhousing |>
  dplyr::filter(median >= 150000, year >= 2005) |>
  dplyr::mutate(
    month = factor(month, levels = 1:12),
    year = factor(year, levels = 2005:2015)
  ) |>
  ggauto(month, year)

Again, if one or both of the discrete variables is a factor, then the order is respected. If not, the categories are ordered by magnitude (based on the sum).

txhousing |>
  dplyr::filter(median >= 150000, year >= 2005) |>
  dplyr::mutate(
    month = as.character(month),
    year = factor(year, levels = 2005:2015)
  ) |>
  ggauto(month, year)

If you have two discrete variables and a third continuous variable showing some summary statistic for each category combination, a heatmap showing that value is created. Labels are rounded to 2 decimal places.

mpg |>
  dplyr::mutate(cyl = as.character(cyl)) |>
  dplyr::group_by(cyl, drv) |>
  dplyr::summarise(mean_hwy = mean(hwy)) |>
  dplyr::ungroup() |>
  ggauto(cyl, drv, mean_hwy)

If there are multiple continuous values per combination of categories, an error is returned, asking you to first summarise the data:

mpg |>
  dplyr::mutate(cyl = as.character(cyl)) |>
  ggauto(cyl, drv, hwy)

Error in `ggauto()`:
! Too many values per category. Summarise data first.

Visualising correlation

To show the correlation between two continuous variables:

mpg |>
  ggauto(displ, hwy)

To show the correlation between two continuous variables, split by a third discrete variable, a scatter plot using colours and shapes is created:

mpg |>
  dplyr::mutate(cyl = as.factor(cyl)) |>
  ggauto(displ, hwy, cyl)

If you try to use more than 6 colours (categories), the chart type changes to a faceted scatter plot with one category highlighted on each facet:

mpg |>
  dplyr::mutate(cyl = as.factor(cyl)) |>
  ggauto(displ, hwy, manufacturer)

Scales

For scatter plots, raincloud plots, and line charts, one or both of the axes may be symmetric about 0 by default. This happens automatically when 0 exists in the range of values. Since the output of ggauto() is simply a ggplot2 chart, you can override this if you don’t want it:

set.seed(123)
plot_data <- data.frame(
  v1 = rnorm(50, 1)
)

ggauto(plot_data, v1) +
  scale_x_continuous()

Scale for x is already present.
Adding another scale for x, which will replace the existing scale.

You’ll get a warning to say you are replacing the existing scale which you can ignore because it’s what you’re trying to do! Similarly, you can edit the default colour/fill scales. However, the default palette is chosen to be accessible.

Text

You can a title, subtitle, caption, and labels with the labs() function in ggplot2 as you normally would, or directly using the same arguments in ggauto(). The latter is recommended as the arguments are used a little abnormally to implement the styling. You can add markdown formatting into the title, subtitle, or caption:

plot_data |>
  ggauto(v1,
    title = "Descriptive title goes here",
    subtitle = "More information about what's in the chart which can be a really, really long sentence that will wrap onto multiple lines automatically.",
    caption = "**Source**: where the data is from",
    xlab = "Nice variable name"
  )

By default, the x or y axis title is removed on chart types e.g. where the axis is a date or category and a further label stating that is unnecessary. Unless otherwise specified, the axis labels are clean versions of the column names where it’s parsed in sentence case, with underscores removed.

You can edit the size and family of the text using the base_size and base_family arguments. Other plot elements e.g. lines and points scale relative to the base_size as well.

Sizing

The first thing that jumps out at me in the default chart, is how thin the lines are and how that makes them quite difficult to see. The default font size is also quite small. Let’s increase the line width and font size. If we had points or bars in our chart, we would also want to increase the size of the points and the line width of the bar outlines.

theme_set(theme_grey(base_size = 16))
g <- ggplot(
  data = plot_data,
  mapping = aes(x = x, y = y, colour = category)
) +
  geom_line(linewidth = 2)
g

Problems resulting from small sizes for fonts and lines are often amplified when viewing charts on smaller screens e.g. on mobile. People shouldn’t have to zoom in to see your chart.

Colours

Let’s move on to thinking about the line colours. Ideally, we want the line colours to be distinguishable from each other, and also from the background.

The first thing we can check is whether the default colours are appropriate and accessible for people with colour vision deficiency. There are many different tools that you can use to simulate colour-blindness, both for palettes in general and for the way a chart might appear. A quick way to check whether your colours are likely to be colour-blind-friendly, is to see how the image would look printed in black and white. You can use simple image editing tools to desaturate the image, or if viewing in a browser use File -> Print to PDF.

Let’s see what our default colours look like in greyscale:

des <- function(c) colorspace::desaturate(c, severity = 1)
g_des <- colorblindr:::edit_colors(g, des)
plot(g_des)

Since all of the default colours are equally bright, in greyscale they look identical and there’s no way to tell apart the lines.

So how do you choose a good colour palette? There isn’t a single colour palette that is the best colour palette for everyone. For example, some people may require high contrast colours whilst other people may require lower contrast. However, some colour palettes are better than others.

There are a couple of good default options. The colours in the Okabe-Ito palette were chosen specifically to be distinguishable by those with the three frequent forms of colour-blindness. Since version 4.0.0, it’s been the default colour palette for base R plots. Paul Tol also introduced several colour-blind-friendly palettes, including high contrast options.

Let’s replace our default line chart colours with the Okabe-Ito palette. We’ll also remove the grey background from the chart and replace it with white to increase the contrast between the lines and the background.

theme_set(theme_minimal(base_size = 16))
g <- g + scale_colour_manual(values = okabeito)
g

I particularly like Viz Palette for evaluating colour palette options. It gives you some sample charts, and simulates how they are likely to look to people with different types of colour vision deficiency. The feature I appreciate the most is the report on how distinguishable colours are at different line widths. For example, colours may be okay for use in an area chart but not for a line chart.

Don’t rely on colour

Regardless of how well chosen you think your colours are, it’s important never to rely on them as the only method of distinguishing groups. When creating line charts, an easy way to improve the accessibility of your chart is to add category names to the end of each line as a direct label.

g <- g +
  geom_point(
    data = slice_max(plot_data, x),
    size = 4
  ) +
  new_scale_colour() +
  scale_colour_manual(values = new_palette) +
  geom_text(
    data = slice_max(plot_data, x),
    mapping = aes(label = category, colour = category),
    hjust = -0.1,
    size.unit = "pt",
    size = 14
  ) +
  scale_x_date(
    date_labels = "%b",
    breaks = seq(
      as.Date("01-01-2024", tryFormats = "%d-%m-%Y"),
      length.out = 4,
      by = "3 months"
    ),
    limits = c(
      as.Date("01-01-2024", tryFormats = "%d-%m-%Y"),
      as.Date("01-02-2025", tryFormats = "%d-%m-%Y")
    )
  ) +
  theme(legend.position = "none")
g

Now, we have a much more accessible chart. There’s still some more work we can do around chart text but before we do that, let’s double check if this approach to line charts is always sufficient.

Let’s say we have a second data set. It’s still the same type of data e.g. continuous observations for four categories over time. Surely the same chart type should work for the same data type? Let’s check.

g2 <- ggplot(
  data = plot_data2,
  mapping = aes(x = x, y = y, colour = category)
) +
  geom_line(linewidth = 2) +
  scale_colour_manual(values = okabeito, guide = "none") +
  scale_x_date(
    date_labels = "%b",
    breaks = seq(
      as.Date("01-01-2024", tryFormats = "%d-%m-%Y"),
      length.out = 4,
      by = "3 months"
    ),
    limits = c(
      as.Date("01-01-2024", tryFormats = "%d-%m-%Y"),
      as.Date("04-02-2025", tryFormats = "%d-%m-%Y")
    )
  ) +
  theme(legend.position = "none")
g2 +
  geom_point(
    data = slice_max(plot_data2, x),
    size = 4
  ) +
  new_scale_colour() +
  scale_colour_manual(values = new_palette, guide = "none") +
  geom_text(
    data = slice_max(plot_data2, x),
    mapping = aes(label = category, colour = category),
    hjust = -0.1,
    size.unit = "pt",
    size = 14
  )

Regardless of how well you can distinguish colours, it’s really hard to distinguish the lines from each other here. There’s lots of crossing over, and so the direct labels become ineffective.

Using different line types (e.g. dashed, dotted) is often suggested as a potential solution. However, using lines that are less complete compared to a solid line has the effect of reducing contrast of the line with the background and so it’s often not a great solution.

A similar but alternative approach is to use different symbols along each category line. So let’s try that.

g2 +
  geom_text(
    data = slice_max(plot_data2, x),
    mapping = aes(label = category, colour = category),
    hjust = -0.1,
    size.unit = "pt",
    size = 14
  ) +
  new_scale_colour() +
  scale_colour_manual(values = new_palette) +
  geom_point(
    mapping = aes(shape = category, colour = category),
    size = 6
  ) +
  theme(
    legend.position = "bottom",
    legend.title = element_blank()
  )

It’s might be more accessible in terms of distinguishing categories but it’s actually less accessible in terms of how easy it is to read and interpret. With a quick glance, how easy is it to see which line(s) are increasing? Not very.

Choosing a chart type isn’t just about the type of data, it’s also about the values in the data you are plotting. Sometimes you have to adapt or even throw away the chart you’ve made if it doesn’t work for your data.

Change the chart type

A good alternative to spaghetti line charts is small multiple line charts. Here, instead of one plot showing all four categories in different colours, we create four small line charts, each highlighting one category.

theme_set(theme_bw(base_size = 16))
g2 + facet_wrap(~category) +
  gghighlight(use_direct_label = FALSE) +
  scale_x_date(
    date_labels = "%b",
    breaks = seq(
      as.Date("01-01-2024", tryFormats = "%d-%m-%Y"),
      length.out = 4,
      by = "3 months"
    ),
    limits = c(
      as.Date("01-01-2024", tryFormats = "%d-%m-%Y"),
      as.Date("15-12-2024", tryFormats = "%d-%m-%Y")
    )
  ) +
  theme(axis.title = element_blank())

The grey lines in the background still allow comparisons between categories, but it’s much easier to see the trend for each individual category now. However, with this new version of the chart, do we actually need colour? No, we don’t. Since the categories are on separately labelled charts, there’s no need for colours (or symbols) to differentiate. When thinking about colours in charts, we don’t want to rely on colour and we don’t want to over use colour. Let’s instead use it to highlight lines, rather than decorate with extra colours.

g2 <- g2 + facet_wrap(~category) +
  scale_colour_manual(values = rep("#91171F", 5)) +
  gghighlight(use_direct_label = FALSE) +
  scale_x_date(
    date_labels = "%b",
    breaks = seq(
      as.Date("01-01-2024", tryFormats = "%d-%m-%Y"),
      length.out = 4,
      by = "3 months"
    ),
    limits = c(
      as.Date("01-01-2024", tryFormats = "%d-%m-%Y"),
      as.Date("15-12-2024", tryFormats = "%d-%m-%Y")
    )
  ) +
  theme(axis.title = element_blank())
g2

Make use of chart text

We can further improve our transformed chart by adding text, and adding it thoughtfully. A few tips for text:

• Chart text should be horizontal. People shouldn’t have to twist their neck to read category or axis labels.
• Choose a sensible font. Much like colours, there isn’t a single font that’s the best choice for everyone. However, choose one that is familiar and where all letters and numbers are distinguishable. For example, make sure you check that an upper-case I, number 1, and lower-case l look different.
• Use narrative titles to summarise the chart. The title should describe the main trend in the chart. Users are more likely to understand and remember the main trend from a chart where it is also in the chart title.

We should also make sure that the y-axis labels are well-presented. Percentage data is often recorded between 0 and 1, but if we don’t transform that axis to be between 0 and 100% it’s not always clear whether a value of e.g. 0.2 represents 20% or 0.2%.

g2_final <- g2 + labs(
  title = "Agreement with statement D increased during 2024",
  subtitle = "Percentage of people agreeing",
  x = NULL, y = NULL,
  caption = "Source: Data simulated from a Uniform distribution"
) +
  scale_y_continuous(
    limits = c(0, 1),
    labels = scales::label_percent()
  ) +
  theme(
    plot.title = element_textbox_simple(face = "bold"),
    plot.subtitle = element_text(colour = "grey50", margin = margin(t = 5, b = 5)),
    plot.caption = element_text(hjust = 0, colour = "grey50"),
    plot.title.position = "plot",
    plot.caption.position = "plot",
    axis.title = element_blank()
  )
g2_final

Before and after

Let’s compare what the default chart looks like (for our second messier dataset), with our transformed version.

I hope you’ll agree that the transformed version is much easier to read, more accessible, and more aesthetically pleasing.

Favourite things I’ve made

This one isn’t really a data visualisation as such, but building a TARDIS from scratch was fun project and I learnt a lot in the process. There are multiple datasets sitting behind this, specifying every rectangle, line, and letter - which were all populated by hand! Then I used D3 to actually build it and add the interactivity, which you can explore online. You can also read the blog post explaining how it was built.

In terms of more traditional data visualisations, one of my favourite ones to make was this small multiple chart of how passport strengths have changed over time in different continents. Although if I could change one thing, I’d switch the yellow for something with a bit more contrast!

Favourite things I’ve seen

These are a few of my favourite things (that are related to data visualisation and that I’ve seen for the first time in 2025):

• The ggplot2 battles from Mike Lydeamore is one of the coolest things I’ve seen! It challenges users to recreate a ggplot2 chart as closely as possible using R code directly in their browser. It’s a really unique teaching resource, and it’s all powered by webR in the background!

• I’ve really enjoyed playing with SveltePlot so far, which brings the grammar of graphics to Svelte. The documentation is also incredibly good with a use gallery of examples and the accompanying code.

• I absolutely love sketchy looking charts and have been using Rough.js for a while, so I’m really excited to see Making Plot Sketchy - an Observable Plot plugin to render Observable charts in Rough.js sketchy style!

Loading GPS data

If you use a GPS watch and/or app to track your runs, you should be able to download a .gpx file for a specific run. If you don’t, many races will have a .gpx file for the route somewhere on their website that you can use instead.

To make it easier for you to run the code in the examples below, we’ll use a GPS file for the route of the Strathearn Marathon that you can dowload from the race website. Assuming that you’ve managed to obtain a .gpx file of the route you want to plot, we can load it into R using the gpx package:

library(gpx)
raw_gpx <- read_gpx("strathearn-marathon.gpx")

Processing GPS data

We need to do a little bit of processing on the GPS data to get it into the right shape for plotting on a map. Let’s start by loading in the tidyverse and sf packages for data processing and working with spatial data, respectively.

library(tidyverse)
library(sf)

If you inspect the raw_gpx object, you’ll see that it’s a nested list of different R objects. We want to extract the complete race route from the tracks element, which we can do using the $ operator. We’ll then convert it to a tibble to make it more pleasant to work with, before making it into a spatial data object using st_as_sf(). Note that we set the crs (coordinate reference system) as 4326 which is the code for the World Geodetic System 1984 (WGS 84), used as standard in global GPS systems.

points_data <- raw_gpx$tracks$`Strathearn Marathon Complete` |>
  as_tibble() |>
  st_as_sf(coords = c("Longitude", "Latitude"), crs = 4326)

The raw data is provided as a series of points, but we’re planning to plot the route that connects those points. Though we could do that within the plotting, it’s easier if we convert it to the correct type of spatial instead. We combine all of the points into one object, and then cast it to a line using st_combine() and st_cast().

line_data <- points_data |>
  st_combine() |>
  st_cast("LINESTRING")

Background map data

Optionally, we might want to provide a little bit of context for the race route by including a minimal background map. Here, we’re going to add all of the other roads and footpaths that exist around the map in the background.

The first thing we need to do is get the bounding box for the race route i.e. the minimum and maximum latitude and longitude of the route. We can do this using the st_bbox() function from the sf package.

bbx <- st_bbox(line_data)

When we’re getting the background map data, we probably don’t want to just go exactly to the edges of the bounding box. Instead, it’s going to look much nicer if we add a little bit of a buffer around the edges. When working with distances, it’s often better to work in a local coordinate reference system rather than a global one. We’re going to convert our route data into the British National Grid (BNG) coordinate reference system (27700), apply the buffer, and then convert it back.

Let’s transform the data, and get an updated bounding box:

line_proj <- st_transform(line_data, crs = 27700)
bbx <- st_bbox(line_proj)

Now we can add a buffer of 500 metres so the north, south, east, and west of the bounding box:

buffer <- 500
bbx_expanded <- bbx
bbx_expanded[c("xmin", "ymin")] <- bbx_expanded[c("xmin", "ymin")] - buffer
bbx_expanded[c("xmax", "ymax")] <- bbx_expanded[c("xmax", "ymax")] + buffer

Before converting the new, expanded bounding box back to the original CRS:

bbx_expanded <- st_bbox(st_as_sfc(bbx_expanded), crs = 27700)
bbx_expanded <- st_transform(st_as_sfc(bbx_expanded), crs = 4326)

As suggested by geodarcy, you could also use st_buffer(units::set_units(500, "m")) to add a buffer around the route data.

Now, we’re ready to use the osmdata package to access OpenStreetMap to get the background data. We pass our bounding box into the opq() function to build an Overpass query, and then specify which features we want to return. Here I’ve returned objects which are classed as a "highway", which includes both roads and footpaths. You can be more specific in your query depending on what type and how many roads you want to return. The area in this example is fairly rural, so I want all of the smaller paths too. If you’re plotting a much more urban, or larger area, you might only want to return the larger roads.

We also use the osmdata_sf() function to return an sf object to make it easier for plotting later on.

library(osmdata)
highways <- bbx_expanded |>
  opq() |>
  add_osm_feature(
    key = "highway",
    value = c(
      "primary", "secondary", "tertiary", "residential",
      "living_street", "service", "unclassified",
      "pedestrian", "footway", "track", "path"
    )
  ) |>
  osmdata_sf()

OpenStreetMap returns any road that exists inside our bounding box, but it doesn’t trim the road to the size of the bounding box itself. For example, if a road extends beyond the edges, it still returns the whole road. To make our map look nice, we want to trim off the straggly roads around the edges, and we can do that by using st_crop() to trim the lines returned to the edges of the bounding box.

roads_cropped <- st_crop(highways$osm_lines, bbx_expanded)

Setting up chart variables

When you’re designing with the main purpose of making something aesthetically pleasing, it can take a little bit of trial and error to find the right colours and fonts. To make it easier to switch between different colours and fonts, I usually start by defining variables for them. This means that if I want to change the colour to something different, I only need to edit it in one place in my code.

Let’s start by loading and setting up our fonts. I often use the showtext package for fonts in R, because it gives easy access to Google Fonts. This means I never have to worry about me (or a collaborator) having the correct fonts installed on my laptop. We’re making a poster, so I’m going to pick a nice bold, display font. Here. I’ll use Oswald.

We run showtext_auto() to tell R that we’re using showtext for fonts, and then showtext_opts() to set our desired resolution. This helps to make sure that our fonts are sized correctly when we later save an image. Optionally, we also add a variable, body_font, to store the name of the font.

library(showtext)
font_add_google("Oswald")
showtext_auto()
showtext_opts(dpi = 300)
body_font <- "Oswald"

We’re also going to set up variables for the colours of the map background, the route line, and the text using hex codes to specify the colours. The map_route_col variable will also serve as the main background colour, but you might choose to define another colour if you want to.

map_bg_col <- "#33658A"
map_route_col <- "grey90"
text_col <- "grey10"

I want to add one more colour that will be used to draw the lines for roads and paths in the background of the map. When adding those lines, I want them to be similar to the map_bg_col colour, but slightly darker. One tool I often use when trying to find lighter or darker shades of a colour is coolors.co.

However, we can also do it programmatically using the monochromeR package from Cara Thompson. Let’s start with the map_bg_col colour and see what some of the darker shades look like:

library(monochromeR)
generate_palette(
  colour = map_bg_col,
  modification = "go_darker",
  n_colours = 7,
  view_palette = TRUE
)

[1] "#33658A" "#2C5777" "#254A65" "#1E3C52" "#172F40" "#11212E" "#0A141B"

We can set the line colour to be the third of these values:

map_line_col <- generate_palette(
  colour = map_bg_col,
  modification = "go_darker",
  n_colours = 7
)[3]

Plotting an initial map

Let’s get started …

Although we already have our colours set up, I tend not to add them on the first draft as the aim of that is just to check that the building blocks of the code work. Here, we start with ggplot() as we normally would, though leaving the data and mapping arguments blank as we’re using multiple different data sources.

We can use geom_sf() to add in the roads data from OpenStreetMap, noting that we don’t need to specify a mapping with aes() here because ggplot2 knows how to interpret sf objects already. We then use geom_sf() again to add the data for the route on top. Finally, we take the first and last points of the route data and again plot them using geom_sf() to show the start and end points of the route.

ggplot() +
  geom_sf(
    data = roads_cropped
  ) +
  geom_sf(
    data = line_data
  ) +
  geom_sf(data = head(points_data, 1)) +
  geom_sf(data = tail(points_data, 1))

Arguably, since the start and end points are (almost) the same place, there’s a perhaps not much use in adding both so you might choose not to add them.

Styling your map

All of the lines are quite prominent on the initial draft, and it’s very hard to see the actual route on the first version since it sits directly on top of the background roads with the same colour and linewidth. Let’s start styling our map by updating the colours and linewidths for all of the basic sf objects.

We’ll also save the updated plot as a variable to keep our code tidy as we add more styling later on. To make sure that our roads go the edge of the plotting area, without the default padding around it, we set expand = FALSE inside coord_sf():

base_map <- ggplot() +
  geom_sf(
    data = roads_cropped,
    colour = map_line_col,
    linewidth = 0.5
  ) +
  geom_sf(
    data = line_data,
    colour = map_route_col,
    linewidth = 1.5
  ) +
  geom_sf(
    data = head(points_data, 1),
    colour = map_route_col,
    size = 3
  ) +
  geom_sf(
    data = tail(points_data, 1),
    colour = map_route_col,
    size = 3
  ) +
  coord_sf(expand = FALSE)
base_map

This is already looking a lot neater than the first draft, though it’s still hard to see the route since it’s so close in colour to the background. Sometimes it’s more helpful to choose a bold, ugly colour for a first draft to check everything is working!

We have two more things to do before we’re finished making this map:

• Add some text with the race name and date (for example);
• Apply the colours we’ve selected for the background.

Let’s start with the text. Here, I’m going to set the title as the name of the race, and the subtitle as the date of the race. For both, I use str_to_upper() to format all of the text in uppercase, to give it more of a poster look.

For the caption, I want to include two different pieces of information: my name, and my race number. To make it clear they are separate pieces of information, I’m going to make one larger and darker. To apply formatting to only part of the text, we can add HTML <span></span> tags within the character string. Later, we’ll use the ggtext package to make sure the HTML formats correctly. Alternatively, you can use the marquee package in a similar way.

We also use the glue package here to pull in the variable we set earlier for the text colour.

library(glue)
text_map <- base_map +
  labs(
    title = str_to_upper("Strathearn Marathon"),
    subtitle = str_to_upper("12 June 2016"),
    caption = glue(
      "<span style='color: {text_col}; font-size:16pt;'>**NICOLA RENNIE**</span> #168"
    )
  )

The last step is to tell ggplot2 to use ggtext for the caption, remove the extra parts of the theming we don’t want, and apply our colours. We can remove most of the default theme parts using theme_void(), setting the default font and size at the same time.

We then adjust the plot (default white) and panel (default grey) backgrounds to our colour variables, adjust the margins, and style the text. Here, I use a slight transparency on the subtitle and caption to get a lighter shade.

library(ggtext)
text_map +
  theme_void(base_family = body_font, base_size = 13) +
  theme(
    panel.background = element_rect(
      fill = map_bg_col, colour = map_bg_col
    ),
    plot.background = element_rect(
      fill = map_route_col, colour = map_route_col
    ),
    plot.margin = margin(5, 20, 5, 20),
    plot.title = element_text(
      colour = text_col,
      hjust = 0,
      lineheight = 1,
      face = "bold",
      size = rel(1.6)
    ),
    plot.subtitle = element_text(
      colour = alpha(text_col, 0.7),
      hjust = 0,
      margin = margin(b = 10, t = 5),
      lineheight = 1
    ),
    plot.caption = element_textbox_simple(
      colour = alpha(text_col, 0.7),
      hjust = 1,
      halign = 1,
      margin = margin(b = 10, t = 10),
      lineheight = 1
    )
  )

Finally, we can save our map as a PNG file (or your preferred format) ready for printing! Since we’re using spatial data which has it’s own fixed aspect ratio this sometimes means there’s a little bit of extra white space either at the top/bottom or left/right of the saved chart. Setting the bg element equal to our chosen background colour fixes this.

ggsave("strathearn-map.png",
  height = 8, width = 6,
  bg = map_route_col
)

Now you’re ready to get it printed and framed!

Prompt 1: weather forecast data

The first dataset used gives information on weather forecast accuracy from the USA National Weather Service. It contains data on the observed and predicted (at 12, 24, 36, and 48 hours before) temperature and precipitation levels for different cities in the USA, between January 2021 and June 2022.

I pre-processed the data to focus on a single city (Syracuse), single year (2021), and one type of forecast (12 hours before). This was mainly to make the data small enough for uploading to different generative AI websites. The data look like this:

tuesdata <- tidytuesdayR::tt_load("2022-12-20")
weather_forecasts <- tuesdata$weather_forecasts
weather <- weather_forecasts |>
  dplyr::filter(
    city == "SYRACUSE",
    lubridate::year(date) == 2021,
    forecast_hours_before == 12
  ) |>
  dplyr::select(date, high_or_low, forecast_temp, observed_temp)

The prompt given to all generative AI tools was:

If I was to visualise this data, I might create something like this as a first draft:

library(ggplot2)
library(ggtext)
library(ggh4x)
# Prep annotations
annotation1 <- annotate("text",
  label = stringr::str_wrap(
    "Predicted temperatures are higher than actual temperatures", 10
  ),
  size = 3, x = 75, y = 7, lineheight = 0.8
)
annotation2 <- annotate("text",
  label = stringr::str_wrap(
    "Predicted temperatures are lower than actual temperatures", 10
  ),
  size = 3, x = 14, y = -7.5, lineheight = 0.8
)
arrow1 <- annotate("curve",
  x = 58, xend = 47,
  y = 7.5, yend = 6.5,
  arrow = arrow(length = unit(0.1, "inches"), type = "closed"),
  curvature = 0.1
)
arrow2 <- annotate("curve",
  x = 27, xend = 38,
  y = -7.5, yend = -6.5,
  arrow = arrow(length = unit(0.1, "inches"), type = "closed"),
  curvature = 0.1
)

# Plot
weather |>
  dplyr::mutate(high_or_low = factor(high_or_low,
    levels = c("low", "high"),
    labels = c("Daily low temperature", "Daily high temperature")
  )) |>
  ggplot(
    mapping = aes(
      x = observed_temp,
      y = forecast_temp - observed_temp
    )
  ) +
  geom_hline(yintercept = 0) +
  geom_point(size = 3, alpha = 0.5) +
  at_panel(annotation1, PANEL == 1) +
  at_panel(annotation2, PANEL == 2) +
  at_panel(arrow1, PANEL == 1) +
  at_panel(arrow2, PANEL == 2) +
  scale_x_continuous(limits = c(0, 100)) +
  scale_y_continuous(limits = c(-10, 10)) +
  labs(
    title = "Temperatures are more likely to be underestimated, especially when they are low.",
    subtitle = "Data from the USA National Weather Service shows that 12 hour ahead forecasts for temperatures in Syracuse in 2021 were more likely to be below the later observed temperature than above.",
    x = "Observed temperature (°F)",
    y = stringr::str_wrap("Forecast error (°F)", 10),
    caption = "Source: USA National Weather Service"
  ) +
  facet_wrap(~high_or_low, nrow = 1) +
  coord_cartesian(expand = FALSE, clip = "off") +
  theme_bw() +
  theme(
    plot.margin = margin(5, 10, 5, 5),
    plot.title.position = "plot",
    plot.title = element_text(face = "bold"),
    plot.subtitle = element_textbox_simple(margin = margin(b = 10)),
    panel.spacing = unit(1, "lines"),
    axis.title.x.bottom = element_text(hjust = 0),
    axis.title.y.left = element_text(angle = 0, hjust = 1, size = rel(0.8))
  )

The key features of this visualisation are:

• Narrative title that states the key takeaway.
• Does not rely on colour to differentiate categories to improve accessibility.
• Uses transparency to make it easy to see where there are multiple observations in the same place.
• Symmetric y-axis, and zero line to make it easier to see if the data is is above or below zero.
• Uses annotations to make the values shown easier to understand.

Prompt 2: CEO departures data

The second dataset gives information on reasons for CEO departures between 2000 and 2018, and is from a publication by Gentry et al. Again, to limit the file size, I filtered the data to only include data points between 2000 and 2009. Even with the more limited time frame, the data is still reasonably large at 3.5Mb.

The prompt given to all generative AI tools was:

ChatGPT

ChatGPT produced the static chart above, with the following accompanying text:

Here’s the chart showing the relationship between forecasted and observed temperatures, separated by high and low temperature forecasts. The dashed line represents perfect prediction accuracy (1:1).

Things that are reasonably good:

• The use of crosses instead of opaque dots makes it easier to see where there are clusters of points overlapping.
• The addition of a comparison line.

Things that are not so good:

• It guessed at the units as being degrees Celsius rather than Fahrenheit - 100°C isn’t exactly a reasonable temperature forecast!
• It relies on colour to differentiate high and low forecasts, and the red and green colour choice is not good for accessibility.
• This is a static chart (with no accompanying code) which makes it harder to edit.

Claude

Claude went way over the top! It built an entire, quite complex app using React. The accompanying text was extensive, and so is omitted here. A screenshot of the home page of the app is shown above. It also created a second page of the app specifically analysing forecast accuracy:

Things that are reasonably good:

• Correctly guessed the units as Fahrenheit.
• Design looks clean, and the colour palette is okay - matching blue for cold, and red for hot.
• It calculates summary statistics, and provides key insights (not quite as good as a narrative title, but still a pretty good summary).

Things that are not so good:

• There’s no guarantee that the person creating this visualisation actually knows React, so creating an app for them using React can easily result in something that they don’t understand. It feels like a disproportionately complex result, given the prompt.
• The choice of break points on the x- and y- axes are weird.

Copilot

Copilot produced the following text:

Here’s a chart that visualizes the relationship between forecasted and observed temperatures, with a clear distinction between high and low forecasts:

📊 Chart Highlights Scatter plot format shows how closely forecasted temperatures align with observed ones.

• Color-coded by high_or_low to differentiate high and low temperature forecasts.
• Consistent styling with gridlines, labeled axes, and a legend for clarity.
• Edge-colored markers improve visibility and accessibility. If you’d like to explore trends (e.g. whether high forecasts tend to be more accurate than low ones), I can help with that too. Want to dig deeper?

Based on the first sentence, you might assume that it generated a chart - it did not! No image was actually generated, even when re-prompted. Instead, it generated some Python code to make a chart which was revealed upon clicking see my thinking. The chart created by the Python code (with some tweaking) can be seen below:

import pandas as pd
import seaborn as sns
import matplotlib.pyplot as plt
import os

# Set seaborn style for better aesthetics
sns.set(style="whitegrid")

# Load the CSV file
try:
    df = pd.read_csv("temperature_data.csv")
except Exception as e:
    raise RuntimeError(f"Failed to load CSV file: {e}")

# Check required columns
required_columns = {'forecast_temp', 'observed_temp', 'high_or_low'}
if not required_columns.issubset(df.columns):
    raise ValueError(f"Missing required columns in the dataset. Found columns: {df.columns.tolist()}")

# Create output directory if it doesn't exist
output_dir = "/mnt/data"
os.makedirs(output_dir, exist_ok=True)

# Create scatter plot
plt.figure(figsize=(10, 6))
sns.scatterplot(data=df, x='forecast_temp', y='observed_temp', hue='high_or_low', palette='viridis')
plt.title('Forecasted vs Observed Temperature')
plt.xlabel('Forecasted Temperature (°C)')
plt.ylabel('Observed Temperature (°C)')
plt.legend(title='Forecast Type')
plt.tight_layout()

# Save the plot
plot_path = os.path.join(output_dir, "forecast_vs_observed_temp.png")
plt.savefig(plot_path)
plt.close()

print(f"Plot saved to {plot_path}")

Things that are reasonably good:

• Scatter plot is a reasonable choice for comparing the two columns.
• The code has error checking - although the built in Python errors actually give an identical error at an earlier point so it’s a lot of redundant code.
• Tries to highlight the design choices made, which are reasonable even if they aren’t well executed.

Things that are not so good:

• It didn’t actually generate a chart! The Python code wasn’t quite correct, and it resulted in a blank plot saved in a very obscure location. The labels also end up chopped off. This isn’t a blog post about using generative AI to write code, so I’ll be forgiving about that here.
• Again, assumes temperatures are in Celsius.
• Colour choices are not great, and it’s quite hard to see the points when they’re layered on top of each other.

Gemini

Gemini produced a small interactive chart (screenshot above), with the following accompanying text:

The scatter plot above illustrates the relationship between forecasted and observed temperatures. The different colors represent whether the temperature is a high or low forecast for the day. This visualization helps to identify how closely forecasted temperatures align with actual observed temperatures and whether there are any patterns in the accuracy of high versus low temperature forecasts.

Things that are reasonably good:

• The chart was interactive, and I could customise the view, see the data as a table, and download the chart as an image.

Things that are not so good:

• The colour choices are very poor. The points for both categories are the same colour, and they are only differentiated by the dot outline being a slightly different shade of blue.
• Non-symmetric axis ranges make it harder to compare, especially without a diagonal comparison line.
• The text colours look fine in dark mode, but the chart downloads with a transparent background. Against the light background of this blog post, the text is very hard to read.

ChatGPT

ChatGPT produced the static chart above, with the following accompanying text:

Here’s the chart showing the rate of involuntary CEO dismissals (non-health related) by fiscal year. It follows best practices by using clear labels, appropriate scaling, and a focus on the trend rather than raw counts. Let me know if you want it broken down further (e.g. by industry or company size).

Similar to the first experiment, ChatGPT produced a fairly basic chart that’s fine but doesn’t quite follow best practices - such as rotated x-axis labels. It did plot the rate rather than the absolute count given, which is probably more appropriate.

Claude

Claude was unable to produce a visualisation for the second prompt, giving the error message that the text is 2413% larger than allowed. Essentially, the data is just too big to upload.

Copilot

Copilot was also unable to produce a visualisation for the second prompt because the data was too large to upload.

Gemini

Gemini again produced a small interactive chart (screenshot above), with the following accompanying text:

Here’s a chart displaying the proportion of CEO dismissals over fiscal years, derived from the data you provided. This visualization illustrates how the rate of involuntary, non-health-related CEO dismissals has changed over time. Let me know if you would like to analyze other aspects of the data!

The styling and issues are very similar to those from Gemini in the first experiment. It also plotted the rate instead of the absolute count.

Further reading

• Neil Richards published a similar blog post to this one, asking Can GPT help create data visualisations? He goes through the process of using ChatGPT to scrape data, then build and iterate on a data visualisation.

• Enrico Bertini wrote a really nice blog post with Five Strategies for Analyzing Data with ChatGPT, with some tips for improving the results you can get from generative AI.