University of Southern California Dissertations and Theses

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

(USC Thesis Other)

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

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content

ANGELES HIKE FINDER:
CREATING A SPATIAL DATABASE AND WEB APPLICATION TO DISCOVER HIKES BASED
ON ATTRIBUTES AND DIFFICULTY

by

Alexander Toy

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)

December 2020

Copyright © 2020 Alexander Toy
ii
Dedication

To a new chapter

iii
Acknowledgements
I wish to extend my gratitude to Dr. Bernstein for her guidance throughout this entire project. I
would also like to thank Dr. Sedano for her help in the project’s infancy and development, as
well as Dr. Duan for her suggestions during the troubleshooting process. Special thanks is owed
to Richard Tsung for numerous instances of technical support over the semester.
To Jorge Amar for commiserating with me throughout the entire program, thank you for
keeping me sane. Finally, to all my friends and family who supported me throughout this
process, thank you.

iv

Table of Contents
Dedication ....................................................................................................................................... ii
Acknowledgements ........................................................................................................................ iii
List of Figures ............................................................................................................................... vii
List of Tables ................................................................................................................................. ix
List of Abbreviations ...................................................................................................................... x
Abstract .......................................................................................................................................... xi
Chapter 1 Introduction .................................................................................................................... 1
1.1. Study Area ..........................................................................................................................1
1.2. Hazards in the Angeles National Forest..............................................................................3
1.3. Existing Trail Data ..............................................................................................................4
1.4. Project Goal ........................................................................................................................5
1.5. Thesis Layout ......................................................................................................................7
Chapter 2 Related Work.................................................................................................................. 8
2.1. Database Construction ........................................................................................................8
2.2. Trail Attributes ..................................................................................................................11
2.3. Existing Applications ........................................................................................................12
2.4. User Interface and User Experience .................................................................................16
2.5. Application Platforms .......................................................................................................18
2.6. Application Testing ...........................................................................................................20
Chapter 3 Methods ........................................................................................................................ 22
3.1. Platform Choices ...............................................................................................................23
3.2. Database Construction ......................................................................................................24
3.3. Application Development .................................................................................................28
v
3.3.1. Application Design ..................................................................................................29
3.3.2. Creating the Web Map .............................................................................................30
3.3.3. Creating the Web Application .................................................................................32
3.4. Application Testing ...........................................................................................................38
Chapter 4 Results .......................................................................................................................... 40
4.1. Trail Database and Web Map ...........................................................................................40
4.2. Angeles Hike Finder Application .....................................................................................40
4.2.1. Splash Screen ...........................................................................................................41
4.2.2. Query Widget ...........................................................................................................41
4.2.3. Additional Widgets ..................................................................................................45
4.3. User Testing and Survey ...................................................................................................47
Chapter 5 Conclusions .................................................................................................................. 50
5.1. Application Achievements ................................................................................................50
5.2. Challenges and Limitations...............................................................................................51
5.2.1. Technical Difficulties...............................................................................................51
5.2.2. Adapting the Project ................................................................................................52
5.2.3. Esri Web AppBuilder: Developer Edition versus Online Edition ...........................52
5.2.4. Shortcomings Revealed by Users ............................................................................53
5.3. Future Improvements ........................................................................................................53
5.3.1. Database Improvements ...........................................................................................54
5.3.2. Mobile Optimization ................................................................................................54
5.3.3. Difficulty Ratings Improvements ............................................................................54
5.3.4. Further User Testing ................................................................................................55
References ..................................................................................................................................... 56
Appendix A Survey Questions and Responses ............................................................................. 58
vi
A.1 Questions ...........................................................................................................................58
A.2 Responses ..........................................................................................................................60

vii
List of Figures
Figure 1. Study area, including CWA, in context to Los Angeles region ...................................... 2
Figure 2. Location of the CWA in relation to the rest of the study area ......................................... 3
Figure 3. Department of Parks and Recreation Trail Data. Only one trail falls completely within
the boundaries of the study area. ............................................................................................. 5
Figure 4. Sample from Modern Hiker of a hike. The hike name and basic information (left), and
directions and downloadable data (right). ............................................................................. 13
Figure 5. Modern Hiker Find a Hike page with filters applied for area, distance, hike time,
season, difficulty, and elevation gain. ................................................................................... 14
Figure 6. AllTrails page on Mount Baden Powell on the desktop site (left) and on iOS (right) .. 15
Figure 7. AllTrails Explore page to find a hike. Several filters have been applied to narrow down
the selection ........................................................................................................................... 16
Figure 8. Simplified development of hiking trail application ....................................................... 22
Figure 9. Workflow for trail geometry and trail data generation before final creation of trail
database. ................................................................................................................................ 26
Figure 10. Entity Relationship Diagram of trail database ............................................................. 27
Figure 11. Project workflow from the database published as a web map integrated into the final
application, AHF ................................................................................................................... 29
Figure 12. View from the developer perspective of the 4 main tabs to configure the application 30
Figure 13. Dialogue box to publish web map (right) and published web map in ArcGIS Online 32
Figure 14. Configuration for the Splash screen on the content tab, allowing text edits ............... 34
Figure 15. Configuration screen for the query widget, with the information tab open ................ 36
Figure 16. Query expression builder launched from the query configuration dialogue box ........ 37
Figure 17. The splash page greeting a visitor when the application is first launched .................. 41
Figure 18. AHF when a user selects query widget, then select by attributes, and provides inputs
............................................................................................................................................... 42
Figure 19. Results of Select by Attributes with query layer added .............................................. 43
Figure 20. Results of Search by Difficulty query with result layer added .................................... 44
viii
Figure 21. Drop down menu in results allowing for exporting trails ........................................... 45
Figure 22. Additional widgets: 1 Home Button, 2 Find My Location, 3 Zoom, 4 Legend, 5
Layers, 6 Attribute Table ....................................................................................................... 46
Figure 23. AHF with open attribute table displaying trail layer data ........................................... 47
Figure 24. Charts of survey responses for interacting with the AHF ........................................... 48
Figure 25. Survey results for the ease of exporting trails ............................................................. 49
ix
List of Tables
Table 1. Difficulty Values with Corresponding Attribute Ranges ............................................... 27
Table 2. Database Field Design .................................................................................................... 28

x
List of Abbreviations
AHF Angeles Hike Finder
ANF Angeles National Forest
CWA Cucamonga Wilderness Area
GIS Geographic information system
SBNF San Bernardino National Forest
SSI Spatial Sciences Institute
UI User Interface
USC University of Southern California
USDA United States Department of Agriculture
UX User Experience
VGI Volunteered Geographic Information
WYSIWYG What you see is what you get

xi
Abstract
The Angeles National Forest (ANF) contains miles of backcountry hiking trails easily accessible
to residents of Los Angeles. Those who are planning to go on a hike have several options to aid
in their planning process from guidebooks, to online resources, to mobile applications. These
resources often include trail descriptions, directions to the trailhead, and statistics regarding each
hike, which sometimes includes a vaguely defined difficulty rating. However, not every hiker
experiences trail difficulty the same way. New hikers are unlikely to agree with experienced
hikers as to the difficulty rating for the same hike. Similarly, different hikers may disagree on
what exactly makes one trail harder than another.
To address this, this project developed the Angeles Hike Finder (AHF). The AHF allows
users to identify which factors they consider to be most difficult, and receive a customized output
of trails in the ANF that meet the search criteria. This application was developed from a
manually generated trail database of hiking trails in the ANF, containing trail data regarding trail
distance, elevation gain, maximum elevation, and trail type. Once the database was developed,
the AHF was created using Esri Web AppBuilder. The AHF allows users to determine what
range of attributes or difficulty ratings they are interested in before the application generates the
customized trail listing. The goal of this application development project was to address the lack
of defined difficulty ratings for trail planning present in other hiking applications. Through the
creation of the AHF, hikers in the ANF can see what is perceived as most difficult for their
unique needs. The AHF can serve as a template for how other hiking applications address the
concept of the difficulty for hiking trails.
1
Chapter 1 Introduction
The Angeles National Forest (ANF) lies primarily within Los Angeles County and contains
miles of trails accessible to anyone with a vehicle. Even in hot weather, higher elevations offer
conditions that are cool based on summer months in Southern California. In winter, these same
high elevation trails can be covered in snow, offering opportunities for activities like
snowshoeing and mountaineering.
Information regarding these trails is available in print and online sources, but before the
completion of this project, there was a lack of a unified database of backcountry trails that could
be easily input into a geographic information system (GIS). These sources also lack the ability
for users to decide what characteristics of the trail they find to be difficult. Instead, they usually
rely on a relative rating stemming from the author’s opinion or a crowd rating. The goal of this
project was to create a database of backcountry hiking trails in the ANF, as well as a web
mapping application that allows users to find hikes within the ANF and rank these hikes based
on their own definition of difficulty.
1.1. Study Area
Despite the reputation of Los Angeles as a flat city covered in asphalt, the ANF is a
drastic topographical change from the city, with a maximum elevation of 10,000 feet, and a
diverse array of plant life (United States Department of Agriculture 2020). The vegetation varies
from chaparral environments to pine and fir forests at higher elevations (USDA 2020). At higher
elevations, snow is common in winter months, leading to the existence of ski lifts near Mount
Baldy and Mount Waterman. Trails are accessible from several road access points, including the
Angeles Crest Highway and Highway 39. The ANF contains 557 miles of trails (USDA 2020).
This includes 73 miles of National Recreation Trails and 176 miles of the Pacific Crest Trail.
2
The ANF consists of two main areas, one just north of the LA basin, encompassing the San
Gabriel Range, and another section just north of Santa Clarita (
Figure 1). The project focused on trails in the section just north of the LA Basin due to its closer
proximity to the large population of Los Angeles.

Figure 1. Study area, including CWA, in context to the Los Angeles region
The easternmost portion of the ANF is comprised of the Cucamonga Wilderness Area
(CWA), which is jointly managed by the ANF and the San Bernardino National Forest (SBNF).
Roughly 1/3
rd
of the CWA lies within the ANF, with the other portion in the SBNF (USDA
3
2020). A small number of the trails employed in this study cross the boundary of the ANF into
the SBNF. These trails are included for a couple of reasons. All of the trails are at least partially
within the ANF, and the ones that do cross over are still within the CWA.

Figure 2. Location of the CWA in relation to the rest of the ANF
1.2. Hazards in the Angeles National Forest
Hiking in the ANF carries inherent risk, due to trail conditions, vegetation, and weather.
The presence of Poodle Dog Bush, a plant causing painful skin irritation is frequently found in
areas of forest that have been burned recently. Hikers who are experienced on trails in summer
4
conditions may suffer harm during winter recreation on the same trails, as was the case when a
hiker went missing and a search and rescue worker was killed in the resulting search (Andone
2019). From May 2019 to April 10, 2020, incident reports from the ANF WildCad page show 66
search and rescue operations. WildCad is a service that allows wildfire and other emergency
communication centers to track incidents in their jurisdiction and dispatch aid as needed.
Inexperienced hikers may find themselves overly ambitious despite their skill level, such as the
Eaton Canyon hike. A quick search for “Rescues in Eaton Canyon” returns results from early
2020 and date back over 10 years, despite an official closure of a deeper and more difficult
section of the trail back in 2014 (Trinh 2014). Improved preparation on the part of hikers can
mitigate the chance of emergencies, injuries, death, and search and rescue operations.
1.3. Existing Trail Data
While information on hiking trails is widely available, existing GIS databases of trail data
focus on trails within city boundaries. Smaller nature paths and green spaces make up the
majority of the data, and are available from the Los Angeles County GIS Data Portal (Figure 3).
Larger trail datasets available from the United States Forest Service focus on National Scenic
Trails. Currently, there is no database consisting of backcountry trails in the ANF that can be
downloaded into ArcGIS. This limitation prevents other GIS analysis of trails within the ANF,
and makes the development of hiking applications focusing on the region more difficult. With
this project’s focus on hiking trails in backcountry regions, a lack of a GIS ready dataset serves
as a major obstacle to application development. Since the backcountry trail data that is available
from applications like Modern Hiker and AllTrails allows users to download a line feature of
individual trails, and does not include additional information, the metadata must be added in
separately to a trail database. The first stage of this project focused on creating such a database,
5
containing the necessary information regarding trails that serves as the foundation for the web
application.

Figure 3. Department of Parks and Recreation Trail Data. Only one trail falls completely within
the boundaries of the study area.
1.4. Project Goal
Applications like AllTrails and Modern Hiker exist that already focus on mobile use and
will provide in depth information on a trail once it is selected. This project instead focused on the
initial planning for a hike and developed the AHF, an application. During the planning stage,
users are looking to see what hikes are available to them, and can search for them based on two
6
approaches, searching by trail attributes, and searching by trail difficulty ratings for the
associated attributes. Users can see this information within the attribute table of the trails layer,
allowing them to explore the data before choosing their inputs. Therefore, the goals of this
project were as follows:
1. Create a database of hiking trails that can be easily incorporated into a GIS
2. Create a web application that includes a database of hiking trails that users can explore
3. Allow users to search for trails based on both their attributes and associated difficulty
rankings based on their desired criteria
Once they can see what hikes are available, other resources can provide more detailed
information for the next phase of planning. From a user perspective, the goals of the web
application were as follows:
1. Navigate around trails in the ANF
2. Interact with the map through movement and being able to turn layers on and off
3. Find their location with location services enabled on their device
4. Search for trails either by their attributes or difficulty ratings
5. View more detailed information about individual trails
6. Export the trails resulting from their search results as a table
With these user requirements in mind, the AHF was developed to accomplish them.
The application was developed with Esri Web AppBuilder Developer Edition. In order to
facilitate a positive user experience, the application emphasizes a simple user interface, taking
cues from other web applications, such as Google Maps, to allow users to use the application
with minimal teaching. Finally, users can export the list of trails they generate based on their
search parameters input into the application for later use.
7
At the start of this project, the initial goal was similar but slightly different. Instead of
searching for trails based on their attributes or difficulty ratings, users were going to be able to
rank trails by whichever difficulty factor they found to be most difficult. This would have
allowed for users to define difficulty for themselves, instead of using predetermined difficulty
ratings. Accomplishing this unfortunately became impossible within the project’s timeframe, due
to numerous technical difficulties and troubleshooting steps. This initial goal informed some of
the decisions made to create the application, and while the goal had to shift, these choices still
allowed for the goals listed above to be accomplished. A deeper exploration and discussion of
this initial goal, and the choices made to accomplish them can be found in Chapters 3 and 5.
1.5. Thesis Layout
The remainder of the thesis will examine the academic literature relating to the AHF, the
methods used to complete the development of the database and application, the results of the
project, and finally the conclusions drawn from the completion of the project. Each subsection of
the Related Work chapter addresses individual components of the project. This includes the
database development, difficulty factor for ranking the hikes, application development, and
similar applications already being used by hikers in the Los Angeles region.
8
Chapter 2 Related Work
This chapter explores the different components of the AHF, from developing the trail database to
developing the web application to rank the hikes. These sections will also examine sources
exploring factors relating to trail difficulty, as well as existing applications and how they differ
from the proposed project.
2.1. Database Construction
While existing web applications have their own databases, they are not available for
download other than as individual components. Doing so only yields trail geometry without its
associated information. AHF therefore has two components in the database, a geometry
component, and an attribute component. Ensuring the proper information was included in both
components, as well as guaranteeing the two can be implemented together seamlessly was of
upmost importance before creating the application. The following section explores how different
studies developed databases from multiple information sources to support a geodatabase for
spatial analysis. These resources informed an effective workflow in developing the AHF.
A study focusing on the creation of a database to help determine the locations of new
public facilities in Minna, Nigeria, involved creating a database of existing public facilities, and
defining how to select the locations for recommended new facilities (Umar et al. 2015). Since the
study involved creating a database that linked both spatial and non-spatial data, it served as an
excellent framework for creating a similar database for this project. The authors integrated data
from both spatial and non-spatial sources together, which helped with the conceptualization of
the database used in the AHF.
Establishing guidelines for the database design was an important step before the actual
database was constructed. Using pre-established professional guidelines from other organizations
9
can serve as a baseline for the design (Newman 2019). Newman focused on creating a geologic
database to assess the risk of landslides in Washington State based on standards and guidelines
established by the United States Geological Survey and the National Geologic Map Database.
This database consisted of several different geologic features, including geologic units, faults and
folds, and map points. Each dataset was added after the creation of geologic maps and provided
additional attribute information to corresponding points on the map. Eventually, the database
served to develop geologic maps to provide information regarding risk. While creating the
geodatabase, organizing individual components with proper associated information allows for an
easier separation of features that may otherwise be hard to distinguish. Ensuring the use of
proper symbology leads to a better end result that more clearly communicates the desired
information. Since Newman’s project focused on the spatial component of the data, but still
needed the underlying attribute information, a geodatabase served as the answer. This solution
was applied to developing the AHF, where visible trail data needs its attribute data to function
properly.
Since the raw information for creating a database may need to be taken from multiple
sources, data needs to be properly integrated together into a unified dataset within a geodatabase.
Data integration is the process where the different sources are combined in a way to allow for
comparative analysis. In a paper meant to provide a general overview of data integration, the
authors discuss the challenges faced when attempting to use multiple sources of data that do not
match up (Haas, Lin, and Roth 2002). The authors discuss the concept of database federation,
which serves as a middle step to access the multiple sources of data. In database federation, a
relational database management system is used to link multiple sources of data together through
relationships. As a result, a user will experience the data as a single entity. This article was useful
10
in conceptualizing the approach of integrating multiple data sources together. The Angeles Hiker
Finder integrated several data sources together, and allow the application to reference the data as
a single unit.
The nature of the project was such that the database needed to be constructed to serve as
the base information for the web application. Babcock developed a similar project where the
author constructed a web application based upon volunteered geographic information (VGI) that
was input into a database (Babcock 2019). This project focused on creating a database for
biochar, a substance with ties to climate change and environmental management. The application
in turn allowed for visualization of the database, as well as the ability to interact with the spatial
data to serve a user’s own research interests. Babcock developed a database which in turn
supported the project goal of creating a web application for the data. Finally, Babcock distributed
a survey among the targeted user base to evaluate the success of the web application. This
project has a similar structure to the AHF. Consequently, it serves as an excellent framework
from which to build off of.
The creation of a database reveals what components are necessary for simplified database
management. In order to query the data, different datasets need to be in similar vector formats or
combined into a single raster dataset to prevent difficulties in queries (Vaitas et al. 2019). This
study created a database of climate information, mapping out how the different components
related to each other with UML mapping and Entity-Relationship diagrams. Due to the large
amount of data implemented, a separate application was created in order to input the data into the
database. Although this project does not deal with as large of a dataset, the study highlights the
importance of a well-designed database to ensure a subsequent application will run smoothly.
11
2.2. Trail Attributes
Since the project goal was to allow users to define their own difficulty on trails using the
AHF, this section will explore trail attributes commonly associated with difficulty. While
different hikers may experience these factors in unique ways, examining the literature can
narrow down which attributes are most important. Additionally, if classes need to be created for
the factors, divisions amongst each class can be better determined from the information in the
following section.
For many hikers, altitude has a major impact on trail difficulty. Most hikers who begin to
feel the effects of acute mountain sickness do so at above 2,500 meters, or 8,200 feet, and the
effects increase in probability and intensity beyond that elevation (Paul et al. 2018). This study
focuses on illness that results from being at high elevations without proper time to acclimate to
the lack of oxygen. The paper aims to educate people on how to adjust to higher elevations, and
provides an overview of the effects that elevation can have on the human body when it is not
used to it. While this research has a medical approach, it contextualizes the effect of high
elevation on those unprepared for elevation, and explains the risks and side effects associated
with these conditions. Symptoms are even more powerful above 3,480 meters, or 11,400 feet
(Burtscher et al. 2019). The authors also evaluate how elevation is linked to potential adverse
health effects. Additionally, the study looks at more extreme health conditions, and how there is
a potential for predicting risk based on initial exposure to high altitudes. The paper breaks down
health effects at different elevations, and provides some guidelines for potential categories of
elevation difficulties for the proposed application.
Slope, or steepness, also makes a hike more or less difficult. Hikers consume 2.5 times as
much oxygen at a 15% gradient (Burtscher 2004), and gait is heavily affected even at a 9%
12
slope, regardless of uphill or downhill direction (Sun et al. 1996). Sun et al. sought to better
understand how human effort and gait are influenced by differing slopes in an urban
environment. The study examined thousands of participants over a three-month period to fully
study walking speed, cadence, and step length variation over the different slopes. The authors
found that on descents, step length decreased to make steps easier, meaning down slope can still
be difficult like going up slope. Burtscher sought to understand the demands hiking places on the
bodies of older hikers by evaluating different factors that influence difficulty, and provides
recommendations regarding how to address them. Burtscher (2004) evaluated how slope and
elevation change affects aerobic activity, and shows how high elevations and steep trails increase
the amount of effort in hiking. Based on this information, elevation change, overall elevation,
and length can all be considered as attributes within the trail database.
2.3. Existing Applications
There are currently several hiking applications that provide information on trails in the
ANF. This section will explore some of these existing applications, highlighting the niche they
serve in informing hikers about hikes, and what they lack that sets this application apart from
them. These existing applications exist as both web resources and mobile resources, and some as
both. Some exist as resources for planning a hike, and others can be used on a mobile device on
the hike itself.
The website Modern Hiker provides reports on specific hiking trails. Each trail has its
own page that describes the trail, including overall statistics like total distance, elevation gain, an
estimated time to complete, and difficulty rating (Figure 4). The difficulty rating contains six
classes: beginner, easy, moderate, challenging, strenuous, and expert. The main report describes
the trail, and includes pictures that provide an overview as to what can be expected on a trail.
13
The reports do a good job pointing out interesting information, and covering any possible
confusing trail junctions. Each page also has a download for a kml or gpx file, an elevation
profile, links to driving directions for the trailhead through Google Maps, and a map through
Natural Atlas to show where the trail is located.

Figure 4. Sample from Modern Hiker of a hike. The hike name and basic information (left), and
directions and downloadable data (right).
To find hikes, users can search in a search bar for hikes they know of, or they can use a
feature called Find a Hike. On this page, a map is visible with flags for each hike. Using filters,
users can select what state, region, distance category, time category, season, difficulty category,
and elevation gain category they desire. After filters are applied, the page refreshes, showing the
hikes that fall under the criteria selected, and a list with the basic information for each hike
(Figure 5). While this feature can help narrow down what hikes users see based on the provided
criteria, it does not allow users to choose which difficulty factor they find most challenging, and
what determines the difficulty rating is not clearly defined. Additionally, the categories are in
classes that do not have justifications. With elevation gain, the categories do not have a uniform
range between categories, and all hikes with gain above 3,000 feet are grouped into a singular
category. Very different hikes into a single category, where a hike with 3,000 feet of gain would
14
show up with ones having 8,000 feet of gain. Without allowing users to choose what they find
most difficult, a user may find themselves with a list of hikes that does not accurately reflect
what they want.

Figure 5. Modern Hiker Find a Hike page with filters applied for area, distance, hike time,
season, difficulty, and elevation gain.
AllTrails is available both as a web and mobile application. Like Modern Hiker, each trail
has a write up with information regarding the hike, as well as providing basic statistics. This
information includes distance, elevation gain, and route type, which can be loop, or out and back
(Figure 6). The difficulty rating stems from VGI, allowing users to rate the trail and leave
comments regarding their experience on the trail. To find a trail, users can either search
manually, or view a map which has flags for each hike similar to Modern Hiker. The mobile
application functions in a similar way, with the same features, but with a different interface.
15

Figure 6. AllTrails page on Mount Baden Powell on the desktop site (left) and on iOS (right)
To sort the hikes on the AllTrails explore page, users can use a slide bar to define their
own category, allowing them to choose their desired length, or distance range. The other factors,
like rating and difficulty allow selection of each difficulty, rating, and route type (Figure 7).
However, AllTrails uses only three difficulty ratings—easy, moderate, and hard. Unlike Modern
Hiker, AllTrails does allow users to select multiple difficulty ratings at the same time. Trails can
also be tagged with features, like dog friendly, which can be incorporated into the search filters.
Like Modern Hiker, AllTrails does not define how their difficulty ratings are determined. It does
allow users to choose the distance and elevation gain interval they are interested in, but does not
allow users to determine which factor is considered most difficult.
16

Figure 7. AllTrails Explore page to find a hike. Several filters have been applied to narrow down
the selection
2.4. User Interface and User Experience
User Interface (UI) and User Experience (UX) refer to how a user interacts with
technology, and how they feel about that interaction, respectively. The UI focuses on what a user
interacts with, in this case the web application, while UX is how the user feels about the
experience of working with the actual application. Focusing web application development on
UI/UX can ensure that a website or application is consistently used, and that similar competing
sites and applications are not used instead (Hardianto 2019). A large part of ensuring a good
UI/UX is to conduct user testing, which is further expanded upon in section 2.6.
To ensure good UI/UX design, emphasis should be placed on simplicity and centering the
design around the end goals for the application (Wong 2020). By focusing on the goals laid out
in section 1.4, the design of the AHF can improve the overall UI/UX by emphasizing the search
capabilities of the application to find desired trails. Wong (2020) also suggests minimizing effort
17
needed by users to interact with the application. If there are too many extra steps to complete a
task, there is more possibility for user to get confused or make a mistake, which in turn
negatively impacts the UX. Limiting the number of components within an application leads to a
more streamline UX, as a user is less likely to be overwhelmed with a smaller number of
capabilities. Finally, explicitly outlining the capabilities of the application for the user will
improve the UI/UX as a user will know what the application is capable of, and what they can do
with it (Wong 2020). Their expectations are immediately set and managed, and they know what
to expect from their interaction. By framing the project goals through the lens of these
suggestions, the AHF can be developed to be as effective as possible from a UI/UX standpoint.
Any application is only as good as its ability to be easily operated and understood by its
users. Almarashdeh and Alsmadi provide insight into developing an application that is user
friendly and intuitive (Almarashdeh and Alsmadi 2016). The paper evaluated government mobile
applications, and made recommendations as to how problems with their usability could be
addressed. The authors had several experts evaluate a mobile government application’s overall
usability, and provide feedback for improvements. This study provides some examples of
common mistakes and suggestions for overall improvements that can be applied to the proposed
study application in development. Some of these mistakes include using conventions that vary
from other applications users may already be familiar with, and not being concise enough with
any instructions. From this study, the authors suggest ensuring that applications are reviewed by
the targeted end user base, and overall emphasis is placed on easy usability for the user base. If
an application is too difficult for someone to use, they simply will not use it.
Creating an effective application that any novice user can immediately navigate with ease
is no small task. To accomplish this task, a paper by Roth provides a survey of opinions from
18
professionals in the geospatial industry (Roth 2015). It seeks to find what experts think in regards
to human interaction with spatial applications and data, and how these interactions can be
improved. In essence, the author is asking other GIS professionals the who, what, when, where,
and why of GIS. This article explained concepts that can be applied to the construction of the
proposed application, and how it can be better developed so users can interact with it more
efficiently. Roth provides the example of how users are frequently expecting applications to
function across multiple platforms with an emphasis on mobile devices. This consideration
informed the decision to use Esri WebAppBuilder, which simultaneously allows for application
construction across multiple platforms. Considering the questions raised in the study can help
guide the application design process, and allow for a better identification and fulfillment of needs
for the final product.
2.5. Application Platforms
For developers with limited coding experience, a WYSIWYG application can increase
their ability to develop an application they may not otherwise be able to develop (Lennartz
2008). WYSIWYG applications allow for interaction with the application components directly as
opposed to code, making the development process simpler. The other benefit of a WYSIWYG
application is the development process requires interaction with the components of the final
application, meaning the developer will have a similar UX to the end user while in the process of
configuring the UI. This means that better choices regarding UI/UX can be made sooner in the
development process.
Esri Web AppBuilder is a what-you-see-is-what-you-get (WYSIWYG) application,
allowing for the creation of other web applications without the need for writing custom code
(Esri 2020). It provides a platform where a developer can see individual components of the
19
application, including the map and widgets, and use or edit them immediately. This allows
developers to adjust the UI of the application without needing custom code, and can improve the
overall UX as a result. Esri Web AppBuilder allows users to develop mapping applications
available online for easy viewing (Esri 2019). It allows customization of themes and widgets,
and has built in tools to minimize the need for coding. Widgets in Web AppBuilder are modular
software components that can be individually added or removed from an application in order to
provide additional functionality. Using Esri Web AppBuilder can simplify the development
process.
There are other competing products to Esri Web AppBuilder that serve as WYSIWYG
platforms for application development. Some of these products could be used to develop an
application like the AHF. However, for various reasons, Esri Web AppBuilder became the better
choice. Some of the other alternative WYSIWYG platforms include Froala Editor, TinyMCE,
Vev, Summernote, and Setka Editor. All of these platforms offer varying degrees of
customization, set up, administration, and usability, but despite all of their strengths, none of
them focus specifically on developing spatial applications focused on a map. Esri Web
AppBuilder does, and has the added benefit of being streamlined for use with ArcGIS Pro.
A similar project on hiking trails used Esri Web AppBulder to construct their application
(Yeung 2017). Yeung used Esri Web AppBulder to construct an application for hiking trails in
Santa Barbara supported by VGI. While Yeung’s project focused on the VGI component, the
AHF focused more on user customization. Yeung faced limitations in using Esri Web
AppBuilder to host his project, which mainly centered around the inability to create a many-to-
one relationship between the VGI and a single trail feature. Since this project focuses on how a
user interacts with preexisting data, the platform is beneficial.
20
2.6. Application Testing
Creating an application is simply the first step in a development project. Without
feedback from outside users, an objective evaluation of the application will be severely limited.
Feedback from users familiar with the subject matter can provide insight as to who else may
benefit from the application, and detail what works well and what does not (Gao et al. 2014).
Gao et al. outline how to implement application testing. The authors provide an overview of the
different kinds of testing that are available, and why each one may be appropriate and useful.
This is done through a literature review of other application testing studies that focus on
particular methods. They also outline different approaches to testing, and how different issues
can develop throughout the testing process. This study is excellent in providing both an overview
of different testing methods, as well as including other literature to review in the event that this
application will need a more specific testing method. The paper helped determine which
questions should be included in the user survey, and stressed the importance of inquiring about
how the users interact with the application.
In a study that created a geospatial database of Mexican migration, users who tested it
were able to provide insight to the author regarding the overall success of the project (Rodriguez
2019). This feedback allowed the author to determine the overall success of the project, and
validate that the goals of the project had been met. The study also discusses the creation of a
database, and was done for the SSI program, which makes it useful on multiple levels.
Considering the diverse array of technological platforms, testing a web application from
multiple technological sources can also aid in assessing an applications functionality (Macauley
2018). Testing an application from platforms like desktops, tablets, and mobile phones and
through multiple web browsers can serve as an initial step in the testing process before users
21
provide feedback. Identifying potential issues from this testing can lead to more responses if a
certain platform does not properly run the application. This in turn would lead to more useful
responses from the user base.
The Gao et al. study serves as an excellent overview of application testing as a subject. It
examines common strategies for evaluation, as well as how different methods excel in certain
ways while suffering from some shortcomings in others. It also highlights other projects with
application development as the focus that can be reviewed for a better understanding of the
subject as the time comes for testing of the proposed project. The Rodriguez and Macauley
sources are SSI application development thesis papers. Both projects developed applications and
contained a component of user testing. The fact that the two papers were written for the same
project provides an excellent context for what the proposed project can be tested for. Ideally,
testing can be done early enough in the project to accommodate for adjustments in the
application based on feedback from testing.
22
Chapter 3 Methods
This project developed a web application supported by a database of hiking trails wherein users
have the ability to search for hikes based on their attributes or difficulty ratings. After the
application was developed, it was tested and evaluated through a survey of volunteers. The
following section highlights the necessary steps for completing the project. These steps include
the initial development of a trail database based on existing hiking information, the creation of
the application itself, and finally, user testing of the application and the completion of a survey to
evaluate the success of the web application. These are all highlighted in Figure 8.

Figure 8. Simplified development of hiking trail application
While the following section details the work conducted to complete the project, there was
a great deal of work conducted in the pursuit of a slightly different objective. Because the initial
goal influenced some of the early choices made for the project’s overall methodology, the initial
goal is briefly described here. As mentioned in section 1.4, the original goal of this project was to
allow users to define what attributes of hiking trails they found most difficult, rank these factors
as most and least difficult, and then receive an output of all trails in the database with a
customized difficulty rating. This approach would have ranked each trail relative to each other
within the database, and provided a more customized approach to hiking trail difficulty.
Numerous technical glitches in Esri products made this goal impossible to achieve in the
23
project’s time frame, even with three separate Esri support staff involved with troubleshooting.
The goal was therefore shifted to a fully developed application allowing users to search for their
hikes by either their attributes, or by difficulty ratings, and the methodology for the final
application is reflected throughout the document.
3.1. Platform Choices
Several different software applications were needed in order to accomplish the goals laid
out in section 1.4. ArcGIS Pro, Microsoft Excel, and Esri Web AppBuilder Developer Edition
were selected to accomplish them. Other programs, like Google Sheets, could have been used to
record attribute information, but Excel was chosen for its ability to save data in multiple file
formats, including csv files, which can be used in ArcGIS Pro. ArcGIS Pro contains all of the
functionality needed to manage data, construct a database, and export a web map for use in a
web application. Like ArcGIS Pro, Esri Web AppBuilder Developer Edition is a product
managed by Esri, and the two programs are specifically built to support each other. As a
WYSIWYG application, Esri Web AppBuilder allowed for extra focus on UI/UX throughout the
development process. With the added benefit of compatibility with ArcGIS Pro, it was the
natural choice.
Esri Web AppBuilder provides a platform for application development that simplifies the
design process of application constructions. The program provides several themes, allowing
users to choose how the different components of the application will be organized, and how end
users will interact with the interface. As an Esri product, data from ArcGIS Pro can be shared
and serve as the base data for an application. The greatest benefit of the standard version of Web
AppBuilder is the ability to do all application development online, hosting the application on
ArcGIS Online. Esri Web AppBuilder also provides an environment that does not require
24
expertise in coding, making the development simpler, as well as numerous themes allowing for a
customizable and user friendly interface.
Initially, the goal of the project was for the user to receive a ranking of trails based on
their chosen difficulty attribute. This could have been achieved with the app running a field
calculation in the background using a geoprocessing widget in Web AppBuilder, but could only
be developed using the Web AppBuilder Developer Edition. The Developer Edition was
therefore initially selected to build the app. After the goals shifted, this version became
unnecessary. However, with all of the data already imported into the Developer Edition, and with
all of the same functionality of the standard version, the Developer Edition continued to be used.
Microsoft Excel was also used to help with data management during the database construction.
More rationale for its use can be found in the following section.
3.2. Database Construction
As mentioned earlier in section 1.3, GIS trail data is only available from the County of
Los Angeles for trails closer to urban spaces and not in National Forest land. The trails in the
National Forest Service Trails file only includes the trails directly managed by the USDA, and
does not include the trails involved in this project. Trail data for the trails in this project are
widely available from online resources like Modern Hiker and AllTrails, as well as printed
guidebooks, yet it is not a simple matter to import this data into ArcGIS Pro. The online sources
have elevation profiles and gpx files available for download to a mobile GPS device to aid in
navigation along the trail. The database for the AHF is constructed from the gpx files to provide
geometry within ArcGIS Pro before the trail data was added in. The database of hiking trails
contains attributes for trail distance, elevation gain, maximum elevation, as well as the difficulty
25
ratings for those three factors. The other attribute information added was trail type, which was
provided as context for the user but otherwise does not affect the application.
The database of trails for this project was developed from a preliminary experimental
database consisting of ten trails and their associated attribute data. The goal of the preliminary
database development was to ensure that generating a larger database later on would not be too
time consuming, necessitating a separate project altogether. It was important to discover the
necessary steps to add in each individual trail, and what data to include in the shapefile versus
what to join later on from an attribute table.
The dataset needed to be manually generated, which took time because it was not easily
automated. Trail geometry first was downloaded as a gpx file from either AllTrails or Modern
Hiker. AllTrails gpx tracks for in and out trails are only for one direction of travel, requiring less
data editing, and are preferred to tracks from Modern Hiker, which required deleting the
duplicate track recorded when a hiker turned around. After acquiring the gpx file, the Gpx to
Features tool in ArcGIS Pro converts the file into an Esri shapefile of a series of points. Next, the
Points to Line tool was used to convert the features to line geometry. A new field was added with
the name of the trail. Finally, the newly created trail line feature was added to the overall trail
database using the Append tool. The workflow for the trail database creation is summarized in
Figure 9.
26

Figure 9. Workflow for trail geometry and trail data generation before final creation of trail
database.
In a separate Excel file, the trail attribute was recorded using the ObjectID field to join
the information to the main dataset after all of the trails were added to the spatial database.
Attribute information was recorded in Excel to avoid potential error in appending the trail
geometry to the spatial dataset. Excel also allowed for easy recording of attribute data and to
export the table as a csv file, which ArcGIS Pro can read as a standalone table for eventual
joining to the trail geometry. The Append tool in ArcGIS Pro requires the same fields between
the new data being added and the target dataset. If every trail attribute field needed to be added
to a new trail before the append step, it would have added several extra steps. Instead, using
Excel allowed for a faster recording of trail attributes, and only the name field needed to be
added to each trail geometry feature before it was appended to the main dataset. The ObjectID
field was automatically added by Esri, and corresponds to the order that each trail was added into
the geodatabase. The Excel file contains fields for trail distance, elevation gain, maximum
elevation, and trail type. The difficulty categories were calculated based on the attribute
information. The difficulty categories correspond to a range of values seen in Table 1. These
categories are defined by the range of values research in Section 2.2, and personal experience
27
with the hiking trails included. Each category has separate levels of difficulty divided into scales
from 1 to 5, representing difficulty levels for each category of length, elevation gain, and
maximum elevation.
Table 1. Difficulty Values with Corresponding Attribute Ranges
Difficulty Values Length Gain Max
1 0-3 0-800 0-3000
2 3.1-6 801-2000 3001-5000
3 6.1-9 2001-3500 5001-7000
4 9.1-12 3501-5200 7001-8500
5 12.1-16 5201-7300 8501-10100

Once the database was completed, the data was exported as a csv file and added into
ArcGIS Pro where it was joined to the shapefile containing the trail line data. A join was added
using the ObjectID fields, and finally the data was exported into a complete trail database in a
single feature. The two components of the database share a one to one relationship as
summarized in the Entity Relationship Diagram in Figure 10.

Figure 10. Entity Relationship Diagram of trail database
A summary of the fields and their data types is available in Table 2. Database Field DesignTable
2Table 2.
28
Table 2. Database Field Design
Field Name Field Description Data Type
ObjectID Unique ID for each trail ObjectID
Shape Polyline Z. Generated from conversion from gpx file Geometry
Shape_Length Esri calculated distance in Degrees Double
Trail Name Unique name for each trail Text
Length Trail length (miles) from Modern Hiker, or AllTrails if
unavailable from Modern Hiker
Double
Elev_Gain Elevation gain (feet) from Modern Hiker, or AllTrails if
unavailable from Modern Hiker
Long
Max_Elev Maximum elevation (feet) from Modern Hiker, or AllTrails
if unavailable from Modern Hiker
Long
Trail Type In and out, loop, or point to point. Indicates to hikers what to
expect, and if special consideration for a trail is needed
Text
Length
Category
Trail difficulty on a scale of 1-5, with 1 being least difficult
and 5 being most difficult
Long
Gain Category Elevation Gain difficulty on a scale of 1-5, with 1 being least
difficult and 5 being most difficult
Long
Max Category Maximum Elevation difficulty on a scale of 1-5, with 1 being
least difficult and 5 being most difficult
Long

3.3. Application Development
The main focus of the project was the development of an application based upon the trail
database. The following section describes the steps taken to develop the ANF, including the
design process, the creation of the foundational basemap, and finally the application and its
components. Also included is a description of the initial attempt to incorporate the geoprocessing
widget to accomplish the original goal of the project. While attempting to develop the
geoprocessing widget to allow for trail ranking, technical issues between publishing ArcGIS Pro
tasks to Web AppBuilder proved insurmountable. Three separate Esri representatives were
29
unable to sort out the issue within the project timeframe, and in order to progress, the goals for
the project shifted to those highlighted in section 1.4.
The workflow for the application development process and the application components
can be viewed in Figure 11.

Figure 11. Project workflow from the database published as a web map integrated into the final
application, AHF
3.3.1. Application Design
The application design was centered around the project goals outlined in section 1.4. The
application UI was designed so that users can select a range of values for either the factors or
difficulty ratings they desire, and generate a custom list of trails as a result. The list provided for
the user allows them to explore the options available to them and view where they fall on the
map. Finally, this report can be exported if the user desires.
Widgets, which are tools that add functionality to the application can be added as desired.
Widgets can also be moved throughout the application to make them more or less prominent
depending on their importance to the project. The Developer Edition allows for even greater
customization within the application, and users can create custom widgets and designs within the
30
Web AppBuilder platform. An overview of the developer view of Esri WebApp Builder can be
viewed in Figure 12.

Figure 12. View from the developer perspective of the 4 main tabs to configure the application
The tabs include allow the user to set the theme, the base map, configure the widgets, and change
the credits within the application. All of these functions do not require additional coding.
3.3.2. Creating the Web Map
Creating the application stemmed from the work accomplished at the conclusion of the
database development outlined in Section 0. The web map includes several other components
besides the trail database, including an outline of Los Angeles County, the ANF, and the CWA.
The county boundary helps provide context for the study area, and as a unique shape, it can help
provide context for a user of what geographical area they are looking at. The boundaries for the
ANF and CWA also provide context for the study area, and serve to contain the trails that are
included in the study. The symbology for the county boundary is the least obtrusive to the eye,
with a thinner line weight and softer blue color. It is noticeable, but the other two polygons are
31
more prominent with their symbology. The ANF and CWA both use a thicker line weight, and
more visible color than the county boundary to highlight their importance. The ANF boundary
uses a green color to match with the fill of the ANF on the base map. The CWA is a vivid red to
attract attention and compensate for its smaller size compared to the other two boundaries. The
trails use a dark green color that is visible against the base map, but also fits in with the theme of
being in the ANF. A thinner line is used to prevent distortion from overlaps between trails. The
base map used contains plenty of location data that allows users to help orient themselves,
including city names, highways, and the ANF itself. It uses a different color for the ANF, and
combined with the polygon boundary, the study area is prominently highlighted.
Once all of the necessary data was assembled and mapped in ArcGIS Pro, the data
needed to be moved to ArcGIS Online in order to be used in Esri Web AppBuilder. This step
involved publishing the data created in ArcGIS Pro to a web map in the University of Southern
California (USC) Spatial Sciences Institute (SSI) online account. The web map was set to a
public profile, allowing anyone to view it. The extra benefit of the web map is the ability for a
third party to view the published trail database, and save a copy of it if they so desire. The
dialogue screen to publish the map and the fully published web map in ArcGIS Online can be
viewed in Figure 13.
32

Figure 13. Dialogue box to publish web map (right) and published web map in ArcGIS Online
3.3.3. Creating the Web Application
Esri Web AppBuilder is optimized for the Windows operating system. A private remote
desktop needed to be set up in order to use Web AppBuilder. Once installed, the application was
created with the remote machine as the server. Upon the creation of a new application, it will
display a default world base map. In order to bring the relevant data into the application, the base
map was instead set to the web map published in Section 3.3.2. With the Angeles Trails layer
that was described in section 0 added in, functionality and customization could be added in
before publishing the application.
3.3.3.1. Splash Screen
A splash screen serves as both a welcome to users of the application as well as an
instruction on how to interact with it. Without it, users have no guidance on how to interact with
the application unless they have some preexisting knowledge of what the application is meant to
33
do. However, too much text on the splash screen would dominate the initial view, and would be
more likely to cause a first time user to click away from an overly long explanation of features.
In order to be as useful as possible, brevity and clarity within the splash screen ensured that a
user would take away the key information needed for using the AHF. The size of the splash
screen was made to be large enough to immediately attract attention, yet small enough to be
obvious it was a splash screen. Esri Web AppBuilder allows for the simple construction of a
splash screen, which was employed to provide a very brief description of the application and
instructions on the key query functions within it. The configuration for the splash screen can be
viewed in Figure 14. The configuration screen allows the user to change the text included on the
splash screen, the appearance of the splash screen box, and the option to allow users to disable
future appearances of the splash screen or a requirement of acknowledgment.
34

Figure 14. Configuration for the Splash screen on the content tab, allowing text edits
3.3.3.2. Initial Goal: Geoprocessing Widget.
The initial goal mentioned earlier required using the geoprocessing widget. This widget
requires either a service URL or a geoprocessing service from ArcGIS Online in order to
function. The Calculate Field tool in ArcGIS Pro allows users to populate an empty field based
on a selected mathematical expression, and would have provided the customized ranking.
However, errors kept preventing an export of this geoprocessing task from ArcGIS Pro to
ArcGIS Online. This meant that the geoprocessing widget in Web AppBuilder could not be set
from ArcGIS Online. An attempted workaround showed some promise when the geoprocessing
task was able to be shared to ArcGIS Enterprise instead. However, when the geoprocessing
35
widget referenced the service URL from the task now in ArcGIS Enterprise, a new error
occurred saying it was an invalid task.
At this point, help was sought out from Esri, but despite several weeks of attempted
solutions with three separate representatives from Esri, the geoprocessing widget was still not
functional. With the time constraints for the project, the geoprocessing widget was abandoned,
and the goals outlined in section 1.4 were adapted to complete the project. This in turn led to the
selection of the query widget to provide the necessary tasks to complete the application and
address the project goals.
3.3.3.3. Adding Widgets and Customization
The core functionality of the application allows users to search for trails based on their
attributes or difficulty ratings. To facilitate this, the query widget was added. As a way to
highlight the importance of this tool, the default icon for the query widget was changed to a
hiking trail icon of two figures with walking sticks that is commonly associated with hiking
trailheads. Once added to the application, the widget was edited to provide the search functions.
Adding widgets is accomplished on the widget tab as seen in Figure 12, before launching the
widget’s configuration screen, available on every visible and added widget.
36

Figure 15. Configuration screen for the query widget, with the information tab open
The widget has two possible query options, search by attributes and search by difficulty.
In order to allow users to search for trails in two different ways, separate icons were used to
distinguish one from the other, with one visible in Figure 15. Setting up the queries required the
same basic steps for both:
1. Select the trail layer as the data source to be queried
2. Launch the query builder
3. Add multiple expressions
4. Set each expression to appropriate field in the trails layer
5. Select the “Ask for values box”
6. Provide a hint to guide the user to appropriate selections
37
For both possible queries, the expressions as for a range of values using the phrase “is between”
in the builder. This allows users to select multiple values for both the attributes and difficulty
ratings. For instance, a user can specify a trail length between 5 and 12 miles, or an elevation
gain difficulty of 4 or 5. Alternatively, a user can select a single value by inputting the same
value in both inputs for the query, such as 4 for length and 4 for difficulty. The button to launch
the expression builder for the query widget and the expression builder can be seen in Figure 16.
The option to tailor the query to the user need gives the AHF its uniqueness over other
applications already in use.

Figure 16. Query expression builder launched from the query configuration dialogue box
The other native supporting widgets included in the AHF support navigation around the
map and interaction with map layers. These widgets include a find my location widget, which is
most useful for users already in the study area of the Los Angeles Region, a Home button
returning the application to its default extent, zoom buttons to change the map scale, a search
bar, and finally, a legend a layers widget. All of these widgets are automatically included in the
38
main widget area of the widget configuration tab seen in Figure 12, and simply need to either be
turned on or off, or configured if necessary by the developer.
3.4. Application Testing
Once the web application was developed and functioning, it needed to be tested by hikers
in the Los Angeles region, the target user base. In order to conduct the survey on potential users,
approval was needed from the USC Institutional Review Board (IRB). To complete this process,
a preliminary application was submitted and the IRB determined that a survey issued online
meets the criteria for Human Subject Research, necessitating a full application for approval. This
application (UP-20-00388) was completed and submitted, and the IRB approved the survey for
use with the condition that all surveyed hikers will be adults over the age of 18. For the survey,
hikers in the Los Angeles region were asked to evaluate the application in order to see if it met
the development goal. Additionally, these testers evaluated the overall success of the application
in regards to its interface. Emphasis was placed on questions regarding how easy it was to
navigate around the map and interact with the trail database.
A group of 16 individuals known to the author were asked if they would be interested in
testing out the AHF application and filling out a survey to evaluate their experiences with it.
These individuals were chosen due to their either experience with hiking in the study area, or
interest in hiking in the study area. These individuals were chosen due to convenience, and are
nonrandom and nonrepresentative of Los Angeles hikers as a whole. Once consent was given
through text, a formal invitation was sent out via email providing a brief overview of the project,
as well as links to both the application and the survey. The survey was distributed via Google
Forms, allowing for an easy evaluation of survey results for individual questions as well as
respondents.
39
Users were asked a series of questions using a Likert scale including a 1-5 to rate the
ease of use concerning map navigation, the query system and how it is used, and the output of
trails generated. They were also asked for their overall impressions, what improvements or
limitations they see, and what other hiking applications they may already consult. This survey
allowed for the collection of concrete data to evaluate the outcome of the application. It also
addressed any shortcoming or improvements that may need to be made in order to better fulfill
the goal of the application that the testing group experienced or suggested. The full survey and
responses are included in Appendix A.

40
Chapter 4 Results
The completion of this project resulted in a publicly available web map containing a database of
50 hiking trails in the ANF, the completed AHF application, and 13 survey responses resulting
from application testing. The trail database, while not representative of every trail in the ANF,
serves as a template for any future work to expand it, or for others wishing to use it. The
application allows users to explore trails in the ANF, search for them based on their attributes or
difficulty ratings, and export the results of the searches. The survey evaluated user experiences
with the AHF, and provided insights into the successes and limitations of the project.
4.1. Trail Database and Web Map
The trail database, as described in section 0 was successfully published to the USC SSI
Organization on ArcGIS Online as a part of a publicly accessible web map. As a part of a web
map, anyone can access and download the trail layer for their own use in a GIS. Consisting of 50
trails, this database can serve as the basis or template for future analysis of hiking trails in the
ANF. At the beginning of this project, data for these trails was not available in an Esri ready
format. Developing the AHF has resulted in a dataset that is publicly available and ready for
immediate use in a GIS.
4.2. Angeles Hike Finder Application
The following section outlines the components of the AHF, serving as a description of
the application and its individual parts. It encompasses the user experience when the application
is first opened and the splash screen is launched, as well as the included widgets and the core
query function that allows users to make their trail selections and view their results.
41
4.2.1. Splash Screen
When the application is launched, a user is greeted by a splash screen seen in Figure 17.
This splash screen welcomes the user to the application, and provides an overview of the
application and its functionality. This description includes the number of hikes displayed in the
application, the ways a user can apply filters, the trail attributes and difficulty ratings, and how to
launch the widget that actually filters the hikes for the user. There is also the option to prevent
the application from displaying the splash screen again if the user were to refresh the web page.

Figure 17. The splash page greeting a visitor when the application is first launched
4.2.2. Query Widget
The Query Widget provides the core functionality of the application. When launched,
users have the option to search by trail attributes or by difficulty ratings. If a user selects the
option to search by trail attributes, the widget then prompts the user for inputs for each trail
attribute. The application includes textual prompts for each attribute input, explaining the range
of values that a user can select for the respective feature. For example, the trail distance input
42
prompts the user to choose a range between 0 and 16 miles, and will return trails that satisfy the
selection that the user inputs. Figure 18 illustrates the query widget with the Select by Attributes
option selected and inputs provided.

Figure 18. AHF when a user selects query widget, then select by attributes, and provides inputs
After the user inputs values or leaves a selection blank for Distance, Elevation Gain, and
Maximum elevation, they hit the apply button and the AHF returns all trails that satisfy the user
requirements. This process can be viewed in Figure 19, where the trails that satisfy the query are
displayed, and the resulting trails are added to the map as a new layer that can be toggled on and
43
off for visibility.

Figure 19. Results of Select by Attributes with query layer added
The process is similar for a search using difficulty ratings. To distinguish the difficulty
fields from the attribute fields, each factor has the name Category after it (e.g. Length Category,
Elevation Gain Category, and Max Elevation Category). The difficulty ratings for each field
range from 1 to 5, with 5 being most difficult, and 1 being least difficult. Users are still able to
input a range of values, allowing them to see a range of difficulty amongst their selected trails.
The output can also be renamed, or the default can be used, Search by Difficulty Ratings _Query
44
result, as seen in Figure 20.

Figure 20. Results of Search by Difficulty query with result layer added
Regardless of the search method used, the AHF returns a list of trails that satisfy the
search parameters specified by the user. These trails are listed in order of their ObjectID, and
display the rest of their attribute data. Selecting one of these trails in the results area will cause
the application to zoom in on the selected trail, and a secondary window displaying the
individual trails attributes appears as well. If multiple searches are conducted, users are able to
switch between previously run queries using a drop down menu at the top of the query tool
dialog box. Users are also able to export the results of their search by clicking on the feature
actions menu, represented by 3 dots next to the drop down menu, and selecting one of the export
options, including csv file, feature collection, and GeoJSON. The feature actions menu also
allows users to delete the query, view the results in an attribute table, or view a statistical
45
summary of the returned hikes as seen in Figure 21.

Figure 21. Drop down menu in results allowing for exporting trails
4.2.3. Additional Widgets
Other than the main query widget, the AHF also has a few secondary widgets for easier
interaction with the application. On the left side of the screen, there are a cluster of widgets for
navigation. The Home Button will take users back to the default extent of the map, which
overlooks Los Angeles County and the ANF. The My Location widget is best for users already
in the Los Angeles area, and allows the user to see where they are relative to the trails. There are
46
zoom in and out buttons as well. These widgets are all identifiable in Figure 22.

Figure 22. Additional widgets: 1 Home Button, 2 Find My Location, 3 Zoom, 4 Legend, 5
Layers, 6 Attribute Table
In the top right, there are the Legend and Layers widgets, allowing a user to see what
each map feature is and turn them on or off to let them control feature visibility. At the base of
the screen, there is an arrow allowing the attribute table of every layer to be seen. The default
attribute table that becomes visible upon launch is for the trail database, letting a user explore
which trails are available to search for at any point while using the application. The application
47
with the opened attribute table is visible in Figure 23.

Figure 23. AHF with open attribute table displaying trail layer data
4.3. User Testing and Survey
Once the application reached a functional level, a group of 16 hikers were sent an
emailed invitation to test the application, along with a link to a survey in Google Forms, as
discussed in Section 3.4. Of the 16 people contacted, 13 completed the survey to provide
feedback on the application. Since an identifying email address was not required, it was not
possible to determine exactly which 3 participants had not responded, and no further
communication attempts were made. A detailed view of the survey and the responses can be
viewed in Appendix A. As a whole, the responses to the survey indicate that users found the
AHF to be fairly simple to use, and found the ability to find trails based on their attributes as well
as their difficulty to be helpful. Of the respondents, 9 stated that they found it overall simple to
use, and 10 rated it either a 4 or 5 out of 5, with respect to usefulness, with 5 being very useful
with respect to being able to search by both attributes and difficulty.
48
Other questions regarding the ease of use for the application yielded similar results.
When asked about how easy to use different features were on a scale of 1-5, with 5 being very
easy, 11 rated the ease of navigation around the map as a 4 or 5, while 2 rated the ease of
navigation as a 3. 10 respondents rated their comprehension of the search function as a 4 or 5,
while 3 rated it as a 2. 9 respondents rated the ease of applying parameters to their search as a 4
or 5, with 1 rating it as a 3, 2 as a 2, and 1 as a 1. These results are summarized in Error!
Reference source not found..
49

Figure 24. Charts of survey responses for interacting with the AHF
The one question that revealed a different trend regarding ease of use for the application
concerned the ability to export the output result of a trail search, where only 6 respondents gave
the application a score of 4 or 5, while 5 gave it a score of 3, and scores of 1 and 2 each received
one vote. This question can be viewed in more detail in Figure 25.
50

Figure 25. Survey results for the ease of exporting trails
Survey respondents were also able to explain some of their answers further and leave
comments. This feedback led to more informed information outlining how the application could
be improved. One participant suggested using sliding bars instead of directly inputting the
desired range of values into the search parameters. Another pointed out that the search bar should
be refined to only query the trail layer. A recurring theme in the written feedback was the benefit
of being able to search for hikes by both the attributes and the difficulty, and the ability to
compare the two together. Considering this feature was the defining characteristic of the AHF,
this survey result reveals the success of the application in meeting the development goal.
51
Chapter 5 Conclusions
This section examines the achievements of the application, the challenges and limitations, and
the areas of opportunity for future improvements. The applications successes are examined
through what sets the AHF apart from several already existing applications, as well as its overall
ease of use to the testing group. The challenges and limitations will address the setbacks faced
throughout the development process of the application before its completion, and the subsequent
challenges experienced as a result in testing. Finally, the future improvements section will
address the areas that could be improved upon with additional work or by other studies.
5.1. Application Achievements
The results of the survey as discussed in Section 4.3 reveal that the AHF at its core level
allowed users to search for hikes based on either their attributes or difficulty factors. 10 out of 13
respondents rated the application a 4 or 5 out of 5 concerning the usefulness of being able to
search for hiking trails based on their trail attributes, or trail difficulty ratings. Additionally, 9
stated that they found the application easy to use. Based on the feedback from the survey results,
the AHF can be considered to be an overall success. Some of the additional comments
highlighted its uniqueness from other applications, in that the AHF has difficulty ratings that are
defined and attributable to their actual statistics instead of a poorly defined label provided by the
application. Additionally, the fact that each attribute had its own associated difficulty rating
allowed users to see what in particular made a hike difficult, whether it is only one factor, such
as trail length, or multiple.
The survey results also reveal that the application can be run on both a desktop as well as
a mobile platform. With so many applications already available on a mobile device, it is
important that the AHF is not only usable on a desktop. Luckily, the Esri Web AppBuilder
52
platform builds mobile functionality directly into the application, making development for both a
desktop and mobile user essentially the same. Including a question in a follow up survey
regarding how respondents viewed the application may reveal trends and differences in usability
between the two users, and reveal clear approaches to improving the application.
5.2. Challenges and Limitations
This project faced significant challenges throughout the development process that
ultimately put more constraints on the application versus the original version that was planned.
The sheer number of technical difficulties, and the time taken to troubleshoot them consumed
more time than originally anticipated. As a result, improvements to the application that were
identified as a result of the survey were not able to be implemented, as well as a more robust
version of determining a difficulty rating.
5.2.1. Technical Difficulties
Esri Web AppBuilder Developer Edition is optimized for the Windows operating system.
With this restriction, a private remote workstation needed to be set. Regular correspondence
became necessary to get Web AppBuilder to function remotely, delaying the development
process. Other technical difficulties included an inability for anyone else to view the application,
an insecure connection to the site, resulting in a security warning for those attempting to view the
site, and registering the IP address causing the site URL to change several times. While delays
were worked into the original timeline for completion, future work should account for even more
time for troubleshooting technical issues.
53
5.2.2. Adapting the Project
While the AHF used the query widget to provide its core function, the geoprocessing tool
was originally considered instead. Using this tool would have used a field calculator to calculate
a distinct ranking for each hike so users could compare hikes to each other. However, the desired
field calculation necessary for this function would not function in ArcGIS Pro during the initial
development. Trying to move this calculation into Web AppBuilder was not any more successful
either. Three separate Esri representatives were unable to troubleshoot the issue within the
necessary timeframe, leading to the necessity of switching focus to the query tool and a different
direction for the AHF. This solution sidestepped the problem, addressing the goal of the AHF to
allow users to choose what difficulty factors they are interested in, just without the same level of
precision that was originally wanted.
5.2.3. Esri Web AppBuilder: Developer Edition versus Online Edition
Given the attempts to develop the geoprocessing widget as explained in the beginning of
Chapter 3, it was originally decided to use the Developer Edition of Esri Web AppBuilder. Once
the decision was made to switch to the query widget to provide the application’s core
functionality as discussed in Section 5.2.2, the level of customization needed to complete the
development decreased. As a result, the AHF could have been developed using the standard
online edition of Esri Web AppBuilder, and not the Developer Edition. The AHF was configured
within the online setting. The only customization that was attempted could have been done in the
online setting as well.
Using the Developer Edition led to several technical problems addressed in Section 5.2.1.
The Developer Edition requirements led to the necessity of the remote desktop, and the issues
with registering the URL. While the Developer Edition is optimized for use on the Windows
54
Operating System, the Online Edition is browser based, meaning the computer operating system
does not matter as much as it does for the Developer Edition. Unless the added customization
features of the Developer Edition are needed, switching to the Online Edition can simplify the
Application Development process and would have eliminated several problems faced during the
creation of the AHF.
5.2.4. Shortcomings Revealed by Users
While the survey results for the AHF were overall positive, there were a few users who
did not find the application easy to use, and listed several problems. The lowest rated feature was
the ability to export a search result. For this feature, 7 of 13 respondents rated the ease of use for
this feature to be a 3 or less, with 5 being very easy. Based on this feedback, future
improvements should make exporting trails less difficult for users. Additionally, with the
development of the AHF conducted on a desktop platform, mobile consideration was secondary.
Because of this, three survey respondents mentioned issues with the application on a mobile
device. Some of these critiques include the zoom rate when using fingers, and locating the
parameter filters on a mobile screen.
5.3. Future Improvements
While overall the project achieved its goal, there are definite improvements that could be
made. The trail database, currently with 50 trails, could be expanded, and more attributes
included. The application could be optimized to be used more easily on a mobile device, and the
application overall could add in more precision in trail difficulty selection. Finally, additional
testing and surveys would reveal if improvements improved the application for the user
identified issues, and determine if it has been optimized for mobile use as well.
55
5.3.1. Database Improvements
While 50 trails serve as a core that demonstrates the utility of the application, the ANF
contains numerous more. Several hiking trails overlap with each other, allowing for numerous
variations on routes that are already included. The database could be expanded upon to include
more trails, and perhaps a way to identify trails that overlap with each other, perhaps as another
field listing its connections to others. Other difficulty factors could include aspect, relating to sun
exposure, or vegetation coverage for ease of traverse.
5.3.2. Mobile Optimization
The AHF was developed with the intention of desktop use. However, users are already
used to using hiking applications on their mobile devices and several respondents in the survey
stated that they tested the AHF on their mobile device. Thus in the future more steps should be
taken to ensure a positive user experience on these devices. Based on the results discussed in
Section 5.2.4, more testing should be done to improve the ease of zooming on a mobile device,
and identifying the parameters. Further user surveys should also include a question regarding
how the application is tested, on a desktop or mobile device. This added question could help
further isolate issues experienced on one device over another.
5.3.3. Difficulty Ratings Improvements
Users reported in their responses overall satisfaction with being able to rank hikes on
attributes as well as difficulty ratings. In the short answer responses, the AHF was complimented
for the fact that users can see which attributes are difficult, because the ratings are associated
with each category, and not for the trail overall. However, the original vision for this application
involved a greater level of precision in choosing what factors an individual user finds to be most
difficult. Integrating this into the application ended up causing a considerable amount of
56
problems, particularly with the geoprocessing widget necessary to implement this function.
Given more time and assistance from Esri representatives, this issue is likely solvable in a future
generation of the AHF. The query function could still be available, and the geoprocessing tool
would be a second way for hikers to more precisely determine which difficulty factors they find
most important, and how that affects which trails are recommended for their needs. Regardless,
the AHF functions as desired, and can serve as a foundation for future improvements.
5.3.4. Further User Testing
After the improvements outlined in the previous sections have been addressed, the
application could undergo another round of user testing and surveying. Ideally, the same
participants as the first round would be surveyed again, and the survey could then ask the
participants how they feel the application has been improved. A question would be added asking
users if they tested the application on a desktop or a mobile device setting, as well as a section
for comments addressing issues unique to the testing platform. This round of questioning would
also emphasize if the ease of exporting the search results has improved. These two issues came
to light during the first survey, so questions directly addressing them can provide information on
whether or not they have been adequately addressed.
57
References
Andone, Dakin. 2019. “A Rescue Worker Died While Looking for a Missing Hiker on Mount
Baldy in California.” CNN, December 15, 2019.
Almarashdeh, Ibrahim, and Mutasem Alsmadi. 2016. "Heuristic Evaluation of Mobile
Government Portal Services: An Experts' Review." Internet Technology and Secured
Transactions (ICITST), 2016 11th International Conference for, pp.427-431.
Babcock, Michael. 2019. “Building a Spatial Database of Biochar Research and Practice with
Web-GIS.” Master’s Thesis, University of Southern California.
Burtscher, Martin. 2004. "Endurance Performance of the Elderly Mountaineer: Requirements,
Limitations, Testing, and Training." Wiener Klinische Wochenschrift 116, no. 21-22:
703-714.
Burtscher, Martin, Michael Philadelphy, Hannes Gatterer, Johannes Burtscher, Martin Faulhaber,
Werner Nachbauer, and Rudolf Likar. 2019. "Physiological Responses in Humans
Acutely Exposed to High Altitude (3480 m): Minute Ventilation and Oxygenation Are
Predictive for the Development of Acute Mountain Sickness." High Altitude Medicine &
Biology 20, no. 2: 192-197
Esri 2019. “Web AppBuilder for ArcGIS.” Esri. Accessed April 21, 2020.
https://doc.arcgis.com/en/web-appbuilder/
Esri 2020. “What is ArcGIS Web AppBuilder?” Esri. Accessed September 30, 2020.
https://doc.arcgis.com/en/web-appbuilder/create-apps/what-is-web-appbuilder.htm
Gao, Jerry, Xiaoying Bai, Wei-Tek Tsai, and Tadahiro Uehara. 2014. "Mobile Application
Testing: A Tutorial." Computer 47, no. 2: 46-55.
Haas, Laura, Eileen T. Lin, and Mary Roth. 2002. "Data Integration Through Database
Federation." IBM Systems Journal 41, Volume (no.4): pp.578-596.
Hardianto, Zhafirah Indira Paramarini. 2019. "Analysis and Design of User Interface and User
Experience (UI/UX) E-Commerce Website PT Pentasada Andalan Kelola Using Task
System Centered Design (TCSD) Method." Fourth International Conference on
Informatics and Computing (ICIC): 1-8.
Lennartz, Sven. 2008. “20 Useful WYSIWYG Editors Reviewed.” Smashing Magazine.
Accessed September 30, 2020. https://www.smashingmagazine.com/2008/05/25-
wysiwyg-editors-reviewed/
Macauley, Michele. 2018. “Development of a Web-GIS Application to Aid Marathon Runners in
the Race Selection and Planning Process.” Master’s Thesis, University of Southern
California.
58
Newman, Patricia. 2019. “Developing Improved Geologic Maps and Associated Geologic
Spatial Databases Using GIS: Candy Mountain and Badger Mountain, WA.” Master’s
Thesis, University of Southern California.
Paul, Subhojit, Anamika Gangwar, Kalpana Bhargava, Pankaj Khurana, and Yasmin Ahmad.
2018. "Diagnosis and Prophylaxis for High-Altitude Acclimatization: Adherence to
Molecular Rationale to Evade High-Altitude Illnesses." Life Sciences 203: 171-176.
Rodriguez, Jonathan Daniel. 2019. "The Movement of Mexican Migration and its Impact Based
on a GIS Geospatial Database." Master’s Thesis, University of Southern California.
Roth, Robert E. 2015. "Interactivity and Cartography: A Contemporary Perspective on User
Interface and User Experience Design from Geospatial Professionals." Cartographica:
The International Journal for Geographic Information and Geovisualization 50. Volume
(no.2): pp.94-115.
Sun, Jie, Megan Walters, Noel Svensson, and David Lloyd. 1996. "The Influence of Surface
Slope on Human Gait Characteristics: A Study of Urban Pedestrians Walking on an
Inclined Surface." Ergonomics 39, no. 4: 677-692.
Trinh, Jean. 2014. “One Of The Deadliest Local Hiking Trails Is Getting Closed.” LAist, June
26, 2014.
Umar, Abdulkareem A., Matthew O. Adepoju, Ekundayo A. Adesina, and Michael O.
Bamgbose. 2015. "Optimal Location Determination of Some Public Facilities within
Minna Metropolis: A Geospatial Technique Approach." Journal of Geographic
Information System 7, no. 06: 658.
United States Department of Agriculture. 2020. “About the Forest: Angeles National Forest.”
San Gabriel Mountains National Monument. Accessed April 8, 2020.
https://www.fs.usda.gov/main/angeles/about-forest
—. 2020. “Cucamonga Wilderness.” San Gabriel Mountains National Monument. Accessed June
27, 2020. https://www.fs.usda.gov/detail/angeles/specialplaces/?cid=stelprdb5210347
Vaitis, Michail, Haralambos Feidas, Panagiotis Symeonidis, Vasilis Kopsachilis, Dimitris
Dalaperas, Nikoletta Koukourouvli, Dimitris Simos, and Symeon Taskaris. 2019.
"Development of a Spatial Database and Web-GIS for the Climate of Greece." Earth
Science Informatics 12, no. 1: 97-115.
Wong, Euphemia. 2020. “Simplicity in Design: 4 Ways to Achieve Simplicity in Your Designs.”
Interaction Design Foundation. Accessed September 30, 2020. https://www.interaction-
design.org/literature/article/simplicity-in-design-4-ways-to-achieve-simplicity-in-your-
designs
Yeung, Alvin. 2017. “Generating Trail Conditions Using User Contributed Data Through a Web
Application.” Master’s Thesis, University of Southern California.
59
Appendix A Survey Questions and Responses
A.1 Questions

60

61

A.2 Responses

62

63

64

65

66

Abstract (if available)

Abstract The Angeles National Forest (ANF) contains miles of backcountry hiking trails easily accessible to residents of Los Angeles. Those who are planning to go on a hike have several options to aid in their planning process from guidebooks, to online resources, to mobile applications. These resources often include trail descriptions, directions to the trailhead, and statistics regarding each hike, which sometimes includes a vaguely defined difficulty rating. However, not every hiker experiences trail difficulty the same way. New hikers are unlikely to agree with experienced hikers as to the difficulty rating for the same hike. Similarly, different hikers may disagree on what exactly makes one trail harder than another. ❧ To address this, this project developed the Angeles Hike Finder (AHF). The AHF allows users to identify which factors they consider to be most difficult, and receive a customized output of trails in the ANF that meet the search criteria. This application was developed from a manually generated trail database of hiking trails in the ANF, containing trail data regarding trail distance, elevation gain, maximum elevation, and trail type. Once the database was developed, the AHF was created using Esri Web AppBuilder. The AHF allows users to determine what range of attributes or difficulty ratings they are interested in before the application generates the customized trail listing. The goal of this application development project was to address the lack of defined difficulty ratings for trail planning present in other hiking applications. Through the creation of the AHF, hikers in the ANF can see what is perceived as most difficult for their unique needs. The AHF can serve as a template for how other hiking applications address the concept of the difficulty for hiking trails.

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

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

PDF

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

PDF

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

PDF

Generating trail conditions using user contributed data through a web application

PDF

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

PDF

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

PDF

Building a spatial database of biochar research and practice with Web-GIS

PDF

Analysis of park accessibility in Redan, Georgia Web GIS application

PDF

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

PDF

Exploring commercial catch: creating a responsive Florida fisheries web GIS using ASP.NET, the Esri JavaScript API 4.x, and Calcite Maps

PDF

Implementing spatial thinking with Web GIS in the non-profit sector: a case study of ArcGIS Online in the Pacific Symphony

PDF

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

PDF

Creating a Web GIS to support field operations and enhance data collection for the Animal and Plant Health Inspection Service (APHIS)

PDF

Creating a well database and web mapping application: using geographic information systems to manage and monitor groundwater resources in Sonoma County, California

PDF

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

PDF

Development of a Web GIS application to aid marathon runners in the race selection and planning process

Asset Metadata

Creator Toy, Alexander (author)

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

School College of Letters, Arts and Sciences

Degree Master of Science

Degree Program Geographic Information Science and Technology

Publication Date 11/09/2020

Defense Date 08/27/2020

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

Tag Angeles National Forest,Cucamonga Wilderness,Development,Esri Web AppBuilder,Hiking,Los Angeles,national forest,OAI-PMH Harvest,San Gabriel Mountains,web application,What You See Is What You Get application

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Bernstein, Jennifer Moore (committee chair), Duan, Leilei (committee member), Sedano, Elisabeth (committee member)

Creator Email alexanderctoy@gmail.com,atoy@usc.edu

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

Unique identifier UC11666690

Identifier etd-ToyAlexand-9106.pdf (filename),usctheses-c89-394473 (legacy record id)

Legacy Identifier etd-ToyAlexand-9106.pdf

Dmrecord 394473

Document Type Thesis

Rights Toy, Alexander

Type texts

Source 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 a...

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