University of Southern California Dissertations and Theses

Rails to trails web mapping application for the great Redwood trails: mapping northern California’s repurposed trails

(USC Thesis Other)

Rails to trails web mapping application for the great Redwood trails: mapping northern California’s repurposed trails

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content

Rails to Trails Web Mapping Application for the Great Redwood Trails:

Mapping Northern California’s Trails

by

Melissa Khatry

A Thesis Presented to the
FACULTY OF THE USC DORNSIFE COLLEGE OF LETTERS, ARTS AND SCIENCES
University of Southern California
In Partial Fulfillment of the
Requirements for the Degree
MASTER OF SCIENCE
(GEOGRAPHIC INFORMATION SCIENCE AND TECHNOLOGY)

May 2023

Copyright © 2023 Melissa Khatry
ii

To Chans and Ollie, thank you both for always being so supportive and patient.

iii

Acknowledgements
Thank you to Dr. Swift, Dr. Bernstein, Dr. Ruddell, Dr. Sedano, Dr. Osborne, and Dr. Duan for
the direction and guidance provided. I am immensely grateful for their help, patience, and
dedication to the project. I am grateful for the data provided to me by the Great Redwood Trail
Agency. I hope all the users of the GRT app have a wonderful experience using the app.

iv

Table of Contents
Dedication ....................................................................................................................................... ii
Acknowledgements ........................................................................................................................ iii
List of Figures .............................................................................................................................. viii
Abbreviations ................................................................................................................................. ix
Abstract .......................................................................................................................................... xi
Chapter 1 Introduction .................................................................................................................... 1
1.1. Overview .............................................................................................................................1
1.2. Study Area ..........................................................................................................................3
1.3. Motivation .........................................................................................................................10
1.4. Methodology Overview ....................................................................................................11
1.5. Structure of Thesis ............................................................................................................12
Chapter 2 Related Work................................................................................................................ 13
2.1. Existing Hiking Applications ............................................................................................13
2.2. Tourist-Facing Applications .............................................................................................16
2.3. Apps Utilizing Real-Time Data and Low-Maintenance Apps ..........................................18
2.4. Web Map Development ....................................................................................................21
2.4.1. Web Map Design and Development Process ...........................................................22
2.4.2. User-Focused Design ...............................................................................................23
2.4.3. Interactive Design ....................................................................................................25
Chapter 3 Project Planning and Data Preparation ......................................................................... 27
3.1. Preliminary Client Discussion ..........................................................................................27
3.1.1. GRT User .................................................................................................................29
3.1.2. App Design ..............................................................................................................29
3.2. Esri Software Requirements .............................................................................................30
v

3.2.1. ArcGIS Pro...............................................................................................................31
3.2.2. ArcGIS Online .........................................................................................................31
3.2.3. ArcGIS Web AppBuilder .........................................................................................32
3.2.4. ArcGIS Web AppBuilder Developers Edition .........................................................32
3.2.5. Tech Transfer/Web Server .......................................................................................34
3.3. Data ...................................................................................................................................35
3.3.1. Counties Layer .........................................................................................................36
3.3.2. Trailhead Layer ........................................................................................................36
3.3.3. Hiking Trails Layer ..................................................................................................36
3.3.4. Wildfire Layer ..........................................................................................................37
3.3.5. Weather Events Layer ..............................................................................................39
3.3.6. Data from other WebMap Layers ............................................................................39
3.3.7. Yelp Data from Widget ............................................................................................41
3.4. Great Redwood Trail Agency (GRTA) Data Prep ............................................................42
3.5. Entity-Relationship Diagram ............................................................................................48
3.6. Database Creation and Set-Up ..........................................................................................50
3.7. ModelBuilder Workflows .................................................................................................52
Chapter 4 Development Process ................................................................................................... 54
4.1. WebMap Development .....................................................................................................54
4.2. Symbology ........................................................................................................................56
4.2.1. Hiking Trails Symbology .........................................................................................56
4.2.2. Wildfire Symbology.................................................................................................56
4.2.3. Trailhead Symbology ...............................................................................................57
4.2.4. USA Weather and Warnings Symbology ................................................................57
4.2.5. Counties Symbology ................................................................................................57
vi

4.2.6. Highways Symbology ..............................................................................................58
4.2.7. Recreational Routes Symbology ..............................................................................58
4.2.8. Campground Symbology .........................................................................................58
4.3. Widget Development ........................................................................................................58
4.3.1. Restaurant Locator Widget Creation .......................................................................60
4.3.2. Radar Widget Creation ............................................................................................61
4.3.3. Layers List Widget Creation ....................................................................................62
4.3.4. Wildfire and Weather Information Widget Creation ...............................................62
4.3.5. Wildfire Filtering Widget Creation ..........................................................................63
4.4. UX/UI Design ...................................................................................................................63
Chapter 5 Results .......................................................................................................................... 67
5.1. Database Results ...............................................................................................................67
5.2. ModelBuilder Results .......................................................................................................67
5.3. Widget Customization Results ..........................................................................................69
5.3.1. Restaurant Locator Widget ......................................................................................71
5.3.2. Radar Widget ...........................................................................................................73
5.3.3. Layers List Widget ...................................................................................................75
5.3.4. Wildfire and Weather Information Widget ..............................................................75
5.3.5. Wildfire Filtering Widget ........................................................................................75
Chapter 6 Conclusions .................................................................................................................. 78
6.1. Issues Faced with Data and Software ...............................................................................78
6.1.1. Data Issues ...............................................................................................................78
6.1.2. USC Web Server Issues ...........................................................................................79
6.2. Application Results Discussion ........................................................................................79
6.2.1. Database ...................................................................................................................80
vii

6.2.2. Web Map Symbology ..............................................................................................80
6.2.3. Widget Construction ................................................................................................82
6.2.4. Application Limitations ...........................................................................................83
6.3. Future Development..........................................................................................................83
6.3.1. Future Design ...........................................................................................................84
6.3.2. Other Software Available ........................................................................................85
References ..................................................................................................................................... 86
Appendix A Existing Hiking Apps ............................................................................................... 91
Appendix B Attributes of GRT datasets defined .......................................................................... 94

viii

List of Figures
Figure 1 Project Area ...................................................................................................................... 4
Figure 2 Fire hazard map showing the severity of fires in the project area .................................... 9
Figure 3 Mock trail application to understand the visualization aspect of trail data .................... 29
Figure 4 GRT app Development Process...................................................................................... 34
Figure 5 Fire Data from the GRT Geodatabase ............................................................................ 38
Figure 6 Additional Layers Visualized ......................................................................................... 41
Figure 7 Imported Esri Legacy Map Package with Trail Data ..................................................... 45
Figure 8 Entity-Relationship Diagram .......................................................................................... 50
Figure 9 Datasets Without Relationships ...................................................................................... 51
Figure 10 Web Map on AGOL ..................................................................................................... 55
Figure 11 Manifest.JSON file ....................................................................................................... 61
Figure 12 Esri ModelBuilder Workflows ..................................................................................... 68
Figure 13 Splash Screen Message Mobile Version ...................................................................... 70
Figure 14 Desktop Version of GRT App ...................................................................................... 71
Figure 15 Restaurant Locator Mobile Version ............................................................................. 72
Figure 16 Widget with Populated Restaurants.............................................................................. 73
Figure 17 Radar Widget Mobile Version...................................................................................... 74
Figure 18 Mobile Version of Wildfire Filtering Widget .............................................................. 76

ix

Abbreviations
AGOL ArcGIS Online
APP Application
CAL FIRE California Department of Forestry and Fire Protection
CSDGM Content Standard for Digital Geospatial Metadata
ERD Entity Relationship Diagram
FAQ Frequently Asked Questions
FHSZ Fire Hazard Severity Zone
GIS Geographic information system
GRT Great Redwood Trail
GRTA Great Redwood Trail Agency
HTML HyperText Markup Language
ID Identifier
IT Information Technology
IRWIN Integrated Reporting of Wildland-Fire Information
JS JavaScript
JSON JavaScript Object Notation
MS Microsoft
NAD North American Datum
NCRA North Coast Railroad Authority
NEXRAD The Next Generation Weather Radar
NIFC National Interagency Fire Center
NOAA National Oceanic and Atmospheric Administration
x

PFA Portuguese Forest Authority
Pro ArcGIS Pro
S.B Senate Bill
Saas Software as a Service
SMART Sonoma-Marin Rail Transit
TMCs Traffic Management Centers
QGIS Quantum Geographic Information System
UGC User-Generated Content
URL Uniform Resource Locator
US(A) United States of America
USGS United States Geological Survey
USC University of Southern California
VHFHSZ Very High Fire Hazard Severity Zones
WGS World Geodetic System

xi

Abstract
Many online applications exist that allow users to search for hiking trails, but none have yet
included the new Great Redwood Trail project that spans from San Francisco to Humboldt Bay
in California. This “rails to trails” project is repurposing 320 miles of historic railway tracks in
northwest California into public hiking trails. The new trails exemplify a positive relationship
between human-created infrastructure and nature. Rather than creating more industrial waste, the
Great Redwood Trail Agency is revitalizing the railway tracks for the purpose of promoting
environmentalism and activeness in nature. For this project a mobile web mapping application
was developed to familiarize hikers and the public with these trails. The Great Redwood Trail
application provides and interactive digital map of the trails and includes relevant information
and points of interest in surrounding areas aimed at stimulating the local economy, which is vital
in garnering community support for trail development. Lastly, the app includes real-time wildfire
information since this is now an incessant natural hazard in the Northern California region.
Ultimately, this project aspires to showcase repurposed railways to hiking trails, promote local
communities, and help ensure safety of app users.

1

Chapter 1 Introduction
With the decline of the timber industry in Northern California, a push to improve the region’s
economic state while maintaining its ecological sustainability began in the late 2010’s (Guilfoil
2022). One such means is the nascent and exciting Great Redwood Trail project (GRT), a “rails
to trails” initiative connecting Marin, Sonoma, Mendocino, and Humboldt counties in California
via 320 miles of reclaimed and unused railroad. The GRT provides opportunities for ecotourism,
recreation, and preservation along its course. The project described herein maps the trails for the
public through a web mapping application. The GRT web and mobile GIS application,
henceforth referred to in this thesis as the GRT app, includes five custom widgets that allow
users to access information on the hiking trails, local amenities, and wildfire and weather updates
in a user-friendly digital map interface.
1.1. Overview
The Great Redwood Trail Agency (GRTA) is the organization that leads the rails to trails
project (Guilfoil 2022). Its predecessor institution was the North Coast Railroad Authority
(NCRA), formed by the California Legislature pursuant to the North Coast Railroad Authority
Act (Great Redwood Trail n.d.). The Act was intended to ensure continuation of railroad services
in Northwestern California and envisioned railroads in this region playing a significant role in
the transportation freight (Great Redwood Trail n.d.). The purpose of the NCRA was to maintain
316 miles of rail line. However, the NCRA struggled with rail preservation and lacked consistent
funding. The NCRA was eventually disbanded and later re-envisioned as the GRTA under
California Senate Bill 69 (2021). This bill ensures that the GRT receives funding and support at a
state level (California Senate - Open States 2021-2022).
2

Various organizations from Marin, Sonoma, Mendocino, and Humboldt counties in
California make up the GRTA. In addition to the GRTA, the Sonoma-Marin Rail Transit
(SMART) agency worked to further the development of the hiking trails. The SMART agency
oversaw part of the trail up to Cloverdale, while the GRTA is responsible for trail development
from Cloverdale to Humboldt Bay. Additionally, the state Coastal Conservancy assists in
organizing and planning the master plan for the GRT. The master plan consists of developing the
railway lines into hiking trails from the San Francisco Bay to the Humboldt Bay shoreline. The
GRTA’s mission is to masterplan, design, construct, operate, and maintain the Great Redwood
Trail.
The GRTA strives to connect the five counties through the Great Redwood Trail, as well
as support the local communities surrounding the trail. When managing funding for the trail and
making decisions on how to best promote further trail development, a steering committee
consisting of representatives from each county leads the charge.
The GRTA proposed to repurpose 320 miles of railroad track into a continuous walkable
and bikeable trail beginning in Marin County and ending in Humboldt County (Guilfoil 2022). It
is well on its way and has the potential to revitalize small towns in Northern California, draw
crowds to bed-and-breakfasts and bakeries, and allow locals and tourists alike to enjoy the
splendor of the redwoods of Northern California. This project could benefit individuals, families,
and local economies.
The GRTA was commissioned to further the trail development while encouraging
engagement with the public. Public awareness of the trail development is vital in securing
funding, participation, and tourism for the surrounding areas. To increase public awareness of
and interaction with the trails. The GRTA proposed that a web and mobile app focused on public
3

users, in particular hikers, be developed. The GRT app developed as part of this thesis was
designed to support the rails to trails GRT effort by developing a prototype for the GRT app. The
GRT app is intended to serve the communities involved by providing easy to access information
on trails, local points of interests, weather, and fire warnings in the area.
1.2. Study Area
The GRT app contains unique features beyond existing trail apps, the latter described in
detail in Chapter 2 of this thesis. Digital, interactive maps of the Great Redwood Trails have
never before been mapped to be included in other existing trail apps to date, so including these
trails in the GRT app was considered vital in publicizing the repurposed railroad tracks. The
decision to include weather and real-time fire data in the GRT app was particularly important in
that the area surrounding the trails is susceptible to wildfires (California Department of Forestry
and Fire Protection n.d.). Another unique feature of the GRT app design is a custom widget that
allows users to find restaurants in their proximity so users may engage with the wider local
community and thus help stimulate the local economy.
The region containing the Great Redwood Trails consists of five major counties in
Northern California, including Marin, Sonoma, Mendocino, Humboldt, and Trinity Counties in
Figure 1. Nearly half of the population resides in Sonoma County, and another quarter in Marin
County, which are both in the San Francisco metro area. Four out of the five counties border the
Pacific Ocean which helps bring in tourism for Marin, Sonoma, Mendocino, and Humboldt
Counties. Landlocked Trinity County does not border the Pacific Ocean but can still bring in
trails tourism to stimulate its local economy. The following sections discuss the geography, fire
susceptibility, demographics, and economy of each county. The demographic makeup for the
counties differs amongst one another, however, the total percentages for each of the counties’
4

demographics do not add up to 100% as reported by the U.S. Census Bureau Quickfacts: Marin
County, California 2020-2022, due to the Census methods for calculating these statistics.
Nonetheless, the topographic makeup, fire vulnerability, and demographics of the five counties
contributed to the overall design of the GRT app.

Figure 1 Project Area
5

Marin County’s terrain includes natural sites, such as forests, beaches, and parks that
attract tourists and hikers (Blake et al. 2000). The county encompasses a total area of 828 square
miles including ecological biodiversity in protected plants and animals. As a result of the varying
landscape in Marin County, the topography includes flat lands, coastal zones, and rolling hills
and brush covering areas of Mount Tamalpais (Marin Magazine n.d.). This vast terrain includes
vegetation such as oak trees, firs, and redwoods that are surrounded by water, canyons, and
valleys (Ferguson 2022). With varying microclimates, the residential areas in the hilly areas of
Marin County are highly susceptible to wildfires due to flammable natural vegetation and long-
term drought conditions.
As of 2020 thru 2022, Marin County’s demographics consist of about 84.7% white
population, 16.8% Hispanic population, 6.9% Asian population, and 2.9 African American
population (U.S. Census Bureau Quickfacts: Marin County, California 2020-2022). As of 2022
approximately 64% of its total population contribute to the labor force, with 103,990 people
being employed.
Sonoma County’s landscape is made up of valleys, plains, forests, and beaches that bring
in a wide variety of people to enjoy the terrain through trails. Similarly, to the topography of
Marin County, Sonoma County has considerable biodiversity and varying microclimates in the
region (Tourism Official Site | SonomaCounty.com n.d.). The coastal cities typically experience
fog and cooler temperatures brought by winds from the Pacific Ocean, while inland cities
experience higher temperature and less fog. Cities near the Sonoma Mountains experience the
warmest temperatures due to their distance from the ocean. Most of the county receives a
significant amount of rainfall, with cities near the Russian River yielding the greatest amount.
6

Sonoma County is highly susceptible to wildfires due to extreme droughts and heat (Permit
Sonoma n.d.).
Sonoma County’s demographics consist of 86.1% white population, 28.3% Hispanic
population, 4.8% Asian population, and 2.1% African American population as of 2020 thru 2022
(U.S. Census Bureau Quickfacts: Sonoma County, California 2020-2022). About 65% of its total
population participates in the labor force, with 177,333 people being employed.
Mendocino County accounts for 3,878 square miles and a part of the World Wildlife
Fund's Pacific temperate rainforests ecoregion, which is the largest temperate rainforest
ecoregion on the planet (Olson 2019). The temperate rainforests are filled with diverse
vegetation and contain an equable climate that serves as ideal conditions for visitors. The
county’s topography consists of redwood forests and is one of the three counties in the Emerald
Counties, the other two being Humboldt and Trinity counties (Visit Mendocino County – Room
to Roam n.d.). Mendocino County consists of hills, canyons, and flat lands alongside rivers. The
hilly areas experience drier weather which further fuels wildfires (Frontline 2022). In addition,
the vegetation consists of grass, oak trees, and brush that are highly flammable. The canyon area
in this county consists of rugged terrain in higher elevations with challenging access which can
hinder firefighters’ ability to contain wildfires.
Mendocino County’s demographics consist of 85.7% white population, 27.2% Hispanic
population, 2.4% Asian population, and 1.1% African American population during the year
series of 2020 thru 2022 (U.S. Census Bureau Quickfacts: Mendocino County, California 2020-
2022). As of 2023, approximately 58% of its total population occupies the labor force, with
23,335 people being employed.
7

Humboldt County contains dense areas of ancient redwood forests that exist only in
certain areas of Northern California, making this county a majestic place to visit. This county
consists of 4,052 square miles of forest, mountains, and access to water bodies. The coastal lands
of the county are surrounded by dense amounts of redwood forests (Humboldt n.d.). The varying
elevation can contribute to wildfires spreading to remote areas. The large forests surrounding the
county are also susceptible to wildfires as are many of the homes throughout the area (Fire
Season | Humboldt County, CA - Official Website 2021). This county is separated into two
distinct areas, the northeast and southwest, which are highly susceptible to wildfires, and the
coastal areas and river valleys, which have a lower risk of wildfires.
As of 2020 thru 2022, Humboldt County’s demographics consist of an approximately
83% white population, 13% Hispanic population, 3% Asian population, and 1% African
American population (U.S. Census Bureau Quickfacts: Humboldt County, California 2020-
2022). As of 2023, about 60% of the total population participate in the labor force, with 35,482
people being employed.
Trinity County is unique in that it encompasses 3,208 square miles and has no
incorporated cities, but wilderness areas, scenic rivers, and many outdoor recreation activities
attract tourists to the area (U.S. Census Bureau Quickfacts: Humboldt County, California 2020-
2022). One of the three Emerald Counties, the Trinity Alps, Trinity River, and Trinity Lake
surround Trinity County. The mountains provide the county with diverse vegetation, trails, and
historic logging tracts (Welcome to the Visit California Homepage n.d.). The river and lake
provide the county with a watershed filled with fish and wildlife. This mountainous terrain in
conjunction with dense vegetation makes it difficult for firefighters to respond to fire related
events. The topography of Trinity County includes rugged mountains and rugged hills. This
8

terrain fuels wildfires as intense winds may contribute to wildfires even spreading uphill
(Maizlish et al. 2021). Dense vegetation also serves as a wildfire ignitor that can cause wildfires
to spread throughout the county.
Trinity County’s demographics consist of 82.6% white population, 7.9% Hispanic
population, 2.1% Asian population, and 0.7% African American population from the 2020 thru
2022-year series (U.S. Census Bureau Quickfacts: Trinity County, California 2020-2022). As of
2023, 43% of its total population participates in the labor force, with 1,540 people being
employed.
The population of the five counties is vastly dispersed but the counties do share similar
characteristics. The commonality amongst the five counties include nature, outdoor recreation
opportunities, and wildfire vulnerability. The natural beauty of the counties brings in tourists and
stimulates each county’s economy. Additionally, the landscape of the counties provides the ideal
terrain for hikers to trek along the Great Redwood Trail. But, along with the unique terrain
comes susceptibility to wildfires. The area of interest to the GRT consists of redwood trees that
are highly susceptible to wildfire. Since redwood bark can serve as either a resister or enabler of
fire damage, depending on the tree’s cambium layer, wildfires are a common occurrence (Fritz
1931). Thin trees are more vulnerable to fire damage, as are large trees that have sustained
previous fire damage (Fritz 1931). The wildfire information included in Error! Reference
source not found. shows the susceptibility of the five counties to wildfires.
9

Figure 2 Fire hazard map showing the severity of fires in the project area (California Department
of Forestry and Fire Protection n.d.)
A Fire Hazard Severity Zone (FHSZ) is a mapped area that designates zones that are
susceptible to fire hazards as created by the California Department of Forestry and Fire
10

Protection (California Department of Forestry and Fire Protection n.d.). These FHSZ zones are
categorized by varying levels of severity: moderate, high, and very high. The FHSZ maps
illustrate where wildfire susceptibility could be high, but the maps do not predict where a
wildfire will occur. Additionally, the FHSZ maps act as a way for local governments and citizens
to take wildfire precautions and be prepared. Error! Reference source not found. shows fire
severity zones for State Responsibility Area (SRA).
1.3. Motivation
The GRT app development is an important contribution to the GRTA by making
information about the Great Redwood Trails easily accessible via the internet. Rather than going
through traditional public awareness routes such as paper flyers or word-of-mouth promotion, a
web and mobile app allows anyone living anywhere to view the trails. Online access to hiking
trails helps share information about ongoing trail developments. Such public visibility about trail
development can garner funding and public support for the completion of the rails to rails efforts,
as well as contribute to local economies as previously mentioned. The five counties have natural
habitats that surround the Great Redwood Trail, environments resplendent with native beauty
perhaps known to users unfamiliar with this region. In summary, the region of the GRT app
includes information about these five counties, Marin, Sonoma, Mendocino, Trinity, and
Humboldt. The trails cover hundreds of miles of terrain and run through several cities as well, in
the five counties.

The GRT app is focused on highlighting the amazing work being conducted by the
GRTA and other stakeholders to revitalize unused railroad track into hiking and biking trails and
highlights the new trails (Guilfoil 2022). But the app will go further than just including trails. It
11

encourages users to interact with local businesses and engages community by including
restaurants in the surrounding areas. Also, the app promotes safety for users by mapping out live
fire streaming data. This is to ensure that users have the most up to date information to make the
best decisions. The application is developed to serve the clients, the GRTA.
1.4. Methodology Overview
The GRT app’s goal is to allow users to access information about the existing Great
Redwood Trails, repurposed railroad tracks to trails, local restaurant information, wildfire
location, and weather updates on web and mobile devices. Through discussions with the clients,
the application was created using Esri’s ArcGIS Application Programming Interface (API) for
JavaScript and Web AppBuilder frameworks. Web AppBuilder’s framework consists of pre-built
widgets, templates, and customizable widgets and interactive web maps. Application users can
access the Web AppBuilder app through web browsers or their mobile phones as long as users
have internet access. A widget is a tool that can be further customized to allow users more
interactivity within a given application (ArcGIS Solutions Web AppBuilder Widgets | ArcGIS
Solutions n.d.). These widgets serve to address specific needs of users and can provide unique
functionality in an application.
The design of the GRT app includes built-in features which require no customization
such as map zooming, panning, and choice of map extent (boundaries), allowing users to search
the five-county region using standard web map tools they may be accustomed to using with other
web GIS software such as Google Maps or Apple Maps. The five customized widgets developed
as part of this thesis incorporate several of these built-in features in that they work to extend the
users map search capabilities. The users can filter data to produce user-specific results, such as
finding specific areas that are affected by wildfires in near real-time or are experiencing serious
12

weather conditions in real-time. The GRT app also allows users to turn off spatial data layers in
order to better view specific information of interest to them, such as locating wildfires or local
restaurants in their proximity. The development of this design is explained in detail in Chapter 3
of this thesis.
1.5. Structure of Thesis
The following chapters, sections, and subsections are organized by research, application
requirements, software usage, and customization of the application. The second chapter discusses
the research conducted on existing related applications and guiding tutorials. This research
provided a basis for deciding on key functionalities and features needed in the GRT App. The
third chapter discusses the prerequisites needed in order to begin the application development.
The database creation and web map creation are both described in this section. Additionally, this
chapter details the software used to develop the application. Chapter 3 discusses the various Esri
platforms utilized to create the database, design the web map, and develop the application and its
widgets. The fourth chapter explains the customization of the widgets that comprise the tools
within the application. Chapter 5 illustrates the outcome of the application development process.
From the final database to the end design of the application, the results of the creation of the
Great Redwood Trails application are described. Chapter 6 provides concluding considerations,
such as the overall benefits to the community and GRT app users, limitations to the app
development, and thoughts about future software required to expand upon the GRT app.
13

Chapter 2 Related Work
Many sections of the GRT are open to the public, so it is critical that users can safely and
intelligently navigate the trail. The necessary research for the development of the app includes
analyzing existing hiking applications and their functionalities that pertain to the GRT app to
understand the design and functions of current apps that are most applicable to the clients’ design
requests. Additionally, researching existing tourist-facing apps is vital in ensuring how to best
serve users. Also, a user-friendly interface is paramount to guarantee that an app is successful
and usable. In addition, the next section of research involved understanding how to incorporate
real-time data. Utilizing real-time data can be challenging, so reviewing exiting apps that already
include real-time data serves as guidance for the GRT app. General guides are described that
assisted with designing the customized components of the app. Lastly, the final section of this
chapter discusses web map design. The goal of this design process is ultimately to foster a
positive user experience with the GRT app.
2.1. Existing Hiking Applications
To better understand existing hiking applications and their key features, research on
seven popular hiking applications similar in design and functionality to the client’s requests for
functionality in the GRT app was conducted and is summarized in Appendix A. Each
application’s key features were reviewed as part of this thesis work. Understanding what tools
work well versus those that do not in a hiking app was paramount to present to the clients to
better understand their priorities for the GRT app. The author’s experiences and opinions about
each of the existing hiking trail apps tested as part of this thesis work were shared with the
clients to better understand the key features to be incorporated into the GRT app. This section
describes existing apps tested.
14

AllTrails is currently the leader of existing hiking apps (AllTrails 2010). AllTrails was
presented by the clients as a guide for choosing important functionality for the GRT app. Some
key features of AllTrails include its extensive hiking trails inventory, variety of basemaps,
downloadable maps, and other social exercise and networking features. Subsequent testing of
AllTrails by the author led to inspiration for the GRT app development. For example, some
positives of AllTrails include its filtering capabilities and categorization of trails. Users can filter
hiking trails based on accessibility, distance, and level of difficulty. Some negatives of AllTrails
include its cluttered home page design.
Gaia GPS includes its offline capabilities and highly detailed 3D maps through
subscription (Gaia GPS: Hiking Trail Maps, Ski Touring, 4x4 Offroad App 2021). The best
features of Gaia GPS are the easy-to-read maps illustrating mountain ranges and their peaks, an
important feature which allows for photos to be uploaded to the application by users, and
elevation. Some critiques of Gaia GPS were that the screen split into two maps could cause
confusion for users, and the functionality is geared towards mountain peaks and mountainous
terrain. The feasibility of replicating the intricate maps in the design of the GRT app was
discussed with the clients.
PeakVisor was explored for its detailed 3D (three dimensional) maps of mountainous
terrain. The technology utilized by PeakVisor models’ terrain illustrates the precise landscape of
mountains but is only available through purchase. PeakVisor allows users to not only explore
mountains, but surrounding trails, summits, and parking areas (Peakvisor App 2017). Similarly,
to Gaia GPS, PeakVisor is a mountain-focused app, meaning users have focused access to
information about viewpoints and mountain peaks rather than hiking trails. So, the lack of hiking
15

trails is a weak point in the app. The split screen and 3D views within PeakVisor were discussed
withthe clients.
The Hiking Project was researched because of its publicly sourced hiking information
(Hiking Project 2016). The Hiking Project utilizes publicly crowdsourced data to gather real-
time data from users. The Hiking Project utilized a MapBox basemap and permits customization
of maps by end users. The application includes widgets that allow users to narrow the location or
area they wish to hike in. Some limitations in the application involve its unique use of crowd
sourced data, which lacks quality control. Inaccurate information could mislead users.
Additionally, the search bar produced a list of hikes that does not populate the map, so users
must switch back and forth between a trails list and the actual map. Consideration of inclusion of
crowdsourced data in the GRT app was a key feature discussed with the clients throughout the
exploration of the Hiking Project.
Recreation.gov was reviewed because it includes information about hiking trails,
including their condition (Recreation.gov 2022). However, it extends into allowing users to book
recreational activities. For example, users can book lodging, campsites, kayaking, and other
available activities (Recreation.gov 2022). Similarly, to the Hiking Project, Recreation.gov uses
MapBox to allow developers to create custom maps. Recreation.gov populates data and lists next
to the map, allowing users to view search results and a map at the same time. The addition of
activities and booking choices add uniqueness to the app, however, they are also the app’s
downfall. The extra activities make it difficult for users to find information on actual trail data.
Similarly, the booking feature takes away from being able to plan out a hike. Recreation.gov was
discussed with the clients to determine if local businesses should be included in the GRT app.
16

Far Out app was explored because it contains detailed hiking guides (FarOut n.d.). The
information on trails includes distance, elevation, waypoints, water sources, and campsites.
These trails are viewable in the form of topographic maps or satellite maps. The app also features
live tracking to assist hikers in following trails. Additionally, trail map access is available offline
without any data usage. The biggest limitation of the Far-Out app is that accessing trail guides
with detailed information requires purchase. The highly descriptive trail guide format of Far Out
app was shared with the clients.
Cairn app was researched for its extensive safety features (Fit Club 2019). The app
allows users to record their hikes or runs and provides users with individual activity statistics.
Additionally, users can share their hikes along with their location. The Cairn app developers
promote the location sharing feature as a key to safety. Continuing with safety precautions, the
Cairn app allows users to locate where others have had access to cell phone coverage along a
specific trail. If users do not have access to cell phone reception, the offline capabilities of the
app are extensive. Users can send time specific messages and share their location. The main
limitation of the Cairn app is that it focuses more on safety than on providing an extensive trail
repository. The Cairn app was shared with the clients as an example of offline app capabilities,
and to discuss if some of the safety features of Cairn might be recommended to be replicated.
2.2. Tourist-Facing Applications
The GRT app is a hiking app that also allows users to gain access to local restaurant
information. This is important in going beyond existing hiking applications and including
tourism features in the application. Working with local communities that are impacted by the
Great Redwood Trails is paramount in ensuring support and collaboration with the GRTA Team
17

and these communities. The following studies describe the importance of such user-friendly
features.
It was important to understand the relationship mobile phones play in tourism and
decision making. A study by Wang et al. (2011) explored stories of those who travel and use
smartphones for planning and making travel-related decisions. The results of the study show that
utilizing phones for travel purposes can change tourists’ behavior and emotional states by
addressing a wide variety of information needs. For example, phones provide instant information
which then enables tourists to share experiences and “store” memories more effectively (Wang et
al. 2011). The implications of these findings are important in that they suggest an immense
potential for smartphones in changing many aspects of the tourism business. This component of
utilizing smartphones to stimulate tourism is a significant contribution of the GRT app.
Smartphones, especially, play a key role for hikers through their access to the internet
that allows for real-time research of trails and updates on their conditions. Increasingly, hikers
opt to bring their smartphone along for hikes. The inclusion of smartphones on hikes has been
studied by Anderson and Jones (2017). They conducted a survey to assess hikers’ preferences
and found that 95% of respondents to their survey prefer to bring a smartphone when they go
hiking. Their survey discusses the increasing role of cell phones in hiking expeditions. Rather
than rely on static or printed maps, hikers now utilize apps to navigate through trails (Anderson
and Jones 2017). The use of phones and apps when hiking has led to debate over whether this
leads to meaningful hiking interactions or distracts users while hiking. Anderson and Jones
(2017) discuss both sides of the debate, but ultimately conclude that cell phones already exist in
hiking interactions and do improve hiking experiences. They conclude that bringing a cell phone
on a hike is like bringing a tool that can hinder or further an experience. This decision is up to
18

the hiker or cell phone user. The respondents from Anderson and Jones’s (2017) survey
reportedly used their cell phones in positive ways, creating a positive experience with their cell
phones and nature. Thus, hikers who have access to the GRT app can make real-time decisions
that can positively impact their hiking experience.
2.3. Apps Utilizing Real-Time Data and Low-Maintenance Apps
The inclusion of real-time data in the GRT app was an integral part of the app and served
to add uniqueness to it. Live data allows users to digest up-to-date information which impacts
their decisions. From deciding which trails to use to avoiding certain areas, the inclusion of live
wildfire information in the application is intended to help keep users safe. The following section
covers existing literature about similar uses of real time data.
Real-time information can provide the public with live updates that support decision
making. Specifically, real-time data incorporation in public safety components, such as fire
maps, can promote safety and inform citizens of the location of wildfires. For example, Teodoro
and Duarte (2013) conducted a study to explain the process of creating and sharing of real-time
forest fire risk maps for the Northwest of Portugal. This study wanted to ensure accessibility to
the maps by utilizing three open-source desktop GIS software all while creating plug-ins written
in Python to publish such maps (Teodoro and Duarte 2013). The Portuguese Forest Authority
(PFA) requires cities and towns in Portugal to produce annual fire risk maps, so the goal of this
study was to aid the mapping efforts of these municipal entities’ maps that will aid cities and
towns in Portugal in producing annual fire risk maps that the rules of the PFA require. The
project employed three open-source desktop GIS software and creating plug-ins written in
Python to publish maps. Another goal was to utilize open software programs such as QGIS and
develop tools which can be freely used by other professionals. The concept of accessible fire
19

maps influenced the decision to include wildfire data in the GRT app, in particular data that does
not require paid subscriptions or for personal user information to be accessed.
Similarly, information on weather events is useful in providing users with the most up-to-
date information that can help with decision making. On the fly risk assessment provides
relevant information on environmental conditions. This factor was vital when developing the
GRT app, as hikers should possess current information on weather conditions. For example,
Barnett (2016) discusses landslide risk in Western Washington and its effect on the population
and surrounding environment. First, real-time landslide triggering variables are used to generate
a model to report up to date risks to the local areas. The model is shared and published through a
web application to be utilized and replicated in different regions to make assessments on
landslide risk (Barnett 2016). The goal was to create a portable, automated method for assessing
landslide risk to a particular area, providing an opportunity to improve safety. Barnett’s
application (2016) replaced typically static information with near-real time updates on landslide
risk. Similarly, the GRT app is intended to provide real-time weather and future forecasts to help
improve the safety of hikers.
In addition to live data on fire occurrences and weather events, a mobile app in which all
data is updated regularly and in a timely manner is also important. If an app is difficult to
maintain and requires extended periods of time to update, then users may miss out on key
information. To better understand the creation of a minimal maintenance app, a study by Neene
et al. (2017) provided guidance. The goal of the study by Neene et al. (2017) was to create an
app that maps property easily and quickly. The application was useful to help local jurisdictions
in developing countries to easily overcome the challenges they typically experience when
mapping property. The application is fully mobile, multi-user, real-time, and fast. Also, the users
20

do not have to be GIS experts. The app was low cost because the data and software used to build
it was free or inexpensive. In the app, the user access simple forms to record property attributes
(owner, address, land, and building info), draw polygons (draw with satellite image and GPS),
and capture images (pictures of the property) for consenting property owners. The property
information is saved in a PostgresSQL database. The tool can be used by anyone, even those
with no GIS experience (Neene et al. 2017). This app is an easy to maintain app that does not
require a software developer to maintain, so it can be easily replicated by non-developer
professionals.
Similarly, to the importance of a low-maintenance app, an app that does not require
extensive software development knowledge is vital to the design of the GRT app. The future
maintenance of an app is just as important as the preliminary development. Ensuring robust
performance, accuracy, and minimal downtime for app maintenance is vital. Specifically, for the
GRT app, a seamless management strategy was prioritized, so that future developers of the GRT
app would have a straightforward to update the app. To provide guidance in how to create an app
that is accessible to all developers of all skill levels, a study by Wiley (2018) created a wildfire
tracking service that required minimal GIS or software development knowledge. The aim of the
Wiley (2018) study was to create a Web GIS that does not require GIS background or specific
fire management knowledge, but still has a credible source to provide information on wildfire
preparation in Santa Barbara County (Wiley 2018).
This web GIS tool is extremely useful in increasing wildfire awareness and preparedness
for the Santa Barbara County community. The author discusses some limitations that they
believed were hindering the application. They included the overall coding knowledge of the
author, the ability to edit the widgets and features because of source limitations, and the addition
21

of crowd-sourcing tools. Incorporating crowd-sourcing tools can strengthen an application. By
adding comments or real-time updates from the community about wildfire status can provide
quick, updated information on wildfires that some static websites can. The application aims to
provide its users with up-to-date tracking information about nearby and surrounding wildfires.
Additionally, users can access the web application via any source of device and without any
previously needed credentials. This makes the application equitably accessible to all. The layout
of the page also highlights the usability of the application. The various sources of information
input into creating a rich map of wildfires in the county, the widgets chosen, and the format of
the map all add to an easily readable and understandable application. The web application is
directed for all, no matter their GIS knowledge or wildfire knowledge. This factor is important in
that it guided the author to create a project that is simple yet resourceful. Lastly, the author
desires to further develop the application by creating a section to allow for user input. This
represents the “user-generated content” by allowing the users to add data, furthering their
interaction and applicability to the web mapping application.
2.4. Web Map Development
The creation of the GRT app web map involved relying on existing literature for
guidance on effective and ineffective practices. Web map literature discusses the design and
development process for creating the most efficient map. Additionally, the importance of
components such as a user-focused design and an interactive design were heavily prioritized.
Understanding these practices influenced decisions about which components would be
prioritized in the GRT app and web map. The following subsections go into detail about this
literature review concerning the design and development process of a web map, how to create a
user-centered map, and the importance of creating interactivity in a map.
22

2.4.1. Web Map Design and Development Process
When creating a web map, the design is important in producing the final web map that
will be integrated into a mobile app such as the GRT app. First, the design component consists of
thinking through and visualizing the final map. Many questions and considerations impact the
design of a map. From user friendliness to deciding the color of certain features, designing a map
incorporates a variety of elements. The development process builds off the design stage by
constructing the theoretical components of the design. Developing a web map incorporates all
the aesthetic elements needed, but also includes programming and constructing. The following
section discusses the two processes and their eventual joining to create a final map.
Existing literature discuss topics from how to avoid a poor design to steps to create the
most user-friendly map. These topics emphasize the importance of consistency, easy viewing,
attention grabbing, best formatting, and template design. However, the most crucial factor a
developer should consider is knowing their web map user (Hansen 1971). Understanding who
the target audience is vital in designing a map. Although the design workflow differs for app
developers, understanding the user requirements ensures how the map functions, the widgets
included, and how any unique features should perform. Building from the design process, the
development process ensures that the main project goals are brought to fruition.
The development environment consists of GIS-based software that allows for
programming and editing of web maps. Developers must decide early on which web map tools to
add to a web map to make it useful for the user. With the array of technological options for
developers, there exists the possibility of not only creating an oversimplified map but creating a
map with too much information (Haklay 2010). In the development process, developers decide
how much information to convey and where to convey it on the map. Without this decision
making, maps can become too busy and distract users from the relevant information. It is up to
23

the map developers to determine how the users will consume the map and how long it will take
them to consume. Therefore, the design of the GRT app web map prioritized key spatial data
layers that were symbolized to ensure clarity in content of each layer and that none of the layers
were hidden from the user. Rather than overwhelming a GRT app user, the web map within the
GRT app focuses on key components. For example, the key layers in the web map are the hiking
layers. So, symbolizing each trail segment in a way that is eye-catching but not overwhelming
ensured that users can digest the information they are looking at. Additional layers include for
example the counties of the project area, the trailhead points, the location of wildfires, intended
to aid in navigation, local resources, and safety options, as previously mentioned. The
symbology choices for each layer play a significant role in determining how user consumes the
information presented by the developer. The GRT app web map symbology choices were made
so that each layer’s content, or purpose, was obvious and not obscured.
2.4.2. User-Focused Design
As stated in Chapter 1, the users of the GRP app are assumed to be the general public, in
particular people who hike trails. When creating a web map within a web or mobile GIS app,
centering the design around the users is of the utmost importance. It is the users that interact
most with a web map within the app and determine whether the design is successful (Fleming
1998). To create a product that will benefit its users, one must have a good understanding of the
psychology of the users as well as being familiar with the web and mobile GIS technology being
used to develop the design. This focus on combining psychology and technology stems from
Donald Norman’s human-centered design approach (Norman 2013). Prioritizing human needs
ensures that developers understand these as design requirements then accommodate those needs
in the development stage. Thus human-centered design is a process that works to create a design
24

that fulfills the needs and capabilities of the intended users. This approach requires developers to
create memorable or pleasurable experiences for their users to ensure longevity of a product.
User-centered design is a concept that is now at the forefront of web mapping design with
the explosion of cell phones using mobile web GIS apps every day. As users are becoming more
mobile so must their maps. Creating a web map that is not only compatible for mobile users but
also focuses on their needs while they are on the go is vital in the user-centered design approach.
To ensure users’ needs are met, web cartographers can design the most successful map by
focusing on user interfaces, map functionality, and the interactive components (Tsou 2011). User
interface is described as the tool that allows users to communicate with the map (Haklay 2010).
User interface design is the process of creating tools and functionality that then allows for
interaction with the map. This design process ensures that users can extract the information they
need from the map. So, part of the user interface design process is to decide what buttons will
best convey the desired information and where these buttons should be placed in the app and web
map helps create a user focused map design (Cybulski and Horbinski 2020). The creation of web
and mobile GIS tools, buttons, or widgets is what sets the stage for user interactivity. The GRT
app and web map tools were designed and placed in the most efficient places within the app, to
gain insights and feedback to iterate the design. The process of understanding how the user
interacts with the map begins with the first design testing. In summary, the layout of the GRT
app was determined to prioritize the web map and use of the widgets with the intent of
strengthening the map interaction user experience. In a nutshell, the design focused on how users
interact with the widgets that populate results into the web map, then how they consume the
resulting map. Ultimately this is a map centric user design.
25

2.4.3. Interactive Design
A pivotal component of a web map is its interactivity for users. Generally, users expect to
be able to easily manipulate, zoom, and filter information displayed on a web map. The
interactive design should ensure that users can do the right things – what they are expecting to do
- at the right time (Rosson and Carroll 2001). Interactivity strengthens the communication
between the map and user. Meaning, the user requests the map to perform a function and the map
responds to the request and produces a result. For the GRT app, successful interactivity means
users are able to utilize widgets to find area-specific information on trails, restaurants, weather
events, and wildfires displayed on a web map. The widget design allows each GRT app user to
have a tailored experience with the GRT app and its web map through their specific widget
requests.
Roth (2017) emphasizes the importance of interdisciplinary practices of cartography.
Since technological advancements have led us to rethink how we visualize and create maps, Roth
(2017) discusses the need to use mapping technologies alongside traditional cartographic
practices to design maps for web and mobile applications (Roth 2017). Through focusing on the
user and their needs, maps and mapping tools can evolve to suit not only user needs but increase
interactivity with maps. Each user has a different justification or need to access or look for
information. Therefore, the cartographic or web map interaction needs to satisfy each user's
needs at each stage of the process. Finding the balance between the amount of web map
interaction required and the complexity of these interactions is particularly important in creating
a user-friendly experience. The user and who they are or what they want is at the core of
customization. The user's needs, experiences, and knowledge are all factors that affect the
cartographic interaction’s effectiveness.
26

In conclusion, visualizing geospatial data in a web or mobile GIS application requires key
guidelines. Web maps exist to answer questions users have, such as finding the location of
something or obtaining directions to a certain point. Web maps must be designed so that users
can visualize the answers to their questions. Also, a good web map design means that the
transferal of data to a map accurately reflects the geospatial information (Kraak and Brown
2014). Thus, the goal of the GRT app is for a user to be able to easily locate places and points on
the map and understand the symbology used to represent an object or a location. Symbology,
object placement, and visualizing data accurately were all elements of the GRT app’s web map
composition (Muehlenhaus 2013). The decisions about what to display on the GRT app web map
involved two critical web map making elements: how to display information and what the user
interaction should be with this information.
To summarize chapter 2, detailed research was conducted on existing hiking tourist
applications to aid in the design of the GRT app. The components deemed most useful by the
clients were incorporated into this design, also taking int consideration the use of real-time local
resource data as well as up-to-date trails information typically included in existing hiking apps.
Finally, the GRT app and web map within it were designed by the processes described above,
following user-focused and interactive web map design best practices recommended for the
GRTA’s intended audience. The next chapter described the implementation of this research in
the GRT app development process.

27

Chapter 3 Project Planning and Data Preparation
The first step in the development of the GRT app involved in-depth collaborations concerning
the design with the clients, as described in Chapter 2. This Chapter describes subsequent
discussions with the clients to finalize the user scenario, web and mobile GIS software
requirements, the spatial data collected, stored, and incorporated into the GRT app, and
customized GIS-based workflows created to facilitate long-term maintenance of the data within a
web or mobile GIS app.
In Section 3.1, the initial client discussions took place in order to determine what a GRT
user will require of the app and the app’s overall design. Next, Section 3.2 discusses the software
for the GRT app. Section 3.2 discusses the functionality of Esri’s various platforms that were
used in this thesis. Section 3.3 highlights the key datasets used in the GRT app. Section 3.4
describes how the initial data provided by the GRTA were prepared for use in the GRT app were
conducted. Section 3.4 details the spatial data analysis steps taken to prep and upload the data
into a spatial database. Section 3.5 discusses the next step of creating an entity-relationship
diagram with the datasets. Section 3.6 explains the creation of the spatial database and how the
data were added to the database. Section 3.7 explains the three ModelBuilder workflows created
as part of this thesis that facilitate data maintenance. This chapter focuses on data preparation
steps that led to the creation of the GRT database that fed into the GRT app.
3.1. Preliminary Client Discussion
From the initial client meeting, it was determined that an Esri-based application would be
the best platform with which to develop the GRT app. This decision was made because of Esri’s
Web AppBuilder platform that contains customizable widgets and its easy maintenance. The
initial meeting with the GRTA team provided an opportunity to present a mockup trail app and
28

discuss which platform would be best suited for the GRT app. The initial research conducted for
the clients discussed in Chapter 2 was presented to the clients, summarized in Appendix A. The
table of hiking apps in Appendix A displays the functionalities and widgets of various
applications that have similar purposes to those of the GRT app. This research was presented to
the clients to gather feedback on key functionality they require in the app. Through these
discussions with the clients, the initial application (GRT app) was created using Esri’s ArcGIS
Application Programming Interface (API) for JavaScript and Web AppBuilder framework. The
Web AppBuilder framework consists of pre-built widgets, templates, and the ability to customize
widgets as well as a web map incorporated into the app. Users can access Web AppBuilder apps
through web browsers or using mobile devices, as long as users have internet access.
The first application development stages included creating a mockup application design
to show the clients how the user interface would appear as shown in Error! Reference source
not found.. To provide an example of a hiking application interface, the Santa Monica
mountains trail data was chosen. This choice was made because of the data’s availability and
hiking features. The clients provided positive feedback that, in turn, informed the next iteration
of changes that the application should include. Feedback from the clients determined that the
application should contain localized descriptions of features and places within the study region.
For example, the new rails to trail data and maps should be shown in the application.
Additionally, features such as searching for points of interest, such as restaurants and amenities
should be included, as well as the addition of real time wildfire data. The clients concluded that
the application should be unique and should feature local amenities, while the most important
feature of the application remains the visibility and usability of the trail features.
29

Figure 3 Mock trail application to understand the visualization aspect of trail data
3.1.1. GRT User
The client’s emphasis on the importance of the trails and local amenities influenced the
design of the GRT app. According to the clients, a typical GRT user, in particular those
unfamiliar with a given area, will consists of a hiker that utilizes a mobile device during a hiking
event. Additionally, the clients stipulated that users should have the option to access local
weather conditions and wildfire events in order to aid in their decision about where best to hike
in real time or near-real time. Therefore, weather and wildfire information were added to the web
map, to be accessed using customized widgets. The web map was designed so that only selected,
specific layers are automatically turned on, to keep the web map initially loaded clean and not
cluttered. These choices were made with the hiker GRT app user in mind.
3.1.2. App Design
The preliminary discussion with the GRTA clients provided a general basis for the GRT
app’s web map design. Based on these requirements, the prioritized layers and their symbology
30

were developed into the web map. Additional decisions about the final web map design were
influenced by the literature and current hiking app reviews that included best practice guidelines
for web GIS app developers. These practices focused on who the application user is and what
their needs are, the design of the map itself and its key functions, and the importance of creating
an enjoyable interactive experience for users. It is important that the components are positioned
in the application in an appropriate, easy to view and use way.
Since a mobile application was the GRTA end goal, it was important to have each
widget, layer, or feature viewed and utilized in a simple to use design for users. Additionally,
minimal future maintenance of the GRT app was part of the development process emphasized by
the GRTA team since it would be fully transitioned to the GRTA team at the end of the project
Also, the client requested that the application software be low cost and require minimal software
development skills to maintain.
The main goal of the GRTA was to create an application that included all of the relevant
spatial data and was fully mobile, multi-user, real time, and fast. Another requirement was that
users did not have to be GIS experts to effectively use the GRT app. The application from the
study has an extremely low cost because everything is free or cheap for the developers. The
mobile cloud computing uses mobile and cloud computing and solves problems with limited
computing, storage, and energy resources in mobile devices (Neene et al. 2017). The GRT app
was developed to be easy to maintain and not require a software developer to update and deploy
it. This is a crucial factor for the development of the application for the GRT and stakeholders.
3.2. Esri Software Requirements
The Esri platform offered the most appropriate web and mobile GIS application
functionality, application development tools, and easiest long-term maintenance, so therefore it
31

was the best choice for the GRT app. Each step in the development process involved utilizing
various Esri platforms, including cloud-based GIS, online mapping tools. The Esri software
utilized to build the various components of the GRT app are described in the following sections.
3.2.1. ArcGIS Pro
Esri ArcGIS Pro provided a platform to create an appropriate spatial database, the Esri
File Geodatabase, for this project. In Pro, the data provided by the GRTA team were stored in a
single project database, referred to as the GRT database, that serves as the foundation for hosting
all the data used in the application. With the GRT database created, attribute relationships were
established based on a unique entity relationship diagram created as a data structure design for
this project. These relationships helped to connect and validate the attribute data within the tables
in this spatial database. Additionally, Pro’s ModelBuilder tool provided an easy-to-use
geoprocessing environment to develop multiple repetitive workflows to support data
manipulation and decrease the potential for human error in completing geoprocessing tasks.
Three unique ModelBuilder workflows were created to support semi-automated data additions or
updates in the spatial database, deletion of data from the database, and an option for amending
existing data in the GRT database.
3.2.2. ArcGIS Online
After the map from Pro was shared, the map layers required editing and updating on
ArcGIS Online (AGOL). AGOL is Esri’s software as a service (SaaS) platform that runs through
internet access. It integrates with desktop platforms, such as ArcMap and ArcCatalog and
ArcGIS Pro. A key feature is the sharing capabilities of AGOL. The simple functionality of the
AGOL platform makes sharing maps with the public extremely easy. The Living Atlas feature in
AGOL allows for creators to select various basemaps to include in the map. Additionally,
32

ArcGIS Online contains a lot of data from Esri, Esri partners and the Esri user community. This
data allows access to authoritative data sources and layers to be included in a web map. For
example, the wildfire data, weather data, and highway data were all found through AGOL’s
extensive authoritative datasets. The layers were added to the web map, as well as the cited
sources for each layer. Having the ability to access data from credible sources, such as the
California Department of Transportation or the National Weather Service ensures all the web
map layers are reflecting accurate and legitimate data. Through AGOL’s web mapping services,
content creators can use their existing web maps to create applications through Esri’s ready-to-
use apps.
3.2.3. ArcGIS Web AppBuilder
Esri’s Web AppBuilder provided a platform for the GRT app and its widgets to be
developed on. This decision was made because of the customization of widgets and template
theme for the application. Web AppBuilder allows for an easy transition from the creation of a
web map in AGOL to developing an application. There are many built-in widgets included in
Web AppBuilder that developers can utilize. Additionally, there are premade templates to
display the web map and widgets. There exist ways to create custom widgets and templates in
the developer’s edition of Web AppBuilder that the online version does not contain. The
developer’s edition contains custom widgets tools for the application.
3.2.4. ArcGIS Web AppBuilder Developers Edition
In addition to the templates offered by Web AppBuilder, the depth of custom features
offered through the developer edition of Web AppBuilder allowed for further customization and
development of the application (Create your first app-ArcGIS Web AppBuilder | Documentation.
n.d.). The developer downloaded the software node.js. This software download was necessary
33

because Web AppBuilder runs on top of node.js, so it had to be installed on the computer.
The ArcGIS Web AppBuilder download package contains the Windows version of Node.js that
allows for the developer edition to be downloaded and edited.
Once the developer edition was downloaded various folders were contained within the
argiswebappbuilder developer edition download. The folder contained data and code on all the
ready-to-use widgets, templates, and developer guidelines. Additionally, there were sample
widgets and templates that could be utilized to create custom widgets or themes.
The development process in Error! Reference source not found. specifies sections of
the workflow further by describing coding libraries. These libraries are vital in creating any
interactivity a developer wishes to be available on their map. For the creation of the Great
Redwood Trail application, the development environment was Esri’s Web AppBuilder
Developers Edition platform. The folder containing all the preliminary code was opened through
sublime text editor. Sublime text editor was used to ensure any additional programming could be
performed then reflected in the developer’s console. The data for the application was formatted
as shapefiles, map packages, map exchange documents, and live layers. Esri’s ArcGIS Pro
hosted the data in a geodatabase. Once the symbology for the datasets was determined, the web
map was then shared to ArcGIS Online to be integrated into the GRT app. The coding and
interface creation for the application was done utilizing JavaScript. JavaScript was utilized to
generate content that is regularly updated. Once the application was created, it was deployed
onto USC’s web server.
34

Figure 4 GRT app Development Process
Next, a sign in portal appears to access the development platform homepage. The sign in
consists of having an ArcGIS organizational account or an ArcGIS Developer account. Then, the
URL for the ArcGIS organizational account that Web AppBuilder will access must be specified.
After log in credentials are used, then the app had to be added to ArcGIS Online to obtain
an app id. This meant going to the developer’s AGOL account and adding the app. First, one
must navigate to the My Content tab then click add item. The following parameters had to be
specified, type of app, purpose, API, and URL. For the GRT app, the type of app selected was
Web Mapping, the purpose was Ready to Use, JavaScript API selected. These steps ensured the
app was registered and ready to be developed.
3.2.5. Tech Transfer/Web Server
Esri’s ArcGIS API for JavaScript is laid out to support custom Esri tools, and for
developed applications to be registered then rehosted on another web server. USC web server
35

hosted the app. Uploading the application to the server required the code in the config.json file
had to include code that added a proxy to the proxy property in the application. Next, the
application had to be registered through Esri. The application’s ID had to be included and
updated in the config.json file. After all the programming edits were completed, the application
was ready to be transferred to the USC web server. To do so, FileZilla was utilized to upload the
folder to the personal USC account directory. The folders were able to be transferred to the USC
web server, but the GRT app would not load on a web browser. So, a new way of transferring the
app had to be developed. For this, the GRT app was downloaded and saved to a shared google
drive. There, the GRT app can be downloaded with five widgets. Rather than uploading the
entire GRT app into a WebApp Builder, the five widget folders were copied over to a new app
template. Once the five widgets were added to the new app’s widget page, they were added to
the web app and placed around the web map. The web map was kept the same and selected to be
included in this new version of the GRT app web app. Once the widgets were uploaded and the
original web map selected the web app was able to be transferred to the clients.
3.3. Data
The data used in the GRT app is described in the following sections. This data contained
datasets that were incorporated into the GRT database. The GRTA provided key datasets on
trailhead points, bike lanes, counties, and other project area features. Additionally, live fire and
weather events datasets were incorporated into the GRT app to allow users access to more
information. All the datasets used in the GRT app provided users with key information, such as
county boundaries, trailhead points, hiking segments, live fire locations, and weather patterns.
36

3.3.1. Counties Layer
The counties layer was shared from the GRTA team via google drive. In google drive, the
counties layer was downloaded as a shapefile then uploaded as a feature class into the GRT
database. The layer was in the NAD 1983 (2011) State Plane California projection. These
attributes gave identifiers to each county. The data author is stated as GRT since the GRTA team
provided the datasets that did not contain metadata with the origin source. However, through
research, the attributes in the table matched the data from the California County Boundaries
feature layer by the California Department of Forestry and Fire Protection. This authoritative
source containing the same data as the GRT key counties layer, ensured the information’s
legitimacy and was added to the map.
3.3.2. Trailhead Layer
The trailhead data was used in the GRT app to represent the trailhead points of the hiking
trails. The trailhead layer was shared from the GRTA team via google drive. In google drive, the
trailhead layer was downloaded as a shapefile then uploaded as a feature class into the GRT
database. The trailhead layer was in the NAD 1983 (2011) State Plane California projection. The
attribute table contained the following columns on the gps coordinates of the trailheads, the name
of the trailheads, and their elevation. The author of the layer is the GRTA team. Since this data
was created by the GRTA, they are credited for its creation and the primary data source. Unlike
the Counties layer, the trailhead layer did not have an authoritative source to check it against. It
was still added to the map because of its vital information on trailhead location.
3.3.3. Hiking Trails Layer
The hiking trails layer was utilized in the GRT app so that users could view the location
of the trails. The trails layer was shared from the GRTA team via google drive. In google drive,
37

the trails layer was downloaded as map packages then uploaded as a feature class into the GRT
database. The trails layer was in the NAD 1983 (2011) State Plane California projection. The
attribute table contained the following columns on the length of the trails, the location of the
trails, and their specific ID. Similarly, to the trailhead layer, the hiking trails layer attributed the
GRTA as its author. This was because of its creation by the GRTA members to create trail
segments. These segments are characterized by the type of trail, existing trails, and bike lanes,
proposed hike and bike trails, and different type of trail classifications. This layer was important
for GRT users to have access to because of the trail segments. This layer gives users information
on trail routes and future trail routes.
3.3.4. Wildfire Layer
The next dataset of use involved real-time fire data so that users could have real-time updates
as to where wildfires occur. Through ArcGIS Online’s layers, Esri had an authoritative layer of
fire data. The fire data is updated regularly, according to the description of the feature layer.
Since the fire information is regularly updated and comes from the Federal government’s
Integrated Reporting of Wildland-Fire Information (IRWIN) and National Interagency Fire
Center (NIFC) initiatives, it was deemed sufficiently authoritative and added to the map in
Figure 5. For the live-fire data, Esri’s live fire data stream was used which sources its data from
Integrated Reporting of Wildland-Fire Information (IRWIN) and National Interagency Fire
Center (NIFC). These are collaborative reporting ventures from several Federal agencies,
including the Bureau of Land Management, the National Parks Service, and the US Fish and
Wildlife Service. To ensure this data was accurate and legitimate, researching both entities’
websites provided the authoritative, trustworthy data needed to ensure the fire streaming was
reflective of real time updates.
38

Figure 5 Fire Data from the GRT Geodatabase
The live streamed data was created by the California Governor’s Office of Emergency
Services that was projected in WGS 1984. The fire data from this layer was divided into two
categories, wildfires, and wildfire perimeters. The current incidents or wildfire points were
obtained from Integrated Reporting of Wildland-Fire Information (IRWIN). While the current
perimeters or wildfire perimeter were obtained from National Interagency Fire Center (NIFC).
The data from the IRWIN provided users with information of wildfire points on the map. These
wildfire points were categorized by acreage, 300,000 or more, 50,000-299,999, 10,000-49,999,
1,000-9,999, 0-9,999, New (Past 24-hours), Incident Complex, and Prescribed Fire. The NIFC
displayed fire perimeters to show users the boundary encompassed by a wildfire. These were
included in the web map to give users access to wildfire information. The legitimacy of the
wildfire data sources ensured that users were streaming accurate information.
39

3.3.5. Weather Events Layer
The National Weather Service layer provides users information on the type of weather
event occurring and where it is occurring. The National Weather Service was the source for
weather data that was projected in WGS 1984. This weather data was visualized as polygons
showing the area of a weather event, which was organized by event type. This feature layer was
created by Esri but sourced its data from the National Weather Service. This layer was added to
the web map to show users where extreme weather events were occurring.
3.3.6. Data from other WebMap Layers
The additional layers included are the national highway layer, weather conditions layer,
campgrounds, and recreational routes. The inclusion of the highway layer provides users with
some geographic reference. Highways are easily distinguishable and provide a solid frame of
reference when trying to understand one’s location. The highway layer is a way of linking the
built environment, such as highways, with the natural environment, such as the trails. The
highway layer serves as a source of navigation for the users to utilize. Similarly, the weather
forecast layer provides users with valuable information. The weather conditions of a particular
area influence one’s decision to hike in that area. The layer helps serve the users in a way that
allows them to make decisions that pertain to their safety. The weather conditions layers make it
easy for individuals to access weather-forecasting information that impacts users’ decision
making. With use of the additional layers, users can determine the safest route to take to access
campgrounds.
Overall, these additional layers feed information to the users. With the inclusion of the
highway and recreational routes data, users have a frame of reference and a geographic source.
These layers serve as an overview for users to understand the layout and landscape of the area
40

shown in Figure 6Error! Reference source not found.. Without the additional data layers, users
would simply have a map showing trail landscape lacking roadways that are commonly utilized.
Mapping out highways and roadways is vital in displaying a publicly used source of
transportation and movement. Similarly, campground areas are important for the user to plan out
visits. Combining road status information along with campsite locations gives users the most
relevant information when making decisions. The importance of weather data is similar in
providing users with valuable information as the inclusion of highway and campground data. The
decision to include weather patterns is to provide users with information that can impact their
decision on where to hike. Delivering weather data to users not only impacts their decision
making but helps ensure their safety. A hiking application provides users with information on
trails, but an application, such as the Great Redwood Trails application, goes further and
provides users with information to help orient themselves and make safe decisions. These layers
are visualized in ArcGIS Online as shown in Figure 6.

41

Figure 6 Additional Layers Visualized: The National Highway Layer, Weather Conditions
Layer, Campgrounds Layer, and Recreational Routes
3.3.7. Yelp Data from Widget
The restaurant data was gathered through a token requesting information on restaurants
from Yelp’s API. This source was legitimized through Yelp’s extensive data resource guidelines.
42

The moderators for Yelp evaluate the accuracy, eligibility, and formatting of all business
information submissions. The accuracy of business information is checked against the primary
business website, business presence on social media outlets, and relevant user-generated content
(UGC) (Yelp Developers n.d.).
Table 1 Primary Datasets Utilized in Application
Data Name Data Type Acquired Original Projection Source
Key Counties Shapefile NAD 1983 (2011)
State Plane California
GRT

Yelp Yelp API WGS 1984 Web
Mercator (auxiliary
sphere)
Yelp API
Fire Feature Layer WGS 1984 Web
Mercator (auxiliary
sphere)
Esri Authoritative
Source-
Integrated
Reporting of
Wildland-Fire
Information
(IRWIN) and
National
Interagency Fire
Center (NIFC);
initially NASA’s
data was going to
be used
Weather Events Feature Layer WGS 1984 Web
Mercator (auxiliary
sphere)
National Weather
Service
Hiking Trails Map package NAD 1983 (2011)
State Plane California
GRT
Trailhead Points Shapefile NAD 1983 (2011)
State Plane California
GRT
3.4. Great Redwood Trail Agency (GRTA) Data Prep
The datasets provided by the GRTA were shared through a Google Drive containing Esri
legacy formats including shapefiles and map packages that were to be explored and uploaded to
the GRT database. These datasets were initially visualized using ArcGIS Pro to better understand
43

their purpose and functionality for the web map. The datasets were used in the beginning stages
of the database creation. The datasets were cleaned up to reduce any duplicates, had attributes
defined, and used to create relationships with each other. The datasets were transferred as
shapefiles in the WGS 1984 Web Mercator (auxiliary sphere) projection. The shapefiles included
key counties information, trailhead points, and hiking trails.
To utilize the key counties dataset, preliminary preparation was required. The key
counties dataset was in the NAD 1983 (2011) State Plane California projection and had to be
reprojected to WGS 1984 Web Mercator (auxiliary sphere) projection. The dataset was uploaded
into the database in its original format, a shapefile. This consisted of selecting the GRT database
then importing the shapefile. Once the key counties shapefile was uploaded, it was then
analyzed. The attribute table was opened, and missing attribute definitions were noted and sent
over to the GRTA team for clarification. The dataset did not contain a credit source, but through
research, the key counties dataset matched county data information from the State of California’s
GIS database. The key counties layer shared from the GRTA seemed to be a clipped version of
the State of California’ overall county shapefile. Therefore, the key counties layer was added to
the web map.
For the trailhead points data, it was uploaded to ArcGIS Pro in its original projection,
NAD 1983 (2011) State Plane California. Then, the attribute table was opened to better
understand what the trailhead points represent. At this step, it was understood that this data layer
was point data that showed the location of the trailheads for each trail. The table contained
latitude and longitude points that, when searched in Google Maps, gave the point location of a
trailhead. So, this data created by the GRTA was included in the web map to show users where
44

the trailheads were located. This layer worked alongside the hiking line segments layer to
provide both a starting point for the trails, as well as highlighting the actual trails.
The second set of data that was shared from the GRTA team contained data on trails
projected in NAD 1983 (2011) State Plane California that would later be reprojected to WGS
1984 Web Mercator (auxiliary sphere) projection. The bike facilities data was divided into two-
point categories showing bike parking and bike shops. The bike routes dataset contained bike
routes in Arcata, Blue Lake, Eureka, Ferndale, Fortuna, HC, Multiregional Facilities, PCBR
Humboldt Co, Rio Dell, and Trinidad. The bike shapes dataset contained existing bike shapes in
Arcata, Blue Lake, County, Eureka, Fortuna, Rio Dell, and Trinidad. The existing bike lanes
dataset contained a single layer that contained existing bike lanes from 2017-2018.
The infrastructure dataset contained layers on Amtrak lines, bus routes, and other transit
routes. The major destinations dataset showed destinations that included commercial and
business centers, major destinations for all jurisdictions, major destinations for Fortuna, and
major destinations for Rio Dell. Lastly, the trails data contained a layer labelled HP3 Routes.
This should contain all the hiking trail line segments. However, to ensure the trails were
accurately depicted through the HP3 Routes layer, the mdx and mpk files were uploaded to Pro
and analyzed.
To bring the ArcMap .mdx data into ArcGIS Pro, it consisted of clicking the Import Map
on the Insert tab to view the new map. Next, the data path sources were corrected, and updated
path files were saved and refreshed to be reflected on the map. This final display included the
bike lanes and trails in the project region.
To import the Esri ArcGIS Desktop legacy map packages (mpk) in Pro, using the import
map function to select all the map packaged to be imported into the project. The map packages
45

were not imported directly to the database, they were viewed in Pro as various map layouts.
Figure 7 shows an imported map package originally provided by the GRTA team. Each layout
contained a legend, symbology, and trail lines. The map packages confirmed that the
HP3_Routes layer was in fact the trail layer. The only layer imported into the GRT geodatabase
was the HP3_Routes layer. This layer contained the hiking trail segments. This was the
prioritized layer to be included in the GRT app.

Figure 7 Imported Esri Legacy Map Package with Trail Data
The HP3_routes data layer was added to the web map because of its hiking trails created
by the GRTA team. The legitimacy of the data stems from the GRTA team creating these line
segments of current and future trail development. The HP3_Routes layer was checked to ensure
that all the necessary lines segments were included through the cross reference of the
HP3_Routes layer and the map packages that showed localized or zoomed in areas of the trail
segments. Since the map packages already symbolized the line segments in a particular format,
this symbology was transferred over to the HP3_Routes layer that would be used in the web app.
46

The next three datasets analyzed were the Major Rivers GRT layer, Major Lake and
Reservoirs GRT, and the Major River and Creeks GRT. These datasets were shared as shapefiles
in the NAD 1983 (2011) State Plane California projection. Similarly, to the other datasets, they
were uploaded to Pro, and each attribute table was analyzed. The source for these datasets was
unknown, so checking their attributes against attributes USGS’s Content Standard for Digital
Geospatial Metadata (CSDGM) ensured that the three datasets being analyzed were actual river,
reservoir, and creek locations. The datasets were confirmed to be legitimate rivers, reservoirs,
and creeks, but they were specific rivers, reservoirs, and creeks to the project area. Therefore,
they were reprojected to WGS 1984 Web Mercator (auxiliary sphere) projection and uploaded to
the GRT database.
The Key Cities and Cities GRT shapefiles were shared in the NAD 1983 (2011) State
Plane California projection. These datasets were represented as polygons showing the boundaries
of cities rather than points. To ensure the city boundaries layer shared from the GRTA were
correct, they were checked against the State of California’s city boundary layer. Once the GRTA
datasets and the State of California’s city boundary layer were uploaded to Pro, it showed the
overlap between city boundaries. So, the city layer was just specific cities that were pulled from
the overall California City boundary layer. It was then reprojected to the WGS 1984 Web
Mercator (auxiliary sphere) projection and uploaded to the GRT database.
The Subwatershed GRT and Subbasins GRT were shared similarly to the other datasets
in that they were shared via Google Drive as shapefiles in the NAD 1983 (2011) State Plane
California projection. Similarly, to the other datasets, once the attribute tables were opened the
attributes were not defined or understood. So, researching the attribute definitions from the
USGS’s website allowed for clarification. This led to the realization that the two datasets were
47

the boundaries or watersheds and basins in the GRT project area. A quick search of the location
of the subwatersheds and subbasins showed that they were legitimate locations of active
watersheds and basins. Therefore, the two datasets were reprojected to the WGS 1984 Web
Mercator (auxiliary sphere) projection and uploaded to the GRT database.
The Bioregions dataset was shared through Google Drive as a shapefile in the NAD 1983
(2011) State Plane California projection. This dataset was easier to analyze because of its broad
attributes. Rather than being a specific subset of data focused on the GRT project area, the
Bioregions layer was an overarching dataset of ecological makeup. This dataset was much easier
to overlay over the Environmental Protection Agency’s Ecoregions of the US since they were the
same. Therefore, its legitimacy was confirmed through overlaying with an authoritative
bioregion layer. It was then reprojected to the WGS 1984 Web Mercator (auxiliary sphere)
projection and uploaded to the GRT database.
The Bays dataset functioned like the Bioregions dataset. It was also shared through
Google Drive as a shapefile in the NAD 1983 (2011) State Plane California projection. Similarly,
to the Bioregions layer, the Bays layer was not specific to the GRT project area. The Bays layer
encompassed a greater scale. To ensure the Bays layer represented the actual location of bays, it
was overlayed with National Oceanic and Atmospheric Administration’s (NOAA) data layer on
bays. Once both datasets were uploaded to Pro and analyzed for overlap, it was confirmed that
the Bays dataset shared from the GRTA was legitimate. Then the Bays layer was reprojected to
the WGS 1984 Web Mercator (auxiliary sphere) projection and uploaded to the GRT database.
The GRT 5-Mile Points is like the Trailhead layer, discussed in the previous sections, in
that it represents Trailhead locations but splits the points to show them at a frequency of five
miles. The GRT 5-Mile Points layer is a duplicate of the trailhead layer but lacks detailed
48

information from the trailhead layer. The realization of the similarities between 5-Mile Points
and the Trailhead layer was realized when comparing their attribute tables. Both shapefiles share
similar attributes and point locations on the map, however, the frequency of points differs
between the two. The GRT-5 Mile Points layer was reprojected to the WGS 1984 Web Mercator
(auxiliary sphere) projection and uploaded to the GRT database, but it was not prioritized to
represent the trailhead locations as the Trailhead layer was.
The Rail Mile Posts GRT layer was shared similarly to the other datasets in that it was
shared via Google Drive as shapefiles in the NAD 1983 (2011) State Plane California projection.
Its attribute table was opened and analyzed to understand the shapefile better. Once opened, the
attribute table contained information of rail station locations and names. So, this layer
represented the points of where rail stations are located. To be sure that the rail stations were
represented correctly in the Rail Mile Posts GRT layer, the rail station was searched in Google
Maps for legitimacy. Once the rail stations were searched and existed in the correct county and
district as shown in the attribute table and Google Maps, it was confirmed that the rail stations
were correct and able to be used. The Rail Mile Posts GRT layer was reprojected to the WGS
1984 Web Mercator (auxiliary sphere) projection and uploaded to the GRT database.
3.5. Entity-Relationship Diagram
Once all the initial data from the GRTA team was prepped, an entity-relationship diagram
was created to establish relationships between datasets that would eventually be transferred to
the GRT database. To begin, the data that was acquired from the GRT team was downloaded
from the google drive then uploaded to ArcGIS Pro to be visualized. Once visualized, each
layer’s attribute table was opened to fully understand the purpose of each dataset. Some of the
attributes did not have clear meanings. So, it was decided to start a data dictionary defining what
49

attributes were known and asking the clients for the definitions of the unknown attributes. This
step was vital to begin the next step, creating an entity-relationship diagram. An entity-
relationship diagram serves to establish relationships between the datasets that will later be
created in the Pro database. The entity-relationship diagram (ERD) shows the datasets that were
established to be relational to another dataset depicted below in Figure 8Figure 8. The ERD
consists of all the GRTA layers and their attributes from each dataset. In black text are the data
attributes that were able to be defined, while in red text are the attributes that no definition was
able to be found. Each dataset is in a three-column chart. The first column determines which
attribute is the primary key. The second column lists all the given attributes of the dataset. The
third column describes the type of data of the attribute. The relationships established were five
relationships between datasets. The first relationship was a one-to-many relationship between
Major Rivers GRT and Major Rivers and Creeks GRT. Next, there was a one-to-many
relationship between GRT 5-mile points and GRT points. Then, another one-to-many
relationship between Key Cities GRT and Cities GRT. Key Counties and Rail Mile Posts GRT
had a one-to-many relationship. Key Counties and GRT counties had a one-to-many relationship.

50

Figure 8 Entity-Relationship Diagram
3.6. Database Creation and Set-Up
After the entity-relationship diagram was constructed, the creation of the ArcGIS Pro
geodatabase began. Section 3.4 discusses the data prep steps that were taken to ensure the
relevant layers were added to the map. The shared GRTA datasets were uploaded into the
geodatabase. This was done by adding the shapefiles directly into the database rather than just
adding data to the map. If the data was simply added to the map, then the datasets would not
exist in the actual database. After all the datasets were uploaded into the database, the
relationships from the ERD were created in Pro. To create the relationships in the database, one
right clicks on the dataset on interest in the database. Then navigate to manage and click on the
relationships tab. Here, the relationship between datasets is established, as well as primary keys,
and the cardinality of the relationships. The first relationship was a one-to-many relationship
between Major Rivers GRT and Major Rivers and Creeks GRT. Next, there was a one-to-many
relationship between GRT 5-mile points and GRT points. Then, another one-to-many
51

relationship between Key Cities GRT and Cities GRT. Key Counties and Rail Mile Posts GRT
had a one-to-many relationship. Key Counties and GRT counties had a one-to-many relationship.
The rest of the datasets that did not contain relationships were added to the database as well.
They were included separately from the ERD tables, but still included in both the geodatabase
and the data dictionary. Figure 9 below shows the non-relational datasets. After the datasets were
uploaded to the geodatabase, the map in Pro was shared as a web map. The web map’s title had
to be stated as well as the summary of the map and any tags. This map from Pro had to be shared
as a web map to be accessed in ArcGIS Online because the only way to select the base web map
for the app was to select a web map from AGOL.

Figure 9 Datasets Without Relationships
52

3.7. ModelBuilder Workflows
The next step was creating a ModelBuilder that will update the database with data. First,
the developer must navigate to the Analysis tab of the ArcGIS Pro ribbon. Then, ModelBuilder is
selected. Once selected a new window opens with an empty ModelBuilder workflow. The
developer can select any geoprocessing tool to include. For the GRT ModelBuilder, the ‘Create
Feature Class’s geoprocessing tool was selected first. This tool requires a database for the new
feature class to be created into, so the GRT database was selected. The feature class name is left
open for any developer to add in any data that then gets uploaded to the database. The next
workflow consisted of selecting the ‘Append’ geoprocessing tool. Developers can select the edit
existing datasets they wish to update then the updates are reflected into the existing GRT
database. The developer can upload the updated data that will replace an existing dataset. The
last workflow involved using the ‘Delete Rows’ geoprocessing tool. This tool allows developers
to select the targeted rows from a particular dataset in the GRT database that will be removed.
The removal of rows is then reflected in the GRT database. These three workflows allow any
future data amendments to be done with minimal steps when utilizing one of the workflows.
To summarize chapter 3, an initial meeting with the GRTA team set the stage for
important components of the GRT app, such as identifying the GRT user, discussing the design
of the app, and sharing key datasets. Once the datasets were shared, initial data preparation steps
were taken. This involved creating a data dictionary and building an entity-relationship diagram
with the datasets provided by the GRTA team was vital in ensuring the integrity and legitimacy
of the data. Once the data was cleaned and the relationships were established, then the database
was created on ArcGIS Pro. In ArcGIS Pro, the relationships from the entity-relationship
diagram were transferred over, three ModelBuilder workflows were created, and the GRT map
53

was finalized. These steps were crucial for the next series of development to occur. In the next
chapter, the development of the web map and widgets for the app are described.

54

Chapter 4 Development Process
The development of the GRT app consisted of creating a web map, selecting appropriate
symbology, and developing widgets to allow user interactivity. Section 4.1 discusses the process
of web map development. Next, section 4.2 describes the symbology for all layers. It was
important that the layers did not overlap causing layers to be hidden or obscured. Therefore,
making symbology choices that created an easy to digest map was key. The next step involved
the development of the five custom widgets. Section 4.3 discusses how the widgets were all
developed. Each customization of all five widgets is described in the following sections. Section
4.4 describes the user deign of the GRT app. This chapter discusses the creation of the web and
GRT app in great detail in order to explain the developmental choices made in regard to the GRT
app.
4.1. WebMap Development
The web map consisted of the shared GRTA data layers that were uploaded to the
database in ArcGIS Pro (Pro) then shared to ArcGIS Online (AGOL). The process of sharing the
web map from Pro to AGOL involved using the share function in the Pro ribbon. This share
function provides options for the type of package or formatting a project will be shared as. The
preliminary Pro map was shared as a web map. The web map formatting was decided so that the
map could then be selected and consumed in the app. Once this setting was chosen, the title of
the map, any additional tags, and the summary of the project were added in. Then, the map was
shared to ArcGIS Online (AGOL). This was to ensure that the datasets and their relationships
were shared in AGOL. To access a web map for an application, it had to be shared to Esri’s
AGOL platform. Then, the map for the application could be selected to serve as the base web
map for the application.
55

Once the map from Pro was shared to AGOL the base web map for the application was
developed. The layers were prioritized in order of the most relevant to the least useful layers
needed to be displayed depicted in Error! Reference source not found.. The layers that were
automatically turned on when a user accesses the web app were: current wildfires, trailhead
points, wildfire perimeters, key counties, the national highway layer, weather conditions layer,
campgrounds, and recreational routes. These layers were symbolized in ways that allowed users
to easily view and access them shown below in Error! Reference source not found..

Figure 10 Web Map on AGOL
56

4.2. Symbology
The GRT app consisted of specific layers that shared information on hiking trails,
wildfires, and weather events that had to be symbolized appropriately to convey each layer’s
meaning. The select layers, hiking trails, wildfire, trailheads, weather events, counties, highways,
campgrounds, and recreational routes that were chosen to be displayed on the initial startup of
the web map. Each symbology choice reflects the data most accurately, so that the user can see
the data in the most accurate way. Since each layer represents a different concept, it was
important to display those characteristics on the map. Similarly, ensuring all the data is
visualized in the map was a key factor when making symbology decisions.
4.2.1. Hiking Trails Symbology
The trails for the GRT app were shared as a layer called the “HP3_Routes” and
symbolized according to trail type. The HP3_Routes or hiking trails were line segments of
several types of sidewalks, trails, and future trail development. These line segments consisted of
both existing and proposed boardwalks, existing and proposed bike trails, existing and proposed
trails. These categories were symbolized through the selection of a color ramp that showed each
line segment in a distinct color. The color ramp allows users to view line segments at the same
time but know that they are not the same line segment. The width of the trail segments was all
five points so they would not distract one another. This was to ensure that users could click on a
line segment and a legend would tell them the type of trail it was.
4.2.2. Wildfire Symbology
The Currents Incidents layer is symbolized as a red-colored fire symbol showing the
distinct categories of fire incidents. These categories symbolize the severity of a fire by acreage
burned, if the fire is a new fire, the incident is complex, and the fire is prescribed. Point
57

symbology was chosen since the data reflects on the map as points of active wildfires. The
Current Perimeters layer is a polygon that shows the area the fire is encompassing and burning. It
was vital to use a red outline with light red fill as the polygon symbology to show a wildfire
perimeter as well as correlate with the red coloring from the current wildfire incidents.
4.2.3. Trailhead Symbology
The trailhead symbology is shown as a circle filled with a dark purple. This decision was
made after testing out other symbology, such as a hiker, which was not visible on the map. The
dark purple point acts as points on the map that users can click on to obtain directions to and
from. These dark purple points display the locations of trailheads on the map.
4.2.4. USA Weather and Warnings Symbology
The USA Weather and Warnings symbology is categorized by varying polygons. These
classes are broken down by weather event type and shown as a differing color polygon. The
differing colors represent different weather events. Some weather events include air pollution,
flooding, or hurricanes that are represented on the map as a distinct color of the red, blue, green
color ramp. Additionally, the area that the weather event occurs in is encompassed in a polygon.
The user can identify what type of weather event is occurring and where it is occurring, by the
area of the weather event and the color it is symbolized in.
4.2.5. Counties Symbology
The symbology for the key counties was a black border around each county. This ensured
that the boundary for each county was clearly defined. Additionally, each county contained a
label. This label showed the user what the name of the county was. A county name label helps
users know which county they are accessing.
58

4.2.6. Highways Symbology
The highway layer contained information on all highways in the US. This layer was
clipped to show highways only in the state of California. At first, it seemed useful to symbolize
each California highway in a distinct color to show that they are different from each other.
However, different colored line segments representing highways distracted from the top priority
hiking trails. So, the highways were represented as a thin, black line that displays the locations of
major highways without distracting from other line symbology.
4.2.7. Recreational Routes Symbology
The recreational routes are symbolized in blue to show the distinct line segment. Since
there already exists line segments, a blue line stands out and does not become hidden amongst
the other line segments.
4.2.8. Campground Symbology
The campground data reflects points on the map where campgrounds are located. The
campground symbology reflects points that are symbolized by a basic shape that displays a tent.
This allows users to understand that the point reflects a campground. Because of the point
symbology, users can direct themselves to and from that point.
4.3. Widget Development
Through various tutorials, FAQ sheets, and documentation assistance, the vital
components of the app were created. Utilizing Esri’s “Get Started” guide allowed for the steps
and process to develop widgets to be constructed (Get started - ArcGIS Web AppBuilder |
ArcGIS Developers n.d.). The guide was through Esri’s ArcGIS Developers site, in which, a zip
folder containing the files to launch Web AppBuilder locally. Then, the guide provided steps on
59

how to link a blank app to the new browser where the widget would be deployed. Additionally,
the guide contained tips and outsourced links for any issues faced. Similarly, the “Get Started
with the Yelp Fusion API” documentation provided key steps in understanding what data was
available (Get Started - Yelp Fusion API n.d.). Through Yelp, there were instructions on how to
create and manage an app, which would have been utilized in case the app development on Web
AppBuilder did not launch. Additionally, the business points were linked to the developer’s
guidance page, which provided a description of the data being accessed. The API key was vital
in incorporating into the custom widget. This was so that when a user opens and searches on the
widget, it calls on the Yelp API, then, producing restaurant information.
The next step in the application development process involved creating widgets through
AGOL’s Web AppBuilder Developer Edition tools. The web map met the design requirements
for the application, however, there were more components that needed to be included. To do so,
the Developer Edition folder of Web AppBuilder was downloaded to a local machine. From
custom widget building, to editing existing widgets to creating new template themes, the
Developer Edition folder contained the foundational coding to begin customizing the application.
The process for accessing the folders and subfolders consisted of various steps. First, the Web
AppBuilder Developer Edition program folder had to be downloaded to the local machine
alongside a developer’s license and Esri credentials. Then, the startup batch file within the Web
AppBuilder Developer folder, was launched to start the program. Next, the AGOL account
associated with the Developer Edition usage had to be authenticated. In addition, the App ID and
the Web AppBuilder developer machine’s address, the name of the local computer where the
Web AppBuilder Developer was downloaded, were both registered. After the registration steps,
60

the Web AppBuilder Developer Edition folders were available to use and edit so that the
customization of the application could begin.
4.3.1. Restaurant Locator Widget Creation
The ‘Restaurant Locator’ widget was created through the utilization of Yelp’s API.
However, before an API Key was requested, the environment for the widget had to be set. First,
the ‘Sample Widget’ subfolder in the widgets folder was copied into the main widget folder.
containing the pre-designed (built-in) widgets that are installed with Web AppBuilder. After the
‘Sample Widget’ folder was copied over, it was renamed ‘Find Restaurants’ to distinguish the
widget. In the ‘Find Restaurants’ folder, there were an images subfolder, manifest.json file, and
widget.JavaScript file. The name of the widget and author of the widget were both changed and
updated in the manifest.json file depicted in Figure 11Error! Reference source not found.,
containing the core programming comprising a widget. Next, in the main branch, the server
folder contained a config.json file with code that was copied into the config.json file of the Find
Restaurants so that the widget will be loaded from the widgets folder that contains all the Web
AppBuilder widgets (Youtube - Extending the Web AppBuilder for Arcgis 2018). Then the nls
folder was created. This folder contained translations for the manifest.json to utilize. After the
nls folder was created, the manifest.json file was updated to show the line of code that states
“hasLocale” was switched from false to true. Then, new folders were created. The config.json
which is the settings for the widget that contains the Yelp API key. A css folder was created to
add styling to the widget to edit the appearance. A widget.html file was created to serve as the
html template for Web AppBuilder to load in the widget with. Next, the widget.JavaScript file
was updated in order to add some functionality. In the widget.JavaScript file, dependencies for
the widget were added and the pre-rendered html template string was removed, because the
61

widget.html file was created to replace it. The RestaurantsNearAction.JavaScript file was created
to add feature action coding for the widget. In the manifest.json file, lines of code were added to
inform over the use of the feature action file, RestaurantsNearAction.JavaScript. Then, a settings
folder was created to extend the settings capacity in order to have Web AppBuilder populate
restaurant information for the Yelp API key. Lastly, in the images folder, Yelp stars and the Yelp
icon were added to add some graphics to the widget.

Figure 11 Manifest.JSON file
4.3.2. Radar Widget Creation
NEXRAD data was used in the Radar Widget that provided a live radar forecast for the
United States (National Centers for Environmental Information n.d.). The Radar Widget shows
users a live radar of weather patterns across the United States that the user can turn off or keep
on. For the creation of the widget, the ‘Sample Widget’ was copied and pasted in the main
widgets folder. Then, the manifest.json file was edited as new files and folders were created. The
config,json file contained the code to run the widget by obtaining data from NEXRAD.
62

Additionally, a css folder contained the styling code to customize the widget. The nls folder
contained many subfolders within it that had translations for the manifest.json file to utilize to
run the widget. A widget.html file was created to serve as the html template for Web AppBuilder
to load in the widget with. Next, the widget.JavaScript file was updated in order to add some
functionality. In the widget.JavaScript file, functions for the widget were added that loaded or
ran the data, as well as stopped the data from running. Similarly, the setting folder contained
JavaScript files that extended the configuration of the widget (Esri Community 2016).
4.3.3. Layers List Widget Creation
The list of all layer’s toolbox was configured to display accurate information for the GRT
app. First, the title and legend were selected so that users can see the title name of all the
available layers. Next, specific actions that the users can make were selected. These actions
included: zooming, changing the transparency of a layer, enabling, or disabling pop ups for
layers, reordering the list of layers, accessing a layer’s attribute table, and looking at the
metadata of a layer. From the developers’ side, not all the layers had to be shown on the list
widget. However, the decision was made to allow users access to all the layers.
4.3.4. Wildfire and Weather Information Widget Creation
The wildfire and weather information widget provides two lists of occurring weather
events and wildfires. These lists are populated through active wildfire and weather events.
Meaning, no user input is required since the layers in the web map feed into the lists. The
developers view shows the layer that had to be selected, each layer’s information symbology,
and the additional display features. The configuration of the information widget allowed two key
information on two separate layers to be displayed simultaneously. The first layer shown was the
current incident layer. It was shown to generate a list of the wildfire events. The symbology for
63

the wildfires remained the same as in the original web map. The next layer was the weather
events layer which displayed the weather events ordered by type of event. These weather events
kept their original symbology but generated a list of the weather events taking place. These
weather events were further categorized by type and each type of weather event could be
expanded to show the number of events for a specific weather type occurring.
4.3.5. Wildfire Filtering Widget Creation
The filtering widget was configured to utilize the current incidents layer that displayed
the wildfire events. The label was set as Current Incidents with the symbology icon remaining
the same as in the original web map. Two expressions were generated to allow for filtering. The
first expression allows for users to select the point of origin state from the current incidents
attributes and ensure that it is equal to a state which is all the unique values to the field. The next
expression used the attribute from current incidents point of origin county to filter by county.
Then, the expression ensures that all the point of origin county values are equal to counties in the
field. These two expressions created allowed for the wildfire filtering enabled by users.
4.4. UX/UI Design
Once all of functionality components were complete, then the application design began.
The user interface design of the application had already been discussed and thought out. But,
once the custom widgets, layers, and database were all complete, they were added to the map.
When an app developer opens the developer portal of Web AppBuilder, there are four
main categories on the ribbon bar to customize. The first is the theme category. In the theme
section, ten different themes to choose from. These themes consist of several types of layouts
such as dashboards, pocket, tab, and more to determine the appearance of the app. Each theme
has a distinct layout that determines choices such as widget placement and map placement. Next,
64

the style choices in the theme tab allow developers to choose the color of the title or header of
the app. The title of the app may be filled with any color the developer chooses. The default
color is gray, but developers can change it and even import custom colors. The last section of the
theme tab is the layout section. This layout section allows developers to organize the layout of
the widgets. The widgets can be grouped together on one side of the app or spread out. The
layout allows developers to organize where and how users access widgets.
The next tab in the ribbon customization is the map tab. In the map tab, developers can
select the web map for their app. There are options to select custom web maps or web maps from
AGOL’s map portal. Developers can set the extent for their web map. The existing web map
view is the default choice, but developers can further customize the view of the map to their
preference so that users have a specific extent when starting the app. Next, developers can
customize the visible scales of the map. This means that developers can control how much a user
zooms in or out of the map. The last section involves setting a refresh interval. Developers can
set their map to refresh at whatever cadency they prefer. Developers can refresh the map at a to
honor the rate each layer is refreshed or use a single interval for all non-static layers.
Next, the widget customization tab allows the sequence of widgets to be set.
Additionally, to widget layout, built-in widgets can be searched and edited. For example, in the
GRT app, the existing filter widget was edited to allow for specific filtering. An expression was
created to filter wildfires by county and state so users could view current wildfires in a specific
area. In the widgets tab there are fifty-three existing widgets that can be used and edited by
developers. Also, once developers download the developer’s edition folder, developers can
create their own widgets that are then searchable in the master list of widgets.
65

The last tab is the attribute configuration tab. There, developers can add branding to their
app. The type of branding available includes logos, titles, and subtitles for the app. Additionally,
any external links can be added to the app in this section. Also, the state of the app can be set in
this section which allows the map extent and layers visibility to remain the same while exiting
the app. Lastly, developers can configure data sources for the app that are not including already
in the layers of the web map.
For the Great Redwood Trails application, a dashboard theme was chosen. The dashboard
theme was selected formatting of widgets around the web map. Therefore, the dashboard
template displayed the web map and five widgets that conveyed restaurant, fire, weather, and
layer information for the users. The color of the dashboard theme was white color so that the
map stands out. Additionally, a splash screen was added so that when users first access the
application, they are welcomed to it as well as read a disclaimer in the formatting. The splash
screen was a built-in widget in Web AppBuilder. The splash screen widget was turned on with a
disclaimer. The disclaimer is simply to notify the users that the data might not be updated as
quickly as needed. Therefore, there are links to up-to-date wildfire and weather pattern
information.
In summary, this chapter discussed the development of two key components: the web
map and the widgets. For the development of the web map, each key layer had to be symbolized
accordingly. The eight key layers symbology choices were made with the user in mind to ensure
that a user can understand the meaning of each layer. The next component involved the
development of the widgets that are included in the GRT app. Each widget had a different
development process that ultimately produced a Restaurant Locator Widget, Radar Widget,
66

Layers List Widget, Wildfire and Weather Information Widget, and Wildfire Filtering Widget. In
Chapter 5 the results of the database and widget development are assessed.

67

Chapter 5 Results
The GRT app consisted of creating the GRT database on ArcGIS Pro and the development of the
GRT app on Web AppBuilder with the key results building from each other. The database had to
be created first to host the data for the app. Then, once the database was finished, the GRT app
and its five widgets were developed. The following sections discuss the results of both the
database and the GRT app and each of its widgets.
5.1. Database Results
The ArcGIS database provides a centralized location for hiking layers, whether focused
on trailheads, bike lanes, or roadways. The input data for the application consists of existing
GRT layers. which are viewed by users in the web map, being fed or streamed from the
Geodatabase. When users are viewing the GRT app, they can toggle on or off data layers at their
discretion. This is to ensure users can view relevant layers, while still being provided all
available layers. The database also acts as the source of information for the layers list widget.
The same symbology and naming convention from the database appear in the layers list widget
for users to manipulate. The database serves as a base for future developers to add, amend, or
remove data from the web app. Developers can access the database through Pro and make any
dataset amendments. To reflect these changes in the web app, the Pro map must be shared as a
web map to AGOL. Then, in Web AppBuilder the updated web map must be selected to serve as
the map for the app.
5.2. ModelBuilder Results
The ModelBuilder workflow helps to ensure that the database can be maintained over
time. The ModelBuilder has three different functionalities for manipulating data. The database
68

engineer can add new data through the add new dataset in the 1
st
workflow by using the add
dataset function and naming the new dataset. Next, one can delete existing datasets in the
database by using the delete rows in existing dataset function and then updating dataset the
dataset from the 2
nd
workflow in Error! Reference source not found.. The 3
rd
workflow in
Error! Reference source not found. allows the database maintainer to amend existing datasets
or update them and publish them as new datasets in the database through the amend function
then creating a new feature class and naming the output. These three workflows were chosen and
created because of the commonly needed tools to maintain a database: add new data, delete data,
and amend existing data.

Figure 12 Esri ModelBuilder Workflows
69

5.3. Widget Customization Results
The widgets in the GRT app allow users to filter information that populates onto the web
map or in a widget. Each widget provides users with more access to information that can be
tailored to each user’s preference. When a user first accessed the GRT app, the first thing that
appears is a splash screen message shown below in Figure 13. The message welcomes the user to
the app as well as provides a disclaimer about the frequency of data updates and provides users
with websites with the most up to date information. In the mobile version of the GRT app, the
user is presented with the web map and the first widget, the restaurant locator widget. This
widget appears first because of the clients request to highlight local restaurants. Here, the user
can type in an address or choose a point on the map to populate a list of restaurants near their
proximity. If a user desires to use another widget, they simply click the next arrow button to
scroll to the next widget, the radar widget, as well as continue to view the web map. With the
radar widget on, users can view weather patterns. They can turn it off and clear the radar forecast
off the web map. Next, the user can click the next arrow to scroll to the following widget, the
layers list widget, the users also can scroll back to the previous widget. The layers list widget
allows users to filter which layers are visible on the map. With the web map above the widget,
users can see in real-time the layers turning off and on. Next, users click to the subsequent
widget, the wildfire and weather information widget. Here users view a list of active wildfires as
well as a list of weather events that are categorized by the type of weather event. The last widget
users can scroll to is the wildfire filtering widget. This widget allows users to select the state and
the county they wish to filter by. Then, the filter populates the desired area of wildfire locations
on the web map.
70

Figure 13 Splash Screen Message Mobile Version
The web view of the GRT app consists of the same splash screen message and widget
functions as the mobile version. The layout of the web map and widgets is the only difference
shown below in Figure 14. The web view has the web map on the upper right corner of the web
page with the five widgets bordering around the web map. The following subsections describe
the results of each widget of the GRT app.
71

Figure 14 Desktop Version of GRT App
5.3.1. Restaurant Locator Widget
To include local restaurants, the Yelp API allows for restaurant information to be pulled
and added to the map. The custom widget included some coding to ensure that the Yelp API is
being requested and then is generating restaurant search results. The widget was further
customized to include a feature action tool. This tool allows users to select a point on the map
then populate a list of restaurants in the point’s proximity. In the mobile version, the GRT user
can scroll and find the Restaurant Locator widget below the web map shown in Figure 15. Then,
the user can input an address or use the feature action tool to populate a list of restaurants. Figure
16 then shows the generated list of restaurants users can access. This list allows users to select a
restaurant and be navigated to the Yelp page of the business. Additionally, users can navigate to
the selected restaurant.
72

Figure 15 Restaurant Locator Mobile Version
73

Figure 16 Widget with Populated Restaurants
5.3.2. Radar Widget
The radar widget shows the type of weather patterns occurring in a certain area. The
legend within the widget displays colors. The radar is depicted as a color spectrum. The green in
the radar signifies light or moderate rainfall (Ahrens 2023). The yellow, orange, and red colors
74

represent moderate to heavy rainfall and may represent hail. The white and blue indicate
snowfall while the pink indicates freezing rain, sleet, or a wintry mix.
Additionally, users can track the movement of a weather event type as visualized in
Figure 17. This allows users to be better informed and visually observe where a weather event is
occurring and how to best avoid it. This widget provides users with the ability to see weather
patterns and track their movements throughout the US depicted in Figure 17. This mobile version
shows how users can scroll to the radar widget. Additionally, the radar widget contains a stop
button which will turn off the radar information on the map.

Figure 17 Radar Widget Mobile Version
75

5.3.3. Layers List Widget
The Layer List widget provides a clear list of all the layers included in the web map and
their default symbols. Additionally, the widget allows developers and users the ability to turn
individual layers on and off. Each of the layers in the list contains a check box on the side of
each layer’s title that allows for viewing individual or collective layers (ArcGIS Online
Resources n.d.). Some of the layers even contain sublayers within them. For the GRT app, the
HP3_Routes_Tails, Current Incidents, Current Perimeters, weather events, counties, highways,
campgrounds, and recreational routes layers were selected for the default view.
5.3.4. Wildfire and Weather Information Widget
The Info Summary widget allows developers to provide counts of features in a specified
layer, as well as a collapsible list of information of the layer or layers selected. The list of layers
produced in the widget panel can be grouped by a specified field (ArcGIS Online Resources
n.d.). The layers added to this widget were the USA wildfire and USA weather current condition
layers. For each layer, the attribute was selected at the top of the menu and extract data source
was selected. Then, the layers selected, USA wildfires and USA weather conditions, were both
selected. From the wildfire layer, the current conditions sub layer was chosen. For the current
weather conditions, the events ordered by size and severity were chosen. Then, the title of the
widget was updated.
5.3.5. Wildfire Filtering Widget
The Filter widget allows developers to offer limits or filters for users to select to limit the
visibility of features in a layer (ArcGIS Online Resources n.d.). When the criterion for the filter
is selected, the map reflects the filtering and displays the selected data. For the GRT app, a new
filter was selected, and the layer chosen to be filtered was the USA wildfire layer. Then, two
76

expressions were added: Point of Origin State (string) is Unique and Point of Origin County
(string) is Unique. Then, the box for ‘Ask for values’ was selected. The prompts were Select
State and Select County shown in Figure 18. The list of values able to be selected was ‘All
unique values of this field’. This was to ensure that users would select states and counties that
pertain to the layer and project area (Using Web AppBuilder’s Dashboard Theme – Esri n.d.).
Then, the feature being filtered, for the GRT app being wildfires, generates onto the map. So,
wildfires for a specific state and county are filtered to only display the fires in the selected state
and county. Figure 18 shows this process visualized on the map.

Figure 18 Mobile Version of Wildfire Filtering Widget
77

To summarize Chapter 5, the creation of the geodatabase, ModelBuilder Workflows, and
widgets all resulted in the GRT app. The database resulted in a centralized location for all the
datasets that were consumed by the GRT app. The ModelBuilder Workflows assisted in allowing
database manipulation that would then be reflected in the app. The widgets allowed users to
search, query, and manipulate the existing information and layers in the GRT app in order to
populate additional or user-specific information. In all, these creations, database, ModelBuilder,
and widgets, built off one another to produce the GRT app. In the final chapter, limitations and
future work are discussed in order to propose alternative methods for improving and furthering
the GRT app.

78

Chapter 6 Conclusions
The following sections describe challenges faced with the GRT app data, software, and
symbology. Section 6.1 and its subsequent subsections discuss the issues with working with the
data given by the GRTA team and the challenge in uploading the GRT app onto the USC web
server. Section 6.2 discusses the results of the widget creation, symbology choices, and
limitations with the GRT app itself. Section 6.3 proposes future research on furthering the GRT
app.
6.1. Issues Faced with Data and Software
The following subsections describe at length some of the data and software challenges
faced when developing the GRT app. One of the biggest challenges to overcome was working
with data provided by the GRTA team. Section 6.1.1 discusses the data inconsistencies as well as
the extensive data cleanup that had to be conducted. Another challenge faced involved the
deployment of the app on the USC web server that caused issued with a smooth deployment of
the GRT app onto the server, which is discussed in section 6.1.2.
6.1.1. Data Issues
The biggest challenge with the data used in the GRT app was the integrity of data given
by the GRTA team that did not include metadata or sources of the data. The GRTA team initially
provided shapefile layers via google drive. These layers included data on: Major Rivers, Major
Rivers and Creeks, GRT 5 Mile Points, GRT Points, Bays, Key Cities, Cities GRT, Key
Counites, Rail Mile Posts GRT, Major Lake and Reservoirs GRT, GRT Counties Points,
Subwatershed GRT, Subbasins GRT, and Bioregions. These layers were uploaded onto ArcGIS
Pro to understand their symbology and visualize them. Once these layers were visualized, their
79

attribute tables were opened to understand what each layer was symbolizing. These attribute
tables contained attributes that were shortened and not defined. So, it was realized that the
metadata was incomplete and the GRTA team did not know the origin source for the data layers.
Then, what attributes could be defined were and used to establish an entity-relationship diagram.
This diagram would establish relationships that would be created in the geodatabase as well. The
defined and missing attributes for all the data layers are available on appendix a.
The biggest challenge faced with these two live layers is ensuring the data reflects the
most up-to-date information. Since the app might not have refreshed in a timely manner, a splash
screen was created with a message that warned about the live layers and re-directed users to
websites that could provide more current information.
6.1.2. USC Web Server Issues
The web app was created on a local computer to eventually be transferred to USC’s web
server to host the app. First, some programming edits were completed, so that the application
was ready to be transferred to the USC web server. To do so, FileZilla was utilized to upload the
folder to the personal USC account directory. Once it was uploaded, the application loaded on
the USC account. However, the layers would not load on the web version of that app. It was
through discussions with the USC IT lead that the discovery that the USC web server did not
have the configuration to support the download of Web AppBuilder Developer Edition to then
deploy the GRT app was made. So, the pivot was made to share the app’s folders and data until
the USC web server was configured to support Web AppBuilder Developer Edition.
6.2. Application Results Discussion
Throughout the development of the GRT app, there were successes, challenges, and
pivots that led to the final pilot app. The development process consisted of three main
80

components. These included, creating a geodatabase to be passed onto the GRTA team which
contained the necessary data for the app, the symbology choices made in creating a web map,
and the construction of the widgets that went into adding interactivity to the app. The following
subsections discuss the results of each component of the GRT app, as well as any limitations in
the GRT app.
6.2.1. Database
The geodatabase was created through data obtained from the GRTA team. As discussed
in pervious sections, there were challenges with working with the given datasets. The missing
data dictionary and attribute definitions made it difficult to establish relationships amongst the
datasets. Additionally, the prioritization of particular datasets was a strenuous process without
timely feedback from the clients. Since the clients preferred the database to be hosted and created
on Esri’s software platform, ArcGIS Pro, there were limitations with the capabilities of Pro itself.
For example, it was not possible to view all the tables of each dataset at the same time. Meaning,
a simultaneous view of all the data’s attribute tables could not be possible. This was a challenge
because it meant opening a single table up a time and noting the attributes in it. A solution to this
issue would be to create the database on a different platform. MS Access was used to obtain an
overall view of the attribute tables. On MS Access, the ability to generate relationships through
attributes is possible. So, furthering the GRT app would involve hosting the database on a
different software platform to have access to database manipulation and maintenance tools that
are not available on ArcGIS Pro.
6.2.2. Web Map Symbology
The symbology choices of the web map were a great challenge because of three factors,
fulfilling the user requirements for designing a web map and ensuring the multiple layers were
81

easily visible, and the use of a cell phone for accessing the GRT app. These factors influenced
how each layer appeared on the map while always prioritizing what a GRT app user needs to
view.
In the GRT app, users can filter the location of wildfires. The user filters the state and
county they would like to view wildfires in, then the map populates active wildfires in the
specified area. The web map design process consists of components, such as user-friendliness,
cartographic choices, and interactivity that all shape a web map’s effect on users. With each
component in mind, the GRT app’s web map was developed to allow user to interact with the
web map, and then manipulate the information populated on the map itself. This interaction adds
to a user’s experience by connecting two sources of information, the information from the data
layers and the user’s specified widget filtering and searches. The web map design process
consists of components, such zooming abilities, symbology choices for each data layer, and
widgets that allow users to input specific requirements or parameters. With each component
created, the GRT app’s web map was developed to allow user to interact with the web map, and
then manipulating the information populated on the map itself.
The GRT app’s web map was created to ensure that layers do not overlay each other and
are visible to users. Since a phone would be the primary source for accessing the GRT app, the
layout of features of the web map was critical. From displaying hiking trails to describing the
wildfire and weather conditions, the symbology choices were made with both a web and mobile
design in mind. However, ensuring the best layout of each data layer proved to be a challenge.
For example, many of the layers were line segments that represented different types of trails,
such as pedestrian trails and future pedestrian trail development. So, attempting to symbolize
these lines while also maintaining their meaning involved ensuring each line segment was shown
82

in distinct colors. These distinct colors allowed users to know that each line represented a
different type of trail and to know what it represented meant clicking on the line segment that
would show a pop-up with information on the line. Similarly, the weather events symbology was
difficult to decide and work with. The weather events were symbolized by weather event type
that was represented as differing colored polygons. So, that the area the weather event was
occurring would be obvious. However, the colored polygons hid some of the layers and parts of
the project area. A way to overcome this solution was trying to discover a method of
symbolization that allowed for the layer to be hidden, but when a user hovers above a certain
area, the weather event polygon would appear. This type of symbology would have been ideal
for the weather events layer but was not possible to do. The ability to hide then show the layer in
accordance with the area a user hovers over was not a capability of ArcGIS Pro. So, the layer
remained on but had a 25% transparency so that the additional layers were not hidden.
To elevate the symbology choices in the GRT app, it would be beneficial if layers had
been prioritized since the start of development by the clients. This is to ensure that some
unnecessary layers are not included in the app. Rather than choosing symbology for each layer,
the clients could have discussed the appropriate symbology for the layers. Additionally, custom
symbology, such as GRT trail head points or wildfire icons, could add uniqueness to the app and
ensure users are fully aware of the meaning of the layer. These symbology suggestions could one
day be made to further the development of the GRT app that would allow the layers to be
eventually available offline.
6.2.3. Widget Construction
The construction of the five widgets was done on Esri’s Web AppBuilder Developers
Edition platform that would then be deployed onto USC’s web server. The biggest challenge
83

faced with the web app was deploying the GRT app that contained the five widgets. As
previously discussed, the USC web server was not properly configured to download and
maintain Web AppBuilder Developer Edition’s environment. So, the GRT app was not properly
launched. The workaround involved sharing the GRT app and its folders that contained the
custom programming for each widget. Once the web server could support Web AppBuilder, the
GRT app will be launched. This web server technicality could not have been foreseen and
alternatives have been extensively thought out. Therefore, sharing widget folders, app folders,
the datasets, and the geodatabase until the GRT app can be properly launched has become the
temporary solution.
6.2.4. Application Limitations
The two main limitations in the GRT app include the lack of full trail line segments and
the inability to deploy the app on the USC web server. Since the trails are still being developed
from previous rail lines, not all the trail lines are accessible as datasets to include in the GRT
app. This limits the accessibility users have to hiking routes. However, as more of the trail
becomes developed and mapped out, these trail segments will be added to the GRT app.
6.3. Future Development
The further development of the GRT app includes adding newly developed trails to the
web map and creating additional widgets, while hosting the app development on a different
software platform. Adding additional trail layers can disrupt the current layout of the web map.
Therefore, rethinking the web map design may be a key component in furthering the GRT app.
Also, including new layers may require new widgets to populate specific information onto the
map. Along with these web map and widget developments, looking at other software platforms
to host and develop the GRT app may serve to create a better setting for it.
84

6.3.1. Future Design
As new hiking trails become developed, they will be included in the web map of the GRT
app. The inclusion of new trails may lead to a redesign of the web map to better illustrate the
trails and other layers. The original symbology ensures that all the layers in the web map are
displayed clearly and do not overlap. However, with more trail segments being included, these
symbolized layers may require new symbology to ensure users can view each layer clearly.
These new symbology choices can include using dotted line segments, custom line segments,
trail type specific colors, or creating out of the box symbology.
Along with additional layers being added to the web map, new widgets may become
necessary for the GRT app to best serve users. Widgets that show condition, type, or
classification of trails may need to be developed to not only improve user experience but add to
the functionality of the app. Currently, trail characteristics do not exist in the GRT app. But, in
the future the trails may contain information about their conditions that could be conveyed to
users through a widget. Additionally, existing widgets may need updating to ensure information
being displayed reflects any changes. The existing widgets may be configured to reflect any new
data that has been included in the GRT app.
The Radar Widget could be improved by including a legend of what the colors in the
radar spectrum symbolize. The spectrum is a standard spectrum and reflects the same meaning as
other radars. However, the user may not have prior knowledge as to what the colors of the
spectrum signify. The inclusion of a legend on the radar widget would help the user better
understand the weather patterns occurring.
85

6.3.2. Other Software Available
The GRT app was developed on Esri’s Web AppBuilder platform. As discussed in
previous sections there were challenges with app development and with app deployment. So, to
combat these issues in the future, developers could look to other platforms to further the GRT
app. Through Esri’s platform, there are two alternatives to Web AppBuilder, StoryMaps and
Dashboards. StoryMaps is a platform that allows developers to add text alongside a web map, so
that users can read information that the developers wish to convey to users alongside a map. It
does not allow for widgets to be included, but, if in the future, the GRT app requires a lot of text
to give a contextual background to users alongside the web map, then StoryMaps would be the
ideal option. The second alternative is Esri’s Dashboards platform. Dashboards is a platform that
allows developers to have multiple widgets and windows alongside the web map. It is ideal for
showing statistics, text, and widgets with a web map. However, it is not like an app in which
developers can deploy it and users can access it through their phone. Dashboards would be ideal
if in the future the GRT app requires more widgets that contain charts and statistics to convey the
data.
An alternative to Esri’s platforms would be to look into developing the GRT app
completely from scratch. This would mean obtaining software development programs and tools
that would create an environment to create every component. Visual Studio and Firebase are two
examples of software programs that allow for database development and user interface
development. The challenges with re-creating the GRT app out of Esri’s platform would be the
time constraint and all the necessary troubleshooting. It would be very time consuming to create
the app all over but could allow for further customizations that were not possible through Esri.

86

References

Ahrens, D.C. 2023. Essentials of Meteorology: An Invitation to the Atmosphere. Pacific Grove:
Brooks/Cole, 2023.
AllTrails. 2010. “AllTrails: Trail Guides & Maps for Hiking, Camping, and Running.” Accessed
November 10, 2022. AllTrails.com. https://www.alltrails.com/.
Anderson, Z., and Jones, M. 1970. “Rethinking the Role of a Mobile
Computing in Recreational Hiking.” SpringerLink. Springer International Publishing,
https://link.springer.com/chapter/10.1007/978-3-030-45289-6_16.

ArcGIS Online Resources. n.d. “Web Appbuilder.” Accessed July 31, 2022.
https://dlac.grinnell.edu/arcgisonline/web-appbuilder/.

ArcGIS Solutions Web AppBuilder Widgets | ArcGIS Solutions. n.d. “Solutions Web
Appbuilder Widgets.” Accessed October 6, 2022.
https://solutions.arcgis.com/shared/help/solutions-webappbuilder-widgets/.

Barnett, M. 2016. Precipitation Triggered Landslide Risk Assessment and Relative Risk
Modeling Using Cached and Real-Time Data (dissertation).
Blake, M.C., Jones, D.C., and Graymer, R.W. 2000. “Geologic Map and Map Database of Parts
of Marin, San Francisco, Alameda, Contra Costa, and Sonoma Counties, California.”
Geologic map and map database of parts of Marin, San Francisco, Alameda, Contra Costa,
and Sonoma Counties, California, 2000. https://doi.org/10.3133/mf2337.
California Department of Forestry and Fire Protection (CAL FIRE). n.d.
“Fire Hazard Severity Zones Maps.” Cal Fire Department of Forestry and Fire Protection.
Accessed July 14, 2022. https://osfm.fire.ca.gov/divisions/community-wildfire-
preparedness-and-mitigation/wildland-hazards-building-codes/fire-hazard-severity-zones-
maps/.

California Senate - Open States. 2021-2022. “SB 69.” Accessed July 14, 2022.
https://openstates.org/ca/bills/20212022/SB69/.

Create your first app-ArcGIS Web AppBuilder | Documentation. n.d. “ArcGIS Web
AppBuilder” Accessed June 9, 2022. https://doc.arcgis.com/en/web-appbuilder/create-
apps/makefirstapp.htm#:~:text=Create%20an%20app,Create%202D%20and&text=
On%20the%20My%20Content%20tab,click%20Create%20a%20Web%20App.

87

Cybulski, P., and Horbinski, T. 2020. User Experience in Using Graphical User Interfaces of
Web Maps. ISPRS international journal of
geoinformation;9(7):412.doi:10.3390/ijgi9070412

Esri Community. 2016. “Isuradar Nexrad Weather Radar Widget.”
https://community.esri.com/t5/web-appbuilder-custom-widgets-documents/isuradar-
nexrad-weather-radar-widget/ta-p/914966.
FarOut. n.d. “Farout.” Accessed October 27, 2022. https://faroutguides.com/.
Ferguson, J. 2022. “Marin County, California.” Marin County, California: History and
Information. Accessed September 15, 2022.
https://www.ereferencedesk.com/resources/counties/california/marin.html.
Fire Season | Humboldt County, CA - Official Website. 2021 “Fire Season - Humboldt County.”
Accessed September 15, 2022. https://humboldtgov.org/2874/Fire-Season.
Fit Club LLC. 2019. “Cairn: Hiking & Outdoor Trail.” Google Play Store, Vers. 1.3.1 (2019)
https://play.google.com/store/apps/details?id=com.cairnapp.cairn&hl=en_US&gl=US

Fleming, J. 1998. Web navigation: designing the user experience. O'Reilly & Associates,
Inc., USA.

Fritz, E. 1931. The role of fire in the redwood region. Journal of Forestry 29:939–950
Frontline. 2022. “The Mendocino Complex Fire - Causes, History & Statistics.”
https://www.frontlinewildfire.com/wildfire-news-and-resources/mendocino-complex-fire/.
Gaia GPS: Hiking Trail Maps, Ski Touring, 4x4 Offroad App. 2021. “Gaia GPS: Hiking Trail
Maps, Ski Touring, 4x4 Offroad App.” Accessed November 10, 2022.
https://www.gaiagps.com/.
Get started - ArcGIS Web AppBuilder | ArcGIS Developers. n.d.“Get Started.” Accessed July
17, 2022. https://developers.arcgis.com/web-appbuilder/guide/getstarted.htm.

Get Started – Yelp Fusion. n.d. “Get Started with the Yelp Fusion API.” Accessed June 9, 2022.
https://www.yelp.com/developers/documentation/v3/get_started.

Great Redwood Trail. n.d. “Great Redwood Trail: The Great Redwood Trail Agency.” Accessed
January 25, 2023. https://thegreatredwoodtrail.org/great-redwood-trail/.

Guilfoil, J. 2022. California Coastal Conservancy to manage the Great Redwood Trail project.
The Ukiah Daily Journal.

88

Haklay, M. 2010. Interacting with Geospatial Technologies; Wiley-Blackwell: Hoboken, NJ,
USA; ISBN 978-0470998243.

Hansen, W. J. 1972. User engineering principles for interactive systems, Proc. Fall Joint
Computer Conference, 39, AFIPS Press, Montvale, NJ (1971),523-532
Hiking Project. 2016. “Hiking Trail Maps.” Accessed November 10, 2022.
https://www.hikingproject.com/.
Humboldt. n.d. “Visit Humboldt- California's Redwood Coast.” Accessed September 15, 2022.
https://visithumboldt.com/.
Kraak, M.J., and Brown, A. 2001. Web Cartography, developments and prospects.

Maizlish, N., English, P., Dervin, K., Chan, J., and English, D. 2021. “CDPH
Climate Change and Health Profile Reports.” CDPH Climate Change and Health Profile
Reports, December 2, 2021.
https://www.cdph.ca.gov/Programs/OHE/Pages/ClimateHealthProfileReports.aspx.

Marin Magazine. n.d. “About Marin County.” Accessed January 21, 2022.
https://marinmagazine.com/about-marin-county/.

Muehlenhaus, I. 2013.Web Cartography: Map Design for Interactive and Mobile
Devices. United Kingdom: CRC Press, 2013.

National Centers for Environmental Information. n.d. “Next Generation Weather Radar
(NEXRAD).” Accessed May 2, 2022., https://www.ncei.noaa.gov/products/radar/next-
generation-weather-radar.

Neene, V., and Kabemba, M. 2017. “Development of a Mobile GIS Property Mapping
Application Using Mobile Cloud Computing.” International Journal of Advanced
Computer Science and Applications 8, no. 10. https://doi.org/10.14569/ijacsa.2017.081008.

Norman, D. A. 2013. The Design of Everyday Things. New York, NY: Basic Books

Olson, D., and Sawyer, J. 2019. “Northern California Coastal Forests.” WWF. World Wildlife
Fund, 2019. https://www.worldwildlife.org/ecoregions/na0519.
PeakVisor App. 2017. “Peakvisor App” Accessed November 10, 2022. PeakVisor App.
https://peakvisor.com/.
89

Permit Sonoma. n.d. “Sonoma County Historic Overview.” Accessed September 15, 2022.
https://permitsonoma.org/divisions/planning/historicresources/sonomacountyhistory/sonom
acountyhistoricoverview.
Recreation.gov. 2022. “Camping, Cabins, Rvs, Permits, Passes & More.” Accessed November
10, 2022. Recreation.gov. https://www.recreation.gov/.
Rosson, M.B., and Carroll, J.M. 2001. Usability Engineering: Scenario-Based
Development of Human-Computer Interaction. Elsevier

Roth, R. 2017. User Interface and User Experience (UI/UX) Design. Geographic
Information Science & Technology Body of Knowledge. 2017.
10.22224/gistbok/2017.2.5.

Teodoro, A.C., and L. Duarte. 2013. “Forest Fire Risk Maps: A GIS Open Source Application –
a Case Study in Norwest of Portugal.” International Journal of Geographical Information
Science 27 (4): 699–720.
Tourism Official Site | SonomaCounty.com. n.d. “Sonoma County Tourism Official Site.”
Accessed September 15, 2022. Sonoma County. https://www.sonomacounty.com/.
Tsou, M.H. 2011. "Revisiting web cartography in the United States: The rise of user-
centered design." Cartography and Geographic Information Science 38, no. 3: 250-257.

U.S. Census Bureau Quickfacts: Humboldt County, California. n.d. “U.S. Census Bureau
Quickfacts: Humboldt County, California.” 2020-2022. Accessed November 3, 2022.
https://www.census.gov/quickfacts/humboldtcountycalifornia.

U.S. Census Bureau Quickfacts: Marin County, California. n.d “U.S. Census Bureau Quickfacts:
Marin County, California.” 2020-2022. Accessed November 3, 2022.
https://www.census.gov/quickfacts/marincountycalifornia.

U.S. Census Bureau Quickfacts: Mendocino County, California. n.d “U.S. Census Bureau
Quickfacts: Mendocino County, California.” 2020-2022. Accessed November 3, 2022.
https://www.census.gov/quickfacts/mendocinocountycalifornia.

U.S. Census Bureau Quickfacts: Sonoma County, California. n.d “U.S. Census Bureau
Quickfacts: Sonoma County, California.” 2020-2022. Accessed November 3, 2022.
https://www.census.gov/quickfacts/sonomacountycalifornia.

U.S. Census Bureau Quickfacts: Trinity County, California. n.d “U.S. Census Bureau
Quickfacts: Trinity County, California.” 2020-2022. Accessed November 3, 2022.
https://www.census.gov/quickfacts/trinitycountycalifornia.

90

“Using Web AppBuilder’s Dashboard Theme - ESRI.” n.d. Accessed July 31, 2022.
https://downloads.esri.com/learnarcgis/educators/app-builder-dashboard.pdf.
Visit Mendocino County – Room to Roam. n.d. “Visit Mendocino County.” Accessed September
15, 2022. https://www.visitmendocino.com/
Wang et Al. 2011. “The Role of Smartphones in Mediating the Touristic Experience.” Accessed
July 15, 2022. https://journals.sagepub.com/doi/10.1177/0047287511426341.
Welcome to the Visit California Homepage. n.d. “Trinity County.” Accessed October 20, 2022.
https://www.visitcalifornia.com/experience/trinity-county/.
Wiley, B. 2018. "Tracking Santa Barbara County Wildfires: A Web Mapping
Application." Order No. 11016999, University of Southern California.
http://libproxy.usc.edu/login?url=https://www-proquest-
com.libproxy1.usc.edu/dissertations-theses/tracking-santa-barbara-county-wildfires-
web/docview/2179993356/se-2?accountid=14749.

Yelp Developers. n.d. “Yelp Data Quality Guidelines.” Accessed July 29, 2022.
https://docs.developer.yelp.com/docs/yelp-data-quality-guidelines.

YouTube- Extending the Web AppBuilder for Arcgis. 2018. “Extending the Web AppBuilder for
Arcgis.” January 23, 2018. YouTube
https://www.youtube.com/watch?t=12m52s&v=CgLFkDogAN0&feature=youtu.be.

91

Appendix A Existing Hiking Apps
Appendix A below shows a table that was presented to the GRTA to show initial research on
existing hiking applications. The key features, likes, and dislikes of each hiking app was added to
the table.
App
Name
Key Features Website Likes Dislikes
AllTrai
ls
-Browse 300,000+ trails with
hand-curated trail maps
-Access 8 different map
types
-Export files from trails,
activities, and maps on
AllTrails.com -Import files
to your AllTrails activities
and maps lists
-Read and leave reviews
-Create custom lists and
favorites lists of trails
-Create custom maps on
AllTrails.com
-Use Navigator to keep track
of your adventures and log
your activities
-Use map details to get more
information on trails
-Be an active member in the
AllTrails community
https://www.all
trails.com/
-search bar
-different
filters/categories
-description of
trail types/level
-busy home
page
-no easy to
use/access
widgets
Gaia
GPS
-Navigate offline even
without cell service.
-Print Custom Maps.
-Always have a backup map.
-Access All Maps.
-The best maps for any
adventure.
-Layer Maps Together.
-Discover even more terrain
details.
https://www.ga
iagps.com/
-3D maps
-Peaks are all
clearly pointed
out
-Import photos
-Elevation and
cardinality shown
-Zoomed in insert
of current
location
-Two maps on
one screen
might be
confusing
-App
specifically
for mountain
peaks
-Base map
hard to
replicate

Peak
Visor
-The cutting-edge technology
with high-precision terrain
https://peakvis
or.com/panora
-3D maps -Two maps on
one screen
92

modeling allows simple yet
effective insight into the
landscape of the mountains.
-It is the most convenient
way to explore a
mountainous area, its trails,
summits, passes, viewpoints,
and even parking areas.
ma.html?lat=4
5.9420159&ln
g=7.8699421&
alt=4598
-Peaks are all
clearly pointed
out
-Import photos
-Elevation and
cardinality shown
-Zoomed in insert
of current
location
might be
confusing
-App
specifically
for mountain
peaks
-Base map
hard to
replicate
Hiking
Project
-Hiking Project provides
detailed information on trails
near you, including GPS
route info, elevation profiles,
interactive features and
more.
-It is a core gathering place
for the hiking community.
https://www.hi
kingproject.co
m/
-Uses MapBox
basemap -Widget
bar with hiking
categories
-Clear/visible
search bar
-Trail directory:
States then
subregions
-Crowdsourced
map data
-When you
use search bar
no map but
search list
-List not map
is the first
thing shown

Recreat
ion.gov
-book a weekend getaway
-plan a cross-country road
trip
-helps you find and reserve
campsites
-review location details for
your trip -quickly access
information on past and
upcoming reservations.
https://www.re
creation.gov/
-MapBox base
map
-Map alongside
lists are populated
-Search bar for
locating trails
-More features
not about trails
-Must scroll
to find trail
map locator
-Too many
other
activities
included
Far Out -detailed trail information
like: -distance -elevation -
waypoints -water sources -
campsites,
-all viewable on topographic
or satellite maps
-app actively
tracks your
location on the
map, making sure
you’re always on
trail.
-All of this works
offline without
cell reception.
-each trail is
purchased
individually
Cairn -Record your hikes, climbs,
and outdoor runs, and then
analyze your trips’ stats
-Share your progress and
location for safety
-See where others have
found cell coverage on the
trail
https://www.ca
irnme.com/
-Extensive offline
capabilities
-Send time
specific messages
-Allow others to
track you
-Focuses
more on
safety than
searching for
trails
-Offline
abilities are
93

-Focused on safety primary
features
-Might be too
difficult to
replicate

94

Appendix B Attributes of GRT datasets defined
Bays
● Id- identification
● fnode- FNODE# is the internal number of the from-node.
● Tnode- TNODE# is the internal number of the to-node.
● Lpoly- LPOLY# is the left polygon number (cover# in polygon attribute table).
● Rpoly- RPOLY# is the right polygon number (cover# in polygon attribute table).
● Length- length
● County- county
● county id- unique county identification
● lucode
● state- state
● bay name- name of bay
Bioregions
● id- identification
● area- area of bioregion
● perimeter- perimeter of bioregion
● inaccreg
● inaccreg_i
● inacnum
● inacname
Boundaries
● id- identification
● objectid- identification of object
● county_nam- county name
● county_abb- abbreviated county name
● county_num- number for identifying county
● county_cod- code for identifying county
● county_fip- county fip code, Federal Information Processing Standards (FIPS), now known as
Federal Information Processing Series, are numeric codes assigned by the National Institute of
Standards and Technology (NIST
● island- island
● shape_are- area of the shape
● shape_length- length of the shape
● globalid- global identifier
Cities
● id- identification
● uace10
● name10- name of city
● uatyp10
95

● intptlat10- latitude
● intptlon10- longitude
GRT Points
● FID
● Shape- shape
● Gns_id- Geographic Names Server identifier
● Feat_name- name of feature
● Feat_type- type of feature
● Latdd- latitude
● Londd- longitude
● Cell name- name of the cell or point
● Elevat_ft- elevation in ft
● Variant- variant
● Sequence- sequence
Major rivers and creeks
● Id – identification
● Permanent- permanent
● Fdate
● Resolution- resolution
● Gnis id- Geographic Names Server identifier
● Gnis name- Geographic Names Server name
● Length km- length of river in km
● reachCode
● FlowDir- direction of river flow
● WBArea_Per
● FType
● FCode
Major rivers grt
● Id- identification
● Permanent- permanent
● Fdate
● Resolution- resolution
● GNIS_ID- Geographic Names Server identifier
● GNIS_Name- Geographic Names Server name
● LengthKM- length or river in km
● ReachCode
● FlowDir- direction of river
● WBArea_Per
● FType
● FCode
● MainPath
● InNetwork
● Visibility
96

● Enabled
● Shape_Length- length of river
Rail Mile Posts GRT
● FID
● Shape- shape
● Row_owner
● Subdivision
● Mp
● Station- rail station
● Crt_miles
● Tc
● Dist- district of stattion
● Co- county of station
SubBasins GRT
● ID- identification
● Tnmid
● Metasource- metadata source
● Sourcedata- source of data
● Sourceorig- origin source
● Sourcefeat- feature source
● Loaddate- date of data being uploaded
● Gnis_id- Geographic Names Server identifier
● Areaacres- are in acres
● Areasqkm- area in sqkm
● States- states
● Huc8
● Name- name of subbasins
● Shape_star
● Shape_stle
SubWatershed GRT
● Id- identification
● Tnmid
● Metasource- metadata source
● Sourcedata- source of data
● Sourceorig- origin source
● Sourcefeat- feature source
● Loaddate- date of data being uploaded
● Gnis_id- Geographic Names Server identifier
● Areaacres- area in acres
● Areasqkm- area in sqkm
● States- states
● Huc12

Abstract (if available)

Abstract Many online applications exist that allow users to search for hiking trails, but none have yet included the new Great Redwood Trail project that spans from San Francisco to Humboldt Bay in California. This “rails to trails” project is repurposing 320 miles of historic railway tracks in northwest California into public hiking trails. The new trails exemplify a positive relationship between human-created infrastructure and nature. Rather than creating more industrial waste, the Great Redwood Trail Agency is revitalizing the railway tracks for the purpose of promoting environmentalism and activeness in nature. For this project a mobile web mapping application was developed to familiarize hikers and the public with these trails. The Great Redwood Trail application provides and interactive digital map of the trails and includes relevant information and points of interest in surrounding areas aimed at stimulating the local economy, which is vital in garnering community support for trail development. Lastly, the app includes real-time wildfire information since this is now an incessant natural hazard in the Northern California region. Ultimately, this project aspires to showcase repurposed railways to hiking trails, promote local communities, and help ensure safety of app users.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Alaska Hike Search: designing a mapping application for Alaskan trails and user contributed hazards

PDF

Angeles Hike Finder: creating a spatial database and web application to discover hikes based on attributes and difficulty

PDF

Generating trail conditions using user contributed data through a web application

PDF

Silicon Valley construction project web mapping application

PDF

Advancing Redwood City's bicycle infrastructure through a geodesign workflow

PDF

Commute GeoCalculator: a GIS server extension for comparing automobile and transit travel costs

PDF

Pharmacy shortage areas across the United States: a visual representation by a web mapping application

PDF

Development of a historical urban land use web application for the city of Hong Kong

PDF

Recreational Off-road Adventure Motorcycle mapping System (ROAMS): a web application facilitating adventure motorcycling in Idaho public lands

PDF

Trojan Food Finder: a web-based GIS campus food sharing application

PDF

Designing an earthquake preparedness web mapping application for the older adult population of Los Angeles, California

PDF

Happy Traveler: discovering joy on university campuses and beyond through a web-based GIS application

PDF

Designing an early warning system web mapping application for the Atlanta Metropolitan Area before a flooding event

PDF

Mapping punk music and its relative subgenres

PDF

Web GIS as a disease management workspace: enabling advocacy at multiple scales across multiple continents with the case of tungiasis

PDF

Creating a geodatabase and web-GIS map to visualize drone legislation in the state of Maryland

PDF

Cartographic design and interaction: An integrated user-centered agile software development framework for Web GIS applications

PDF

Geographic local routing for social connection: a novel application for the integration of routing technology and multi-user environments

PDF

California ballot results viewer, 2008-2018: a Web GIS application for viewing ballot proposition results in California

PDF

Philly Bike Report: a mobile app for mapping and sharing real-time reports of illegally blocked bike lanes in Philadelphia

Asset Metadata

Creator Khatry, Melissa (author)

Core Title Rails to trails web mapping application for the great Redwood trails: mapping northern California’s repurposed trails

School College of Letters, Arts and Sciences

Degree Master of Science

Degree Program Geographic Information Science and Technology

Degree Conferral Date 2023-05

Publication Date 01/31/2023

Defense Date 01/30/2023

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag Hiking,OAI-PMH Harvest,redwoods,trails,web app

Format theses (aat)

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Duan, Leilei (committee member), Sedano, Elisabeth Jane (committee member), Swift, Jennifer (committee member)

Creator Email khatry@usc.edu

Permanent Link (DOI) https://doi.org/10.25549/usctheses-oUC112723860

Unique identifier UC112723860

Identifier etd-KhatryMeli-11456.pdf (filename)

Legacy Identifier etd-KhatryMeli-11456

Document Type Thesis

Format theses (aat)

Rights Khatry, Melissa

Internet Media Type application/pdf

Type texts

Source 20230201-usctheses-batch-1005 (batch), University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the author, as the original true and official version of the work, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright. The original signature page accompanying the original submission of the work to the USC Libraries is retained by the USC Libraries and a copy of it may be obtained by authorized requesters contacting the repository e-mail address given.

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA

Repository Email cisadmin@lib.usc.edu