Who shops at which store? Answers to this fundamentally geographic question often use a wide variety of models and data to understand consumer decision making to help locate new stores, target advertisements, and forecast sales. Understanding store trade areas, or where a store’s customers come from, plays an important role in this kind of retail analysis. The Trade Area Models web app lets users dip their toes into the world of retail geography in a dynamic, interactive fashion to learn about buffers, Voronoi polygons, and the Huff Model, some of the models that can underlie trade area modeling.
The Huff Model on display in the Trade Area Models web app
The web app features a tutorial that walks new users through the basics of trade area modeling and the app itself. Step by step, it introduces some of the underlying concepts in retail geography, and requires users to interact with the app to relocate a store and resize the square footage of another, giving them an introduction to the key interactions that they can use later when interacting with the models directly.
A tutorial screenshot showing users how to interact with the web app
The web app is designed to have a map dominate the screen. On the left of the browser window, users have a control panel where they can learn about the models displayed on the map, add and remove stores, and adjust model parameters where appropriate. As parameters are changed, users receive instant feedback on the map that displays the result of their parameter changes. This quick feedback loop is intended to encourage playful and exploratory interactions that are not available in desktop GIS software. At the top of the screen, users can navigate between tabs to see different trade area models, and they are also provided with an option to return to the tutorial, or read more about the web app in the About tab.
The Buffers tab allows for Euclidean distance and drive time buffers (pictured above)
Implementation
The Trade Area Models web app was implemented using HTML/CSS/JavaScript and third party libraries including Bootstrap, JQuery, Leaflet, Mapbox, and Turf.js. Bootstrap and JQuery provided formatting and functionality frameworks that are common in web development. Leaflet provided the base for the web mapping components, including the map itself, most of the map-based user interactions, and the polygon layers. Mapbox was used for the base map layer and its Isochrone API was used to visualize drive time buffers. Turf.js is a JavaScript-based geospatial analysis library that makes performing many GIS-related functions and analysis simple to do in web browsers, and it was used for distance calculation, buffering, and creating Voronoi polygons. Toronto (Census Metropolitan Area) census tract data for 2016 were gathered from the CensusMapper API, which provides an easy to use interface to extract census data from Statistics Canada. Data retrieved from the API included geospatial boundaries, number of households, and median household income. The Huff Model was written from scratch in JavaScript, but uses Turf.js’s distance calculation functionality to understand the distance from each store to each census tract’s centroid. Source code is available at https://github.com/mappinjack/spatial-model-viz
Limitations
One of the key limitations in the app is a lack of specificity in models. Buffer sizes and store square footage areas are abstracted out of the app for simplicity, but this results in a lack of quantitative feedback. The Huff Model also uses Euclidean distance rather than drive time which ignores the road network and alternative means of transit like subway or foot traffic. The Huff Model also uses census tract centroids, which can lead to counter intuitive results in large census tracts. The sales forecasting aspect of the Huff Model tab makes large assumptions on the amount of many spent by each household on goods, and is impacted by edge effects of both stores and customers that may fall outside of the Toronto CMA. The drive time buffers also fully rely on the road network (rather than incorporating transit) and are limited by an upper bounded travel time of 60 minutes from the Mapbox Isochrone API.
Future work
The application in its current form is useful for spurring interest and discussion around trade area modeling, but should be more analytical to be useful for genuine analysis. A future iteration should remove the abstractions of buffer sizes and square footage estimates to allow an experienced user to directly enter exact values into the models. Further, more demographic data to support the Huff Model, and parameter defaults for specific industries would help users more quickly create meaningful models. Applying demographic filters to the sales forecasting would allow, for example, a store that sells baby apparel to more appropriately identify areas where there are more new families. Another useful addition to the app would be integration of real estate data to show retail space that is actually available for lease in the city so that users can pick their candidate store locations in a more meaningful way.
Summary
The Trade Area Models web app gives experienced and inexperienced analysts alike the opportunity to learn more about retail geography. While more analytical components have been abstracted out of the app in favour of simplicity, users can not only learn about buffers, Voronoi polygons, and the Huff Model, but interact with them directly and see how changes in store location and model parameters affect the retail landscape of Toronto.
An interactive demo of Voronoi polygons that includes adding and moving stores
GeoVis Project Assignment @RyersonGeo, SA8905, Fall 2020
Natural phenomenon can be challenging to map as they are dynamic through time and space. However, one solution is dynamic visualization itself through time series maps, which offered on Tableau. Through this application, an interactive dashboard can be created which can relay your data in various ways, including time series maps, graphs, text and graphics. If you are interested in creating a dashboard in Tableau with interactive time series and visuals, keep reading.
In this example, we will be creating a timeseries dashboard for the distribution of California’s wildfires over time. The overall dashboard can be viewed on Tableau Public HERE.
First, let’s go over the history of these wildfires which will present an interesting context for what we observe from these fires over time.
History of Wildfires
There is a rich, complicated history between civilization and wildfires. While indigenous communities found fires to be productive in producing soils rich in fertile ash ideal for crops, colonizers dismissed all fires as destructive phenomenon that needed to be extinguished. Especially with the massive fires in the early 1900s causing many fatalities, such as that in the Rocky Mountains that killed 85 people. The United States Forest Service (USFS) decided in implementing a severe fire suppression policy, requiring fires of 10 acres or less to be put out beginning in 1926, and then all fires to be put out by 10 A.M. the next day in 1935. It is expected that from the immediate extinction of fires in the early to mid-1900s, natural fire fuels such as forest debris continued to build up. This is likely the cause of massive fires that appeared in the late 1900s and persist to the current age which continue to be both difficult and expensive to manage. This pattern is obvious, as shown on the bar graph below for the number of fires and acres burned over the years (1919-2019).
Dashboard Creation
Data Importation
Many types of spatial files can be imported into Tableau such as shapefiles and KML files to create point, line or polygon maps. For our purposes, we will be extracting wildfire perimeter data from the Fire and Resource Assessment Program (FRAP) as linked here or on ArcGIS here. This data displays fire perimeters dating back to 1878 up till the last calendar year, 2019 in California. Informative attribute data such as fire alarm dates, fire extinction dates, causes of fire and acre size of fires are included. While there is a file on prescribed burns, we will only be looking at the wildfire history file. The data imported into Tableau as a ‘Spatial file” where the perimeter polygons are automatically labelled as a geometry column by Tableau.
Timeseries
The data table is shown on the “Data Source” tab, where the table can be sorted by fields, edited or even joined to other data tables. The “Sheet” tabs are used to produce the maps or graphs individually that can all be added in the “Dashboard” table. First, we will create the wildfire time series for California. Conveniently, Tableau categorizes table columns by their data types, such as date, geometry, string text or integers. We can add column “Year” to the “Pages” card from which Tableau will use as the temporal reference for the time series.
The following timeseries toolbar will appear, where wildfire polygons will appear on the map depending on the year they occurred and is defined by the following scroll bar. The map can be shown as a looped animation with different speeds.
Additionally, the “Geometry” field can be added to the “Marks” card which are the wildfire perimeter polygons. Tableau has also generated “Longitude” and “Latitude” that are the total spatial extent of the wildfire geometries and can be added to the “Columns” and “Rows” tab.
In the upper-right “Show Me” table, the map icon can be selected to generate the base map.
Proportionally Sized Point Features
Multiple features can be added to this map to improve the visualization. First, the polygon areas appear to be very small and hard to see on the map above therefore it may be more effective to display them as point locations. In the “Marks” card, use the dropdown and select the ‘Shape” tab.
From the shape tab, there are multiple symbols to select from, or symbols can be uploaded from your computer into Tableau. Here, we chose a glowing point symbol to represent wildfire locations.
Additionally, to add more information to the points, such as proportional symbol sizes according to area burned (GIS ACRES field) by each fire. A new calculated field will have to be created for the point size magnitudes as shown:
The field is named “Area Burned (acres)” and is brought to the power of 10 so that the differences in magnitude between the wildfire points are noticeable and large enough on the map to be spotted, even at the lowest magnitude.
Tool Tip
Another informative feature to add to the points is the “Tool Tip,” or the attribute box about the feature that a reader has scrolled over. Often, attribute fields are already available in the data table to use in the tool tip such as fire names or the year of the fire. However, some fields need to be calculated such as the length of each wildfire. This can be calculated from the analysis tab as shown:
For the new field named “Fire Life Length (Days)” the following script was used:
Essentially this script finds the difference between the alarm date (when the fire started) and the contained date (when the fire ended) in unit “days.”
For instance, here are some important attributes about each wildfire point that was added to the tool tip.
As shown, limitless options of formatting such as font, text size, and hovering options can be applied to the tool tip.
Graphics and Visualizations
The next aspects of the dashboard to incorporate would be the graphs to better inform the reader on the statistics of wildfire history. For the first graph, it will not only show the number of fires annually, but the acres burned as this will show the sizes of the fires.
Similarly to the map, the appropriate data fields need to be added to the columns and rows to generate a graph. Here the alarm date (start of the fire) is added to the x-axis, whereas the number of fires and Gis Acres (acres burned) was added to the y-axis and are filtered by “year.”
The field for the number of fires was a new field calculated with the following script:
Essentially, every row with a unique fire name is counted for every year under the “Alarm_Date” field to count the number of fires per year.
Another graph to be added to this dashboard is to inform the reader about the causes of fires and if they vary temporally. Tableau offers many novel ways of displaying mundane data into interesting visualizations that are both informative and appealing. Below is an example of a clustering graph, showing number of fires by cause against months over the entire timeseries. A colour gradient was added to provide more emphasis on causes that result in the most fires, displaying a bright yellow against less popular causes displayed with crimson red.
Similarly to the map, the “(Alarm_Date)” was added to the “Filters” card, however since we want to look at the average of causes per month rather than year, we can use the dropdown to change the date of interest to “MONTH.”
We also want to add the “Number of Fires” field to the “Marks” card to quantify how many fires are attributed to each cause. As shown, the same field can be added twice, such as one to edit its size attribute and one to edit its colour gradient attribute.
Putting it All Together
Finally, in the “Dashboard” tab, all these pages below of the timeseries map and graphs can be dragged and dropped into the viewer. The left toolbar can be used to import sheets into, change the extent size of the dashboard, as well as add/edit graphics and text.
Hopefully you’ve learned some of the basics of map and statistical visualizations that can be done in Tableau using this tutorial. If you’re interested in the history, recommendations and limits of this visualization, it is continued below.
Data Limitations and Recommendations
Firstly, with the wildfire data itself there are shortcomings, particularly that fires may have not been well documented prior to the mid-1900s due to the lack of observational technology. Additionally, only large fires were detected by surveyors whereas smaller fires were left unreported. With today’s technology in satellite imagery and LiDAR, fires of all sizes can be detected therefore it may appear that more fires of all sizes happen frequently in the modern age than prior. Besides the data, there are limitations with Tableau itself. First, the spatial data are all transformed to the spatial reference system WGS84 (EPSG:4326) when imported into Tableau and there can be inaccuracies of the spatial data through the system conversion. Therefore, it would be helpful for Tableau to utilize other reference systems and provide the user the choice to convert systems or not. Another limitation is with the proportional symbols for wildfires. The proportional symbol field had to be calculated and used had to be put to the “power of 10” to show up on the map, with no legend of the size range produced. It would be easier for Tableau to have a ‘Proportional Symbol” added onto the “Size” tab as this is a basic parameter required for many maps and would communicate the data easier to the reader. Hopefully Tableau can resolve these technical limitations to making mapping a more exclusive format that will work in visualizing many dataset types.
With gaps in wildfire history data for California, many recommendations can be made. While this visualization looked at the general number of fires per month by cause, it would be interesting to go in depth with climate or weather data, such as if there are an increasing number of thunderstorms or warmer summers that are sparking more fires in the 200s than the 1900s. Additionally, visualizing wildfire distributions with urban sprawl, such as if fires in range of urban centers or are more commonly in the range of people so are ranked as more serious hazards than those in the wilderness. Especially since the majority of wildfires are caused by people, it would be important to point out major camping groups and residential areas and their potential association with wildfires around them. Also, recalling the time since areas were last burned, as this can quantify the time regrowth has occurred for vegetation as well as the build-up of natural fuels which can then predict the size of future wildfires that can occur here if sparked. This is important for residential areas near these areas of high natural-fuel buildup and even insurance companies to locate large fire-prone areas. Overall, improving a visualization such as this requires the building of context surrounding it, such as filling in gaps of wildfire history through reviewing historical literature and surveying, as well as deriving data of wildfire risk using environmental and anthropogenic data.
Please read on below or use the search function, categories list, or tag cloud to find posts of interest. Keep in mind that most posts reflect student work summarizing one of two projects that had to be completed within a 12-week term. Happy reading!
