clock menu more-arrow no yes mobile

Filed under:

Three things I learned while making Vox’s solar eclipse graphic

Total solar eclipse in Salem, OR

We recently published a graphic on Vox about the upcoming solar eclipse in August. While I enjoyed working on this graphic, building it certainly put my problem solving skills to the test. As I drew numerous circles on scratch paper and worked through calculations to determine where to place certain elements, a number of my colleagues expressed interest in what I was doing and wanted to know more about how the graphic works. Here are a few of my takeaways from building this piece.

1. The data you’re looking for is probably already out there

Did you know that The United States Naval Observatory (USNO) has an API that provides detailed eclipse data? Neither did I until I Googled “solar eclipse 2017 API.” Talk about a game changer. Learning that I could get all of the information that I needed to create the animation at the top from one source made my week. Well, really, it made this project.

In order to get the data for each zip code from the API, I needed to know the geographic coordinates for the zip code center. While I could have created this data myself, I didn’t need to. Thanks to erichurst, it already exists.

Turns out that there is also an existing data set for mapping zip codes to timezones from DoubleDor and Moment.js has library for formatting dates based on these timezones.

While we ended up compiling and manipulating these data sets to make them more manageable and reduce page weight, we didn’t have to create any of the data ourselves.

2. You don’t have to be a math expert

The animation at the top is essentially one circle moving over top of another circle along an invisible line that recurs every 15 seconds. Figuring out the math to draw this line was complicated, but for the most part doable. The USNO API gave me three important pieces of information that I needed to draw the path of the moon over the sun:

  1. The starting vertex angle (the angle where the moon first touches the sun).
  2. The maximum obscuration percentage.
  3. The ending vertex angle (the angle where the moon last touches the sun).

One important (and interesting) thing to note: The vertex angle is measured counterclockwise from the point on the sun that has the highest local altitude, which differs from how circle angles are typically measured.

Diagram showing how vertex angles are measured as compared to how angles are typically measured on a circle.
Diagram showing how vertex angles are measured as compared to how angles are typically measured on a circle.

Creating the animation

Since the USNO data provided the angles where the moon enters and exits the sun, it wasn’t too difficult to determine the starting and ending center points for the moon. These points would become the starting and ending points on the invisible line that the moon is animated along.

Diagram of calculating the starting and ending points for the line used to animate the moon.
Diagram of calculating the starting and ending points for the line used to animate the moon.

Behind the scenes, the “sun” circle is actually a circle composed of 360 nodes (shoutout to Aaron Bycoffe’s Block, “Placing n elements around a circle with radius r”), which made it easy for me to pull out the coordinates for the entering and exiting angles and compute the line endpoints as shown above.


Now that I had the starting and ending points, I needed to determine where to place the line midpoint. Drawing a straight line between the two points would not account for the obscuration percentage or depict the true path of the moon across the sun. In order to place the midpoint, I needed to know how far away from the sun’s center it needed to be and at what angle.

Determining the angle of the midpoint was a combination of determining the bisecting angle of the start and end angles along with knowing whether the current zip code’s location relative to the path of totality. If the user would need to travel SW or SE to view the totality, the line midpoint would be placed somewhere below the sun’s center point and if the user would need to travel NW or NE to view the totality, the midpoint would be placed somewhere above the sun’s center point.

Image showing that line midpoint would be placed below the center of the sun since the user would need to drive SW to see the total eclipse.

If you’re interested in seeing all of the fun math that went into figuring this out, here’s a look at some of my notes.

Math to calculate midpoint of line for animating the moon

After figuring out the angle for the midpoint, I needed to figure out the distance between it and the sun’s center. Given that I knew the percentage that the circles overlapped (the maximum obscuration percentage), I was able to find a formula online that would help me compute the distance between the two points. And since I’m a little rusty on my trigonometry skills, I used Wolfram Alpha to help me compute the percentage overlap of the radii for all obscuration values between 1 percent and 100 percent. The percentage overlap multiplied by the size of the radius (in pixels) allowed me to find this last missing variable.

After placing this point and drawing the line, I ended up with an animation that looked like this.

3. Simple is okay

When I first created the mock for this graphic, I included a play/pause button on the timeline below the animation. We ended up nixing that idea fairly early on.

Everyone I showed the graphic to in the early stages found it straightforward and easy to understand. The animation loops every 15 seconds, so even if the user misses something the first time, they don’t have to wait long for it to come around again. Adding the play/pause ability for such a simple visualization seemed like a bit much (and would have added extra dev time).