Pixels, rasters, GIFs, and beads — because who said remote sensing can’t be fun?

Oh, and I built a Google Earth Engine web app too.

Geovis Project Assignment, TMU Geography, SA8905, Fall 2025

Author: Amina Derlic

Introduction

I’ve always been fascinated with things above the Earth. As a kid, I wanted to be an astronaut — drifting through space, staring back at the planet from far, far away. Life didn’t take me to the International Space Station, but it did bring me somewhere surprisingly close: remote sensing. Becoming a forest scientist turned out to be its own kind of space adventure — one where satellites become your eyes, algorithms become your instruments, and forests become your landscape.

For this project, I wanted to explore something that has always caught my curiosity: how forests and vegetation heal after fire. What actually happens in the years after a burn? How quickly does vegetation come back? Are there patterns of resilience, or scars that linger? And what changes become visible only when you zoom out and look across a whole decade of satellite data?

While digging through disturbance datasets, I came across the Kenora018 fire, a May 2016 wildfire right on the Ontario–Manitoba border near Kenora and Ingolf. It was perfect: great Landsat coverage, and a well-documented footprint. I even downloaded the official fire polygon from the Forest Disturbance Area dataset on Ontario’s GeoHub.

But instead of sticking strictly to that boundary, I decided to take a more playful cartographic approach. The broader border region burns often — almost rhythmically — so I expanded my area of interest. Looking at a larger extent allowed the landscape to tell a much bigger story than the official fire perimeter could.

From there, the project grew into a full workflow. My goals in Google Earth Engine (GEE) were to:

• build NDVI layers for 2015–2025 using Landsat composite imagery
• compute dNBR for key fire years (2016 and 2025) to quantify burn severity
• mask water and overlay Hansen tree loss for added ecological context
• create an interactive GEE web app with a smooth year slider
• animate everything into a GIF, visualizing a decade of change
• and finally, turn one raster into a piece of physical bead art — transforming pixels into something tactile and handmade

This was also my first substantial project using JavaScript — the language that Earth Engine speaks — which meant a learning curve full of trial, error, debugging, breakthroughs, and a surprising amount of satisfaction. Somewhere between the code editor, the map layers, the exports, and the bead tray, the project turned into a multi-stage creative and technical journey.

And from here, everything unfolded into the full workflow you’ll see below.

How I Built It: Data, Tools, and Workflow

The study area for this project was chosen along the Kenora–Ingolf border, where the Kenora018 wildfire burned in May 2016. Instead of limiting the analysis strictly to the official fire boundary downloaded from the Ontario GeoHub, I expanded the area slightly to include surrounding forest stands, repeated burn patches, road networks, and nearby lakes. This broader geometry allowed the visualization to reflect not only the 2016 fire but also the recurring disturbance patterns that characterize this region.

All data processing was carried out in Google Earth Engine, using a combination of Landsat imagery, global forest change data, and surface-water products. To track vegetation condition through time, I relied on the Landsat 8/9 NDVI 8-day composites from the LANDSAT/COMPOSITES/C02/T1_L2_8DAY_NDVI collection. I extracted summer-season imagery (June through September) for every year from 2015 to 2025, producing a decade-long series of clean, cloud-reduced NDVI layers. These composites provided a consistent view of vegetation health and were ideal for comparing regrowth before and after disturbance.

For burn-severity analysis, I used the Landsat 8 and 9 Level-2 Surface Reflectance collections (LANDSAT/LC08/C02/T1_L2 and LANDSAT/LC09/C02/T1_L2). These datasets include atmospherically corrected spectral bands, which are necessary for accurately computing the Normalized Burn Ratio (NBR). Using the NIR (SR_B5) and SWIR2 (SR_B7) bands, I calculated NBR for two time windows: a pre-fire period in April and a post-fire growing-season period from June through September. The difference between these two, dNBR, is a widely used indicator of burn severity. I produced dNBR images for 2016, the year of the Kenora018 fire, and for 2025, which showed another disturbance signal in the same region.

To contextualize the burn information, I incorporated the Hansen Global Forest Change dataset (UMD/hansen/global_forest_change_2022_v1_10). The lossyear layer identifies the precise year of canopy loss, and I used it to highlight where fire corresponded with actual forest removal. Importantly, dataset I used is only published up to 2022, so canopy loss could only be displayed through that year. The red pixels were blended into the 2016 dNBR map to show where burn severity aligned with structural forest change.

Because the region contains extensive lakes and small water bodies, I also used the JRC Global Surface Water dataset (JRC/GSW1_4/GlobalSurfaceWater) to create a water mask. However, in several places the JRC water polygons didn’t fully cover the lake edges, allowing some of the underlying Landsat pixels to show through — which made the water appear patchy and inconsistent on the map. To fix this, I converted the JRC water layer to vectors and applied a 3-metre buffer around each polygon. This small buffer filled in those gaps and produced smooth, continuous lake boundaries. After rasterizing the buffered shapes, I applied the mask across all imagery, which made the lakes look much cleaner in both the GIF animation and the interactive map.

Together, these datasets formed the backbone of the project, enabling a multi-layered visualization of fire, recovery, water, and forest change across eleven years of Landsat imagery.

Once all annual NDVI and dNBR layers were created, I assembled them into an interactive web app using GEE’s UI toolkit. I built a year slider, layer toggles, and a map panel that automatically revealed the correct layers as the user scrolled through time. This allowed viewers to explore forest disturbance and regrowth dynamically rather than through static maps.

For the animation component, I generated visualized frames for each year, blended in the water mask and Hansen tree loss where needed, and assembled everything into a single ImageCollection for export as a GIF. While the interactive web app uses the full study area, I decided to crop the GIF to a smaller subregion that showed the most dramatic change. Much of the surrounding forest remained relatively stable over the decade, so focusing on the high-disturbance zone made the animation cleaner, more expressive, and easier to interpret. After exporting the GIF from Google Earth Engine, I added a simple title overlay in Canva to keep the aesthetic cohesive.

Results & What the Data Revealed

Once everything was assembled in the Google Earth Engine web app, the decade-long story of the Kenora–Ingolf forest began to unfold frame by frame. The 2015 NDVI layer offers a clean, healthy baseline — a landscape of mostly intact canopy, rich in mid-summer vegetation.

Check the App Here: Vegetation Cover Explorer

Before diving into the year-to-year patterns, it’s worth noting how the two key indicators behaved in this landscape. NDVI ranged roughly between 0.0 and 0.8, with the higher values representing dense, healthy canopy. This made it very effective for tracking vegetation recovery: strong greens in 2015, a sharp drop in 2016, and then a clear, steady resurgence in the years that followed. dNBR, on the other hand, showed burn severity in a way NDVI alone could not. In 2016, most values fell between –0.1 and 0.7, signalling low to moderate burn severity — not as intense as some fire reports suggested, but consistent with Landsat’s 30-metre pixel averaging. This also aligned with USGS MTBS. By 2025, dNBR peaks were higher on the eastern edge of the AOI, revealing a more severe burn pattern associated with the Kenora 20 and Kenora 14 fires. Together, NDVI and dNBR provided a complementary narrative: one charting the health of the vegetation, the other capturing the intensity and extent of disturbances shaping it.

The shift happens abruptly in 2016 with the Kenora018 wildfire. The dNBR layer reveals a clear patch of moderate burn severity. Interestingly, this contrasts with some local fire reports that described the event as severely burned. Landsat’s 30-metre pixel size helps explain the difference: each pixel blends many trees, softening the appearance of smaller, high-intensity burn pockets. The NDVI for 2016 fully supports this reading — vegetation drops sharply in the burn scar, transitioning toward yellows.
The Hansen forest-loss data for 2016 reinforces this interpretation. The red loss pixels align closely with the drop in NDVI and the moderate dNBR signature, confirming that actual tree mortality followed the same spatial pattern seen in the spectral indices. Even though dNBR suggested mostly low–moderate severity, the Hansen layer shows that canopy loss still occurred in the core of the burn scar, creating a consistent picture when all three datasets are viewed together.

By 2017, recovery is already visible. Small patches of green begin resurfacing across the scar. In 2018, the regrowth strengthens further, and the forest steadily rebuilds. That pattern breaks briefly in 2019, where NDVI shows a dip in vegetation unrelated to the 2016 burn. This aligns with fire reports describing several minor grass fires in the Kenora and Thunder Bay districts that year — small on the ground, but detectable at Landsat’s scale.

From 2020 to 2024, the forest rebounds spectacularly. NDVI values rise and stabilize, indicating a canopy that not only recovers but in many places reaches even higher productivity than the pre-2016 baseline. This decade-long greening makes the region appear surprisingly resilient.

Then 2025 changes the story again. Two separate fires — Kenora 20 and Kenora 14 — burned portions of the eastern side of my AOI. These events show up clearly in both NDVI and dNBR: sharp declines in vegetation, strong burn-severity signals, and fresh scar boundaries distinctly different from the 2016 burn. The contrast between long-term recovery and sudden new disturbance makes 2025 an especially dramatic year in the final visualization.

To showcase the temporal changes more clearly, I exported the processed frames as a GIF. Since the file was too large for standard embedding, I converted it into a short video and uploaded it to YouTube. This made the animation smoother, easier to share, and more accessible across devices. The video captures the most dynamic portion of the study area — including the 2016 Kenora018 burn and the later Kenora 20 and Kenora 14 fires in 2025 — and shows the forest shifting through cycles of disturbance and recovery.

Watch the Animation on YouTube: Vegetation and Burn Severity Time Series

Physical Mapmaking With Beads

Finally, I wanted to take the project beyond the screen and turn part of the data into something tactile. I started by downloading the official Kenora 018 fire perimeter shapefile from the Ontario Ministry’s GeoHub, printed it, and used it as a physical template. Then I exported and printed my 2016 NDVI layer outlined with Hansen tree loss, trimmed it precisely to fit the perimeter, and used this as the base map for my physical build.

From there, I began assembling the bead map pixel by pixel using tweezers. Each bead colour corresponded to a class in the combined NDVI + tree loss dataset: blue for water, dark/healthy green for intact vegetation, yellow for stressed or low NDVI vegetation, and red for Hansen-confirmed 2016 tree loss. Because each printed pixel still contained sub-pixel variation, I used a simple decision rule: whichever class covered more than 50% of the pixel determined the bead placed on top.

The process was surprisingly challenging. Some beads were from different brands and sets, meaning they melted at different temperatures — a complication I didn’t anticipate. As a result, the final fused piece is a little uneven and imperfect. But that imperfection also feels true to the project. Converting satellite indices into something handcrafted forced me to slow down and engage with the landscape differently. It’s one thing to analyze disturbance with code; it’s another to physically place hundreds of tiny beads representing real burned trees. The end result may be a bit chaotic, but it’s meaningful, tactile, and oddly beautiful — a small, imperfect echo of a real forest recovering after fire.

Process of creating bead board:

And final product on the table:

Limitations

As with any remote-sensing project, several limitations shape how the results should be interpreted. Landsat’s 30-metre resolution smooths out fine-scale fire effects, often making burns appear more moderate than ground reports suggest. Cloud masking varies year by year and can affect NDVI clarity. The Hansen dataset, used in this project, only extends to 2022, which means it cannot capture the 2025 tree loss associated with Kenora 20 and Kenora 14. And NDVI, while powerful, saturates in dense forest, making some structural changes invisible.

Even with these constraints, the decade-long patterns remain strong and revealing: the 2016 burn, the gradual regrowth, the 2019 dip, the robust recovery into the early 2020s, and finally the sharp return of fire in 2025.

Wrapping Up

What began as a small idea — “let’s check out what happened after that 2016 fire” — spiraled into a full time-travel adventure across a decade of Landsat data. I built sliders, animated rasters, chased burn scars across the Ontario–Manitoba border, and ended up turning satellite pixels into actual beads. Not bad for one project.

The forest’s story was both familiar and surprising: a big fire in 2016, recovery that starts immediately, a weird dip in 2019, years of strong regrowth… and then boom — the 2025 Kenora 20 and Kenora 14 fires lighting up the right side of my study area. You can almost feel the landscape breathing: exhale during fire, inhale during regrowth.

This was my first time writing JavaScript for real, my first time making a GIF in GEE, my first time turning data into a physical object — and definitely not my last. I’m leaving this project both tired and energized, full of new ideas and very aware of how fragile and resilient forests can be at the same time.

If you had told kid-me — the wannabe astronaut — that I’d one day be stitching together satellite imagery and making bead art out of forest fires… I think she would have approved.

Geovis Project Assignment, TMU Geography, SA8905, Fall 2025

Author: Pravar Joshi

Introduction

This tutorial walks through how I created Follow Your Flush, an educational web app that shows where wastewater travels in Toronto after someone flushes a toilet or drains a sink. The goal of the project is to help the public understand a complex urban system in a simple, visual way. Toronto has nearly 3,800 km of sanitary sewers and more than 523,000 property connections. Most of this infrastructure is underground and difficult to picture. This project uses interactive mapping, routing, and animation to turn a hidden system into an intuitive experience.

It invites the user to click anywhere in the city. The app then:

1. Identifies which wastewater treatment plant serves that location.
   
2. Computes a walking route (as a stand-in for sewer pipes) from the chosen point to the plant.
   
3. Animates a smooth camera flythrough along the path.
   
4. Extends the journey along an outfall pipe to Lake Ontario or the Don River.
   
5. Presents a treatment stages summary with a simple looping wastewater animation.
   
6. Shows the total travel distance.

The app brings together Mapbox GL JS, ArcGIS Online (AGOL) feature services, Mapbox Directions, and Turf.js for spatial calculations. It also uses the Mapbox Free Camera API, along with terrain and sky layers, to turn a simple map click into a fully animated 3D experience. In this tutorial, I will walk through how to combine these tools to build your own interactive story maps that draw on AGOL data, incorporate animations, use 3D map views, and perform open source geospatial analysis.

Why create an interactive story map?

This project shows how web mapping can turn a hidden system into something easy to understand. Most people never think about how wastewater makes its way to a treatment plant. A story-driven, animated map helps people understand distance, direction, and the treatment process.

The same approach can be used for other topics:

• Drinking water treatment story
• Fish migration patterns (eg salmon)
• A bike or transit route animation
• A delivery vehicle or garbage collection story
• A heatwave moving across a city
• A “walk the proposed development site” planning tool for developers

The storytelling approach stays the same. Only the datasets change.

Integrating Mapbox with ArcGIS Online (AGOL) Data

One of the most important pieces of this project is the ability to bring AGOL data directly into a Mapbox application. AGOL hosts feature services that can be queried through a simple REST API. These services can return data as GeoJSON, which Mapbox can load immediately as a source. This creates a flexible workflow where authoritative data is stored in AGOL (eg municipalities often post data on AGOL and it can be accessed for free) and rendered interactively through Mapbox in a custom web application.

This integration enables you to access the plentiful feature services in AGOL while leveraging Mapbox’s industry-leading graphics layers and APIs that allow for interactive web apps to be created with ease.

In this project, two AGOL layers were used:

• Wastewater Treatment Plants (points)
• Wastewater Catchments (polygons)

These were loaded through REST queries. First, I stored the URL for each of them separately:

Then, I fetched the URL for each of them independently; for example:

Once the request is sent to AGOL to retrieve the feature service, then it needs to be converted into a JavaScript object that contains the GeoJSON features:

The next step is to register the data inside Mapbox as a source, so it can draw this data, filter it, transform, and animate:

Lastly, I created a circle layer for the plant locations since this is point data and added labels above the plant. I kept the visibility as ‘none’ or hidden as this data is only shown on the map once the user triggers the entire workflow:

To summarize, this part of the tutorial walks through how to download an AGOL feature layer as GeoJSON such that it can be used in Mapbox. In this example, a point layer from AGOL was transformed in a circle layer for wastewater treatment plant locations and a symbol layer was also created in Mapbox for readable labels. Please refer to more detailed documentation here: https://developers.arcgis.com/rest/services-reference/enterprise/query-feature-service-layer/

Using Turf.js for Open-Source Spatial Analysis

Turf.js is a lightweight, open-source geospatial analysis library for JavaScript. It fills an important gap if you want to do geospatial operations, without depending on commercial APIs or paying credits for repeated calls via ESRI’s APIs.

In this project, Turf.js is used to support:

• Finding the nearest address to a click
• Creating line geometries
• Point-to-Point distance calculations
• Computing final journey lengths
• Handling geometry operations that Mapbox does not perform

Finding the nearest address to a click

When the user clicks the map, the app looks for the closest address point. This gives the user context: “You clicked near 123 Sample Street.”

This pattern can also be used for a variety of use-cases. Instead of the closest address point, you can program the app to find the nearest park, nearest fire station, nearest trailhead, nearest bus stop, etc..

While the reverse-geocoding itself is done through the Mapbox Geocoding API, Turf provides the geographic structure needed to represent the clicked location correctly. The codeblock below is converting the raw coordinate pair into a proper GeoJSON Point. Then, the location can be passed cleanly into downstream spatial logic, distance functions, and API calls. Turf ensures the click is formatted as a true spatial feature rather than just a number pair.

Creating Line Geometries

A major part of the app involves drawing routes and pipe paths on the map. Turf.js makes this possible by converting plain arrays of coordinates into valid GeoJSON LineStrings. These LineStrings are then used for routing, animation, and distance calculations.

Walking Route (user click → treatment plant)

When the Mapbox Directions API returns a walking route, it provides the geometry as a raw array of coordinate pairs. Turf turns that list into a real spatial feature:

This gives the route a formal geometric structure. That structure is what allowed me to smooth the route, fit the map to the route’s bounding box, computre the route’s geodesic length, and animate the camera along the path. Without converting the coordinates to a LineString, none of those operations would work reliably.

Point-to-Distance Calculations

Turf allows the app to treat the walking route and the outfall pipe as real geographic lines instead of screen-based pixels. Using turf.length(), the distance between route coordinates is computed with proper geographic units. This converts hundreds of small coordinate segments into a single cumulative distance.

Conclusion

Mapbox is good at rendering beautiful map outputs for web apps, but it does not run geospatial operations. Turf fills this gap and can be leveraged for your interactive story-based web app!

Handling User Input and Spatial Logic

User interaction drives the entire application. The workflow always begins with a map click that triggers the logic for selecting the correct spatial boundary, calculating a route, and starting the animation.

This process applies can apply for many different use-cases:

• Identify which watershed a user clicked
• Identify or assign a bike route or transit line based on where a user clicked
• Detect which fire station or service zone covers an area

In my example, the code performs two essential operations:

1. Detect which AGOL polygon contains the user clicked point.
2. Use that polygon’s attributes to guide the rest of the story

This codeblock below is the main map click handler for my application. Some of the key features:

• Listening for a Click
  The handler begins with map.on("click", …), which waits for the user to click the map. This is the trigger for all interaction.
• Cleaning Up the Interface
  The tooltip that guides first-time users is hidden as soon as they click. This keeps the interface clean for the rest of the workflow.
• Capturing the Click Location
  The clicked longitude and latitude are extracted from the event (e.lngLat). These coordinates are wrapped into a Turf.js point object (turf.point(lngLat)), which allows the point to be used in spatial operations.
• Checking That the Data Is Loaded
  Before running any spatial queries, the code checks whether the catchment polygons and plant data have actually finished loading. If either dataset is missing, the user sees an alert and the function stops.
• Executing Point-in-Polygon Logic Before running any spatial queries, the code checks whether the catchment polygons and plant data have actually finished loading. If either dataset is missing, the user sees an alert and the function stops.
• Handling Clicks Outside the Study Area If the loop finishes without finding a catchment, the system alerts the user that the click was outside the valid boundary and ends the function.

Enhancing the Map with Terrain and Sky Layers

To make the map feel more immersive, the project uses Mapbox’s terrain and sky layers. These layers add visual depth by emphasizing elevation and atmospheric light, giving users the sense that they are traveling through a landscape rather than sliding across a flat 2D map.

Adding a Digital Elevation Model (DEM)

Mapbox provides a global DEM that can be used to give the map a 3D effect. The DEM can be added as a raster source:

Once the DEM is loaded, you can apply it as the map’s terrain:

The exaggeration value controls how “vertical” the terrain appears. A little exaggeration helps users see the landscape without making the scenery look unnatural.

Adding a Sky Layer

The sky layer gives the map a realistic horizon when the camera tilts which is especially important in a project with dramatic camera movements such as this one as there is a camera that follows the path.

This sky layer the camera animation feel more cinematic. When the camera swoops down behind the walking path or flies across Lake Ontario during the outfall animation, the sky contributes to a sense of motion and depth.

Using the Mapbox Free Camera API for Animation

The free camera API allows the map’s viewpoint to move smoothly along a path. This is similar to mimicking a drone or guided flythrough and transforms the map from a static reference into a narrated journey.

Setting up the camera

You start by grabbing the current free camera options from the map:

This camera can be repositioned and rotated independently.

placing the camera at a coordinate

For each coordinate in the route, you update the camera’s position and orientation:

The .position function controls where the camera is located. The .lookAtPoint function controls what the camera is pointed at and CAMERA_ALTITUDE adjusts how high above the path the animation flies. In my application, I enable the user to adjust the altitude via a slider.

Animating the flight

You can create a recursive step() function that updates the camera a little at a time to create an animation:

The result is a smooth glide along the walking route and the outfall pipe, in my application. This creates the core storytelling moment of the application, letting users “follow their flush” as if traveling along the sewer network themselves.

Educational Modals and Storytelling Structure

The Follow Your Flush web app uses a sequence of modals to turn geographic data into a guided, educational story. This approach ensures users learn something at every step rather than just looking at moving lines on a map.

Intro Modal (Setting the Stage)

This modal set the introductory concept and disappears when the user is ready to begin:

This helps new users understand what the app represents and what they should do next (press enter!).

Click Info Modal (SHOWING KEY DATA ATTRIBUTES BACK TO THE USER)

Once the app determines which treatment plant services the area the user clicked, it displays an informational modal. This modal is the bridge between the spatial logic and the educational experience. To build it, the app uses DOM manipulation methods that let JavaScript read and update HTML elements on the page:

The key DOM methods used here are:

• getElementById() finds the exact element to update
• .innerHTML writes dynamic HTML content into the modal
• .style.display controls when modals appear
• state flags like awaitingEnter help manage user flow

Overall, the use of modals throughout an interactive web app help create a narrative for the user.

Conclusion

This project brings together ArcGIS Online Data Integration, Mapbox graphics, Turf.js, camera animations, and interactive modals to create a guided, educational experience on top of real spatial data. While there is no need to re-create these exact steps, the techniques demonstrated here can be leveraged for any interactive web app. Thank you for reading this post!

SA8905: Geovisualization Project

Erika French

Background

Data

The data used for this project are all publicly available for download at the links provided below.

The NOAA’s National Weather Service Storm Prediction Center publishes tornado occurrence data dating back to 1950. This file can be found on their website and is named ‘1950-2024_all_tornadoes.csv’. Additionally, a data description file can be viewed here.

The US Boundary layer was downloaded from the US Census Cartographic Boundaries website. The ‘2024 1 : 500,000 (national) States’ shapefile was chosen.

How-To!

Part One: Geoprocessing in ArcGIS Pro

Two important tasks must be completed using ArcGIS Pro.

1. Creating point data for all tornado occurrences.
2. Creating tornado paths for all applicable tornado occurrences.

Here is how these tasks were completed.

Creating the tornado occurrence point data layer

1. Add data to the map.

Open a new ArcGIS Pro Project and add the ‘1950-2024_all_tornadoes.csv’ and the ‘2024 1 : 500,000 (national) States’ shapefile to the current map.

2. Create point data.

Right click on the ‘1950-2024_all_tornadoes.csv’ in the contents pane and navigate to “XY Table to Point”. Fill out the parameters as pictured below and run. This creates point data for all tornado occurrences using the start longitude and start latitude.

3. Creating a unique Tornado ID Field

Currently, there is no unique tornado ID field as tornado numbers are reused annually. We will now create a unique tornado ID field. Right click on the new All_Tornadoes layer and navigate to Data Design > Fields. Here, add a new field as pictured below.

Open the All_Tornadoes attribute table and navigate to the new t_id field. Right click and choose Field Calculate. Here, we will create a unique tornado ID by concatenating the om field and the year field as pictured below.

4. Using Select by Location to clip point occurrences apppearing outside the United States.

With the All_Tornadoes layer selected, navigate to Select by Location and fill the parameters out as pictured below.

Right-click on the All_Tornadoes layer and navigate to Data > Export Features. Ensure that you are exporting the selected records. Name this new feature layer “USA_Tornadoes”.

5. Symbolizing Point Occurrences

Navigate to the USA_Tornadoes layer symbology. Here, we will choose unique values and symbolize the Magnitude field (mag) as pictured below.

Enable scale-based sizing of points at appropriate ranges so that they do not crowd the map at its full extent. To begin, I used 3 pt, then 8 pt, and then 12 pt progressive sizing.

6. Labelling Point Occurrences

Right-click on USA_Tornadoes and navigate to labeling properties. We would like to label each occurrence with its magnitude. This Arcade expression leaves any points with a -9 value unlabelled, as they have unknown magnitudes.

Under the new Label Class, navigate to symbol and fill out the settings as pictured below.

Under Visibility Range, fill out the minimum scale as pictured below. This will stop the labels from crowding the map when zoomed out. Save your project!

Creating tornado paths

1. Use the XY to Line Tool to create paths

Launch the XY to Line tool. Use the ‘1950-2024_all_tornadoes.csv’, as the input feature. Fill out the parameters as pictured below. This will create a line from each tornado’s start lat/long to end lat/long. Running this will take a few minutes, be patient. Name this new layer “Tornado Paths”

2. Select by Location all tornado paths in USA

Some tornadoes may only have a start lat/long, and no end lat/long recorded. In this case, the end of their path will appear at a 0,0 lat/long. To remove all of these inaccurate paths, we will peform a select by location. Fill out the parameters as pictured below.

Open the tornado paths attribute table and switch the selection. Visually confirm that the only highlighted paths are now outside of the USA. Delete these records.

3. Creating a Buffer

To appropriately visualize the width of the tornado’s path, we will create a buffer of the Tornado Paths layer. Start by adding a new field to the Tornado Paths layer as pictured below.

Open the attribute table and field calculate the new halfwidth field as pictured below.

Now we can create a buffer. Open the buffer tool and fill in the parameters like below.

Symbolize this buffer in red and change the transparency to 60%. Add a 1 pt outline of grey. We have now created a layer showing the path of each tornado visualizing accurate length and width.

Save the project. Navigate to the share toolbar and share as a web map. We can now open our web map in ArcGIS Online.

Part Two: Preparing the Web Map for Experience Builder

1. Open the web map.

Open up the new web map in ArcGIS Online. The web map should have two layers: USA Tornadoes and Tornado Paths. Any other layers can be removed. Our map appears the same way in which we saved it in ArcGIS Pro.

2. Format Popups.

Click on the USA Tornadoes layer. On the right hand pane, navigate to popups. Here, we will create some attribute expressions using Arcade to create nicely formatted fields for our popups. Add the following attribute expressions:

Length:

Text($feature.Len, “#,###.##”) + ” miles”

Width:

Text($feature.wid, “#,###.##”) + ” yards”

Crop Loss:

IIf($feature.closs_1 == 0,

    “Unknown”,

    “$” + Text($feature.closs_1, “#,###”) + ” million”

)

Property Loss:

IIf($feature.Year < 1996,

    When(

        $feature.closs == 0, “Unknown”,

        $feature.closs == 1, “$50 – $500”,

        $feature.closs == 2, “$500 – $5,000”,

        $feature.closs == 3, “$5,000 – $50,000”,

        $feature.closs == 4, “$50,000 – $500,000”,

        $feature.closs == 5, “$500,000 – $5,000,000”,

        $feature.closs == 6, “$5,000,000 – $50,000,000”,

        $feature.closs == 7, “$50,000,000 – $500,000,000”,

        $feature.closs == 8, “$500,000,000 – $5,000,000,000”,

        $feature.closs == 9, “$5,000,000,000+”,

        “No data”

    ),

    “$” + Text($feature.closs, “#,###”))

Number of Fatalities:

Text(Round($feature.loss, 0), “#,###”)

Magnitude:

IIf($feature.mag == -9,

    “Unknown”,

    “F-” + Text($feature.mag)

)

State:

var abbr = Upper($feature.State);

var full = When(

    abbr == “AL”, “Alabama”,

    abbr == “AK”, “Alaska”,

    abbr == “AZ”, “Arizona”,

    abbr == “AR”, “Arkansas”,

    abbr == “CA”, “California”,

    abbr == “CO”, “Colorado”,

    abbr == “CT”, “Connecticut”,

    abbr == “DE”, “Delaware”,

    abbr == “FL”, “Florida”,

    abbr == “GA”, “Georgia”,

    abbr == “HI”, “Hawaii”,

    abbr == “ID”, “Idaho”,

    abbr == “IL”, “Illinois”,

    abbr == “IN”, “Indiana”,

    abbr == “IA”, “Iowa”,

    abbr == “KS”, “Kansas”,

    abbr == “KY”, “Kentucky”,

    abbr == “LA”, “Louisiana”,

    abbr == “ME”, “Maine”,

    abbr == “MD”, “Maryland”,

    abbr == “MA”, “Massachusetts”,

    abbr == “MI”, “Michigan”,

    abbr == “MN”, “Minnesota”,

    abbr == “MS”, “Mississippi”,

    abbr == “MO”, “Missouri”,

    abbr == “MT”, “Montana”,

    abbr == “NE”, “Nebraska”,

    abbr == “NV”, “Nevada”,

    abbr == “NH”, “New Hampshire”,

    abbr == “NJ”, “New Jersey”,

    abbr == “NM”, “New Mexico”,

    abbr == “NY”, “New York”,

    abbr == “NC”, “North Carolina”,

    abbr == “ND”, “North Dakota”,

    abbr == “OH”, “Ohio”,

    abbr == “OK”, “Oklahoma”,

    abbr == “OR”, “Oregon”,

    abbr == “PA”, “Pennsylvania”,

    abbr == “RI”, “Rhode Island”,

    abbr == “SC”, “South Carolina”,

    abbr == “SD”, “South Dakota”,

    abbr == “TN”, “Tennessee”,

    abbr == “TX”, “Texas”,

    abbr == “UT”, “Utah”,

    abbr == “VT”, “Vermont”,

    abbr == “VA”, “Virginia”,

    abbr == “WA”, “Washington”,

    abbr == “WV”, “West Virginia”,

    abbr == “WI”, “Wisconsin”,

    abbr == “WY”, “Wyoming”,

    abbr

);

return full;

In the popups options, choose the fields pictured below to appear in the popups. Ensure you are using the attribute expressions you have made so that the popups have the data formatted as desired.

Repeat these steps on the Tornado Paths layer. Save the web map.

Part Three: Creating the Experience

1. Choose a template.

In ArcGIS Online, select create a new app > Experience Builder. This experience was generated using the template. However, I published the template with all of the edits made to create the Historical Tornado Events in the United States Experience.

2. Connect your web map.

Connect your Tornadoes web map to the map widget. Modify a custom extent for the map to appear at.

3. Configure filter widgets.

For each filter widget, configure a SQL expression using predefined unique values. For example, configure the Magnitude filter as pictured below.

This allows the user to select a value from a dropdown rather than typing in a value.

Additionally, configure a trigger action that will action the map to zoom to the filtered records, as pictured below.

4. Configure Feature Info widget.

Connect the feature info widget to the map widget. This widget will show the same information that we formatted in the web map popups.

5. Configure the Select Features widget.

Connect the Select Features widget to the map widget. Enable select by rectangle and select by point.

6. Save and publish! All widgets have now been configured.

Result

The Experience Builder output is an interactive web app that allows users to explore historical tornado occurrences dating back to 1950, their paths of destruction overlaying aerial imagery to see the exact structures and cities they passed through, and compares the statistics of human and financial loss caused by each. Users can see where the most severe tornadoes tend to occur, or visualize severity temporally.

Sources

The Online Tornado FAQ (by Roger Edwards, SPC)

Storm Prediction Center Maps, Graphics, and Data Page

Cartographic Boundary Files

Sughra Syeda Rizvi, Geovis Project Assignment, TMU Geography, SA8905, Fall 2025

Hey everyone! For my Geovisualization project, I wanted to explore something familiar, cultural, and globally recognizable: the international expansion of Tim Hortons. Although the brand is iconic in Canada, fewer people know just how far it has spread across the world. My goal was to create an interactive, chronological StoryMap that guides viewers through the first Tim Hortons location in every country where the brand operates.
To do this, I combined online research, geographic coordinates, and a storytelling platform that lets users “travel” from country to country using a next-slide navigation system. The result is an easy-to-follow visual timeline that maps the company’s journey from Hamilton to the Middle East, Asia, and beyond.

Step 1:
I began by compiling a list of all countries where Tim Hortons has opened at least one store. Since there is no single authoritative dataset, I had to build this list manually.

I used official Tim Hortons country pages and local news sources (e.g., CBC News, Bahrain News, Malaysia Lifestyle Asia)

These articles helped me confirm: The country, the city and address of the first-ever location and when the year the branch opened.

Because accuracy matters in mapping, I double-checked every location to make sure my information was credible, date-verified, and sourced properly.

Step 2: Finding Coordinates for Each First Store

Once I confirmed each opening location, I searched for latitude and longitude using Google Maps

This ensured that the map zooms into the exact spot of each first store instead of a general city view. If a building no longer existed or the listing wasn’t clear, I used the most reliable archival address information available.

Step 3: Creating the StoryMapJS Project

After gathering all my data, I went to StoryMapJS (Knight Lab), signed in, and created a new project. I gave it a title that reflects the purpose of the visualization: showing Tim Hortons’ global growth through time.

StoryMapJS works slide-by-slide. Each slide represents a location on the map paired with text and an image. Because the platform automatically pans to your coordinates, it creates a smooth storytelling experience.

Step 4: Designing the Title Page

My first slide acts as a title/introduction page.

I left the location fields empty so that StoryMapJS wouldn’t zoom anywhere yet. Instead, I wrote a short explanation of the project meaning what it shows, why I chose the topic, and how to navigate the timeline.

This gives viewers context before they begin clicking through the countries.

Step 5: Adding Slides for Each Country

This is where the main work happens.

For every country, I clicked “Add Slide” on the left panel. Entered the country’s name, put in the latitude and longitude, added a title, wrote a short description with the in-text citation of the source. I inserted an image that visually represents the branch

StoryMapJS then automatically zooms into the exact coordinates and animates the movement from one country to the next

This creates a chronological touring experience, allowing viewers to follow Tim Hortons’ global expansion in the order it happened.

Step 6: Adding a Final References Slide

Because this project relies heavily on online sources, I added a final references slide listing all of the sources i used. I made sure to use APA citations.

Step 7: Publishing the StoryMap

When all slides were complete, I clicked:

“Save”, then “Publish Changes”

Then “Share” and finally “Copy Public Link”

This generated a shareable URL that can be posted online, embedded, or submitted for grading.

I hope this tutorial was helpful! Here is the link to check my geovis project yourself! Along with a QR code: 

https://tinyurl.com/54w48bdd

A Geovisualization Project by Rukiya Mohamed
SA8905 – Master of Spatial Analysis, Toronto Metropolitan University

As Toronto pushes toward a cleaner, electrified future, electric vehicles (EVs) are steadily becoming part of the urban landscape. But adoption isn’t uniform, some neighbourhoods surge ahead, others lag behind, and the geography of the transition tells an important story.

For this project, I created a time-series animation in ArcGIS Pro that maps how EV ownership has grown year by year across Toronto’s Forward Sortation Areas (FSAs) from 2022 to 2025. Instead of four static maps, the animation brings the data to life, showing how adoption spreads, accelerates, and concentrates across the city.

Background: Why Map EV Adoption?

EVs are central to Toronto’s climate goals, but adoption reflects deeper social and economic patterns. Mapping where EVs are growing helps us understand:

• Which neighbourhoods lead the transition
  
• Which areas may require more investment in charging infrastructure
  
• How adoption relates to broader demographic and mobility trends
  
• Where planning and policy may be falling out of sync with real demand
  

This project focuses on how the transition is happening across Toronto—not as a single snapshot but as a dynamic temporal process.

Data Sources

1. Ontario Data Portal – Electric Vehicles by Forward Sortation Area

• Battery Electric Vehicles (BEVs)
  
• Plug-in Hybrid Electric Vehicles (PHEVs)
  
• Total EVs
  
• Quarterly counts (Q1 2022 → Q1 2025)
  
• Aggregated by FSA (e.g., M4C, M6P)
  

2. Toronto Open Data Portal – FSA Boundary File

• Used to isolate FSAs located within the City of Toronto
  
• Provides the spatial geometry needed for mapping

Methodology

This workflow combines Excel preprocessing with ArcGIS Pro spatial joins and animation tools. Below is the full process with a clear tutorial so readers can replicate it.

Step 1: Cleaning EV Data in Excel

The raw EV file arrived as a single unformatted line. To prepare it:

1. Used TRIM() and TEXT-TO-COLUMNS to separate fields into:
   
   • FSA
     
   • BEVs
     
   • PHEVs
     
   • Total EVs
     
   • Year/Quarter
     
2. Created four separate datasets for:
   
   • 2022
     
   • 2023
     
   • 2024
     
   • 2025
     
3. Saved each file as a CSV for import into ArcGIS Pro.
   

Step 2: Bringing Data into ArcGIS Pro

1. Imported the Toronto FSA shapefile.
   
2. Imported each annual EV CSV.
   
3. Performed a Table → Spatial Join using the common FSA code.
   
4. Calculated EVs per 1000 persons using population from the Toronto boundary attributes.
   
5. Created four clean layers, one per year, ready for mapping.
   

Step 3: Building Choropleth Maps (2022–2025)

For each year layer:

• Applied graduated colours to map total EVs (or EVs per 1000 people).
  
• Used a consistent classification scheme to ensure comparability.
  
• Selected a warm-to-cool colour ramp to highlight hotspots vs. low-adoption areas.
  

This produced four individually interpretable annual maps.

But the real magic comes next.

Step 4: Creating the EV Time-Series Animation in ArcGIS Pro

1. Enable Animation

• Go to the View tab → Add Animation
  A timeline appears at the bottom of the screen.

2. Set Keyframes

For each year layer:

1. Turn ON only the layer for that year.
   
2. Set symbology and map extent exactly as desired.
   
3. Click Create Keyframe.
   Result:

• Keyframe 1 = 2022
  
• Keyframe 2 = 2023
  
• Keyframe 3 = 2024
  
• Keyframe 4 = 2025
  

3. Adjust Timing

• Set transitions between keyframes to 2–3 seconds each.
  
• Add fades if desired for smoother blending.
  

4. Export the Video

• Go to Share → Export Animation
  
• Output as MP4 at 1080p for clean blog-quality visuals
  
• The final result is a smooth year-to-year playback of EV expansion across Toronto.
  

Results: What the Animation Reveals

The time-series visualization shows clear geographic patterns:

• Downtown and midtown FSAs lead early adoption, reflecting higher incomes and better access to early charging infrastructure.
  
• Inner suburbs show accelerating year-to-year growth, especially from 2023 onward.
  
• By 2025, EV ownership forms a distinct corridor of high adoption stretching from the waterfront north through midtown and over to Etobicoke and North York.
  

Seeing these shifts unfold dynamically (rather than as four separate maps) reveals momentum,  not just differences.

Geovis Project Assignment, TMU Geography, SA8905, Fall 2025
By: Haneen Banat

Introduction

Traffic collisions are a major urban safety concern in large cities like Toronto, where dense road networks, high population, and multimodal movement create complex interactions between drivers, pedestrians, cyclists, and transit. Traditional 2D maps and tables can represent collision statistics, but they often fail to communicate spatial intensity or the “feel” of risk across neighbourhoods. For this project, I explore how GIS, 3D modeling, and architectural rendering tools can work together to reimagine collision data as a three-dimensional, design-driven geovisualization.

My project, 3D Visualization of Traffic Collision Hotspots in Toronto, transforms Toronto Police Service collision data into an immersive 3D map. The goal is to visualize where collisions are concentrated, how spatial patterns differ across neighbourhoods, and how 3D storytelling techniques can make urban safety data more intuitive and visually compelling for planners, designers, and the public. I use a multi-software workflow that spans ArcGIS Pro, the City of Toronto’s 3D massing data, SketchUp, and Lumion. This project demonstrates how cartographic tools can support modern spatial storytelling, blending urban analytics with design. 

Data Sources

Toronto Police Open Data Portal

Dataset: Traffic Collisions (ASR-T-TBL-001)
Link: https://data.torontopolice.on.ca

This dataset includes over 770,000 collision records across many years. Each record includes: Location, Date, time, collision type, mode invloved and different attributes. Because the full dataset is extremely large and includes COVID-period anomalies, I filtered the dataset to only the year 2022. This produced roughly 50,000-60,000 collision records. For this project, only automobile collisions were used. I downloaded the geodatabase file as a CVS.

The second piece of data that was needed was City of Toronto – Neighbourhood Boundaries: Link: https://open.toronto.ca/dataset/neighbourhoods/

The third piece of data is City of Toronto Planning, 3D Massing Model. Link: https://cot-planning.maps.arcgis.com/apps/webappviewer/index.html?id=161511b3fd7943e39465f3d857389aab

This dataset includes 3D building footprints and massing geometry. I downloaded individual massing tiles in SketchUp format (.skp) for the neighbourhoods with the highest hotspot scores. Because each tile is extremely heavy, I imported them piece by piece.

Software Used:

• ArcGIS Pr: filtering, spatial join, hotspot analysis
• SketchUp: extrusion modeling and colour classification
• Lumion: 3D rendering, lighting, and final visuals

Methodology

This project required a multi-stage workflow spanning GIS analysis, CAD conversion, 3D modeling, and rendering. The workflow is divided into four main stages.

Step 1: Data Cleaning & Hotspot Analysis using ArcGIS Pro

Filtering Collision Data:

The Police dataset originally contained 772,000 records.

1. Applied a filter for OCC_DATE = 2022
2. Removed non-automobile collisions
3. Ensured that only records with valid geometry were included
4. Downloaded as File Geodatabase (shapefile download was corrupt)

After filtering, the dataset was reduced to a manageable 50,000 records

Step 2: Spatial Join (Join collisions to neighbourhoods)

To understand spatial distribution, I joined the collision points to Toronto’s 158 neighbourhood polygons

Tool: Spatial Join

• Target features: Neighbourhoods
  
• Join features: Collisions
  
• Join operation: JOIN_ONE_TO_ONE
  
• Match option: INTERSECT

Step 3: Hotspot Analysis (Optimized Hot Spot Analysis)

Tool: Optimized Hot Spot Analysis
Input: All collision points
This produced a statistically significant hotspot/coldspot map: White = not significant Red = High-risk clusters Blue = Low-risk clusters

Step 4: 3D Map in Sketchup

Importing DWG into SketchUp

To import into SketchUp, the downloaded SketchUp files of Toronto neighborhood boundaries that were downloaded earlier were used in this stage. Each file must be downloaded separately. Identifying each section was done through the labels that were automatically applied.

Applying Colour Classification: To create a visually intuitive gradient:

Very high hotspots: red, Low collisions: blue

Step 5: Rendering & Visualization in Lumion

Importing the SketchUp Model: The extruded model was imported into Lumion for realistic visualization.

Adding Atmospheric Lighting: Because this visualization focuses on highlighting hotspot intensities, I chose a night time scene: which then i reduced sunlight intensity. Added Spotlights added at various heights Colours represented collision intensity: Blue = lower-risk area, Red = high collision zones

Add lighting and change color to to match the collision type

Decrease the Sun intensity to set a night time setting

Camera Movement & Composition: I created multiple camera angles to show: Nighttime lighting reflecting collision intensity, Panoramic views of the 3D collision landscape, Close-ups of high-risk clusters

Step 6: Exporting the Final Renders

Each neighborhood would need to be rendered at the chosen angle and exported. 

Results

1. Downtown and Waterfront

Areas such as St. Lawrence–East Bayfront–Islands, Harbourfront–CityPlace, Fort York–Liberty Village, and West Queen West showed extremely high collision densities

2. Inner Suburban Belt

Neighbourhoods like South Riverdale, Annex, Dufferin Grove, and Trinity-Bellwoods exhibited moderate-to-high collision intensity, correlating with high pedestrian and cyclist activity.

3. Lower-risk Zones

Coldspots appeared mainly in low-density residential neighbourhoods with fewer arterial roads.

3D Advantages

The extruded height and nighttime lighting made it easy to instantly see:

• Which areas had the most collisions
• How intensity changes across neighbourhoods
• Where the city might focus safety interventions

Limitations

• Massing data is extremely large: Importing all of Toronto was impossible due to memory and file size constraints.
  Only selected hotspot tiles were used.
• Temporal variation ignored: This project analyzed only 2022 and not multi-year trends.
• Hotspot analysis generalizes clustering
  While statistically robust, it does not differentiate between collisions caused by traffic volume, infrastructure, or behavioural factors.
• Rendering is interpretive
  Height and colour were designed for visual storytelling rather than strict quantitative precision.
• Limited Interactive: The 3D render isnt interactive unless you have acess to the softwares used, which would either need to be Sketchup or Lumion.

Conclusion

This project demonstrates how collision data can be transformed from static points into an immersive 3D visualization that highlights urban road safety patterns. By integrating ArcGIS analysis with architectural modeling tools like SketchUp and Lumion, I created a geographically accurate, data-driven 3D landscape of Toronto’s collision hotspots.

The final visualization shows where collisions cluster most intensely, provides intuitive spatial cues for understanding road safety risks, and showcases the potential of hybrid cartographic-design workflows. This form of neo-cartography offers a compelling way to communicate urban safety information to planners, designers, policymakers, and the public.