What was posit::conf(2025) Like?

posit::conf(2025) was my 5th RStudio/Posit conference and 4th in-person. What I love about it is how chill and friendly it is. You don’t have to dress up, worry about being socially awkward (I see you, fellow neurospicy peeps), or stress too much.

You can come and go as you please and choose how to consume keynotes and talks. Attend presentations live, watch from Posit’s lounge outside the ballroom if crowds aren’t your thing, or – though it seems counterintuitive – watch from your hotel room (I do this more than I care to admit). One of the best things about conf is the ability to tailor it to what you want and engage as much or as little as you’d like.

For first-timers or solo attendees, the organizers work hard to make everyone feel welcome. From Posit Discord invites to encouraging the pac-man rule, the conference has earned its reputation for being newcomer-friendly.

My Personal Highlights

My Personal Takeaways

Needless to say, I had an awesome time and left with new discoveries and motivation to dig deeper into:

• Becoming a programming polyglot, focusing on Python and Rust in my downtime
• Using Air in my workflow
• Transitioning to Positron (this blog post was made in Positron!)
• Getting over my fear of contributing to open source packages
• Being less self-deprecating (TDD showed me that even if I struggle with brevity, I’m still intelligent. I may not know everything, but I know a lot, and that should be celebrated – even if just internally)

As for next year, posit::conf(2026) was announced for Houston, Texas. Not sure how I feel about traveling to Texas, but we’ll see how things shake out. Until then, fellow nerds!

What is artpack?

artpack is a “new-ish” R package created to help generative artists of all levels create generative art in R. The artpack package is intended for use with the tidyverse suite, more specifically with the ggplot2 package. artpack aims to simplify the process of creating generative art while providing increased control over the actual data that’s used to create art on a ggplot. artpack does this by providing tools that create and transform data frames that can be mapped onto a ggplot to create art.

You can install artpack from CRAN with:

install.packages("artpack")

You can install the development version of artpack from GitHub with:

# install.packages("devtools")
devtools::install_github("Meghansaha/artpack")

This post will cover the main new functions included in 0.2.0 that were not present in the original 0.1.0 CRAN release.

You can find all the changes implemented in the release notes here.

Geospatial Tools

New to artpack is a geospatial function, point_in_polygon(), which analyzes points relative to a polygon. It was created in the spirit of {sp}’s point.in.polygon() function. The sp package is currently being deprecated, so point_in_polygon() attempts to provide similar results by using the more stable {sf} package instead. point_in_polygon() is a wrapper for various sf functions and returns a numeric vector of 0’s and 1’s where a value of 0 indicates that a point is outside of the polygon being tested and a value of 1 indicates that the point is either inside or on the border of the polygon being tested.

library(dplyr)
library(ggplot2)
library(artpack)

# Create test points and polygon for visualization
df_points_prep <-
  tibble(
    x = c(0.5, 1.5, 2.5, 1.0, 0.0, 3.0),
    y = c(0.5, 1.5, 2.5, 0.0, 1.0, 1.0)
  )
df_polygon <-
  tibble(
    x = c(0, 2, 2, 0, 0),
    y = c(0, 0, 2, 2, 0)
  )

# Test the points and add labels for the plot
df_points <-
  df_points_prep |>
  mutate(
    position = point_in_polygon(x, y, df_polygon$x, df_polygon$y),
    position_string = case_match(position,
                                 0 ~ "Outside",
                                 1 ~ "Inside/On Boundary"
                                 ) |> factor(),
    color = case_match(position,
                       0 ~ "#e31a1c",
                       1 ~ "#33a02c"
                       )
  )

# Pull out the colors for the plot points
unique_df <- unique(df_points[c("position_string", "color")])
vec_colors <- setNames(unique_df$color, unique_df$position_string)


# Plot it
ggplot() +
  geom_polygon(data = df_polygon, aes(x = x, y = y),
               fill = "#104d70", alpha = 0.3, color = "black", linewidth = 1) +
  geom_point(data = df_points, aes(x = x, y = y, color = position_string), size = 4) +
  scale_color_manual(values = vec_colors) +
  labs(color = "Position:") +
  coord_equal()

Group Tools

If you’re a fan of using geom_polygon() in your generative art, chances are you know the importance of assigning grouping variables to your data where applicable. The group_sample() and group_slice() functions have been added to allow users to sample and slice their data frames by grouping variables. group_sample() and group_slice() were both created in the spirit of dplyr’s slice() function family. Just like how slice() works on single rows, group_sample() and group_slice() will always keep the rows of a group intact. So if you decide to sample 2 groups out of 5, all of the rows labeled by the two groups will be returned while the other rows will be dropped. The same is true for group_slice().

We can demonstrate group_sample() and group_slice() with a simple grid, where each square is its own group:

# Create a grid
df_grid <-
  grid_maker(
    xlim = c(0,10),
    ylim = c(0,10),
    size = 10,
    fill_pal = art_pals("sunnyside", 5)
  )

df_grid |>
  ggplot(aes(x,y, group = group)) +
  geom_polygon(
    fill = df_grid$fill,
    color = "#000000"
  ) +
  theme_void() +
  coord_equal()

Sampling 50% of the groups:

set.seed(09132025)

# Create a sampled df
df_grid_sampled <-
  df_grid |>
  group_sample(group = group, prop = .50)

df_grid_sampled |>
  ggplot(aes(x,y, group = group)) +
  geom_polygon(
    fill = df_grid_sampled$fill,
    color = "#000000"
  ) +
  theme_void() +
  coord_equal(xlim = c(0,10), ylim = c(0,10))

Sampling only 10 of the groups:

set.seed(09132025)

# Create a sampled df
df_grid_sampled <-
  df_grid |>
  group_sample(group = group, n = 10)

df_grid_sampled |>
  ggplot(aes(x,y, group = group)) +
  geom_polygon(
    fill = df_grid_sampled$fill,
    color = "#000000"
  ) +
  theme_void() +
  coord_equal(xlim = c(0,10), ylim = c(0,10))

Slicing the data so that the groups in the bottom half is removed:

# Create a sliced df
df_grid_slice <-
  df_grid |>
  group_slice(group = group, prop = .50, position = "tail")

df_grid_slice |>
  ggplot(aes(x,y, group = group)) +
  geom_polygon(
    fill = df_grid_slice$fill,
    color = "#000000"
  ) +
  theme_void() +
  coord_equal(xlim = c(0,10), ylim = c(0,10))

Slicing the data so that 25 of the groups from the bottom remain:

# Create a sliced df
df_grid_slice <-
  df_grid |>
  group_slice(group = group, n = 25, position = "head")

df_grid_slice |>
  ggplot(aes(x,y, group = group)) +
  geom_polygon(
    fill = df_grid_slice$fill,
    color = "#000000"
  ) +
  theme_void() +
  coord_equal(xlim = c(0,10), ylim = c(0,10))

Sequencing Tools

seq_bounce() generates a regular sequence of numeric values that “bounce” between a provided “start” and “end” number. It will always return a numeric vector of the length provided.

By default, seq_bounce() creates sequences by increments of 1:

#The length argument accepts any positive integer
seq_bounce(start_n = 1, end_n = 5, length = 15)

 [1] 1 2 3 4 5 4 3 2 1 2 3 4 5 4 3

More precision can be obtained with the by argument:

#The by argument accepts any positive numeric
seq_bounce(start_n = 0, end_n = 10, length = 30, by = .247)

 [1] 0.000 0.247 0.494 0.741 0.988 1.235 1.482 1.729 1.976 2.223 2.470 2.717
[13] 2.964 3.211 3.458 3.705 3.952 4.199 4.446 4.693 4.940 5.187 5.434 5.681
[25] 5.928 6.175 6.422 6.669 6.916 7.163

Transformation Tools

resizer() is artpack’s newest transformation tool. It can be used to “resize” or scale existing data points in a data frame based on either the first data point in the dataframe or a provided anchor point.

Resizing a square up by a factor of 6:

# Make a data frame
df_square <-
  square_data(
    x = 0,
    y = 0,
    size = 1
  )

# Resize it
df_square_resized <-
  df_square |>
  resizer(x, y, factor = 6)

# Plot them
df_square |>
  ggplot(aes(x,y)) +
  # resized square - red dashed line
  geom_path(data = df_square_resized, color = "#a83246", linewidth = 2, linetype = 2) +
  # original square - black solid line
  geom_path(color = "#000000", linewidth = .8) +
  coord_equal()

Resizing a circle down by a factor of 3 and manually setting an anchor point:

# Make a dataframe
df_circle <-
  circle_data(x = 5, y = 5, radius = 5, group_var = TRUE)

# Set the anchor point as the middle of the circle c(5,5)
# Although the point 5,5 is in the circle's bounds,
# it's not actually a row in `df_circle`
# A message will display in cases like these and is "fine" to ignore.

df_circle_resized <-
  df_circle |>
  resizer(x,y, x_anchor = 5, y_anchor = 5, direction = "down", factor = 3)

! The anchor point you've supplied (5, 5) is not found in your data.
ℹ The data will be scaled relative to this external point

# Plot it
df_circle |>
  ggplot(aes(x,y)) +
  # resized circle - red dashed line
  geom_path(data = df_circle_resized, color = "#a83246", linewidth = 2, linetype = 2) +
  # original circle - black solid line
  geom_path(color = "#000000", linewidth = .8) +
  coord_equal()

Color Tools

Two new functions, set_brightness() and set_saturation(), have been added to artpack. Both can be used to adjust original colors by percentage of desired brightness and saturation. These functions work by transforming hexadecimal webcolor values or any value from colors() into an RGB value, and then an HSL value to adjust the brightness or saturation. After the adjustment, the values are converted into a hexadecimal webcolor that is then returned to the environment for use.

These functions use a normalized scale of 0 to 1, meaning that 0% is the darkest/least saturated value in relation to the original color provided and 100% is the brightest/most saturated value in relation to the original color provided.

An example of adjusting the brightness of a color. Note how the “darker” color shown is not much darker than the original, because the original color already had a brightness of 35%:

# Create color values
original_color <- "#94321c" #(original brightness == %35)
darker_color <- set_brightness(original_color, .30) #(brightness == %30)
lighter_color <- set_brightness(original_color, .7) #(brightness == %70)

# Make a data frame with the color values
df_colors <-
  data.frame(
    x = 0:2,
    y = 1,
    color = c(darker_color, original_color, lighter_color)
  )

# Add a label for clarity
df_colors$label <- paste(c("Darker", "Original", "Lighter"), ":", df_colors$color)

# Plot to see the brightness changes
df_colors |>
  ggplot(aes(x,y)) +
  geom_label(aes(x = 0:2), y = 2, label = df_colors$label) +
  geom_point(color = df_colors$color, shape = 15, size = 50) +
  coord_cartesian(xlim = c(-1,3), ylim = c(0,3)) +
  theme_void()

Saturation is adjusted similarly:

# Create color values
original_color <- "#748c3f" #(original saturation == %38)
desaturated_color <- set_saturation(original_color, .2) #(saturation == %20)
saturated_color <- set_saturation(original_color, .9) #(saturation == %90)

# Make a data frame with the color values
df_colors <-
  data.frame(
    x = 0:2,
    y = 1,
    color = c(desaturated_color, original_color, saturated_color)
  )

# Add a label for clarity
df_colors$label <- paste(c("Desaturated", "Original", "Saturated"), ":", df_colors$color)

# Plot to see the saturation changes
df_colors |>
  ggplot(aes(x,y)) +
  geom_label(aes(x = 0:2), y = 2, label = df_colors$label) +
  geom_point(color = df_colors$color, shape = 15, size = 50) +
  coord_cartesian(xlim = c(-1,3), ylim = c(0,3)) +
  theme_void()

You might be asking how you could determine the original brightness or saturation of a color you provide. Currently, there is no function in artpack that does this, but it is planned for a future release.

In the meantime, if needed, you can absolutely use other methods to determine this. Take the color “#748c3f” for example. Going to Google.com and using their “Color picker” tool can let you easily see these values:

An “HSL” value is provided in the bottom right of the picker tool. The second value, “S”, is the saturation percentage of the color (38%), and the third value, “L”, is the “lightness” which is essentially the brightness (40%).

More Vignettes

The last update you might want to check out are the new and improved vignettes:

• Brief Examples has an updated example of some art that can be made with artpack.

• Connecting artpack Assets to ggplot2 Geoms is a new vignette that goes over the various artpack asset creations and their recommended ggplot2 geoms that can be used when creating art in R with artpack and ggplot2. It also gives a quick example of how to bring your newly created art data into a ggplot if you need that information.

• See aRtpack in Action is a new vignette that shows you how to make an art piece from start to finish, which may be helpful for anyone just starting or those who just need an example of an entire workflow that’s possible with artpack.

Reminder

artpack is still in its infancy and is currently developed and maintained by one person. Some weird stuff may happen when using artpack. If you come across any bugs or have any ideas about new features you’d want to see implemented, or recommend improvements, please do so on artpack’s github repository by opening a new issue here.

What is a Git Stash?

A git stash is exactly what it sounds like. It’s a command in Git that allows you to save (stash away) any changes that are uncomitted in your current directory. Stashes are unique and centralized to each repository. In comparison, git push is used to get staged changes that are committed onto the remote repository.

Why Would I Want to Use git stash?

Git stashes can help you maintain a clean git/working environment. You would usually want to use git stashes when you need to cleanse your current directory of whatever unstaged changes you have. One of the most common use cases for git stash is when you have changes that you don’t want to commit to your current branch but need to switch to another branch. As stated in my talk, Please Let Me Merge Before I Start Crying, I believe that emergencies aren’t a thing. Still, sometimes, a situation can arise when you have to stop to pivot and work on something else within the same repository.

You might also want to use git stash if you’ve started working on a branch but realized you never pulled down updates from the remote repository. Instead of committing your work in progress, you can keep your commit history clean (which is important!) by stashing your current changes, and then bringing the changes in to resolve any potential conflicts.

How Can I Use git stash?

Stashing with A Terminal

If you’re an R user like myself, you may favor using the RStudio IDE (Integrated Development Environment). While great for many things, it unfortunately does not have a built-in graphical user interface (GUI) for git stashes at the time of writing this. This means there are no accessible buttons to click to create a git stash like you would for creating a commit, pushing and pulling to repositories, or other standard git functions. If you use RStudio, the most accessible way to create and use git stashes within the IDE is to use the embedded terminal:

Making a stash in RStudio’s Git Terminal

If you’re not using Rstudio, you can use any terminal/Command Line Interface (CLI) you’d like. This could be Powershell on Windows operating systems, Terminal on Macs, or even Bash on Linux systems. The potential benefit of using a terminal is increased functionality with the possibility of a steeper learning curve or decreased accessibility due to the difficulty of learning to script in CLIs for most users.

A Rundown of git stash Commands

If you use the Git terminal to do your stash work, you can find the most essential commands you’ll need to know in the table below. If you’re choosing to use a GUI, you won’t have to type the inputs into a terminal, but rather, the application you’re using will be interacting with Git on your behalf to perform some of these commands for you:

Stashes in the Wild

So it’s one thing to list off the commands and tell you to go “figure it out” because there isn’t “much” to git stashes, but I feel like it would be more helpful to see some examples of using stashes in the wild. Let’s look at some scenarios in which you could use these commands.

Making a Stash

Scenario: You jumped into working on a branch that hasn’t been updated from the remote in a month and of course, you forgot to pull before touching anything. You want to make a stash to keep your current work safe so you can pull the updates in and deal with any conflicts later. You save the stash with a message to give a description of the work you’re saving.

git stash -m "premature analysis changes before pull"

Popping the Last Stash Saved

Scenario: So it turns out you won’t have any conflicts from that last scenario, so you simply want to throw your changes from that last stash back into your environment.

git stash pop

Listing Stashes

Scenario: After doing more work, you realize that you’re missing some code you absolutely did write at some point… but can’t find anywhere. You suspect it’s in a different stash but don’t know which one. So you want to see all your available stashes for this project.

git stash list

Showing a Stash

Scenario: You think you’ve found the right stash. The one at index 2, but you’re not entirely sure. You want to see a quick summary to see what changes are on this particular stash.

git stash show 2

Important

Sometimes, when you start using some commands like git stash show or git log the terminal may expect you to input something and won’t allow you input anything else. If this happens, you simply need to “escape” to revert the terminal back to it’s original state. You can do so by inputting the letter q.

Popping a Specific Stash

Scenario: You are sure the stash at index 2 is the correct choice, and you know that whatever work you do today will be good enough to commit to the branch, so you want to pop off that stash to continue your work while removing it from your stash list.

git stash pop 2

Branching a Stash

Scenario: You’re starting to realize that the scope of your work has crept away a bit. It now makes sense to have a dedicated branch that’s separate from the current one to continue this work. You want to name the branch “misc-fixes.”

First, make the stash…

git stash -m "misc fixes port"

… then make the branch.

git stash branch misc-fixes

Applying a Stash

Scenario: You’re starting your work on the new “misc-fixes” branch and have made solid progress before taking a break from it. When you finally pick it up again, you realize that an ambitious function you wrote may need a tweak, but you’re unsure where or how to implement it. You apply the stash (instead of popping it) so you can freely experiment without losing the integrity of your code. If you mess up, your original code will be in the stash list.

git stash apply

Pushing a Stash

Scenario: You’ve switched to a different project someone else was working on because they asked you to help with a data-wrangling problem. Sadly, your brain is fried, and you’re just making it worse. Instead of committing wrong/incomplete code, you decide to push ALL of your changes (even untracked ones) to a stash so you can remove your embarrassment from the branch as if nothing ever happened.

git stash push -u

Dropping a Stash

Scenario: You don’t know what you were thinking, bothering to push those changes to a stash. Your code is broken and makes no sense. It’s not even relevant. You want to put the stash out of its misery and ban it to the shadow realm.

git stash drop

Warning

NOTE: You better be sure you want to do this. Git does not ask you if you’re sure… There are ways to recover stashes you’ve accidentally dropped, but if you’re a git newbie, it’s not pretty, and it’s out of the scope of this blog post.

git stash clear

Some Additional Things You May Want to Know

Stashing Staged Changes

You may have so many changes in your environment at the moment but only want to save/stash a few of them. You can stage those changes and stash them. By default, git does not stash staged changes. You can use this to your advantage to quickly group changes together for a stash:

Either stage them via a GUI, or in the terminal with the -S option:

git add file-to-keep-1.R
git add file-to-keep-2.R
git stash -m "two important updates" -S

Porting Stashed Changes to Another Branch

If, for any reason, you want to bring stashed changes into another branch that is already created, you can do so by switching to (checking out) the branch you want to bring the changes to and either pop or apply the changes to the branch.

If you’re using a GUI, switch to the desired branch. If using the terminal, check the branch out:

git checkout the-other-branch

Then pop or apply the stash (In this case, the stash at index 3):

git stash pop 3

Referencing Stashes

Whenever you use any stash command/option without referencing a specific stash, git will always choose the stash at index 0 in the stash list, which is whatever stash you saved last. The easiest way to reference your stashes is by index. You can easily see which stash is at which index with git stash list:

git stash list

Although not as easy as just referencing the index, you can search for your git stashes via grep if you get in the habit of attaching messages to your stashes:

Let’s say you have a stash that you tagged as “IMPORTANT”. When using grep, it is case-sensitive. Meaning we’d input this:

git stash list | grep "IMPORTANT"

To find the stash/index we’re looking for (Index 1 in this case):

Looking at the Stash Dates

Although it’s an option for the git log command, you can use --date to display the date and time the stashes in the stash list were created:

Use --date=local to see the full day and time the stashes were created.

git stash list --date=local

Use --date=relative to see a relative time calculation like “35 minutes ago”. This could come in handy if you’ve made a lot of stashes without labeling them well, as you can gauge the time on the stash you’re looking for.

git stash list --date=relative

Abandoning Ship

Sometimes, popping or applying stashes into your environment may lead to some merge conflicts:

If this happens, don’t forget that the first rule of resolving conflicts is to NOT panic. If for some reason you can’t help but panic, you can always tell git “nevermind” so you can deal with it later with the following command:

git reset --merge

About

So I already talked about how insane 2022 was for me. A part of the insanity was that I traveled so much, like the most ever. A portion of my travels was to be a maid of honor for my best friend, that got married in Savannah, Georgia (US). It was my first time going to “The South” (Because Disney doesn’t count), and it was a fun experience. Unfortunately, because I was in the middle of so many things, I didn’t get my friend her present until the end of the year because I’m terrible.

Because I’m the nerd I am, of course, I had to incorporate R somehow. So I got a circular map of where she got married printed on a canvas and shipped to her. I’ll explain how this can be done.

Get Your Packages

First, you’ll need a few packages. What you’ll need will depend on what you want to do. At the bare minimum, you’ll need the sf, osmdata, and ggplot2 packages to make this happen. Despite this, I’ll simply show what I used for this particular example:

#=============================================================================#
# Library Load-In--------------------------------------------------------------
#=============================================================================#
library(sf) #For getting "simple features" - It makes my maps go brrr in ggplot
library(tidyverse) #For Everything data (dplyr and ggplot specifically)
library(osmdata) #For geodata and mapping
library(showtext) # For using pretty Google fonts
library(ggtext) #For easier text aesthetics
library(glue) #Also for easier text aesthetics

Pick a Point of Interest (POI)

We first need to pick a “center” point of interest (POI) of our map. In this example, my friend’s wedding venue was The Mackey House in Savannah, Georgia (US). So I found out those latitude and longitude points and put them in an object, POI, with named values lat and long:

#=============================================================================#
#Map Options-------------------------------------------------------------------
#=============================================================================#

#Map's Point of Interest (POI - Center)----------------------------------------
POI = c(
  lat = 32.03825,
  long = -81.1716
)

Make the Map’s Bounding Box

Once we have the POI coordinates, we can make our bounding box. You can think of this as setting the limits we want to see on our map. We’ll also set a “buffer” value to adjust all of the values in our bounding box. Note that you don’t need a buffer value if you don’t want it, but because I’m a GIS newbie, I don’t really understand degree measurements; this was nice to include in the program for trial and error tweaking after everything was finished at the end.

#Map's bounding Box "buffer" size----------------------------------------------
#Helps create the bounds for the entire map#
bb_buff <- .06000

#Map's Bounding Box (mbb)------------------------------------------------------
mbb = c(
  minlong = POI["long"] - bb_buff, 
  minlat = POI["lat"] - bb_buff,
  maxlong = POI["long"] + bb_buff, 
  maxlat = POI["lat"] + bb_buff
) |>
  unname()

Pick Your OSM Features

Next, we need to tell the OSM package what “features” we want on our map. These features will translate into relevant geometry data that will visually appear as structures (like bodies of water, buildings, or roads) in our image. The list of available features is MASSIVE, so I’d encourage you to view this reference and pick the relevant ones for your project. Because my computer is a potato (i.e., slow), I only included five features (buildings, landuse, leisure, natural, and highways). The more features you have and the more populated your POI is with features, the longer it will take for your computer to pull and process the data through the OSM APIs, so balance out what you include in these scripts as you see fit.

I’ve placed my features into objects (feature_names , feature_keys, osm_features) to optimize my code and pulled the data iteratively using purrr’s map function. From the osmdata package, we’ll need to use the following functions to grab this data from the servers:

• opq() - Builds an Overpass query to “talk to” the server to gain access to the Open Street Map data.

• add_osm_feature() - Adds selected OSM features to an existing Overpass query.

• osmdata_sf() - Converts the collected data from the API into Open Street Map Data that is formatted into sf format.

#Specific OSM features desired-------------------------------------------------
feature_names <- c(
  "buildings",
  "landuse",
  "leisure",
  "natural"
)

feature_keys <- c(
  "building",
  "landuse",
  "leisure",
  "natural"
)

#Personally omitting water/rivers (won't map for me)#
#My bounding box data has inconsistencies#
#Not sure if this is just because of where I'm mapping though#
#It is in a rural area, so not sure if that's why#

#OSM feature grabbing and naming-----------------------------------------------
#Native pipe (|>) does not evaluate this properly like magrittr's#
osm_features <- map(feature_keys, ~opq(bbox = mbb) %>%
                      add_osm_feature(key = .x) %>%
                      osmdata_sf() %>%
                      .$osm_polygons) %>%
  set_names(., feature_names) 

For my code below, I made a separate block of calls to collect this data for the highways/roads as I’d need that to be presented as lines and not polygons. I could have just put this into the above map() function, but I found this to be more readable (to me anyway). After we pull this data we prepend() it to our existing osm_features object:

#Road features-----------------------------------------------------------------
roads <- opq(bbox = mbb) %>%
add_osm_feature(key = 'highway') %>%
  osmdata_sf() %>%
  .$osm_lines

#Combining all OSM features#
osm_features_all <- prepend(osm_features, list("roads" = roads))

#Updating feature names to include "roads"#
feature_names <- names(osm_features_all)

If we were to take the data stored in the osm_features_all objects, we’d see that we’ve pulled down the map data from the API that exists within the values of our bounding box in the mbb object:

Mess with The CRS (Coordinate Reference System)

Now that the data is pulled from the API, we need to “filter” the data that only lies in a circle in the middle of our bounding box. We can make this happen with some additional functions from the sf package that we can use for this type of geo data-wrangling with our Coordinate Reference System (CRS):

• st_crs() - Sets/Retrieves a CRS from an object.

• st_as_sf() - Converts and object to an sf object.

• st_buffer() - Used to add or subtract values from sf geometries.

• st_transform() - Transforms/converts coordinates of a sf object.

  
  

Other general purpose functions that we’re using here are:

• unname() - Removes the names attributes of an object.

• enframe() - Converts named vectors to columns in a data frame.

• pivot_wider() - Transforms data from long to wide via pivoting.

Below, we are setting up our CRS, taking our POI coordinates and converting it into a sf object. Next we set a numeric dist value that controls how big our “circle” is. Finally, we manipulate all of this into an updated circle data frame that we will use to filter out the final image from the data we pulled from the API earlier.

Additionally, because I know what I’m making ahead of time, I’m adding another data frame, center_POI that will be used to mark our POI at the center of our map with a unicode heart symbol. We’ll talk about the specifics of that soon in the Set Your Colors and Text section of this post.

#=============================================================================#
#Circle/Center Calculations----------------------------------------------------
#=============================================================================#

#Pulling the CRS---------------------------------------------------------------
#(Coordinate Reference System) from the "roads" polygon object#
crs_data <- unname(st_crs(osm_features_all$roads)$wkt)

#Defining the circular "view" from POI-----------------------------------------
#Setting a distance from the center POI----------------------------------------
#Affects how "big" the circle is#
dist <-  800

#Circle "data" used to crop/filter the original OSM data "down to size"--------
circle <- enframe(POI) |>
  pivot_wider() |>
  st_as_sf(coords = c("long", "lat"), crs = crs_data) |>
  st_buffer(dist = dist) |>
  st_transform(crs = crs_data)

#...and adding a label for the map to mark it#
center_POI <- tibble(long = POI["long"], 
                      lat = POI["lat"], 
                      label = expression("\U2764")) |>
  st_as_sf(coords = c("long", "lat"), crs = crs_data)

Carve Out Your Circle

Now that we have all of the map data and the proper boundaries for the “circle” of our map, we can use the st_intersection() function to “filter” out original data to only include objects that lie in our “circle” boundaries. I’ve made a personal choice to use the list_rbind() function on this cropped data simply because all of my map layers will be the same gold color on a dark blue background (My best friend’s wedding colors) If you want different layers to have different colors (i.e. water = blue, roads = black, etc. I’d suggest either adding these aesthetics as data in this step with the use of the map2() or pmap() functions, or omit the use of the list_rbind() function and set the individual layers in your ggplot instead. You can see these suggestions fleshed out in the Alternative Aesthetics section of this post.

#=============================================================================#
#Cropping OSM data to fit circle-----------------------------------------------
#=============================================================================#

#Calculating intersections-----------------------------------------------------
#Native pipe (|>) does not evaluate this properly like magrittr's#
osm_features_cropped <- map(feature_names, 
                            ~st_intersection(circle,osm_features_all[[.x]])) |>
  list_rbind()

Set Your Colors and Text

The hard part of grabbing the data is done. All that’s left to do is set some aesthetics. As mentioned, I kept this piece simple to mimic my friend’s wedding colors. I tend to store these colors/hex codes in separate objects. This is to make for faster editing if I want to create different pieces with different colors or options. I follow this same convention for the text options as well. In this project, I’m using the free Google fonts La Belle Aurore (For the title and annotated text) and Inter (for the heart in the center, where the Mackey House, our POI, is.) I’m using the second font because it is Unicode-friendly. I want to place a Unicode heart ♥ on the Mackey House. This is just a hacky way to do it. I’m sure there are plenty more options, like exploring the emoji package that’s available on CRAN.

To get the font exactly how I want, I’m choosing to utilize the glue, ggtext, and showtext packages as they will allow me to use the Google fonts with some HTML/CSS syntax to get my font/words/style just right.

You can replace the title and caption texts as you see fit or remove them for whatever you need.

#=============================================================================#
#Map aesthetic options---------------------------------------------------------
#=============================================================================#
#Setting all colors#
map_color <- "#e9d66b" #Gold/Yellow color
map_fill <- "#e9d66b" #Gold/Yellow color
map_background <- "#022052" #Dark blue/Navy Blue
outer_ring_color <- "#e9d66b" #Gold/Yellow color
inner_ring_color <- "#022052" #Dark blue/Navy Blue
POI_fill <- '#960503' #Red color
POI_color <- '#000000' #Black

#=============================================================================#
#Text Options------------------------------------------------------------------
#=============================================================================#
#Adding a pretty font from Google#
font_add_google("La Belle Aurore")
font_add_google("Inter")
showtext_auto()

title_text <- "The Mackey House"
caption_text <- glue("Jessica and Chris<br>",
                     "06 • 10 • 22<br>","Savannah, Ga<br>",
                     "Lat:<span style='color:",POI_fill,"'>",POI[["lat"]],
                     "</span> , Long:<span style='color:",POI_fill,"'>",
                     POI[["long"]],"</span></b>")
map_font <- "La Belle Aurore"

Build the ggplot

Finally, we can throw this bad boy together into a single ggplot. Just like we would with any other standard ggplot visual. The key here is to use the geom_sf() layer for all our geometry data. All of your aesthetics are mapped on the same way you would for any other type of data visualization. The only thing special or unique is the geomanipulation needed for the geom_sf() function to read and visualize the data properly within the ggplot.

You may be wondering about the border that is around the map. I’ve done some hacky stuff with geom_point() to achieve this. My original plan was to manually make the circle/border visual with data points; however, when I attempted this months ago, I couldn’t figure out how to correctly manipulate the coordinate system to project the circle properly, so I opted to use standard geom_point() shapes to make it happen. Both layers were figured out with trial and error based on my specific print size. Be mindful that you may need some trial and error tweaking for your particular needs.

#=============================================================================#
#Map Layering/Building---------------------------------------------------------
#=============================================================================#

#Adding OSM layers to the ggplot-----------------------------------------------
ggplot() +
  theme_void() +
  theme(plot.background = element_rect(
    fill = map_background,
    color = NA),
        plot.title = element_textbox_simple(
          halign = .5, 
          color = map_color, 
          family = map_font, 
          size = 240, 
          face = 'bold', 
          fill = NA,
          margin = margin(1,0,.1,0, 'cm'))) +
  geom_sf(data = osm_features_cropped$geometry,
          color = map_color,
          fill = map_color) +
  geom_text(data = center_POI,
            aes(POI["long"], POI["lat"], label = label),
            color = POI_color, 
            size = 31,
            family = "Inter") +
  geom_text(data = center_POI,
            aes(POI["long"], POI["lat"], label = label),
            color = POI_fill, 
            size = 30,
            family = "Inter") +
  geom_point(data = center_POI, aes(POI["long"], POI["lat"]),
             color = outer_ring_color, 
             shape = 21, 
             size = 399, 
             stroke = 10) +
  geom_point(data = center_POI, aes(POI["long"], POI["lat"]),
             color = inner_ring_color, 
             shape = 21, 
             size = 403, 
             stroke = 4) +
  labs(title = title_text) +
  geom_richtext(aes(x = POI["long"],
                    y = POI["lat"] - .011),
                label = caption_text, 
                text.color = map_color,
                family = map_font, 
                lineheight = .1,
                size = 50,
                fill = NA,
                hjust = .5,
                label.color = NA) +
  coord_sf(ylim = c(POI["lat"] + .008,POI["lat"] - .012))

#ggsave("finished map.png",
       #width = 16, 
       #height = 20, 
       #dpi = 300, 
       #units = "in")

This results in this beauty after we use ggsave() with our set output size:

#=============================================================================#
#Cropping OSM data to fit circle-----------------------------------------------
#=============================================================================#

#Storing the new colors#
feature_colors <- c( "#43963C", "#FCE8E6", "#9e220d", "#9e6e0d", "#ffffff")

#Calculating intersections-----------------------------------------------------
#Native pipe (|>) does not evaluate this properly like magrittr's##
osm_colors_df <- map2(feature_names, feature_colors,  
                             ~st_intersection(circle, 
                                              osm_features_all[[.x]] |>
                                                mutate(color = .y))) |>
  list_rbind()

#=============================================================================#
#Map aesthetic options---------------------------------------------------------
#=============================================================================#

map_background <- "#d9d1a0" #Tan Color
text_color <- "#000000"
outer_ring_color <- "#000000" #Black
inner_ring_color <- "#d9d1a0" #Tan Color
POI_fill <- '#190d9e' #Blue color
POI_color <- '#000000' #Black

ggplot() +
  theme_void()+
  theme(
        plot.background = element_rect(fill = map_background, 
                                               color = NA),
        plot.title = element_textbox_simple(
          halign = .5, 
          color = text_color, 
          family = map_font, 
          size = 240, 
          face = 'bold', 
          fill = NA,
          height = .1,
          width = 1.5),
        legend.position = "none"
        ) +
  scale_color_manual(values = rev(feature_colors),
                     aesthetics = c("fill", "color"))+
  geom_sf(data = osm_colors_df, aes(geometry = geometry,
                                    fill = color,
                                    color = color))+
  geom_text(data = center_POI, aes(POI["long"], POI["lat"], label = label), 
                        color = POI_color, 
                        size = 31,
                        family = "Inter")+
  geom_text(data = center_POI, aes(POI["long"], POI["lat"], label = label),
            color = POI_fill, 
            size = 30,
            family = "Inter") +
  geom_point(data = center_POI, aes(POI["long"], POI["lat"]),
            color = outer_ring_color, 
            shape = 21, 
            size = 399, 
            stroke = 10) +
  geom_point(data = center_POI, aes(POI["long"], POI["lat"]), 
            color = inner_ring_color, 
            shape = 21, 
            size = 403, 
            stroke = 4) +
  labs(title = title_text) +
  geom_richtext(aes(x = POI["long"], y = POI["lat"] - .011),
                label = caption_text, 
                text.color = text_color,
                family = map_font, 
                lineheight = .1,
                size = 50,
                fill = NA,
                hjust = .5,
                label.color = NA)+
  coord_sf(ylim = c(POI["lat"] + .008,POI["lat"] - .012))

#ggsave("map_v2.png",
       #width = 16, 
       #height = 20, 
       #dpi = 300, 
       #units = "in")

#Calculating intersections-----------------------------------------------------
#Native pipe (|>) does not evaluate this properly like magrittr's#
osm_colors_list <- map(feature_names, 
                            ~st_intersection(circle,osm_features_all[[.x]])) %>%
  set_names(., feature_names) 

ggplot() +
  theme_void()+
  theme(
        plot.background = element_rect(fill = "#82a775", 
                                               color = NA),
        plot.title = element_textbox_simple(
          halign = .5, 
          color = "#ffffff", 
          family = map_font, 
          size = 240, 
          face = 'bold', 
          fill = NA,
          height = .1,
          width = 1.5)
        ) +
  geom_sf(data = osm_colors_list$roads,
          color = "#B05f66") +
  geom_sf(data = osm_colors_list$buildings,
          color = "#64513b",
          fill = "#A68662",
          linewidth = 2) +
  geom_sf(data = osm_colors_list$landuse,
          color = "#734B09",
          fill = "#D78C10",
          linewidth = 2) +
  geom_sf(data = osm_colors_list$leisure,
          color = "#d1b39d",
          fill = "#4F443B",
          linewidth = 2) +
  geom_sf(data = osm_colors_list$natural,
          color = "#3b727c",
          fill = "#5CB2C2",
          linewidth = 2,
          linetype = 3) +
  geom_text(data = center_POI, aes(POI["long"], POI["lat"], label = label), 
                        color = POI_color, 
                        size = 31,
                        family = "Inter")+
  geom_text(data = center_POI, aes(POI["long"], POI["lat"], label = label),
            color = POI_fill, 
            size = 30,
            family = "Inter") +
  geom_point(data = center_POI, aes(POI["long"], POI["lat"]),
            color = outer_ring_color, 
            shape = 21, 
            size = 399, 
            stroke = 10) +
  geom_point(data = center_POI, aes(POI["long"], POI["lat"]), 
            color = inner_ring_color, 
            shape = 21, 
            size = 403, 
            stroke = 4) +
  labs(title = title_text) +
  geom_richtext(aes(x = POI["long"], y = POI["lat"] - .011),
                label = caption_text, 
                text.color = "#ffffff",
                family = map_font, 
                lineheight = .1,
                size = 50,
                fill = NA,
                hjust = .5,
                label.color = NA)+
  coord_sf(ylim = c(POI["lat"] + .008,POI["lat"] - .012))

#ggsave("map_v2.png",
       #width = 16, 
       #height = 20, 
       #dpi = 300, 
       #units = "in")

Save it Out and Get it Printed (If you Want)

Because I wanted this to be a wedding gift for my friend, I had the idea to save the output with the ggsave() function but then send it to a printer to get it on a canvas. I ended up using Canva’s printing services for this. While I wouldn’t use Canva for any bulk printing because of the price (say for a shop for merchandise), I will use it for one-off special things like this. My friend received it on time and the quality was great!

#=============================================================================#
#Final Image Export------------------------------------------------------------
#=============================================================================#
ggsave("finished map.png",
       width = 16, 
       height = 20, 
       dpi = 300, 
       units = "in")

That’s it! I want to note that I came across an existing blog by Taras Kaduk and a GitHub repository by Iva Brunec. I used both of these together with a lot of tweaking to get the final result here. If something wasn’t clear here, or you want to see their takes on this type of visual, go check out their work!

If this helped you out or you made anything as a result of reading, I’d love for you to share what you’ve made! Find me on Twitter (@meghansharris), Mastodon (@meghansharris@fosstodon.org), or LinkedIn (meghan-harris) to do so!

Conferences and Talks

So this one is probably the most known. I had A LOT of talks to prepare for and do. Some of you may have found out about me through one of the various talks I did in 2022. Most of the talks were about #rtistry (generative art in the R language), but I also gave more practical ones. The biggest one was obviously RStudio::Conf(2022). This was BY FAR the best conference experience I ever had despite being pregnant and in the middle of so many life-changing things all at once. I was literally onboarding at my new job and had jumped on a plane to D.C. less than a few days after unexpectedly closing on my first home. It was an absolute cluster of chaotic good.

At the conference, I assisted with the Making Art From Code workshop, was a diversity scholar, and gave my own talk, “Making Data Pipelines in R.”

_{Had to take pictures so I could know it was ✨real.✨}

Side note. If you LOVE R and are on the fence about ever going to a (Now Posit) conference, you should go if you can! In the past, if you submit a presentation or even a lightning talk, Posit has provided traveling and boarding assistance. If you are from an underrepresented group in tech, you can also apply for a diversity scholarship. It’s a great way to gain any needed assistance as well. Just like how Twitter used to be great (before the Twitter Exodus), imagine having that in real life for a few days. It was awesome. And I mean, come on, who doesn’t like stickers???

Job Change

One of the cool things about attending the conference was that I could meet some of my co-workers in real life! I recently changed jobs in 2022. I now work at the Prostate Cancer Clinical Trials Consortium (PCCTC) at Memorial Sloan Kettering Cancer Center. This has been a significant change so far, as it has allowed me to stop working so much. I went from having three jobs to one full-time one (and a Per Diem contract one if needed from time to time.)

At the time of writing this, I’m on parental leave now, but I’m excited to get to work when I get back. Some of my work will focus on streamlining internal stuff for reporting on prostate cancer studies, and I’m SUPER hyped about it. I’ve been using R for about four, going on five years now, and I think I’m finally starting to hone in on my “niche.” Besides making art with R, I get a lot of satisfaction from automating things. Building (hopefully) seamless pipelines that make work easier for people. I realized I’d rather spend months building pipelines than doing analyses, external client-facing, and the like. In other words, my current role as a data scientist in this capacity perfectly aligns with my pragmatic interests. Honestly, I’m super lucky there.

Family and Home Changes

Working at the PCCTC also went perfectly with home life. For those of you that missed it, I was very open about my infertility struggles after I got pregnant. But as life would have it, after trying aggressively for three years, I got pregnant right before I found out about the open position at the PCCTC. I almost didn’t apply for it because it felt wrong to do so, knowing that I would have to leave for parental leave.

Looking back, switching jobs was the best thing I could have done. I could support myself financially, stop trying to run a one-person data science team (like I had to do at my old job), and really just focus on working while learning new things everyday. An added bonus is being able to spend time getting to know my son and just being grateful that all the years of feeling like I was working myself to death eventually paid off (yes, even during late nights while I was on the verge of tears trying to console a crying baby 😅)

I have a lot to be grateful for. I feel like I have changed so much as a person and that I am really coming into the best version of myself that I can be. Whether we’re talking professionally or personally.

So, What About 2023?

So… what’s next? Honestly, this year I’d like to “lay low.” I want to actively stay home, study up on things, be a mother, and work. That’s all I want. So, professionally speaking, this is what I’ve got on my to-do list for 2023:

• Get projects done/foundations started at work _{(This has to be done as I have to work lol)}

• Open up my online art store _{(This doesn’t have to be done, but I probably should since I already made the store and everything.)}

• Re-launch the new version of my website _{(If you’re reading this, that means I did this! Go Me!!!)}

• Contribute to the textbook “Rtistry: Methods for Visual Generative Art Using R” along with Antonio Paez, Antonio Sanchez, and Jacquie Tran. _{(This has to be done as a contract was signed)}

That’s it. If I have energy for a blog post here or there, or if my job wants to send me to Chicago for Posit Conf this year (Travis, pls.) Then I’ll do that. But the goal is to work “passively” this year (if that makes any sense at all.)

Let’s Start with a Trig Refresher!

So, confession time. I have never taken a trigonometry class in my life! The closest I got was taking geometry in high school and I got a C. BUT, I was still able to make this piece, so no matter your math background, you can too! These waves are made with sine waves. You might be familiar with them already. We can code for basic sine waves in ggplot by setting up our data appropriately:

# Library Load-In====
library(tidyverse) #For everything data#

── Attaching core tidyverse packages ──────────────────────── tidyverse 2.0.0 ──
✔ dplyr     1.1.4     ✔ readr     2.1.5
✔ forcats   1.0.0     ✔ stringr   1.5.2
✔ ggplot2   3.5.2     ✔ tibble    3.3.0
✔ lubridate 1.9.4     ✔ tidyr     1.3.1
✔ purrr     1.1.0     
── Conflicts ────────────────────────────────────────── tidyverse_conflicts() ──
✖ dplyr::filter() masks stats::filter()
✖ dplyr::lag()    masks stats::lag()
ℹ Use the conflicted package (<http://conflicted.r-lib.org/>) to force all conflicts to become errors

#Let's Start with a Trig Refresher#========================#
theta <- seq(from = 0,
             to = 2*pi, 
             length.out = 100)

sine <- tibble(x = theta,
               y = sin(theta),
               label = 1:length(theta))

… and plotting it like this:

# A basic sine curve======
sine %>%
  ggplot(aes(x=x,y=y))+
  geom_line(color= "red", size = 3)

Warning: Using `size` aesthetic for lines was deprecated in ggplot2 3.4.0.
ℹ Please use `linewidth` instead.

All we are doing with this code is setting up a sequence of points in our theta variable. Using the seq() function. We’re telling R “Create 100 numbers between and including the values 0 to 2pi (6.283185). When we go to plot this data, we put theta on one axis (in this case, the x variable because I want my wave to be drawn horizontally on the plane), and then place the sine values of theta on the other axis. Note that these values don’t have to be 0 and 2pi. In the next section, we will switch this up. But let’s just take one more look at this wave with some labels attached:

# A basic sine curve with more detail pointed out======

sine %>%
  ggplot(aes(x=x,y=y, label = label))+
  geom_vline(xintercept = 0, size = 2)+
  geom_vline(xintercept = 2*pi, size = 2)+
  geom_line(color= "red", size = 3)+
  geom_point(color = "blue")+
  ggrepel::geom_text_repel(max.overlaps = 20, size = 3)+
  geom_text(aes(x = 0,y = -1),
           label =paste(sprintf('\u2190'),"theta's '0'"),
           nudge_x = .5,
           size = 3)+
  geom_text(aes(x = 2*pi,y = 1),
           label = paste("theta's '2*pi'",sprintf('\u2192')),
           nudge_x = -.5,
           size = 3)

Warning in geom_text(aes(x = 0, y = -1), label = paste(sprintf("←"), "theta's '0'"), : All aesthetics have length 1, but the data has 100 rows.
ℹ Please consider using `annotate()` or provide this layer with data containing
  a single row.

Warning in geom_text(aes(x = 2 * pi, y = 1), label = paste("theta's '2*pi'", : All aesthetics have length 1, but the data has 100 rows.
ℹ Please consider using `annotate()` or provide this layer with data containing
  a single row.

If needed, take some time to review the more detailed code/plot of the labeled sine wave. Understanding how data is selected to create the visuals on the plot will set you up for understanding how you can manipulate these visuals in the future.

Make the Transition from Basic Waves to Pretty Waves

OK. So we know how to make a basic sine wave. How do we turn that into a “pretty” wave? There’s multiple ways to achieve this, but we’ll just go through the way that the wave patch image is built from. In order to have more creative control over our wave’s aesthetics, we’ll turn our sine wave into a polygon object. First, we can start by setting our theta. Let’s change it up. This time instead of calling the length.out argument, we’ll call the by argument. The seq() function will automatically calculate all numbers between -.4 and -1.5*pi (-4.712389) by a value of -.1:

# Starting the transition to a pretty wave====
##Setting up our "range" on the x axis for horizontal waves=====
wave_theta <- seq(from = -.4,
             to = -1.5*pi, 
             by = -.1) 

We can now take our new theta and make a tibble, (data frame) for our waves. Say we don’t want these basic sine waves though. We can play around with our x variable when creating the data frame to get some interesting results. We need to also remember to arrange() our frame by the x variable. Or else we’ll run into plotting issues in the future. I’ll speak more on this later. Let’s call this new tibble, curve_top:

##Creating the "top" of our wave polygon====
curve_top <- tibble(x = wave_theta,
                    y = (sin(x)*cos(wave_theta))+exp(x*2)) %>%
  arrange(x)

What we have now is a data frame that contains points for a single sine wave that’s been manipulated a bit by multiplying the sine of x with the cosine of our new theta and then added to the logarithmic value of x squared. If you’re wondering how I figured this out, the answer is by trial and error. While I have taken calculus and geometry classes, I have a very basic understanding of what type of functions create what type of visuals. This basic knowledge is just enough to create some great visuals!

So, let’s look at just this “top” of the wave we made:

Nicer! But still basic. We need some dimension. We want to make a polygon, so now we need to add some sides and a bottom to make a complete polygon. There are many ways to go about doing this, but let’s try to create these pieces one by one for clarity. Let’s add a side to the right of this wave. To do so, first we find the maximum point of the x variable with the max() function, and subset the curve_top data frame with just that point in it:

##Grab the max X value in the wave from the top wave====
max_x_point <- curve_top[which(curve_top$x == max(curve_top$x)),]

Using this row we’ve pulled out, we can simply add a row that includes the “bottom” of our side (because the top position of the side is just the last (max x) point in our wave. Because we want our side to connect to a “bottom” piece, we’ll use the add_row() function to increase the length of our side down the y axis by 0.5. Because of the way polygons are drawn, we should also set the option to have the “side” data rearranged in descending order of the y variable (since we want to move “down” on our plot):

##Create a subset of curve_top to create a "side" of the wave====
curve_side_right <- max_x_point %>%
  add_row(max_x_point - c(0,0.5))%>%
  arrange(desc(y))

Let’s see our addition:

Great! Next, we connect a bottom curve to the side we just created. For simplicity, we’ll use a copy of curve_top that has its y values decreased by 0.5 (the same length as our side we just made. Because of how geom_polygon() will draw onto the plot, we should arrange the x values in the decreasing order for this part of the wave as well:

##Create a copy of the curve_top dataset with the y values decreased by .5====
curve_bottom <- curve_top %>%
  mutate(y = y - 0.5) %>%
  arrange(desc(x))

Let’s take a look:

##Viewing the top curve, curve_side_right, and curve_bottom together====
curve_top %>%
  ggplot(aes(x=x, y=y))+
  geom_path()+
  geom_path(data = curve_side_right, aes(x=x, y=y), inherit.aes = FALSE)+
  geom_path(data = curve_bottom, aes(x=x, y=y),inherit.aes = FALSE)

Aww yeah. Getting closer. Finally, we can close this up by adding the final left side. We can finish this by doing the exact same thing we did for the right side, only this time we’ll subset out the minimum value with the min() function. This time we want to arrange the y variable in ascending order because we want to move “up” the plot. Our code is essentially going to be set up to draw the polygon in a clockwise fashion starting with the top curve:

##Grab the min X value in the wave from the top wave====
min_x_point <- curve_top[which(curve_top$x == min(curve_top$x)),]

##Create a side that will connect curve_top and curve_bottom on the left side====
curve_side_left <- min_x_point %>%
  add_row(min_x_point - c(0,0.5)) %>%
  arrange(y)

Now that we have all of our sides in our wave, we can actually just bind all of these data frames together into one data frame with the bind_rows() function and then view it:

##Slap all of them together into one dataframe IN ORDER (top,right,bottom,left)
wave <- bind_rows(curve_top,curve_side_right,curve_bottom,curve_side_left)

##View the entire thing====
wave %>%
  ggplot(aes(x=x, y=y))+
  geom_polygon()

YESSSS!! (I’m way t00 excited, I know.) If you now try to visualize creating this shape in a clockwise fashion, it might make sense why we arranged those different variables. The following rules will become extremely important once we get further into this piece:

• curve_top is drawn from left to right. The x variable needs to be in ascending order to go right.

• curve_side_right is drawn from top to bottom. The y variable needs to be in descending order to go down.

• curve_bottom is drawn from right to left. The x variable needs to be in descending order to go left.

• curve_side_left is drawn from bottom to top. The y variable needs to be in ascending order to go up.

This is also visualized with notations below:

Keep in mind that the true behavior of geom_polygon() is not to go in a clockwise fashion, but it’s actually to follow the order of the data you supply to it. Because of the order in which the sides of the waves are created in this example, this is one possible version that makes sense. All visuals made with geom_polygon() do not need to be ordered in a clockwise fashion.

Ok so we have one wave, but the wave patch image has multiple patterns of these waves. While I won’t recreate the whole thing, I can plant the seed. Our next step is to make a function to help us with this.

Creating Functions for the Waves

We could take our waves data frame and repeatedly change our ggplot code to create different layers of these waves, but, we can save a lot of work by creating a custom function for this purpose. If you need to brush up on functions and iterations in R programming, you can always check out “R for Data Science” by Hadley Wickham and Garrett Grolemund. Specifically, chapters 19 and 21 on Functions and Iterations, respectively.

What we want to do is take our waves data frame that we’ve already created and iteratively make new data frames with slightly different y values and combine all of that together into one data set. This will create different wave layers on a single plot and streamline our code because we only have to refer back to one data frame instead of multiple ones.

We’re going to create a function called wave_maker that can do this below:

# Creating a function for iterations====

wave_maker <- function(n, wave_df){

  #Creating an empty list to store our multiple dataframes(waves)#
  wave_list<- list()
  
  #Creating a for loop to iteratively make "n" amount of waves#
  for(i in seq_along(1:n)){
    
    wave_list[[i]] <- wave_df %>%
      mutate(y = y - (0.5*i),
             group = i)  
  }
  
 #returning the completed data frame to the environment#
  return(bind_rows(wave_list))
}

Great! This is a smaller function that can probably be more efficient, but it gets the job done. Let’s break it down:

• First we create the function with the function() function (lol). Inside we are supplying two arguments. n which is the amount of wave layers that we want to draw on the ggplot and wave_df, which will be the initial wave data frame we created earlier.

• Next, we create an empty list that will be used to store each n (layer) of waves/data frames.

• Next, we initialize the “for-loop” to run through n amount of iterations. For each iteration, we will mutate the y variable of the original wave data frame, and add a group variable that will automatically be identified by each iteration (i)

• Finally, we have the function return a nice, tidy data frame with all the data for each of our n layers.

Now we can actually create our data frame with this function like so:

# Creating the final data frame used for plotting====
wave_layers <- wave_maker(5, wave)

We can plot this as is, or we can add some color! Let’s add some color using the RColorBrewer package. Because we made 5 layers back in our wave_maker function, we’ll have five polygons to fill. Let’s just randomly pick 5 colors from the Spectral palette in the package and set them in a vector called colors_pal. Because we want to make sure enough color values are applied to all of the points in the wave_layers data frame, we can use the rep() function to repeat the values enough times to fill all of the polygons. I’ll touch more on those specifics in a bit:

# Picking a random color palette from RColorBrewer for the waves
#We made 5 waves, so let's pick 5 colors#
colors_pal <- sample(RColorBrewer::brewer.pal(10,"Spectral"),nrow(wave_layers)/nrow(wave), replace = TRUE)

Finally, we can plot our new waves!

# Final Plotting====
wave_layers %>%
  ggplot(aes(x=x,y=y, group = group))+
  theme_void()+
  theme(plot.background = element_rect(fill = "#ffffff", color = NA))+
  geom_polygon(color = "black", 
               size = 2, 
               fill = rep(colors_pal, each = nrow(wave)))

Fantastic! Because I didn’t set a seed, your colors might be different than mine, but that’s OK. While I won’t go into full detail because this tutorial expects you to already be familiar with ggplot and its aesthetics, I will call attention to the group aesthetic and the color aesthetic in this example. If you recall the wave_maker function, it automatically created a new variable called group in each iteration of our wave data frame. The group aesthetic is our way of telling R and the ggplot system that we want to keep data points that are associated with the same group value drawn together. This is how we can get our waves and their colors mapped as intended. If we didn’t set this group argument, our plot would look a little different:

You should also note the color aesthetic in the geom_polygon() function. Although we only have 5 layers, we’re actually supplying 460 values to this layer. This is because we need to apply a color value for each point that makes up a polygon. Because our initial wave data frame has 92 rows (or points) in it, if we want to color one wave we’d need 92 color values. If we want to color 5 waves we’d need 92 * 5 which is the 460. This code is set up for reproducibility, so as you change your n in the wave_maker function, it should continue to cycle through whatever color values you supply it.

Depending on how you change the coding for the color palette, you may need to be mindful of the logic needed as you start to explore different possibilities. Always try to make it easier on yourself by coding for reproducibility. I’m sure there are more efficient ways than the methods I’ve presented here but it’s a good start!

Go Forth and Make Some Waves!

OK! You have the foundation needed to make some awesome rtistry! Please feel free to take this wave maker function and explore. Use it as an opportunity to practice ggplot iterations, functional programming, building polygons, and more! Not much is required to even make drastic changes to how these waves look. For example, changing how the y variable is mapped in the aes() argument changes the wave:

# You've got the foundation you need now! Go forth and make some awesome waves! Manipulating these aren't too bad#

#An Example: - Simply changing the y value in the aes call creates a different set of waves :)#
wave_layers %>%
  ggplot(aes(x=x,y=y*x, group = group))+
  theme_void()+
  theme(plot.background = element_rect(fill = "#ffffff", color = NA))+
  geom_polygon(color = "black", 
               size = 2, 
               fill = rep(colors_pal, each = nrow(wave)))

Are you going to make some awesome waves? Or feel the need to strip this code apart and make it your own? Please feel free to do so! If you’re on Twitter and want to share your creations, don’t hesitate to share with the #rtistry tag or even mention me if you want to (@meghansharris) I’d absolutely love to see what you create!

Introduction

First things first: let’s get one thing straight, I am NOT an expert, nor am I a computational scientist or a professional generative artist. While knowledge of some “math things” can be super helpful, you don’t need to know complex computational mathematics to make Rtistry (aRt). Granted, if you enjoy and want to create aRt similar to the works of Thomas Lin Pedersen and Danielle Navarro, then maybe you do! But as a beginner, it’s important to remember that your Rtistry is your work and opportunity to learn, grow as an R programmer, and create pieces you can be proud of. Remember that your aRt is an expression of you and no one else and that there is no “right” way to do Rtistry. One of the things I love most about creating aRt is the fact that I don’t have to get anything “right.” For those of us who use R for work/educational endeavors, we must ensure that our statistics, programming, and literally everything else is correct. Creating Rtistry can provide your mind with not only a creative outlet but a way to still practice programming in R in a low-stress environment where things don’t have to be “right.”

Ethics

While using others’ work as inspiration to give yourself ideas is OK, you should always strive to create something of your own merit. Just like in the physical art world, you may also find that some aRtists may not want to share their process or code with you. Those that are new to Rtistry may be shocked by this. Some newbies may even think that creators come off as standoffish or rude if they decline to share their work. This could be because of how supportive the R community usually is and how we are always seemingly ready to share our code.

One thing to remember is that a creator could decline to share their code for many reasons. Those decisions are personal and left up to each aRtist on an individual basis. The aRtists that do exceptionally unique work will have usually put a lot of effort and hours into their pieces to a point where it may even feel proprietary. Some aRtists choose to sell their outputs not only because they have made something truly personal to them, but because they’ve also made something unique that probably hasn’t existed before.

When you find an Rtistry piece that appeals to you, you could try to understand what’s happening behind the scenes instead of asking directly for the code. It tends to be a fun challenge to figure out what’s happening yourself. It’s a lot of work, yes, but I am willing to bet that if you use R for professional work, the work and study you do to figure out how to create your pieces will benefit you in the long run.

What you choose to do with the pieces you create is entirely up to you. Some aRtists get their work printed for sale or personal use, some look into selling them as Non-fungible Tokens (NFTs) and some literally save their output and never save their code, completely erasing its footprint in a cathartic click of a button. Whatever you do, always give credit where credit is due; don’t assume that everyone is willing to share their code with you (but if they do, always express gratitude and give credit for the assist); and try to be ethical in everything that you do.

Geoms

If you want to start making data aRt in ggplot, having some knowledge on ggplot geoms will prove to be very useful. If you’ve ever participated in a #tidytuesday challenge or have made visuals in ggplot, you’re probably familiar with them. The key to using geoms to create your aRt is to understand what type of data is expected for each geom. Some basic ones to start with are:

• geom_point()
• geom_line() & geom_path()
• geom_segment() & geom_curve()
• geom_polygon()

There is no limit to which geoms you can use for aRt in ggplot. Your only barrier would be not having your data formatted appropriately for whichever geom you wish to use. For example, if you want to use geom_segment() you’d need to know that this function expects four different data points (x, xend, y, and yend). The geom functions will usually do a good job of throwing an error and letting you know if you’re missing any data points. If you’re interested, you can always learn more about ggplot with the official cheat sheet or book.

Geoms Examples:

You can think of basic geoms as instruments (paintbrushes) in your Rtistry toolkit. Here are a few simple examples of how each can be used:

Geom points can be used for textures, smaller details, or optical illusions like in the image Candy Rope:

Geom line and path can be used to create linear details and abstract aRt :

Geom segment & geom curve can be used for linear/curved details, or larger components:

Geom Polygon can be used to make any shape that can exist on ggplot’s coordinate system, Like lots of randomized squares:

Making and Applying (Rtistry) aRt Data to Geoms

If the geoms are the instruments in your toolkit, the data is your ink/paint. The data you provide to each geom will produce visuals on ggplot’s coordinate system. Thinking about it broadly, to make one point on a basic ggplot you need at least one x and one y value:

library(tidyverse) #For everything data====

── Attaching core tidyverse packages ──────────────────────── tidyverse 2.0.0 ──
✔ dplyr     1.1.4     ✔ readr     2.1.5
✔ forcats   1.0.0     ✔ stringr   1.5.2
✔ ggplot2   3.5.2     ✔ tibble    3.3.0
✔ lubridate 1.9.4     ✔ tidyr     1.3.1
✔ purrr     1.1.0     
── Conflicts ────────────────────────────────────────── tidyverse_conflicts() ──
✖ dplyr::filter() masks stats::filter()
✖ dplyr::lag()    masks stats::lag()
ℹ Use the conflicted package (<http://conflicted.r-lib.org/>) to force all conflicts to become errors

## Example 1: Data Frame====
single_point <- tibble(x=0, y=0)

## Example 1 ggplot====
single_point %>%
  ggplot(aes(x = x, y = y))+
  geom_point()

Having several x and y points is what will get you some shapes, lines, and other things:

## Example 2: Data Frame====
random_lines <- tibble(x = sample(1:500, 50),
                       y = 1:50)

## Example 2: ggplot====
random_lines %>% 
  ggplot(aes(x=x, y=y, xend = median(x), yend = median(y)))+
  geom_segment()

The magic happens when you can start viewing the grid differently. When you begin to understand the relationship the values in a data frame have with the ggplot coordinate system, it becomes easier to realize what data is needed to create your desired output. For example, if you want to create abstract art, you might practice making datasets with randomized values. If you want to make intentional pieces, you might spend time studying the axes of the ggplot and determine what range of values you need to make the figures you want. The process of creating data for Rtistry and applying them to geoms can be as simple or complicated as your creativity allows. Let’s just go over a simple example with a basic square.

We know that a square consists of four lines. Each line has a start and endpoint. So, we at least need to make four points on our plot. Since each point consists of two values (x and y), we’ll need eight values in total. Four x points and four y points.

## Example 3: Data Frame====
square <- tibble(x = c(0,5,5,0), 
                 y = c(0,0,5,5),
                 labels = 1:4)

Because we want to make a shape that’s closed (so we could potentially fill it with color), we’d want to use geom_polygon(). You might be thinking “why not use geom_line() instead?” because a square consists of four lines, but let’s look at that. If we make a data set of the points that are supposed to make a square but then pass it through to geom_line() or geom_path() functions, we get these instead:

## Example 3: Geom_line() ggplot====
square %>%
  ggplot(aes(x = x,
             y = y,
             label = labels))+
  geom_line()+
  geom_label()+
  coord_equal()

## Example 4: Geom_path() ggplot====
square %>%
  ggplot(aes(x = x,
             y = y,
             label = labels))+
  geom_path()+
  geom_label()+
  coord_equal()

geom_line() looks this way because it plots points in order by the x axis. Try to take a moment to compare the data and the result and understand why it came to be.

geom_path() looks closer to a square! But we’re missing a side! This is because geom_path() doesn’t create a fully closed shape by default. geom_path() is the same as geom_line() except it plots points in the order in which it appears in the dataset.

Now let’s use geom_polygon() with the same data set:

# Example 5: Geom_polygon ggplot====
square %>%
  ggplot(aes(x = x,
             y = y,
             label = labels))+
  geom_polygon()+
  geom_label()+
  coord_equal()

There we go; An actual square. geom_polygon() is similar to how geom_path()’s process of drawing lines works. The only difference is that the start and endpoints are automatically connected and you can add a “fill” aesthetic to your new shape. By default, ggplot does fill the square. You can set fill = NA to make it empty, but remember to set a color argument if you want to see the “border” of the polygon make its shape:

# Example 6: Geom_Polygon ggplot with no fill====
square %>%
  ggplot(aes(x = x,
             y = y,
             label = labels))+
  geom_polygon(fill = NA, color = "black")+
  geom_label()+
  coord_equal()

As a beginner, it’s tempting to try and make every cool idea that comes to you, but it’s a good idea to spend time with these basics first. You can explore creating aRt data sets with formulas you may be interested in or with any of the “non-visual” functions I’ll discuss later in the article. Once you feel comfortable creating aRt datasets and applying them to geoms, you might be able to find cool and unexpected ways to plot things!

Aesthetics

The next important set of basics to learn about is ggplot aesthetics. We’ve already used aesthetics in the previous section’s examples, but let’s think about them a bit more. Each base ggplot and geom function comes with available aesthetics. If you’ve ever made a ggplot visualization and changed any colors, shapes, etc., you’re already familiar with the foundations needed to start customizing the look/style of your work.

There’s two ways you can map aesthetics onto your visuals:

1. The aes() function in your initial ggplot() function
2. Directly into the geom function you wish to change.

As you explore what you want to do and how you want to style your data, you may find that you prefer one way over the other. If you get stuck on this part, take some time to think about what you’d like to see on the grid and then think logically about which method would make sense.

For example, if you have a variable that contains hex color codes attached to each row in a dataset, it may make sense to set up the aesthetic in the aes() function since it’s already connected to the data. If you have a circumstance where you only want one geom to be one color, or you want to map a different data set of aesthetics to the geom, you can put it into the actual function.

A word of caution though, if you want to add values from a different dataset, make sure they have the same number of rows as the initial data set that you are piping into the initial ggplot’s function. If they don’t match up and you don’t set the inherit.aes argument to FALSE in the geom, you’ll get an error. There are ways to use different data sets in addition to the initial one used at the beginning of your ggplot call. I’ll touch on this in the layering section of this article. For now, let’s take a quick look into setting aesthetics in our square example:

Let’s say we want to color our square purple and make colored dots on each point of the square. Because the polygon will only be filled with one color, we can set that in the geom_polygon() call. If we add a color variable to our data set with individual hex color codes attached to each observation, we can place it in the aes() function and get our desired output with the following code:

# Example 7: Geom_Polygon ggplot with colored points====

## Example 7: Data Frame====
square_color_points <- tibble(x = c(0,5,5,0),
                 y = c(0,0,5,5),
                 colors = c("#c0d943","#027337","#d12017","#000a96"))
                 
## Example 7: Geom_Polygon ggplot with colored points====
square_color_points %>%
  ggplot(aes(x = x,
             y = y))+
  geom_polygon(fill = "#4b1980")+
  geom_point(color = square_color_points$colors)+
  coord_equal()

We can also change multiple aesthetics at once. We can change the size of our points too:

# Example 8: Geom_Polygon ggplot with colored points and Random Sizes====
square_color_points %>%
  ggplot(aes(x = x,
             y = y))+
  geom_polygon(fill = "#4b1980")+
  geom_point(color = square_color_points$colors,
             size = sample(1:20, nrow(square_color_points)))+
  coord_equal()

As you get more comfortable with aesthetics, you will find that there may be different ways to explore these settings programmatically using various ideas or functions. One of the greatest things about Rtistry is realizing that you may already have the programming knowledge necessary to use these basic components to create amazing things.

At the end of the day, if you find yourself stuck on how to do something, it may be helpful to search google, the RStudio Community forums, or even Stack Overflow for the answers to programming questions that may help you piece together your Rtistry. In my experience, I’ve always had the best results when I take a moment to stop and think about what I am asking R to do programmatically. R doesn’t know that I want to randomize colors for an image, but it will know if I want it to pick random hex color values from a vector by using the sample() function. I can then apply that result to an aesthetic option and get the desired output.

If I were googling for the answer to this example, I wouldn’t type “how to randomize colors of geom_point()” but instead I’d type “how to randomly pick values from a vector in R programming.” It may take a little bit to understand this thought process, but you are programming after all, so try to approach any troubleshooting as if you were coding for “actual work”.

Using “non-visual” Functions For Your Visuals

The first time I realized that you could pass additional functions into aesthetic options - my mind was blown! I did not realize that anything other than a string of a hex color could go into a color aesthetic in ggplot. My mind was so stuck on how I learned to code for ggplot. It was also bound by the fact that I never needed to think about setting any options outside of regular color “strings” for my everyday work. Take the random data below. We could change the colors of these random points by applying some random colors…

## Example 9: Data Frame====
random_points <- tibble(x = 1:100,
                        y = sample(1:100))

## Example 9: ggplot of randomized points====
random_points %>%
  ggplot(aes(x=x, y=y))+
  geom_point()

## Example 10: ggplot of randomized points with randomized colors====
random_points %>%
  ggplot(aes(x=x, y=y))+
  geom_point(color = sample(RColorBrewer::brewer.pal(5,"PRGn"), nrow(random_points), replace = TRUE))

…Or by placing a logical function in the color aesthetic for geom_point(). For example, we can tell R that we only want to apply randomized colors to any data points that have a y value that’s less than 50, otherwise observations with a y value that’s greater than or equal to 50 will just be colored black with an ifelse() function:

# Example 11: ggplot of randomized points with randomized colors and logic applied====
random_points %>%
  ggplot(aes(x=x, y=y))+
  geom_point(color = ifelse(random_points$y < 50,
                            sample(RColorBrewer::brewer.pal(5,"PRGn"), nrow(random_points), replace = TRUE),
                            "black"))

Since there is no limit to the different types of functions a user can make, the possibilities of different functions that can be added to aesthetics seems endless. A few functions that might help you not only in aesthetics, but working with your data prepping are listed below to get you started:

• sample() – Randomly take a sample from elements of an object
• rep() – Replicate (repeat) elements in a vector or list
• seq() – Generates numeric sequences
• runif() – Returns a random composition of numbers with a uniform distribution
• dnorm() & rnorm() – Creates a normal density distribution and random normal distribution of numbers
• Trigonometric Functions (cospi(),cos(),sin(), etc.) – Results in the computation of various trigonometric functions.
• Crossing(), expand(), nesting() – Tidyr functions that expand data frames to include possible combinations of values.
• Control-flow constructs (while, repeat,if, for, etc.) – Can be used to create iterations, patterns, and functions of your own.
• Apply family functions (lapply, sapply, etc.) – Can be used to apply functions on different objects like matrices, vectors, or lists.

Remember that this is not an exhaustive list, but just a taste of some commonly used functions to hopefully get the gears turning about different ways you can manipulate your ggplot aesthetics and actual Rtistry data.

Layering

The last basic concept in this post is ggplot layering. Adding layers with the layer() function or even annotations with the annotate() function is very useful as it allows the user to add different layers of data. You can also achieve this by adding geom functions as you would normally, but if you ever want to add geoms that pull from different data sources this way, you need to set the inherit.aes argument to FALSE, as this will then allow the ggplot to build without error.

These multiple ways of layering allows for endless possibilities as piecing together an image this way provides a bit more flexibility. Take the two datasets below. One is intended to just create some lines with geom_segment(), and the other is intended to just create circles in between each line with geom_point(). Because we want 4 lines and 3 circles, the amount of data needed to map these things don’t match up. We can tell this on a quick glance by seeing that the number of rows in each data set don’t match up:

## Example 12: Lines_data Data Frame====
Lines_data <-  tibble(x = rep(1, 4),
                      xend = rep(5, 4),
                      y = seq(0,6, by = 2),
                      yend = y )

## Example 12: Circles_data Data Frame====
Circles_data <- tibble(x = 3,
                       y = unique(abs(seq(0,6, by = 2) - 1)),
                       size = 1:3)

##Logic Check: Do these dataframes have the same number of row?##
nrow(Lines_data) == nrow(Circles_data)

[1] FALSE

If we try to add these together by just using a geom function ,geom_point(), and supplying the Circles_data directly into geom_point() without typing inherit.aes = FALSE, the console will throw an error:

## Example 12: Lines_data and Circles_data error====
Lines_data %>%
  ggplot(aes(x=x, y=y, xend = xend, yend = yend))+
  geom_segment(size = 15)+
  geom_point(data = Circles_data, aes(x=x, y=y, size = size)) 

This error tells you that object xend is not found. This is because we are attempting to override the data frame that is attached to the entire ggplot (Lines_data) with Circles_data now and xend definitely does not exist in Circles_data and therefore “can’t be found.” To fix this specific example and get the desired results, simply add inherit.aes = FALSE into the geom_point() function. If desired, you also could just move the aesthetics for Lines_data into the geom_segment() function but as you will find, there are multiple ways to get to the same result. For this example though, we’ll just add the inherit.aes argument to geom_point().

## Example 12: Adding Lines_data and Circles_data together with inherit.aes in geom====

Lines_data %>%
  ggplot(aes(x=x, y=y, xend = xend, yend = yend))+
  geom_segment(size = 15)+
  geom_point(data = Circles_data, aes(x=x, y=y, size = size), inherit.aes = FALSE)

Warning: Using `size` aesthetic for lines was deprecated in ggplot2 3.4.0.
ℹ Please use `linewidth` instead.

We can also use the layer() function or the annotate() function to achieve similar results. Both methods are used in the example below:

# Example 13: Adding Lines_data and Circles_data together with layer function====
Lines_data %>%
  ggplot(aes(x=x, y=y, xend = xend, yend = yend))+
  geom_segment(size = 15)+
  layer(geom = "point",
        data = Circles_data,
        stat = "identity",
        position = "identity",
        mapping = aes(x=x, y=y, size = size),
        inherit.aes = FALSE)

# Example 14: Adding Lines_data and Circles_data together with annotate function====
Lines_data %>%
  ggplot(aes(x=x, y=y, xend = xend, yend = yend))+
  geom_segment(size = 15)+
  annotate(geom = "point",
           x= Circles_data$x, 
           y= Circles_data$y, 
           size = Circles_data$size)

Both functions produce similar images. The layer() and annotate() functions have their own pros and cons based on what you’d like to do. As shown in the code snippets, each method of layering in ggplot is similar but has its own differences that may be favored in certain situations. I’d encourage you to read and explore these methods of layering a bit more, and to see what works best to execute your ideas.

Planet Quad – aRt Example

Now that we’ve gone over some technical basics, let’s look at two Rtistry examples I’ve created. The first is Planet Quad. The creation of Planet Quad demonstrates how we can utilize other packages like patchwork and cowplot to create our own Rtisrty. Let’s break this down step-by-step.

Each layer in ggplot is built on top of each other in the order in which it appears in the code. For this image, that means we want the space/stars background to be behind our planets- so we can start with that first.

We want four different plots with a similar design in different colors, so we can start by creating a named vector of the background colors we want to use. I always use hex colors, but you can use whatever format you’d like. I’ll name mine Space_colors:

# Library Load-In====
library(tidyverse) # For everything data
library(cowplot) # For placing plots on top of each other easily with ggdraw and draw_image

Attaching package: 'cowplot'

The following object is masked from 'package:lubridate':

    stamp

library(patchwork) # For packaging up the plots in the final image

Attaching package: 'patchwork'

The following object is masked from 'package:cowplot':

    align_plots

# Star Backgrounds====

## Making four different stars "backgrounds" with four different colors====
Space_colors <- c("Topleft"="#000000",
                  "Topright"="#130321",
                  "Bottomleft"="#330500",
                  "Bottomright"="#8a4500")

Next, we want to create the data for the stars in our backgrounds. Because I want the image to look pretty filled in, I’ll apply the crossing() function to the data in this tibble that I’ll name stars:

# Making a data set that will be used to create all star backgrounds====
df_stars <- tibble(crossing(x = seq(1,2000,100),
                         y = seq(1,2000,100)))

Next, we want to make a list because we’ll run iterations of our df_stars dataset through a ggplot call that will also iterate through our vector Space_colors. This will result in a list of four similar plots that all have a different color scheme. We’ll name this list All_stars and name the plots inside of the list to make it easier to track each plot as our session continues:

## Making the list to hold the "space" plots====
All_stars <- list()

## Iterating through the "space_colors" to make four different plots====
for(i in seq_along(Space_colors)){
  
  All_stars[[i]] <- df_stars %>%
    ggplot(aes(x = x, y = y))+
    geom_jitter(size = sample(c(.02,.04,.06,.8),nrow(df_stars), replace = TRUE), color = "white")+
    theme_void()+
    theme(plot.background = element_rect(fill = Space_colors[i], color = "#ffffff", size = 6)) 
}

Warning: The `size` argument of `element_rect()` is deprecated as of ggplot2 3.4.0.
ℹ Please use the `linewidth` argument instead.

## Naming the plots just to help keep track of what's going where====
names(All_stars) <- names(Space_colors)

Now we can check and look at one of our plots by typing All_stars$Topleft in the console to verify that it looks like what we were expecting:

All_stars$Topleft

Now, we can work on our planets. The planets are actually just a geom_density2d_filled() plot that will go through four iterations of the planet data set with its coordinate system set to [coord_polar()](https://ggplot2.tidyverse.org/reference/coord_polar.html. Just like we did for the stars data, we also want four very similar plots with different colors. Again, we can make a similar function to create a list of these plots. We just need to generate four different iterations of the data set and pick some colors for the planet surfaces. Let’s start with picking color palettes for planets and different colors for the border lines of each planet. We can place each palette into a list called Planet_colors and each border color into a vector called Planet_borders:

# Planet Creations====
## Setting the color palettes for each planet quad====
Planet_colors <- list("Topleft" = c("#194157","#008dd7","#085b88","#26925e","#095c88"),
                      "Topright" = c("#480463","#392242","#1e0329","#bf9232","#120b17"),
                      "Bottomleft" = c("#47322d","#6b1c09","#a30000","#6b1d09","#851205"),
                      "Bottomright" = c("#c7a602","#998523","#ba690d","#755b3d","#dbab39"))

## Setting the colors of each planet's borders====
Planet_borders <- c("Topright" = "#333333",
                    "Topright" = "#120b17",
                    "Bottomleft" = "#260f09",
                    "Bottomright" = "#5c523a")

We’ll create some randomly sampled data to draw out our planets to encourage some weirdness in its final presentation. We’ll name the dataset planet:

# Making a dataset that will be used to create all the planets====
planet <- tibble(crossing(x = sample(1:1000,100, replace = TRUE),
               y = sample(1:2000, 100, replace = TRUE)))

Now we’ll create our list, named All_planets, that will be filled with our four different planets after it runs through our for-loop:

## Making the list to hold the "planet" plots====
All_planets <- list()

## Iterating through the "planet_colors" to make four different planet plots====
for(i in seq_along(Planet_colors)){
  
  All_planets[[i]] <- planet %>%
    ggplot(aes(x = x, y = y))+
    scale_fill_manual(values = sample(Planet_colors[[i]],100, replace = TRUE))+ #100 is just a arbitrary "safe" number I picked. geom_density does background calcs to create levels that varies based on data.
    geom_density2d_filled(color = Planet_borders[i], size = 2)+
    coord_polar(clip = "on")+
    theme_void()+
    theme(legend.position = "none")
}

## Naming the plots just to help keep track of what's going where====
names(All_planets) <- names(Planet_colors)

All these plots are now in our list All_planets. We can peek at one by typing All_planets$Bottomright into the console. Because a seed hasn’t been set anywhere, yours may look different than mine and that’s all right!

All_planets$Bottomright

Now we can save all these planet plots as images out into the directory so we can load them right back in as png files. Please note that if you are following along, you may have to alter the directory to avoid errors as this directory is located within my Data_aRt GitHub repo in my Planet Quad project file.

# Saving Planets into the directory====
for(i in seq_along(All_planets)){
  
ggsave(paste0("planets/",
              names(All_planets)[i],
              "_planet.png"),
       All_planets[[i]],
       bg = "transparent", 
       device = "png")
}

Saving 7 x 5 in image
Saving 7 x 5 in image
Saving 7 x 5 in image
Saving 7 x 5 in image

Next, we need to bring the processed png files back into the environment. We can do this with the png package. Because I’m only using this once, I chose to call in the readPNG() function directly from the package instead of loading the package itself. We’ll store the images in a list called Planet_PNGs.

# Loading Planets back into the environment as PNGs====
Planet_PNGs <- list()

for(i in seq_along(All_planets)){
  
Planet_PNGs[[i]] <- png::readPNG(paste0("planets/",
                                        names(All_planets)[i],
                                        "_planet.png"))
}

## Setting names to keep track of the planets====
names(Planet_PNGs) <- names(All_planets)

Now that we have png files, we can place these “on top” of our star backgrounds we made earlier using the ggdraw() and draw_image() functions from the cowplot package with for-loops. This time, we’ll store them in a list called Combined_plots:

# Combining both the stars and planets to create four plots in total====
Combined_plots <- list()

for(i in seq_along(All_planets)){
  
  Combined_plots[[i]] <- ggdraw(All_stars[[i]]) +
                                  draw_image(Planet_PNGs[[i]])
}

## Setting names to keep track of the plots===
names(Combined_plots) <- names(Planet_PNGs)

Just like before, we can take a peek at any of the plots in the Combined_plots list to make sure it looks as expected. I’ll use Combined_plots$Bottomleft in the console to see:

Combined_plots$Bottomleft

Looking good! Almost done! Now we can pluck() each of our plots out and save them to individual objects! Because there’s only four of them, I’ll just copy and paste that code because this is Rtistry and it’s totally OK to be lazy. It’s your work. It’s your aRt . Do what you want!

## Plucking out all the individual plots===
Topleft <- Combined_plots %>% pluck("Topleft")
Topright <- Combined_plots %>% pluck("Topright")
Bottomright <- Combined_plots %>% pluck("Bottomright")
Bottomleft <- Combined_plots %>% pluck("Bottomleft")

Finally, we use pacthwork’s layout syntax to combine these plots into one image:

# Final output construction with patchwork functions====
Planet_Quad <- (Topleft + Topright) / (Bottomleft + Bottomright)

# View the piece#
Planet_Quad

And voila! We have our finished piece! I’ve noticed that sometimes patchwork may render in some borders around these images if ggsave() is used. In these cases, I just export using the Export button in the RStudio IDE.

Rainbow Rose – aRt Example

Finally, we’re at our last example! Rainbow Rose is an Rtistry piece that showcases one way trigonometric functions can be used to create cool results. This Rtistry piece was created from a beautiful accident when I mistyped some code while attempting to draw a circle from scratch in ggplot (yes, the geom_circle() function from ggforce exists, but I was trying to improve my manual ggplot skills 🤷🏾️).

To start out, we need to set up some specifications that will alter how the data is plotted onto ggplot’s Cartesian coordinate system. This includes calculating the “theta”(angles) of our intended circle, the number of divisions/data points we want in the dataset “n”, and the radial setting we wish to have for the visual. Because we want to give an effect that starts from the center of the image, we set the radial setting, “r” to a vector that spans from 1 to our “n” value.

# Library Load-In====
library(tidyverse) # For everything data

# Setting parameters to prep ggplot to plot data in a "circular" fashion on the Cartesian coordinate system====

## Angle "slices"/ Sine/Cosine Frequency====
theta <- seq(0, 40*pi, length = 100) 

## Number of divisions/rows in the data wanted====
n <- 500

## "Radial" setting of the "circle" to create "n" different marks====
r = 1:n

Next, I’ll use one of my favorite color palettes that I found for one of my #TidyTuesday submissions. I’ll store them in a vector simply called “colors”:

## Setting up the custom color palette====
colors <- c("#af3918", "#a21152", "#822b75","#612884","#154baf",
            "#0b82b9", "#277e9d","#488e35","#e3a934","#b2336a")

Now I’ll create a simple data frame. I’ll create my x and y variables using the cos() and sin() functions respectively:

# Placing everything into a dataset====
data <- tibble(x = cos(theta)*r,
               y = sin(theta)*r)

Finally, we’ll put everything together. Using geom_path() on this dataset and passing our colors vector into it creates our Rainbow Rose!

# Pulling it all together====
Rainbow_Rose <- data %>%
  ggplot(aes(x = x, y = y, color = color))+
  geom_path(color = rep(colors, each = n/10), size = 1)+
  theme_void()+
  theme(legend.position = "none",
        panel.background = element_rect(fill = "black"))

# View it #
Rainbow_Rose

Mesmerizing! Play around and investigate the options used to try and understand how/why ggplot generated the data this way.

For example, if we change geom_path() to geom_line() we get this:

Still pretty, but a completely different piece! Earlier in the article I mentioned the difference between geom_path() and geom_line() . Given their differences, does it make sense why this version looks this way? These are just some of the questions you can think about and ask yourself while you’re on your Rtistry journey!

There’s a Package for That

If you read all of this and still feel intimidated, that’s OK. You can still try to get into Rtistry with some of the following packages:

• aRtsy developed by Koen Derks “Aims to make generative aRt accessible to the general public in a straightforward and standardized manner”

• Ambient developed by Thomas Lin Pedersen and Jordan Peck(FastNoise) “…is a an R package that provides access to the FastNoise C++ library for generating noise.”

• Ggvoroni developed by Robert Garrett and Thomas Fisher “With ggvoronoi we can easily draw Voronoi diagram heatmaps, with help from packages deldir and ggplot2.”

• contouR developed by Ijeamaka Anyene “contouR is a package that is a wraparound for ggplot2::geom_contour() to use for generative aRt .”

• Jasmines developed by Danielle Navarro “The jasmines package is what Danielle uses to make a lot of her generative artwork with R. Internally it relies heavily on the ambient package, and you may need to install the developer version of ambient to make it work.”

Final Remarks

This concludes The Tidy Trekker Intro to Data Art post! I really hope that those of you who are just trying to start out in Rtistry found this to be useful. While the basics content truly is basic, it really is a good chunk of the foundation needed to eventually progress into more complex generative aRt . Sometimes it can be difficult to disseminate the how-tos or guides for a creative process. As you saw with the Rainbow Rose piece, sometimes aRt can be created by accident. Those accidents can only be unique to you. The best way to improve your Rtistry skills is to just jump in and play. Use the time to zone out, relax, and engage with data in a way you may not have before.

Have you started your Rtistry journey? Do you think some crucial basics were left out of this post? Feel free to contact me directly! Respectful discourse is always welcome!

The Idea

My TarotreadR idea was thought up before the Shiny competition this year. Recently, I’ve personally become interested in tarot cards (and was gifted The Modern Witch Tarot Deck by Lisa Sterle.) This is not because I was planning my career transition into tarot reading, but because I grew fond of the different art styles that different decks can have. I find it so interesting to look at how artists’ interpretations of these decks vary. I must also admit that I do like pulling cards for myself from time to time. I find that some people get surprised when I tell them that. I’m viewed as this highly analytical person that works in data science and “real things.” For me, I liken reading cards to using a fidget spinner in some sense.

As a mental health advocate, I’ve always been open about my mental health struggles and I must say that sometimes pulling tarot cards prompts me to use the Barnum Effect to my advantage by creating some distance from my anxious thoughts. This gives me the space to acknowledge what I already know within me. Being that I started doing this more frequently, I wanted an app that could spell out full interpretations of groups of tarot cards based on what was pulled. Interpreting tarot cards can get messy and confusing if you start doing more than one, and if you allow them to be reversed. It can get complicated because a reversed tarot card can have subtle but key differences in interpretations when compared to upright cards. So, given that I was already interested in this and wanted to do it, the idea of a simpler app, the TarotreadR, was born.

Instead of making fully tailored interpretations, the app would randomly pull cards for the user and give them keywords for each card based on if the card was upright or reversed. To get started with this, I wanted to do the tasks that I thought would take the longest: making the card images and creating tarot card data.

Making the Card Art and Data

The process of making the card art was a bit daunting but something I really wanted to do. The original tarot deck consists of 78 cards in total. Making the card art did take about 2 months over the course of a few sessions. It was the perfect time to get some use out of my Pro Canva account. I created each image by “collaging” various icons, graphics, and shapes together. This was a tedious process as it required thinking outside of the box to get the shapes and figures I wanted. The hardest part was trying to keep the figures (human silhouettes) consistent. Let’s just say I like some cards more than others.

While I was making the card art, I was also creating a dataset to go with it. For an app like this, the dataset was straightforward. I would just need three variables: The card’s name, the associated keywords (card meanings), and the position (upright or reversed/upside down) of the card. I used a combination of published meanings from biddytarot.com and labyrinthos.co to fill in the keywords of each card. This process also took about a few months as I only filled in the data once I completed the art for the card.

Creating the dataset was an iterative process. While I was working on the cards and data, I did start to think about the app structure. Trial and error eventually lead to me figuring out that the text in the “keywords” variable could be in plaintext HTML. This required me fixing the data to follow plaintext HTML and to then introduce line breaks in the UI of the app when keywords were displayed.

After I had a good foundation going with the cards and dataset, I had to finally face my fears and start trying to build the app in Shiny. I thought the best way to do this would be to try to wrap my head around the Shiny environment. I would be lying if I said I wasn’t terrified.

Understanding the Shiny Environment and Reactivity

Spoiler Alert: this part was actually not that bad! The worst is designing your app to make it look pretty and I’ll get to that nightmare shortly. If you’ve read one of my previous R walkthroughs, Making Dull Dashboards, you may recall me talking about the concept of reactivity when creating flexdashboards. The concepts I learned using the Crosstalk and SummaryWidgets packages to make flexdashboards prepared me to comprehend how the Shiny environment works. While I am still a Shiny noob in my mind, it’s definitely not as scary when you have a basic understanding of how the two major components of a Shiny app work together.

I think of a Shiny app as if it were a car made of two main components: the Server and the UI (User Interface). I think of the Server as everything under the hood of the car: the engine, fuel tank, electrical system, etc. I think of the UI as the frame of the car, the seats, the steering wheel, and anything else I would need to comfortably control the car.

I think of it this way: there’s a bare minimum that’s required for a car to turn on and operate. This is like having functions in your Server that, at its bare minimum, will allow the app to operate regardless of efficiency or the warnings that we might ignore in the console while our app is deploying. At its bare minimum, the UI should similarly be able to give the user basic functionality. In our car comparison this could be something as simple as making sure the car has a working ignition and a steering wheel. In the same sense, while our cars can operate with these bare minimums, we’d prefer to not see a check engine light, we’d prefer seat belts, and maybe some nice leather seats to sit on.

Once I started thinking about Shiny apps this way, I realized the importance of the interaction between the UI and the Server. I’m very excited to build from this knowledge to make better apps in the future, but for now, this basic understanding was all I needed to make the TarotreadR happen.

Designing the UI

Creating the UI was also an iterative process. It seemed I was constantly going back and forth between the UI and Server through trial and error. I expected this as I was essentially teaching myself as I progressed. One of the biggest challenges was learning that it’s REALLY helpful to have some knowledge of HTML, CSS, and even JavaScript when designing a Shiny app’s UI. While it’s not required to make an app functional, it is required to make an app pretty. I had a vision of what I wanted the app to look like, and to get that vision, I definitely had to spend some nights refreshing my HTML skills and learning new skills in CSS and JavaScript. These backgrounds were needed to figure out small things like not having cards appear until a user has clicked on an action button and having the cards animate onto the screen when a user “pulled” them.

Another challenge was figuring out spacing and sizing. It required thinking about the app and its components in a modular fashion. Boxes within boxes, if you will. Again, trial and error was my best friend here. The code you see above is a “Frankenstein” masterpiece that came to be after many iterations and failed deployments.

Setting Up the Server

Besides trying to teach myself CSS and minimal JavaScript in less than a month, one of the most difficult things about building the TarotreadR was figuring out the Server component. I needed to figure out how to randomize cards being pulled, but I also needed to get images to show up in the UI based on those randomizations. Things get even more difficult once you add in the reversed card positions.

My original thought was to only make the deck of cards one time and then figure out how to get the images to display in a reversed position programmatically. In my darkest hour, I gave up trying to figure out the CSS to make this happen. Every time I thought I had the answer, the image would somehow be off and not displaying correctly. In that moment, I shed a tear, closed RStudio, and opened up Canva and proceeded to make “reversed” images for each of the cards. In retrospect, I really wish that I would have stuck it out as it might have improved the TarotreadR’s performance (instead of loading 78 card images, it was now loading 156 card images for upright and reversed positions).

Having separate images did end up working for me with the help of this post by Jeroen Ooms. Once I got over the biggest hurdle of getting the images to display properly, I was able to add things like toggling (so that cards are only shown after a button is clicked) and sounds that play with the card animations.

Putting It All Together

Finally, after about three months, all of the work paid off! I finally finished all of the cards, completed all of the data entry, got the UI and Server to talk to each other, and successfully deployed the TarotreadR to Shinyapps.io. If you haven’t seen it action and would like to, you can here.

If you’d like to see the full code and files used to make all of this, you can find it in my Github Repo here.

Lessons Learned

After this whole experience, my professional and personal life got extremely hectic, and I didn’t get a chance to really talk about this publicly (which is what prompted this post). There are a few lessons I’ve learned that I want to highlight:

• CSS, HTML, and JavaScript are crucial to making attractive UIs (in my opinion).

• Sometimes it’s OK if your code is not the most efficient. You can still get your app to work – but it is in good practice to try and revisit the code to improve it if possible.

• Flexdashboards, Crosstalk, and SummaryWidgets are absolutely the reason why I was able to do all of this in three months. Learning these packages can ease you into understanding how app reactivity works.

• I have even more respect for web devs and those that make Shiny apps for a living (I already had a lot of respect for you guys, now it’s just astronomical).

• Shiny isn’t all that scary once you slow down and take the time to understand the environment.

Have you ever made Shiny apps before? Do you have “Shinyphobia” like I did? Are you screaming at the inefficiency of my program? (I know, I’m sorry!) Feel free to contact me directly! Respectful discourse towards efficient solutions or new insights is always welcomed!

The Example:

Let’s say we have a simple survey question that asks participants to select colors that they like. We allow them to “Check all that apply” and give them eight choices to choose from. It might look like this:

Checkbox question-types allow participants to select multiple choices. This can be useful for building strong analyses. However, we may find that the “checkbox” question-type produces undesirable data that will have to be dealt with. Let’s explore this by setting up our R session.

If you’d like to follow along within the R project files you can download them from the Tidy Trekker Github Repository. Be sure to fully extract the ZIP. folders for proper access. You can also download the data set used and load it into your own session for practice.

Using “separate_rows” from Tidyr and “count” from Dplyr:

The simplest and fastest way to tally up these results is to use tidyr and dplyr together. We start by loading in the packages we need: readr, dplyr, and tidyr. These allow us to get our data into the environment and prepare it for cleaning and manipulation. We’ll name the resulting data set “Colors.”

library(readr)
library(dplyr)

Attaching package: 'dplyr'

The following objects are masked from 'package:stats':

    filter, lag

The following objects are masked from 'package:base':

    intersect, setdiff, setequal, union

library(tidyr)
Colors <- read_csv("Data/Colors.csv", col_types = cols(`What colors do you like?` = col_character()))

Pay attention to the file path in the “read_csv” function. If you copy and paste that command and are not using the project files within the Github link above, you will get an error!

We can see our data set in the data viewer. Notice that each observation has a combined, comma-separated string for each response:

We need to tell R to separate the values in the What colors do you like? column into individual rows and then count and tally those occurrences. Let’s do this and store it in a data set called TidyrColors. The code for this can be written in one chunk with the following:

TidyrColors <- Colors %>%
  separate_rows(`What colors do you like?`, sep = ", ") %>%
  count(`What colors do you like?`, sort = TRUE, name = "Tally")

The separate_rows() function from tidyr separates all the values in the column while using “,” as the characters to separate on. Note that we have a whitespace after the comma in the sep= option. This is because whitespaces are present in the original data. If you had options that were only separated by commas and no spaces, you would just need a comma there.

Next, we used the count() function from dplyr to count the occurrences of our colors. Setting the sort= option to TRUE will arrange the observations in descending order in the dataset. The name= option will allow us to set the column name that will hold the count of the values. In this case, we’ve set it to Tally.

And that’s it! Pretty simple and straightforward. Continue on for more involved ways to do this that will give you some string/regex practice if interested!

Using Grepl (or Stringr), Dplyr, and Tidyr:

There are other ways we can do this that are a bit more involved, but can provide some grepl/regex and string manipulation practice if desired. If you choose to use Stringr instead of grepl, you can load in the stringr package as well.

# If using the stringr package===
library(stringr)

In order to get a tally of the individual responses, we need to break up these strings and create variables for each color. We do this by creating a new column for each of our color options available for our survey question. Let’s create a reference vector of all of our color options to help us. We’ll name it Colorref:

Colorref <- c("Red","Blue","Green","Yellow","Black","Orange",
"Brown","Pink")

Pay attention to the strings you enter into your reference vector. These strings need to match your survey responses/options PERFECTLY. Be mindful of any discrepancies in capitalization, spelling, spaces, or punctuations.

Using the reference vector we just created, we can now create an empty data frame that we can populate with our color tallies. We’ll call it Colorsnew. We can use base functions in R to do this. To ensure the tallies are properly recorded in the new data frame, we’ll set the number of columns to match the number of options (Colors) we have and the number of rows to match the number of observations (or rows) we have in the original data set. Afterwards, we replace the column names with the name of each color choice. This can be done with the names function.

Colorsnew <- as.data.frame(matrix(ncol = length(Colorref), nrow = nrow(Colors)))
names(Colorsnew) <- Colorref

The next step is to simultaneously populate all the columns in the data set with an accurate tally for each response. We can do this with the ifelse and grepl functions within one single “for-loop.” This will populate our currently empty Colorsnew data set so we can easily see our changes. The for-loop function will run iterations along the length of the Colorref vector and use the vector’s values to fill in the column names of our data. At the same time we’ll be getting getting a count of how often each color is present in the original Colors dataset with the grepl function. Detailed information about for-loops can be found in the Iteration chapter in the free textbook R for Data Science (written by Hadley Wickham and Garrett Grolemund) :

for (i in seq_along(Colorref)){
  Colorsnew[i] = ifelse(grepl(Colorref[i],Colors$`What colors do you like?`),1,0)}

To reiterate, this code uses the i variable as a placeholder to rename the columns within the Colorsnew data set with the strings found in Colorref (All of our color options.) For each column, we are using an ifelse() test to scan the original strings in the What colors do you like column from the Colors data set (Colors$What colors do you like?). Simultaneously, we check for matches using the grepl function. If you aren’t a fan of using grepl, you can also opt for Stringr’s str_detect() function that performs the same action.

for (i in seq_along(Colorref)){
  Colorsnew[i] = ifelse(str_detect(Colors$`What colors do you like?`,Colorref[i]),1,0)}

Whether you use grepl or stringr, the result will be the same. Each match will produce a “1” while non-matches produce a “0.” The result is a matrix of observations for all of our color choices:

Our last step will be to transpose this wide data into a long data format for easier graphing and analyses. (You can check out a tutorial on wide and long data in R from DataCamp here.) We do this using the pivot_longer, group_by, and summarise functions from the dplyr and tidyr packages. In our pivot_longer function, we tell R we want to transpose all of the columns in the “Colorsnew” dataset with dplyr’s everything() option. We tell R that we want all of our current column names to be put into one variable called Color and that we want the values in these columns to be put into its own column called Tally. Finally, we want to group the data set observations by the “Color” column and add all of the tallies up so we get a sum for each value within the Tally column. This will produce a data frame with a complete tabulation of all the color choices that were picked in our survey.

Colorsnew <- Colorsnew %>% 
  pivot_longer(everything(),
  names_to = "Color", 
  values_to = "Tally") %>%
  group_by(Color) %>%
  summarise(Tally = sum(Tally))

Have any thoughts or suggestions? Know of a better solution or way to make this process more efficient? Feel free to contact me directly! Respectful discourse towards efficient solutions or new insights is always welcomed!

Getting Started:

To start, we’ll look at a cleaned and prepped dataset that includes a mix of categorical and geographic variables. The data is publicly sourced from the New York State Department of Mental Health and contains information for New York State’s Local Mental Health Programs.

For this example, I’ve already cleaned and prepped the set. If you’re interested, you can view the cleaning script and geoprocessing* script. Our main purpose for this project is to create a dashboard with a map, filters for the map, and a data table that let’s us view selected data points.

*The geoprocessing coding in this script came from Dmitry Kisler’s article “OSM Nominatim with R: getting Location’s Geo-coordinates by its Address” Check it out to learn more about the process if you’d like!

If you’d like to follow along within the R project files you can download them from the Tidy Trekker Github Repository. Be sure to fully extract the ZIP. folders for proper access. You can also download the data set used and load it into your own session for practice.

Creating the Markdown File

In order to create the dashboard, we need to write out code in an R Markdown file (.RMD) instead of an R Script (.R). If you don’t have the flexdashboard package installed already you’ll want to do that first:

# Installing the flexdashboard package===
install.packages("flexdashboard")                                                    

After installing flexdashboard, you should be able to create a new markdown document with the flexdashboard template. You can do so by going to create a new markdown document like you normally would…

…but instead of accepting the default document settings, click on the “From Template” option in the left pane, select the “Flex Dashboard” template in the right pane, and finally click “OK” at the bottom:

You’ll now see a pre-generated Flex Dashboard markdown script! You can use this for practice. If you have some time and are interested, play around with the syntax and get a feel for how changes to this template will affect the final knitted document. You can read up more about Flex Dashboard basics here. If you want more information about different layout options you can find them here. For this guide, we’ll be using the “Chart Stack (fill)” layout.

Setting the YAML

The first part of the markdown code that we see is the YAML (Yet Another Markup Language or YAML Ain’t Markup Language) Header. Without getting bogged down with an explanation, this is basically a special block of code that’s going to tell R how to process our markdown document. It’s the “magic battery” that’s needed to power the translation process that converts code to pretty documents. For this project our YAML looks like this:

---
title: "New York State's (Brooklyn,NY) Local Mental Health Programs"
output:
  flexdashboard::flex_dashboard:
    vertical_layout: fill
    source_code: embed
    css: scripts/nycmhstyle.css
---

The Components of this YAML:

• Title: This is the string that will show up in the top left corner of your dashboard.

• Output: This is where the document type is set. You can set options for this on the same line, or underneath it (shown here.)

• Output Options: In this YAML, our options are underneath the “output” line and are indented. The indents are extremely important. If these options aren’t indented in a hierarchical (ordered) fashion, it will not work! Let’s look at them further:

• flexdashboard::flex_dashboard: Note how this is tabbed or indented only once under the output option. This tells R we want this document processed as a Flex Dashboard.

• vertical_layout: fill: Also note how it’s indented/tabbed again. This tells R that these are options that we want applied to this dashboard. This option tells R that we want the dashboard to fill the page vertically. This option can also be set to “scroll.” You can always play around with it and see which is best for your needs.

• source_code: embed: This option tells R that we want to share our source code on the dashboard. This will appear as a button in the top right corner of the dashboard. If we have source code elsewhere on the internet (like GitHub) you can replace “embed” with the actual URL as a string (with quotation marks - “https://github.com/user/code”)

• css: scripts/nycmhstyle.css: This option tells R that we want to use an external css file to change the appearance of our flexdashboard. This file is included on the GitHub repository if you’re interested.

Configuring the “Setup” Code Chunk

Now that the YAML is set, we need to load in all the packages we’ll use and our data.

#Library load in.#
library(flexdashboard)
library(knitr)
library(tidyverse)

── Attaching core tidyverse packages ──────────────────────── tidyverse 2.0.0 ──
✔ dplyr     1.1.4     ✔ readr     2.1.5
✔ forcats   1.0.0     ✔ stringr   1.5.2
✔ ggplot2   3.5.2     ✔ tibble    3.3.0
✔ lubridate 1.9.4     ✔ tidyr     1.3.1
✔ purrr     1.1.0     
── Conflicts ────────────────────────────────────────── tidyverse_conflicts() ──
✖ dplyr::filter() masks stats::filter()
✖ dplyr::lag()    masks stats::lag()
ℹ Use the conflicted package (<http://conflicted.r-lib.org/>) to force all conflicts to become errors

library(leaflet)
library(leafem)
library(crosstalk)
library(DT)
library(summarywidget)
library(raster)

Loading required package: sp

Attaching package: 'raster'

The following object is masked from 'package:dplyr':

    select

There’s a good amount of packages here. I’ve already mentioned flexdashboard, leaflet, crosstalk, DT, and summary widgets, but there’s a few more needed for our particular example: - knitr: Helps with markdown/report generation - leafem: Gives extensions and additional options for the leaflet (map) package. - tidyverse: Group of packages used to aid with data wrangling/manipulation - raster: Helps with geographical data analysis and modelling.

After loading in all of the libraries, we can now load in our data. The data for this project is stored as an .RDS object. The original csv file was converted to an .RDS object to ensure reproducibility and maintain integrity of the data’s structure. The readRDS() function will automatically open the object and restore it as a data frame with all original components intact. This code stores the data frame as MHprograms

#Loading the datasets into the environment.#
#MH programs with geocodes#

MHprograms <- readRDS("data/mhprogramsnyc.RDS")

Now that our data is in the environment, we can use the crosstalk package to translate our data into a shared data object. This will allow interactivity between our dashboard components.

#Converting data frames into shared data objects with crosstalk. This will allow the map, filters, and tables to be interactive and dynamic.#
Sharedgeodata <- SharedData$new(MHprograms)

Thinking about Dashboard Components and Real Estate

When creating our dashboard we must think about the type of data we have and how that data will fill the space on our dashboard. Before thinking about where things will go, we need to think about what would be useful to have on our dashboard. There’s 17 variables in the set, but for the sake of this example let’s focus on the following:

These variables should be just enough to give the user basic description information about the programs in the data set. Keeping this in mind, we might now start to think about what would be useful to add to our dashboard and map. How about the following?

On the map itself:

• A “Home Button” - A button that will snap our map view back to our data if we go wondering off in the map.

• Conditional Formatting - for map icons based on the program category (i.e. different icons based on the program type)

On the dashboard, separate of the map:

• Reactive Values - Values that change based on the data that’s shown on the map. For this example we’ll do a simple “count” of all mental health programs that were found.

• A Simple Data Table - A simple table that can display information about all programs shown on the map.

• Filters - Filters that will limit what locations are seen on the map based on options that the user selects.

When you start to work with flexdashboard more, you’ll learn about the quirks of layout templates and will begin to see what’s possible. It’s recommended to take time to understand how you want your components to work and look together. For some people this may mean taking the time to draw on paper or making a “mock” dashboard in MS Paint. Whatever your method of planning, just make sure you have a plan! Here’s our mock plan drawn up for our dashboard:

Setting up our First Column and Map

So looking at our mock-up, we just need two columns. One on the left with just a map and one of the right with three modules and some text at the bottom. To set flexdashboard columns in markdown you need to put the following “outside” of r code chunks in the regular markdown editor:

Column {data-width=550}
-----------------------------------------------------------------------

### 

Because we want the first column to be filled with our map, we’ll set the width to be a bit wider than the second column. The series of dashes (—) under the “column” option along with the three hashes (#) let’s R know to place everything underneath those hashes in it’s own column within it’s own box. The hashes are also where you can place the title of your box within your column. This one will be left blank to maximize the space for the map.

Now that the column is initialized, we can place more r code chunks underneath it to get our data in. Our first chunk will be for our map. Recall that we designate the beginning of R code chunks with three back-ticks (aka: Grave Accents) and square brackets with options and end them with an additional three back-ticks at the bottom of the chunk:

```{r map}

```

Creating the Home Button, Bounding Box, and Map Center

Let’s recall what we wanted on our map. A home button and conditional formatting for program types. Let’s code for our home button to start. Say we want an actual image of a home. We’ve gone ahead and found a url of one. To create this button, we’ll need to use the HTML function in the htmltools package to use some HTML for this:

#Pulling a "Home" icon I've hosted on the internet===
Homeimg <- htmltools::HTML(paste("<img src='https://i.ibb.co/D8tSw9q/Homebutton.png' width = '15', height '15', title = 'Home'>"))

#Naming the home image for the addhomebutton function in the leaflet map===
Home <- list("Home" = Homeimg)

This code will show us a pretty home icon, but we’ll need to feed the button the bounding box (bbox) so that it knows where to set the map’s view when it’s clicked on. We can do this easily with the make_bbox function in the ggmap package as long as our data has longitude and latitude columns with numeric values (Ours does!)

#Generating a bounding box of the entire data set. This will act as our "homebase" to zoom back to when the home button is clicked on===
homebase <- ggmap::make_bbox(lon, lat, data = MHprograms)

We may also want to designate a “center” for our map that is first shown when the dashboard is open. We can do this by using the coordinates and proj4strings functions from the sp package, The extent function from the raster package, and the as function that comes from the methods package that usually loads in with base R.

# Retrieving the center point for the map data to set the "home" view===
coordinates(MHprograms) <- ~lon+lat
proj4string(MHprograms) <- "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs"
mapcenter <- coordinates(as(extent(MHprograms), "SpatialPolygons"))

The options set in the proj4string line is referring to the Coordinate Reference System that R uses to create our maps. You can learn more about it with some reading material provided by the National Center for Ecological Analysis and Synthesis if you’re interested.

Creating the Actual Map

Now we can finally get our map into the column. The code is as follows:

#Creating the leaflet map from the shared geo data object===
Sharedgeodata %>%
  leaflet() %>%
  addProviderTiles(providers$OpenStreetMap) %>%
  addAwesomeMarkers(
    popup = ~paste0(
      "<b><h3>",MHprograms$`Agency Name`, "</h3></b><br>",
      "<h4>",MHprograms$`Program Name`,"</h4><br>",
      "Phone: ",MHprograms$`Agency Phone`, "<br>",
      MHprograms$`Program Address 1`, "<br>",
      MHprograms$City, MHprograms$`Program State`, MHprograms$`Program Zip`), 
    icon = awesomeIcons(
      library = "fa",
      icon = ifelse(
        test = MHprograms$`Program Category Description` == "Outpatient", 
        yes = "fa-stethoscope",
        no = ifelse(
        test = MHprograms$`Program Category Description` == "Inpatient", 
        yes =  "fa-bed",
        no = ifelse(
        test = MHprograms$`Program Category Description` == "Emergency", 
        yes = "fa-ambulance",
        no = "fa-users"
      ))),
      iconColor = "#ffffff",
      markerColor = "darkpurple")) %>%
  addHomeButton(ext = homebase, 
                group = Home,
                position = "topright") %>%
  setView(lng = mapcenter[1] , lat = mapcenter[2], zoom = 12)

This part of the code starts out by using a pipe operator (%>%) to connect our leaflet map functions to our shared data object Sharedgeodata. Let’s break down the main functions we have here:

• leaflet(): Initiates our leaflet map widget.

• addProviderTiles(): This draws on actual map tiles to create a basemap. In this example we are using OpenStreetMaps. Being as this is Leaflet’s default, we could replace this with addTiles() with no options set inside and it would produce the same result.

• addAwesomeMarkers(): This allows us to add markers on our map with custom color and icons on them.

Arguments within the addAwesomeMarkers() function:

• popup = This is the text that will popup when a marker is clicked on. You can paste data from the original data set that was converted into a shared data object (in this case, the MHprograms set). In this example, we’re pasting the Agency Name, Program Name, Phone Number and Address associated with each marker (observation) in the data set. I’m utilizing HTML here to assist with formatting because I did not spend years learning it on Myspace for nothing. If you’d like to learn more about HTML basics you can do so here.

• icon = These are the options that we set for our icons that show up on our marker. For this example we are using an additional function awesomeIcons() which will allow us to further customize the icons that are shown on our markers. In this function we have two additional arguments (library= & icon=.) In this example we set library= to "fa" because we are using the Font Awesome library. Our icon argument is set to an ifelse function because we want the icons to change conditionally based on the type of program we are displaying at the marker.

• iconcolor = & markercolor = Self-explanatory. Changes the color of the icon in the marker and the marker itself.

• addHomeButton(): This allows us to add a “home/zoom to” button onto our map. Recall that we did some work for this already. This is where we fill in details to make the magic happen.

Arguments within the addHomeButton() function:

• ext = This is the extent variable or bounding box that you’d like the home button to take the user to when clicked on. We already created our bounding box earlier and named it homebase.

• group = This is the group or layer that will be shown in the home button on the map. A character string is expected here. Because we wish to use the home icon for our button that we set up earlier, we use the name we set it to earlier (home). This tells R to place our picture there instead of the text “home.”

• position = Self-explanatory. This lets us choose where our home button will be displayed on the map. The options are topleft, topright, bottomleft, or bottomright. The default is bottomright.

• setView(): This allows us to determine the view that is seen when the map is open. lng and lat refer to longitude and latitude respectively. We can pull these values from the object we’ve already created called mapcenter. We do this by subsetting the first and second elements of mapcenter which is our longitude and lattiude values for the center of all of our data. We can also set the zoom level with the zoom argument. The zoom scale for Leaflet goes from 0-18 with 0 being a view of the entire world and 18 being the closest you can get to a “street” view.

Setting up our Second Column

#Start of the second Column
Column {data-width=450}
-----------------------------------------------------------------------

### **Total Locations Found:** {data-height=70}
<center><h4><font color="#593869"><b>`r summarywidget(Sharedgeodata, statistic='count', digits=0)`</b></font></h4></center>

`r summarywidget(Sharedgeodata, statistic='count', digits=0)`

### **Program Information:** {data-height=200}

```{r datatable}
Sharedgeodata %>% 
  datatable(
    rownames = FALSE,  
    style = "bootstrap",
    class = "compact",
    selection = "multiple",
    options = list(
      dom = "tip", 
      columnDefs = list(
        list(width = '50%',
          visible = FALSE,
          targets = c(0,4:13,15:16))),
    colnames = c(
      "Location Name" = "Program Name",
      "Ages Served" = "Populations Served",
      "Phone Number" = "Program Phone",
      "Address" = "Complete Address"
      ))) 
```

Setting up Reactive Filters

### **Map Filters:**
<center>

```{r mapfilters}

  filter_checkbox(
    id = "Program Category Description",
    label = "Program Type",
    sharedData = Sharedgeodata,
    group = ~`Program Category Description`,
    inline = TRUE
  )

```
</center>

```{r mapfilters2}

  filter_select(
    id = "Program Subcategory Description",
    label = "Program Setting",
    sharedData = Sharedgeodata,
    group = ~`Program Subcategory Description`,
    multiple = TRUE
  )

```

```{r mapfilters3}

  filter_select(
    id = "Populations Served",
    label = "Ages Served",
    sharedData = Sharedgeodata,
    group = ~`Populations Served`,
    multiple = FALSE
  )

```

Finishing up the Dashboard

To finish up this dashboard, you can add some brief information about the data and it’s source. I feel this code chunk is a perfect example of some of flexdashboard limitations:

Data provided by the New York State Office of Mental Health and found publicly on DATA.NY.GOV
Example created by Meghan Harris with the flexdashboard, Crosstalk, SummaryWidget, and DT packages.

````

You can see the finished dashboard in action on the github repo here.

Limitations

While flexdashboard is great because it allows you to whip up some great dashboards without shiny, you are confined to the environment set by the template. It calls for some “hacking” sometimes and if you want your dashboard appearance to be customized (color/themes), some knowledge in CSS/HTML will make it an easier process. You can also use preset themes to change the appearance of your dashboard as well.

Sizing is also a tricky issue with flexdashboards. Because the template uses a browser-based flexbox engine, the sizing will vary based on things like browser window and user monitor size. You’ll also have to consider mobile layouts for viewing the dashboard on mobile devices if this is of interest. Despite the limitations, flexdashboards can be pretty useful and a less intimidating way for those without experience in Shiny to start making dashboards in R.

Lastly, special thanks to Matt Dray for his presentation and work on these packages! He’s the reason I found flexdashboards!

Have you ever used flexdashboards before? Have any thoughts or suggestions? Know of a better solution or way to make this script more efficient? Feel free to contact me directly! Respectful discourse towards efficient solutions or new insights is always welcomed!