Javascript – Master of Spatial Analysis

Visualizing 2013 Cyclist Collisions in Ottawa with Mapbox

Author: Ben Kennedy

Geovis Project Assignment @RyersonGeo, SA8905, Fall 2021

Data referenced contains information licensed under the Open Government Licence – City of Ottawa.

Initial Concept

Early on, when thinking about the project, I decided I wanted to choose a technology I had little to no exposure to and really dive deep into how it worked and what it was capable of. I looked through several different technologies and eventually decided on Mapbox as a result of William Davis’ site and the vast array of cool interactive projects using it as their platform. Mapbox is a platform specifically for web or application maps that gives the user an incredible degree of control over the appearance of all aspects of a map. It does this by providing a studio interface (GUI) where a user can customise a basemap by importing shape files, geojson files, image files, etc. Once you’ve edited this basemap to your satisfaction you can export the map as a url and link it directly into an html document.

My initial idea was to use time series data with a slider to visualize bike accidents in my home city (Ottawa) over a number of years. However, because of how Mapbox methods and functions work (more on this later) I chose to use a slider to run through the numbers of accidents by intersection from a particular year. With this in mind I began the construction of my website (and more tutorials on Mapbox methods than I care to remember)…

Webmap Construction

I will admit quite frankly that I know absolutely nothing about html and CSS, both essential components in website design. However, I do have some javascript experience and since mapbox methods are built on node.js this proved invaluable. The first step in the map construction thankfully involved only graphical tweaking of the openstreetmap basemap that Mapbox provides as an editable style. Keeping in mind those important cartographic principles, I chose to change all the major components on this map into shades of navy blue. I also gave the labels a larger white halo to allow them to stand out and hid those I didn’t think would be very useful.

The next step was to upload a shapefile of the accident points from 2013, obtained from the City of Ottawa open data portal, to Mapbox. Mapbox acts as a host for shape files, geojson, etc. that you upload to it, and converts all these formats into tilesets that you can call in your map by referencing a url. You can also add these tilesets directly into your basemap, however this makes them harder to work with when you eventually switch over to code. For this map, I chose to add a shapefile of the City of Ottawa neighbourhoods directly to my basemap since I had no interest in making this layer interactive. I also uploaded a shapefile containing the cycling network for the City to my basemap just out of personal interest. The file containing the accident points and information was left as a tileset and not added to the basemap so we could easily call it when developing our interactive elements.

The tileset and all of its fields referenced in the final map

Now that I had my data uploaded and my basemap complete it was time to move into a code editor and put together my webmap.

A Daunting Amount of Code

Now, when you first look at the code for this webmap it can appear quite daunting, I certainly felt that way when I first tried to figure it out. You’ll need a few things to actually start editing your html page: 1. You need to go download the node.js repository, this is what Mapbox methods and fuctions run on. 2. You’ll need a good editor/compiler and a live server of some sort so you can see your changes in real time. I used Atom as my editor and then a free live server called “atom-live-server” which is available through atoms tools library. I also played around with creating a python local server – hosted from my PC, but this is quite complicated and it’s much easier to use the available tools.

Once you’ve got all this together it’s time to start putting together your webpage. You can either code it entirely from scratch or base it on a pre-existing project. Since I had little to no experience with html and CSS I chose to take one of Mapbox’s example projects and edit it using my own maps and functions. What this means is that the basics of the page itself were already set up, however none of the information was present. So, for example, the slider element was in the webpage, but none of the information you could scroll through was present, nor was there a method linking the slider to a filter for that information.

Some of the basic HTML and CSS that I edited

So, on to Mapbox and it’s various methods and functions. First off was to add the basemap as the “map element” on our webpage. This was done by plugging the url into the “style” field of the map element. This essentially imports the full style that you’ve created in the GUI. When doing this it’s also important to set your starting zoom and centre point. If you don’t do this, Mapbox will default to a full world zoomout and place you at the projection centre. Here I chose a starting zoom of 9.1, which gives a good overview of the City of Ottawa and a centre sitting smack in the middle of the City.

Next, we call the tileset containing the collision points. I have to admit it took me a full week of work to get this part right. Mapbox has a ton of different ways of styling these layers that you can play with directly in the code. However, ashamed as I am to admit it, my major issue here was not adding the “mapbox://” before my tileset id. This is very important, without this your map will just appear blank, as you are adding a layer that for all intents and purposes does not exist to Mapbox. Once I had eventually figured this out I went ahead and added the layer with a few style options worked out. The three major things I chose to style with the layer were: 1. I set the circle radius to grow with the number of cyclist collisions per point. This was done using a “get” function on the “2013_CYCLI” field that was part of the collisions shapefile. 2. Next, I interpolated the colour of the points, again on the number per intersection, just to give a little more distinction. 3. Finally, and this is a very important step, I set a filter on the “2013_CYCLI” field that would ensure only points with cyclist collisions would be added to the map.

The basic building blocks of my webmap, including the layer calls and styling options

Let’s Add Some Interactivity

Our next step was to link the slider element of our html page to a function that would allow it to filter data. I used a very simple setup for this that would run through the “2013_CYCLI” field and filter the intersections by position on the slider. To do this, I created a variable that stored the slider position as an integer. I then used a “filter” function to go through the layer and pull all accidents with that value or higher. So now the slider would let you go through all the accidents in 2013 and look at all collisions involving cyclists, locations with 2 or more cyclist collisions, and locations with 3 or more cyclist collisions. Essentially, you can see which intersections in Ottawa are the most dangerous for cyclists.

The slider function with the final layer call to re-add the streets to the map

The final touch was to call another layer from openstreetmap and overlay it so you were able to see the road network. With this done, the webmap was complete and ready to be shared.

Oh Github

To share the map I chose to use Github pages. The process is relatively simple once you get going. The first thing to do is to ensure that your html file is called “index” – this is the root file for a github pages site as you are able to add several different pages to any site you create. As we were just sharing the single page, calling it index ensures that it’s always displayed when you load the site. Next you upload the html file to Github, or you link the folder on your machine to github through the github desktop app, I found this super useful as Atom (the code editor I was using) has github desktop integration. And voila, once you’ve enable the pages option in your github repository settings, you can share the link with whomever you’d like!

And here, in fact, is the link to the final product: https://benken97.github.io/SA8905Final/

I do think it would be remiss not to mention a few of the issues I had: 1. The major one was the lack of tutorials for Mapbox. While there is a lot of examples and their API and style reference is exhaustive, a lot of the issues I ran into could have been solved very easily if a solid online tutorial library focused on the basics (they do have one but it’s not that helpful for beginners) existed. The second major issue was my complete lack of knowledge when it came to html and CSS. I was able to learn a fair bit as I went but in the end there are a few portions that I wish I could polish up. Specifically, adding tickmarks and a legend to the slider would have been a very useful feature and I spent hours trying to figure that one out. Unluckily not every browser supports tickmarks and/or legends so I ended up just giving the range by the title. Finally, I do wish that the data I was dealing with had been limited to cycling incidents, as the inclusion of all collisions forced me to filter by cyclist collision rather than year.

Natural Disasters around the world from 1950-2018

By: Zahra H. Mohamed for SA8905 @RyersonGeo

You can download the code here!

Introduction

Natural disasters are major events that result from natural processes of the planet. With global warming and the changing of our climate, it’s rare to go through a week without mention of a flood, earthquake, or a bad storm happening somewhere in the world. I chose to make my web map on natural disasters, because it is at the front of lot of people’s minds lately, as well as there is reliable and historical public data available on disasters around the world. My main goal is to make an informational and easy to use web page, that is accessible to anyone from any educational level or background. The web page will display all of the recorded natural disasters around the world over the past 68 years, and will allow you to see what parts of the world are more prone to certain types of disasters in a clear and understandable format.

Figure 1. Map displaying natural disaster data points, zoomed into Africa.

In order to make my web map I used:

Javascript – programming language
HTML/CSS – front-end programming language and stylesheets
Leaflet – a javascript library or interactive maps
JQuery – a javascript framework
JSCharting – a javascript charting library that creates charts using SVG (Scalable Vector Graphics)

Data & Map Creation

The data for this web map was taken from: Geocoded Disasters (GDIS) Dataset, v1 (1960-2018) from NASA’s Socioeconomic Data and Applications Centre (SEDAC). The data was originally downloaded as a Comma-separated values (CSV) file. CSV files are simple text files that allow for you to easily share data, and generally take up less space.

A major hurdle in preparing this map was adding the data file onto the map. Because the CSV file was so large (30, 000+). I originally added the csv file onto mapbox studio as a dataset, and then as tiles, but I ended up switching to Leaflet, and locally accessing the csv file instead. Because the file was so large, I decided to use QGIS to sort the data by disaster type, and then uploaded them in my javascript file, using JQuery.

Data can come in different data types and formats, so it is important to convert data into format that is useful for whatever it is you hope to extract or use it for. In order to display this data, first the markers data is read from the csv file, and then I used Papa Parse to convert the string file, to an array of objects. Papa Parse is a csv library for javascript, that allows you to parse through large files on the local system or download them from the internet. Data in an array and/or object, allows you to loop through the data, making it easier to access particular information. For example, when including text in the popup for the markers (Figure 2), I had to access to particular information from the disaster data, which was very easy to do as it was an object.

Code snippet for extracting csv and creating marker and popup (I bolded the comments. Comments are just notes, they are not actually part of the code):

// Read markers data from extreme_temp.csv
$.get('./extreme_temp.csv', function (csvString) {

  // Use PapaParse to convert string to array of objects
  var data = Papa.parse(csvString, { header: true, dynamicTyping: true }).data;

  // For each row in data, create a marker and add it to the map
  for (var i in data) {
    var row = data[i];

        // create popup contents
        var customPopup = "<h1>" + row.year + " " + row.location + "<b> Extreme Temperature Event<b></h1><h2><br>Disaster Level: " + row.level + "<br>Country: " + row.country + ".</h2>"

        // specify popup options 
        var customOptions =
        {
          'maxWidth': '500',
          'className': 'custom'
        }

    var marker = L.circleMarker([row.latitude, row.longitude], {
      opacity: 50
    }).bindPopup(customPopup, customOptions);

// show popup on hover
    marker.on('mouseover', function (e) {
      this.openPopup();
    });
    marker.on('mouseout', function (e) {
      this.closePopup();
    });

// style marker and add to map
    marker.setStyle({ fillColor: 'transparent', color: 'red' }).addTo(map);
  }

});

I used L.Circlemarker ( a leaflet vector layer) to assign a standard circular marker to each point. As you can see in Figure 1 and 3, the markers appear all over the map, and are very clustered in certain areas. However, when you zoom in as seen in Figure 3, the size of the markers adjusts, and they become easier to see, as you zoom into the more clustered areas. The top left corner of the map contains a zoom component, as well these 4 empty square buttons vertically aligned, which are each assigned a continent (just 4 continents for now), and will navigate over to that continent when clicked.

Figure 3. Map zoomed in to display, marker size

The bottom left corner of the map contains the legend and toggle buttons to change between the theme of the map, from light to dark. Changing the theme of the map doesn’t alter any of the data on the map, it just changes the style of the basemap. Nowadays almost every browser and web page seems to have a dark mode option, so I thought it would be neat include. The title, legend and the theme toggles, are all static and their positions on the web page remain the same.

Another component on the web page is the ‘Disaster Fact’ box on the bottom right corner of the page. This textbook is meant display random facts about natural disaster over a specified time interval. Ideally, i have variable that contains an array of facts in a list, in string form. Then use the setInterval(); function, and a function that generates a random number, that is the length of the array – 1, and use that as an index to select one of the list items from the array. However, for the moment the map will display the first fact after the specific time interval, when the page loads, but then it remains on the page. But refreshing the page, will cause for the function to generate another random fact.

Figure 4. Pie Chart displaying Distribution of Natural Disasters

One of the component of my web map page, that I will expand on, is the chart. For now I added a simple pie chart using JSCharts to display the total number of disasters per disaster type, for the last 68 years. Using JSCharts as fairly simple, as you can see if you take a look at the code for it in my GitHub. I calculated the total number of disasters for each disaster type by looking at the number of lines in each of my already divided csv files, and manually entered them as the y values. However, normally in order to calculate this data, especially if it was in one large csv file, I would use RStudio.

Something to keep in mind:

People view websites on different platform nowadays, from laptops, to tables and iPhones. A problem with creating web pages is to keep in mind that different platform for viewing web pages, have different screen sizes. So webpages need to be optimized to look good in differ screen sizes, and this is largely done using CSS.

Looking Ahead

Overall my web map is still in progress, and there are many components I need to improve upon, and would like to add to. I would also like to add a bar chart that shows the total number of disasters for each year, for each disaster type , along the bottom of the map, with options to toggle between each disaster type. Also I would like to add a swipe bar that allows you to see the markers on the map based on the year. A component of the map I had trouble adding was an option to hide/view marker layers on the map. I was able to get it to work for just one marker for each disaster type, but it wouldn’t work for the entire layer, so looking ahead I will figure out how to fix that as well.

There was no major research question in making this web page, my goal was to simply make a web map that was appealing, interesting, and easy to use. I hope to expand on this map and add the components that I’ve mentioned, and fix the issues I wasn’t able to figure out. Overall, making a web page can be frustrating, and there is a lot of googling and watching youtube videos involved, but making a dynamic web app is a useful skill to learn as it can allow you to convey information as specifically and creatively as you want.

An Interactive Introduction to Retail Geography

by Jack Forsyth
Geovis Project Assignment @RyersonGeo, SA8905, Fall 2020

Project Link: https://gis.jackforsyth.com/

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

Traffic.me: Mapping live traffic with ArcGIS Runtime SDK and HERE Technologies using Android App Developer

by Nicholas Pulsone
Geovis Class Project @RyersonGeo, SA8905, Fall 2018

Topic & Background

Driving through congested parts of Toronto is a tedious and troubling problem that many people would like to avoid. The goal was to create a mobile application using android app developer that can use traffic data as a live input to map traffic patterns across North America. Many companies such as HERE Technologies record traffic information that updates regularly and can be used to map and observe traffic patterns across the entire world. Using android app developer, it is easy to add software developer packages such as ArcGIS Runtime SDK to develop new tools that can be used on a day-to-day basis.

Data

The first problem when creating an app for a purpose or goal is where to find the data. As previously mentioned, HERE technologies is a company owned by NOKIA and currently has its headquarters in Amsterdam. HERE technologies records live weather, routing and traffic information using a combination of both geolocation and intelligence algorithms. Geolocation services that HERE tracks include:

Devices with location or GPS tracking
Tables or other devices with WIFI and signal strength
Phones while measuring varying strength of reception via cell tower signals

HERE technologies contains a global database of over 93 million cellular towers and over 2.3 billion Wi-Fi hotspots which record and store data. The data needed to be able to map varying levels of traffic or traffic density as well as potential collisions or other disruptions affecting driving conditions. The data would need to be able to be displayed visually on a mapping platform and accessible by android app developer software.

Methods

There are multiple ways a live traffic application can be created using data from HERE technologies:

Creating a live traffic app using HERE API and map creator
Creating a live traffic app using HERE data in ArcGIS Runtime SDK (requires ArcGIS developer license)

The methods in this blog will be describing how to create an application using the data from HERE technologies with ArcGIS Runtime SDK.

The first step is to download the needed requirements. First, is to download the newest version of android app developer studio. Currently, the newest version of Android App developer studio is 3.2.1 and available online for Windows, Mac and Linux. Once android app developer is downloaded, the next step is download the second part of the software that will be used in this creation, which is the ArcGIS Runtime SDK for Android 4.0.

The second step is to set the back-end of the application. After specifying the operating system the application will work on, and inputting the name of the application, the first thing to set up is include the ESRI bintray for ArcGIS.

As ESRI’s repository is not open source, the url must be specified to manually add the url for the ESRI bintray. Then the app dependencies need to updated to include the ArcGIS Runtime SDK.

Once the Gradle scripts were synced, the next step was to add a map view for the app. By default, we can remove the text view element and manually create a map view with the following syntax:

After adding the map view for the data, the next step was to specify a basemap then access the data:

The above syntax is a sample of how a basemap and starting location can be specified upon opening. The final step was to be able to access the data. HERE technologies has collaborated with ESRI to develop a world traffic service that can be accessed from mobile and desktop services using the url:

http://traffic.arcgis.com/arcgis/rest/services/World/Traffic/MapServer

Additionally, ESRI and HERE technologies have also created a layer available on the ArcGIS developer portal to users with an ArcGIS developer license. Once the layer is accessible, it is important to open and save the layer in ArcGIS online and enable sharing and public access permissions. As layers used in ArcGIS require a login to be viewed, the next step is to setup a proxy to bypass the login error that would prevent the data from being used, even if permissions are set to public.

To setup a proxy using the ArcGIS developer server proxy, the application must be authenticated and registered in the ArcGIS developer platform. Once registered, the user has access to many services such as a proxy service which will be used along with the traffic layer.

To enable this proxy under services, we must specify what type of proxy service and request limit the proxy will use. Once the requirements are specified, the service outputs a URL which contains a proxy service from ArcGIS.

To use the proxy, simply add the link as a layer from web in ArcGIS online, and the proxy should be active.

Figure 1: Adding Services to ArcGIS Online Map

The final step was to add in the url for the ArcGIS online webmap which contains the traffic data, into android app developer.

Once the url was added into the Android App developer; just click Sync & Run and the app will appear on your device similar to the picture below!

Limitations

A limitation that was experienced while coding the application was ease of use. Without using a legend or slider, it is very hard to distinguish which areas of Toronto are being affected by what kind of problem. The symbology can be changed, however integrating a legend as a button feature in android app developer was more useful and ultimately was included in the final iteration of the app shown in Figure 3.

NHL Travel Web App

by Luke Johnson
Geovis Project Assignment @RyersonGeo, SA8905, Fall 2017

Context

I’ve been a Toronto Maple Leaf and enthusiastic hockey fan my whole life, and I’ve never been able to intersect my passion for the sport with my love of geography. As a geographer, I’ve been looking for ways to blend the two together for a few years now, and this geovis project finally provided me the opportunity! I’ve always been interested in the debate about how teams located on the west cost travel more than teams located centrally or on the east coast, and that they had a way tougher schedule because of the increased travel time. For this project, I decided to put that argument to rest, and allow anybody to compare two teams for the 2016/2017 NHL season, and visualize all the flights that they take throughout the year, as well as view the accumulated number of kilometres traveled at any point during the season and display the final tally. I thought this would be a neat way to show hockey fans the grueling schedule the players endure throughout the year, without the fan having to look at a boring table!

It all started with the mockup above. I had brainstormed and created a few different interfaces, but this is what I came up with to best illustrate travel routes and cumulative kilometres traveled throughout the year. The next step was deciding on the what data to use and which technology would work best to put it all together!

Data

First of all, all NHL teams were compiled along with the name of their arena and the arena location (lat/long). Next, a pre-compiled csv of the NHL schedule was downloaded from left wing lock, which saved me a lot of time not having the scrape the NHL website, and compile the schedule myself. Believe it or not, that’s all the data I needed to figure out the travel route and kilometres traveled for each team!

Methods

All of this data mentioned above was put into a SQLite database with 3 tables – a Team table, Arena table, and a Schedule table. The Arena table could be joined with the Team table, to get information on which team played at what arena, and where that arena is located. The Team table can also be joined with the Schedule table, to get information regarding which teams play on what day, and the location of the arena that they are playing.

Because I wanted to allow the user to select any unique combination of teams, it would have been very difficult to pre-process all of the unique combinations (435 unique combinations to be exact). For this reason, I decided to build a very lightweight Application Programming Interface (API) that would act as a mediator between the database and the web application. API’s are a great resource for controlling how the data from the database is delivered, and simplifies the combination process. This API was programmed in Python using the Flask framework. The following screenshot shows a small exert from the Flask python code, where a resource is set up to allow the web application to query all of the arenas, and will get back a geojson which can be displayed on the map.

After the Flask python API was configured, it was time to build the front end code of the application! Mapbox was chosen as the web mapping tool in the front end, mainly because of its ease of use and vast sample code available online. For a smaller number of users, it’s completely free! To create the chart, I decided to use an open source charting library called Chart.js. It is 100% free, and again has lots of examples online. Both the mapbox map and Chart.js chart were created using javascript, and wrapped within HTML and CSS, to create one main webpage.

To create the animation, the web application sends a request to the API to query the database for each team chosen to compare. The web application then loops through the schedule for each team, refreshing the page rapidly to make a seamless animation of the 2 airplane’s moving. At the same time the distance between two NHL arenas is calculated, and a running total is appended to the chart, and refreshed after each game in the schedule. The following snippet of code shows how the team 1 drop down menu is created.

Results

After everything was compiled, it was time to demo the web app! The video below shows a demo of the capability of the web application, comparing the Toronto Maple Leafs to the Edmonton Oilers, and visualizing their flights throughout the year, as well as their total kilometres traveled.

To get a more in depth understanding of how the web application was put together, please visit my Github page where you can download the code and build the application yourself!