University of Southern California Dissertations and Theses

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

(USC Thesis Other)

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

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content ALASKA HIKE SEARCH: DESIGNING A MAPPING APPLICATION FOR ALASKAN TRAILS AND USER CONTRIBUTED HAZARDS by Rebecca M. Wilson 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) August 2020 Copyright © 2020 Rebecca M. Wilson ii Dedication To new beginnings. iii Acknowledgements Thank you, Dr. Bernstein, for guiding me on this project and helping me to focus my ideas into a comprehensive but practical application for my thesis. Dr. Loyola, Dr. Swift, and Dr. Vos, thank you for encouraging me to follow my interests on this project and assisting me in identifying the valuable ideas and pieces of the project. Brandon from Alaska Hike Search, thank you for working with me on this and allowing me to use your site as a platform to build this project. To my father, mother, sister, and Louisa. Thank you for providing the spark I needed to start this journey and cheering me along in the moments I struggled. iv Table of Contents Dedication ....................................................................................................................................... ii Acknowledgements ........................................................................................................................ iii List of Tables ............................................................................................................................... viii List of Figures ................................................................................................................................ ix List of Abbreviations ..................................................................................................................... xi Abstract ........................................................................................................................................ xiii Chapter 1 Introduction .................................................................................................................... 1 1.1. Motivation ...........................................................................................................................2 1.1.1. Hiking in Alaska ........................................................................................................2 1.1.2. Trail Hazards ..............................................................................................................5 1.1.3. Trail Conditions and Management.............................................................................7 1.1.4. Public Health ..............................................................................................................9 1.1.5. Tourism Economic Contribution .............................................................................10 1.2. Project Framework ............................................................................................................11 Chapter 2 Related Work................................................................................................................ 13 2.1. Web and Mobile Trail Applications .................................................................................13 2.1.1. Difficulty Ratings.....................................................................................................18 2.1.2. Idaho Trails ..............................................................................................................21 2.2. VGI ...................................................................................................................................22 2.2.1. VGI Quality .............................................................................................................22 2.2.2. VGI for Planning......................................................................................................27 2.2.3. VGI for Trail Management ......................................................................................27 2.3. Web Application Development.........................................................................................29 2.3.1. UX Design ...............................................................................................................29 v 2.3.2. Application Platform Selection ................................................................................31 2.3.3. Trail Selection and Planning ....................................................................................32 Chapter 3 Methods ........................................................................................................................ 34 3.1. Intended Users and Scope .................................................................................................34 3.2. Data Acquisition and Management ...................................................................................36 3.2.1. State of Alaska .........................................................................................................37 3.2.2. National Park Service ..............................................................................................37 3.2.3. US Forest Service ....................................................................................................37 3.2.4. US Fish and Wildlife Service ..................................................................................38 3.2.5. Municipality of Anchorage ......................................................................................39 3.2.6. Missing Trails ..........................................................................................................39 3.3. Geodatabase Design ..........................................................................................................39 3.3.1. Trail Lines Data Compilation ..................................................................................40 3.3.2. Trailheads and Trail Features ...................................................................................41 3.3.3. Park Boundaries .......................................................................................................42 3.3.4. Surface Information Analysis and Difficulty Ranking ............................................43 3.3.5. VGI Hazards Feature Class ......................................................................................44 3.3.6. Publishing Services ..................................................................................................45 3.4. UX Design ........................................................................................................................47 3.5. Web Application Design ...................................................................................................48 3.5.1. ArcGIS API for JavaScript ......................................................................................49 3.5.2. Widgets and Web Application Features ..................................................................49 3.5.3. Splash Screen ...........................................................................................................54 3.6. Application Evaluation .....................................................................................................55 3.6.1. Functional Requirements .........................................................................................55 vi 3.6.2. User Testing .............................................................................................................56 Chapter 4 Results .......................................................................................................................... 58 4.1. Trails Database..................................................................................................................58 4.2. Web Application Tour ......................................................................................................58 4.2.1. Initial Page and Splash Screen .................................................................................58 4.2.2. VGI Trail Hazards Editor.........................................................................................61 4.2.3. Pop-ups ....................................................................................................................63 4.2.4. Measurement Toolbar ..............................................................................................64 4.2.5. Search Tool ..............................................................................................................64 4.2.6. Additional Tools ......................................................................................................65 4.2.7. Mobile Browser Functionality .................................................................................68 4.3. User Testing and Feedback ...............................................................................................70 Chapter 5 Conclusions .................................................................................................................. 72 5.1. Application Successes .......................................................................................................72 5.2. Limitations and Challenges ...............................................................................................73 5.2.1. VGI Trail Hazards Accuracy ...................................................................................73 5.2.2. Editor Widget ...........................................................................................................74 5.3. Future Improvements ........................................................................................................75 5.3.1. Database Expansion and Data Quality .....................................................................75 5.3.2. Advanced Search .....................................................................................................76 5.3.3. Add Trail Hazards ....................................................................................................77 5.3.4. VGI Trail Features ...................................................................................................78 5.4. Future Direction for the Application .................................................................................78 References ..................................................................................................................................... 83 Appendix ....................................................................................................................................... 90 vii A. Web Application Scripts .....................................................................................................90 A.1 Script import of ArcGIS API for JavaScript 4.14 and AMD module .........................90 A.2 Create new webmap that references a portalItem and define the view .......................91 A.3 Define layers and add to map ......................................................................................92 A.4 Layer pop-up design....................................................................................................93 A.5. Locate widget (my location) ......................................................................................96 A.6 Home widget ...............................................................................................................96 A.7 Bookmarks widget ......................................................................................................96 A.8 Basemap Gallery .........................................................................................................97 A.9 Search bar ....................................................................................................................97 A.10 Layer list widget with legend ....................................................................................98 A.11 Filter widget ..............................................................................................................99 A.12 Coordinates widget .................................................................................................100 A.13 Measuring toolbar ...................................................................................................100 A.14 Editor Widget ..........................................................................................................103 A.15 Print widget .............................................................................................................103 A.16 Snackbar Splash Screen ..........................................................................................104 A.17 Media tag in CSS for mobile browser functionality ...............................................105 A.18 Example of CSS used for webpage style ................................................................106 B. Pre-Development User Survey ..........................................................................................107 B.1 Questions ...................................................................................................................107 B.2 Responses ..................................................................................................................109 C. Post-Development User Survey ........................................................................................111 C.1 Questions ...................................................................................................................111 C.2 Responses ..................................................................................................................114 viii List of Tables Table 1 Selected applications........................................................................................................ 14 Table 2 Mapping application platforms comparison .................................................................... 32 Table 3 Shenandoah National Park hiking difficulty rating system ............................................. 44 Table 4 File sizes for current datasets ........................................................................................... 79 ix List of Figures Figure 1 Alaska’s ecoregions .......................................................................................................... 3 Figure 2 Maps showing a comparison of cellular coverage for Alaska and the lower 48 contiguous states from GCI and AT&T ................................................................................. 6 Figure 3 Alaska Hike Search landing page and trailhead pop-up ................................................. 15 Figure 4 Idaho Trails mapping application ................................................................................... 22 Figure 5 User trail experience responses ...................................................................................... 35 Figure 6 User technological skill responses.................................................................................. 36 Figure 7 Master trail line feature class attribute fields ................................................................. 41 Figure 8 Master trailhead feature class attribute fields ................................................................. 42 Figure 9 Trail features feature class attribute fields...................................................................... 42 Figure 10 Master park boundaries feature class attribute fields ................................................... 43 Figure 11 Trail hazards VGI feature class attribute fields ............................................................ 45 Figure 12 Loading page with red arrow and box highlighting the button users must click to use application ............................................................................................................................. 60 Figure 13 Map Help button highlighted in red box and arrow ..................................................... 60 Figure 14 Location of Trail Hazard Editor tool within the application ........................................ 61 Figure 15 Flow Diagram of Trail Hazard Editor tool ................................................................... 62 Figure 16 Result of trail hazard added on a map with pop-up displayed in bottom left ............... 62 Figure 17 Trail information pop-up .............................................................................................. 63 Figure 18 Measurement toolbar and measurement window ......................................................... 64 Figure 19 Search bar functionality ................................................................................................ 65 Figure 20 Other tools in application ............................................................................................. 66 Figure 21 Example of map created from the print tool ................................................................. 67 Figure 22 Mobile device application display ................................................................................ 68 x Figure 23 Editor widget known limitations .................................................................................. 75 Figure 24 Advanced Search tool designed within ArcMap’s ModelBuilder ................................ 77 xi List of Abbreviations ADF&G Alaska Department of Fish and Game AHS Alaska Hike Search API Application Program Interface AST Alaska State Troopers CSS Cascading Style Sheet DEM Digital Elevation Model DNR Department of Natural Resources GIS Geographic information system GPS Global Positioning System GPX GPS Exchange HTML Hypertext Mark-up Language ISO International Organization for Standardization MOA Municipality of Anchorage MXD Map Exchange Document NPS National Park Service NWR National Wildlife Refuge OSM Open Street Map REST Representation State Transfer SAR Search and Rescue URL Uniform Resource Locator USC University of Southern California USFS US Forest Service xii USFWS US Fish and Wildlife Service UX User Experience VGI Volunteered Geographic Information xiii Abstract Alaska is home to an extensive network of hiking trails that navigate a remote and diverse wilderness. Mapping applications are currently available to trail users, but each available option lacks either spatial extent of coverage, accuracy of data, or detailed descriptions of the conditions on the trail. Users can spend significant time researching descriptions and current trail conditions across websites and mapping applications in order to make proper decisions for planning routes and equipment. The website Alaska Hike Search (AHS) provides detailed descriptions of popular hikes across the state but lacks an in-depth mapping application for searching trails. The lack of information on current trail hazards and wildlife activity compounds the concerns for proper trip planning, creating concerns for the safety of hikers and other trail users. In this project, a web application was designed as a prototype for the AHS website that also allows for contribution of volunteered geographic information (VGI) of trail hazards and warnings. This project gathered spatial data available from the agencies and organizations that manage trails, with a focus on the 129 trails described on AHS. Where authoritative data was not available, spatial and feature data was collected from other hiking trail applications to complete the database. Alongside the creation of this database, a web application was designed through hypertext markup language and the ArcGIS Application Programming Interface for JavaScript 4.14. This web application allows users to discover trails near them, search for trails by name, and filter trails that meet their desired difficulty. Through an editable VGI dataset, users can provide hazards as point features for warnings to unsafe conditions, or wildlife activity, such as bears or moose near trails. This data is instantly displayed on the map for other users to view. Future work will include implementing this application on the AHS page, enriching data, designing additional tools and functionality, and developing a mobile application. 1 Chapter 1 Introduction Alaska’s 57 million acres of designated wilderness provide an expansive playground of recreational opportunities for outdoor enthusiasts. Hiking trails in Alaska can provide unique experiences, some of which are only a few hours’ drive from Anchorage, Alaska’s largest city. These unique experiences include activities such as traversing glaciers, summiting mountain peaks, or exploring the Arctic Circle and its vast tundra. However, without proper knowledge and awareness of the areas and trail, hikers can risk putting themselves and others in danger. There is no singular online mapping application of trails in Alaska that is comprehensive in spatial extent and provides information on existing and new features, obstacles, and current hazards present. Existing web and mobile applications for hiking are missing large regions of trails or only provide line features and text information. This information is often outdated, inconsistent in its classifications, or just incorrect. The goal of this project was to develop a comprehensive database and web mapping application for trails and trail features within Alaska that included volunteered geographic information (VGI) functionality to allow for submission of warnings of hazardous conditions on trails. This application was designed through the ArcGIS Application Programming Interface (API) for JavaScript 4.14 and based on the existing framework of the Alaska Hike Search (AHS) website and its library of trails to enhance the searchability and utility of the website. The desired outcome of this database and application development is to provide a tool for hikers to properly plan their outdoor adventures. Trails are an important contributor to public health and increased community value, but also can be a risk to safety when unexpected conditions are encountered by inexperienced hikers. Chhetri (2015) notes that when users can properly plan and anticipate the experience of the biophysical characteristics they are likely to 2 encounter, it greatly reduces the likelihood of an undesirable (or unsafe) experience and promotes the continued use and exploration of other trails. The development of this comprehensive database and mapping application aims to contribute to a more informed trip plan and safer trail experience for all users. 1.1. Motivation This section explores the motivation for this type of application due to the unique characteristics and risks to public safety on Alaskan trails. The discussions in this section will include how outdoor recreation benefits the Alaskan economy, and the impacts and benefits these types of applications can have on trail health, community planning, public health, and outdoor recreation tourism. 1.1.1. Hiking in Alaska The development of this application aims to address the unique issues and events encountered within Alaska’s complex environment. Alaska is made up of eight ecosystems ranging from coastal rainforests to arctic tundra that are further broken into 32 ecoregions (Figure 1). Natural features of the state include glaciers, 34,000 miles of ocean coastline, rugged mountain peaks and ridgelines, North America’s tallest mountain - Denali, tundra, 3,000 rivers, three million lakes, volcanoes, and diverse forest ecosystems. Each of these environments and their unique features provide different challenges that hikers can encounter and should thoroughly prepare for. 3 Figure 1. Alaska’s ecoregions. Source: Alaska Department of Fish and Game 2004 Alaska’s trails are unique compared to those in the lower 48 states (Lower 48) not only because of the features mentioned, but because the trail terrain is often more rugged and difficult. The National Park Service (NPS) website (NPS 2019-a) on backpacking in Alaska notes that hikers should plan for much slower travel than they would in the Lower 48. They also recommend to not plan trips on a “miles per day” expectation, as is a typical strategy with longer multi-day hikes. Since the landscape can often be unpredictable and ever changing, the website instead recommends a “you get where you get” mentality where users remove expectations of planned daily destinations. Unexpected challenges that are present even on more popular routes, may require users to allow for more time to ensure they are still on the trail or backtrack to 4 reconnect with a well-established trail. If users are aware of potential areas of rough terrain or can see where other users have noted points where the trail disappears or landmarks are difficult to identify, they can be prepared with proper gear or looking for features they may have missed without previous warning. These unclear landmarks and trail features as well as injury on the trail are all possible contributing factors to missing hikers that may lead to a Search and Rescue (SAR) response. According to the Alaska State Troopers (AST) Annual Report in 2009 (AST 2009), a person or group was reported missing or overdue to AST SAR once every 12 hours between 2005-2009. Of these 3,700 reported requests 1,778 required a SAR response. The breakdown of SAR responses within the 2012 AST Annual Report (AST 2012) indicated that 38 of the 608 cases that year involved an overdue hiker. Other cases involved overdue boaters, overdue motorists, overdue snowmachiners, overdue aircraft, or an aircraft crash. A broader study by Heggie and Amundson (2009) of SAR in all US National Parks found that from 1997 to 2007, hikers constituted 48 percent of all SAR assistance calls and 22.8 percent of fatalities. A recent example of an Alaskan SAR case occurred in September 2019. A couple started on a popular but more advanced hike over mountains and glaciers in the Hatcher Pass area, 40 miles north of Anchorage. On their second day of hiking they missed their intended turn up a valley and continued five miles past this intersection. Once they realized they had missed their turn they spent two days “bushwhacking” through thick willows as they attempted to find a faster route back to their intended destination. They were eventually found by troopers who had been dispatched to locate them on a Search and Rescue mission (Anchorage Daily News 2019). When need for supplies are balanced with the need to keep backpacks light on long hikes, adding time on to a hike can create stress on food and water rations. Information on features present at 5 important turns is very valuable for a hiker unfamiliar with the trail but is not well documented on any existing trail applications. The application in this project aims to use existing information as well as information provided by users to allow for hikers to develop a clear picture of what to expect and anticipate on trails that are not well marked. 1.1.2. Trail Hazards Unexpected changes on a trail, such as missing landmarks or new hazards, also pose a great risk to the user’s personal safety. These changes in conditions can be caused by natural events, trail degradation from increased human use, or trails that have been redirected to avoid hazards. Situations that lead hikers to lose their trail can progress to a matter of life or death since most trails in Alaska are located outside of cell service (Figure 2). The capability within a mapping application for a user to provide updates from recent hikes can allow for other users to be prepared for trail conditions that diverge from the norm. 6 Figure 2. Maps showing a comparison of cellular coverage for Alaska and the lower 48 contiguous states from GCI [top (Source: GCI 2020)] and AT&T [bottom (Source: AT&T 2020)] 7 Hiking on Alaskan trails that are well marked and heavily trafficked still presents risks to safety, due to an existing and increasing urban-wildland interface. Numerous incidences are documented of mauling and attacks by black and brown bears as well as injuries related to moose attacks within Anchorage (Coltrane and Sinnott 2015). While bears are often perceived as the greater threat, moose are very large, fast, and protective of their young. According to the Alaska Department of Fish and Game (ADF&G) website, moose are responsible for injuring more people in Alaska each year than bears (ADF&G 2019). Both of these large mammals exhibit relatively predictable habitat selection and behaviors during rearing or from seasonal food availability, such as salmon spawning (Albert and Bowyer 1991). This information can be provided as a valuable warning system to trail users for high risk areas during certain seasons. An application with user provided wildlife sightings in the area combined with behavioral information can help keep hikers aware of the existing and potential risks and enable them to make proper decisions and plans to mitigate wildlife interactions on the trail. 1.1.3. Trail Conditions and Management The intent of this database and application is to enable users to experience Alaskan trails with a decreased fear of unknown trail conditions by increasing available information. Creating a more robust set of information can lead to heavier trail use which can then beneficially contribute to community and public health. However, the increase in traffic does create a concern for trail degradation if not properly monitored and managed. Olafsdottir and Runnstrom (2013) compared the impact of tourism population against vegetation status along hiking trails and public areas, finding a strong correlation of decreased vegetation with increased traffic. Further research has found that these risks from increased trail traffic can be mitigated through user education and awareness. 8 The hiking community can play an important role in trail degradation or trail conservation based on their level of knowledge and awareness of the built trail environment and its intended structure. Wimpey and Marion (2011) studied hiking trails within Great Falls Park, VA to learn what was motivating the creation of informal trails branching off of main trails. Their research indicated several reasons for users to veer off track including continuing once a trail ends, shortcuts, and losing the trail by accident. The authors discuss how lack of information and knowledge of trail systems leads to the creation of informal trails resulting in a degradation of the surrounding environment. By implementing more proactive management methods directed toward user knowledge, managing entities may be able to provide a mode of protection to trail degradation. This project, and other similar projects, that work to increase the access to accurate spatial knowledge for trail users can act as a tool for user driven trail and environmental protection efforts. Knowledge provided by mapping applications trail websites can also help users be aware of natural resource concerns being faced in certain areas. In a study of hikers and frequent trail users within Denali National Park, Lawson and Manning (2002) found that if a natural area provides a greater utility to the users, such as good hiking trails or berry picking, the users are willing to relinquish some access in order to prevent deterioration of the resource. This implies that it tends to be merely the users’ lack of knowledge and awareness of local issues that allows for degradation to continue to occur. Providing greater knowledge of areas available or off-limits in an easily accessible manner could lead to a net benefit to environmental remediation (Meijles, de Bakker and Groote 2014). In addition to a tool for trail users, communities with large areas of managed trail systems can use applications like this to make informed planning and development decisions when 9 indicators of user movement through the recreation area can be modeled. Kienast, Degenhardt and Weilenmann’s (2012) studied VGI of various Swiss town resident’s preferred outdoor activities and locations compared to the objective characteristics of the area. From this data, a model was developed for mapping landscape suitability for recreation based on thirteen landscape predictors that were significantly correlated with people’s occurrence. Evaluating how users travel within a trail system or where unofficial new trails may be occurring can allow for trail managers to make determinations on what areas contain a special interest, and where users are willing to go based on landscape and accessibility. An application that allows for users to provide information on missing landmarks or new features can also provide a tool for maintenance crews to address trail issues and trail programs to make informed management decisions. 1.1.4. Public Health Applications that enhance available knowledge of trails not only allow for an increase in conservation, but also provide an increase in public health. Vries, Verheij, Groenewegen, and Spreeuwenberg (2003) found in a study of self-reported health against land-use data, that people in greener environments and who have more interaction with “greenspace”, experience better perceived general health and trend towards better mental health. Neunhauserer et al. (2013) studied the impact of hiking on suicidal psychiatric patients and found that this activity showed promise in allowing patients to be active without causing a detrimental impact on their mental health. Previous studies had shown certain physical activities to lead to increased markers for suicidality in high-risk patients, but patients hiking in this study showed either no change or improvement in these markers. In a literature review of studies that compared health measures to public parks and trails, Schultz et al. (2016) found that the availability and proximity of parks 10 and trails are associated with a greater level of physical activity. This increase in physical activity can lead to lower rates of cardiovascular disease, obesity, and type 2 diabetes mellitus among other health issues. Enabling residents to become more active by providing easily accessible and comprehensive trail information can contribute to active, healthy communities. 1.1.5. Tourism Economic Contribution This application will not only be directed towards residents, but to the numerous tourists who visit Alaska to experience the great outdoors in a safe and positive manner. White et al. (2014) states that on federal lands, hiking is the most popular backcountry activity with 33 percent adult participation compared to other options in the subset of “challenge activities”. These challenge activities are often associated with young and affluent adults, and participation is projected to increase. These activities provide communities with economic benefits through local business stimulation by visitor spending, increased property values, and new business attraction to the community. This attraction for tourist spending also leads to job creation and employment opportunities within the surrounding communities. While Alaska is well known for an economy and employment market based on the oil and mining industry, recreation and tourism has managed to maintain stable employment and expectations of growth despite a state-wide recession (Saupe 2019). Hjerpe’s (2018) study of economic impact of the wilderness in northeastern Minnesota found that the stable growth of the recreation industry and its constant demand for intensive physical labor leads to a more stable local economic market than surrounding resource development. Jobs provided by nearby resource development are often known to disappear with technological advances, but in outdoor activities these advances rarely decrease the workload and job opportunities. Alaska’s physical character leaves no shortage for 11 recreational opportunities in outdoor tourism. To ensure that this economy continues to flourish, it is important that users have the proper tools to plan for the unique challenges they may face in the Alaskan wilderness. 1.2. Project Framework A valuable resource for information for resident and tourist hikers is the AHS website. The AHS website provides detailed information on trails across Alaska along with descriptions of difficulty and what users may encounter at any moment on these trails. The AHS website was started by Bill “Chugachman” in the early 2000s after an identification of lack of trail information in Alaska. The website was designed as a supplement to the guidebooks Bill had purchased as he prepared for his own experiences hiking (AHS 2020). It has since been handed over to another individual to maintain and update as users provide information and updates about trails. Conversations with the owner of this website identified the interest in advancing the trail map display and capabilities. The web mapping application developed within this project serves as a prototype to be embedded within this website. In January 2020 the AHS website moved from the previous text-based search engine into an embedded Mapbox application. This application displays the approximate trailhead locations for trails across the state. These points were manually placed and connected to the trail information pages for trails related to the trailhead. The objective of this project was to develop a compiled database of trail lines and trail features to cover the catalog of trails provided within the AHS website. The database of trails would then be included in a web mapping application designed to display and search the trails and trailheads to advance the existing mapping application within the website. Within the application, users will be able to search for trails by name, location, or difficulty. Functionality for filtering and querying trails across the state will be 12 available as well as identifying trailhead locations. Users who have experience with the trails, or have recently traveled them, will also be able to provide input for temporally relevant trail hazards through VGI. These trail hazards will be displayed on the map for other users to view in order to allow for proper caution and planning when exploring trails. To distinguish this application, Chapter 2 discusses what technology is already available to hikers and the important functionalities and data that are missing from other mapping applications. This chapter also discusses existing research surrounding concerns for VGI data quality and its utility for hike planning and trail management. Chapter 3 of this report will discuss in detail the methods design for creating this application. ArcMap was the platform used to collect and analyze data from organizations, agencies, and other applications in the state, as well as to publish services. ArcGIS Server, ArcGIS Online and Microsoft SQL Server are used to manage the back-end services. The web application was designed within hypertext markup language (HTML) and the ArcGIS Application Programming Interface (API) for JavaScript 4.14. Within the application users can edit feature classes based on trail features and hazards by placing points and providing a detailed location and description for the feature. Users can also view the application on a mobile device or print maps for reference on the trail. This application then underwent a round of user testing in order to identify issues with functionality or where intent and purpose may not have been clear. In Chapter 5, future development of the application and its movement into the AHS website is discussed. 13 Chapter 2 Related Work This chapter will explore research on VGI and existing trail mapping applications that lay the foundation for the work performed in this project. Section 2.1 reviews the existing applications available for hiking trails and the gaps that still exist among them. Section 2.2 reviews the implementation of VGI in crowdsourcing and its accuracy. Section 2.3 explores features of successful web applications and trail planning tools. 2.1. Web and Mobile Trail Applications Hikers in the state of Alaska can find it difficult to plan a hike to an unfamiliar area without spending considerable time researching conditions and characteristics of a trail. Failure to do the necessary research on a trail may open the user to risks of being unprepared for unexpected conditions. Up to date and reliable information can be difficult to find, or non- existent for hiking trails. Many existing web and mobile applications are built by a national company located out of state that does little to ensure the continued accuracy of the information. Local managing authorities, such as state or boroughs, are constrained by budgets and often struggle to manage updating the trails data they provide. Hikers are left to develop an image of the trail experience by spending a considerable amount of time combining information from authoritative sources, mobile/web applications, and social media. Available applications with general information and line data for hiking trails in Alaska exist, the limitation is that a hiking experience is more than a line feature. These existing applications do not convey what types of available infrastructure or hazards a hiker may encounter. Trails are more than a pathway as they all have some combination of natural and man-made features that are present such as a parking areas, trailheads, campsites, signs, turns, 14 landmarks, summits, and water crossings. Unpredictable features that can change from day to day are closures, wildlife encounters, trail degradation, and missing landmarks. Lack of awareness of these features can greatly impact the user experience. Research across existing data and applications shows that data on these types of features is a critical missing component. These missing components comprise information that hikers should have at their disposal to make the most informed decisions. Table 1 provides a list of selected applications that are the best available for meeting the needs of the Alaskan hiker. Table 1. Selected applications Name Platform Coverage Area VGI Capabilities Description of Spatial Data shown on map Alaska Hike Search Web Alaska Users can submit information on trails Trailhead locations AllTrails Web and Mobile Nationwide Users can track their route as they hike, submit trail info, and reviews Line features of trails and Start/Stop Points are displayed. Gaia Mobile and Web Worldwide Users can submit updates to trails Line features of trails, Parking, Peaks. REI Hiking Project Web and Mobile Nationwide Users can submit trails, descriptions, and other information Line features trails Trail Forks Mobile and Web Worldwide Users can submit trail reports and descriptions Line features of trails TrailMapper Web Alaska Users can submit trails and descriptions Trail lines The best place to research Alaskan hiking trails for in-depth information, is on the AHS website due to its extensive information of trail experiences from local hikers and breakdown of what a hiker can expect to encounter. In January of 2020 the AHS website implemented a landing page map that displays trailhead point locations for trails described within the website 15 (Figure 3). Clicking on these point locations provides links to trail description webpages related to the named trailhead. These trailhead locations were manually placed from personal experience and trail descriptions by the owner of the AHS website. The other option for searching trails is by trail name in the manual text “Search” page. The AHS trail description webpages contain information including length of trail, intensity of trail, elevation gain, photos, and comments from those who have completed the trail and provide trail updates. AHS presents itself as being, potentially, the best place for information for Alaska hikers due to its in-depth descriptions of trails that have been compiled over the years from local Alaskans familiar with the trails. Figure 3. Alaska Hike Search landing page and trailhead pop-up 16 A quick online search can provide a user with multiple available hiking trails mapping application platforms, all which have some contributing benefit, but seem to fall short in some aspect or another for trail information or available data. AllTrails (www.alltrails.com) contains the most extensive collection of trail line data for Alaska hiking trails. While it has a comprehensive listing of trails, most information provided for these trails is lacking, or nonexistent. Another issue with the data provided is that it can be difficult to discern the location of a trailhead and where a trail begins. The trails data provides start/stop points, but these points do not always correlate with an accurate location for the trailhead and parking area. Descriptions provided are automated from selections users make when submitting a trail which can leave it feeling questionable as to the reliability of the information. The review systems with recent local users’ information in the trail descriptions can sometimes provide helpful information, but this forces the user to dig through what is sometimes thousands of entries and create their own interpretation of the trail. An additional concern is the lack of a standardized, well-defined, scale of “difficulty” for trails. Without defining how difficulty is determined, hikers can be misled when trying to determine a hike that fits their physical capabilities. The Hiking Project database and application from REI (www.hikingproject.com) does seem promising, but as of September 2019, large regions of the state are missing trails data. One benefit of this web application is that the forms provided to users to submit trail descriptions allow for the user to be descriptive and provide in-depth information on their experience. Reviews of a few popular local trails proved to have very thorough contributions of trail descriptions. It was unclear if the descriptions are reviewed by REI staff for approval before they are posted. 17 Gaia is another trail mapping application (https://www.gaiagps.com/) with a similar site format and mapping application as the AllTrails website. A review of user contributions leaves the impression that this application is not as popular as other mobile/web applications in Alaska as attribute information for many trails was incomplete. This application appears to have a very comprehensive set of trail lines data, but many are just labeled as “Unnamed Trail” and the descriptions are empty. Some trails shown on the map were unfamiliar and seemed questionable as to the accuracy. Further research on the site was unable to uncover any information as to where their line data is sourced. TrailForks provides trails data in Alaska and contains a VGI component for trail status updates (https://www.trailforks.com/). This site has a mobile application where users can provide trail reports and has become popular among users during winter activities such as fat tire biking and cross-country skiing. While the trail updates function has become popular within Anchorage, the user base seems to consist mostly of winter trail users. The lack of a year-round user base across the state, along with many trails missing descriptions makes this application hard to promote as a reliable tool for hikers. TrailMapper (http://www.trailmapper.org/) is a local Alaskan developed application that provides collected trails data and allows for users to update the database with their own line data. This application provides users with trails data that contains in-depth descriptions and elevation profiles. Users with a registered profile can submit line data and trail descriptions for missing trails on the map. Research of existing and submitted trails within the application show that the user base seems to be centered around Fairbanks, as trails data seems to disappear as the map moves further south and away from the area. 18 Another valuable tool in the Alaskan hiker’s toolbox is the library of books documenting hiking trails and their characteristics within the state. Books such as “Hiking Alaska” (Foster 2017) can provide incredibly valuable and in-depth information for planning and preparation of what to expect on trails across Alaska. While these books are still valuable for any hiker in Alaska, it can be difficult to search through a paper copy to find relevant information, and most of these books available do not have an electronic edition. Books can also quickly become obsolete and inaccurate, thus potentially leading a reader to a trail that could be degraded or unsafe. The cost of purchasing many of these books can be expensive, especially as many continue to publish updated editions. 2.1.1. Difficulty Ratings Many of the existing hiking trail applications are inconsistent in their classifications of difficulty. A trail in Alaska can range from a flat paved trail through Anchorage, to climbing a peak that requires climbing gear and harnesses. As discussed in Section 1.1.1, the terrain and difficulty of many trails in Alaska do not compare to those that users may be familiar within the Lower 48 (NPS 2019-a). These differences make it difficult to accept a nationwide difficulty rating system that is uniformly applied across all trails in the country. In addition to the range of intensity of trails in Alaska is the inherent subjectivity of many difficulty rating systems. Hugo (1999) notes that the perceived difficulty of a trail can depend on a complex result of a number of interdependent variables such as weight of the pack a hiker is carrying, elevation differences throughout the trail, height above sea level, fitness of the hiker, and even the emotional state of the hiker. All of these factors along with many other variables of the physical condition of the trail can make it nearly impossible to determine a difficulty ranking that will uniformly cover every hikers experience on the trail. Many of the previously mentioned 19 applications, such as AllTrails, have a difficulty based purely on the input of the user who adds the trail to the database. The one user’s experience could be very different from other hikers on the trail and lead a trail to be wrongly classified when other users are filtering trails to match their capabilities. It was important in this project to select a difficulty rating system that is well defined, objective, and simple enough to be computed from an elevation analysis of the trail line against a digital elevation model (DEM). Multiple models and equations are available for estimating and rating hiking trails based on distance and elevation. Two popular methods of estimating time for completion of a hike were developed by William W. Naismith and Waldo Tobler. Naismith developed a simple theory in 1892 that has held steady throughout the years for estimating time for cross-country walks, stating “…men in fair condition should allow for easy expeditions, namely, an hour for every three miles on the map, with an additional hour for every 2000 feet of ascent.” Alternatively, Tobler’s theory incorporates a variable for the slope of the trail as well as a factor of 0.6 when walking off-road. Tobler’s equation gives walking velocity, W (m/s), approximated by: 𝑊 = 1.67𝑒 −3.5|𝑆 + .05| , where 𝑆 = ∆𝑒𝑙𝑒𝑣𝑎𝑡𝑖𝑜𝑛 ∆𝑑𝑖 𝑠𝑡𝑎𝑛𝑐𝑒 and is commonly used in GIS calculations of walking, specifically in the QGIS software’s walking time function. Both Tobler and Naismith account for movement across space with factors to adjust the pace based on the trail slope and distance (Irmischer and Clarke 2018). Another commonly cited formula when discussing hiking trail difficulty is the “energy mile” theory developed by Paul Petzoldt (1976). Petzoldt’s theory states that one “energy mile” is equal to the energy required to walk one mile on flat terrain. This theory adds that for every 1000 feet of elevation gain, two “energy miles” should be added. So, if a hiker were to travel one 20 mile while climbing 1000 feet, that hiker would have used the equivalent of three “energy miles”. This theory of describing a trail by the energy needed rather than time as suggested by Naismith, can allows hikers to understand the exertion needed to complete a section of trail. This theory was reinforced by Troy and Phipps (2010) through a study measuring energy cost and perceived exertion of subjects on a flat surface compared to the energy cost of climbing 1000 feet over the same distance. Energy costs ranged from an additional 1.34 to 2.02 “energy mile” equivalents for 1000 feet gain, closely aligning with Petzoldt’s estimate of 2 additional “energy mile” equivalents. While this theory holds merit and could be a beneficial addition to further iterations of an application, it could potentially be too complicated for users to understand and still provides some concerns as to the subjectivity of the rating based on the user’s fitness level. The Shenandoah National Park in Virginia relies on a different equation that more closely resembles the methods used by Tobler and Naismith. The equation calculates a difficulty score determined by: √(𝑒𝑙𝑒𝑣𝑎𝑡𝑖𝑜𝑛 𝑔𝑎𝑖𝑛 (𝑓𝑡 ) 𝑥 2 𝑥 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 (𝑚𝑖 )). The numerical score then correlates to a ranking of defined difficulty of “Easiest” (less than 50), “Moderate” (50-100), “Moderately Strenuous” (100-150), “Strenuous” (150-200), or “Very Strenuous” (greater than 200). These scores and rankings also have an associated average pace ranging from 1.5 mph for “Easiest” to 1.2 mph for “Strenuous” and “Very Strenuous” (NPS 2017). While Tobler, Naismith, and Petzoldt’s all provide equations that have held as strong standards for ranking hiking trails, the Shenandoah Hiking Difficulty equation was ultimately selected for this project. It was important to be able to provide users with a website link resource to understand how the difficulty was calculated, to provide a defined ranking system that discerns an easier trail from a more difficult trail, and also provides an average pace rank. The 21 webpage for the Shenandoah National Park Hiking Difficulty equation is provided by the NPS, a familiar organization amongst trail users. These factors led to the selection of this system over the other options for ranking hiking difficulty. 2.1.2. Idaho Trails A web application that is outside of the Alaska coverage, but provides a framework reference for design, is the trail map site for the State of Idaho shown in Figure 4, developed on the Esri ArcGIS Online Web AppBuilder framework. This map contains trails for motorized and non-motorized users and, while the feature information on trails is not extensive, it does provide links for the managing authority allowing a user to investigate further. Another important feature for hikers included within this application are layers of Active Fires and their emergency closures from the United States Forest Service (USFS). While the display and function of the website could be improved, the information available has provided valuable insight regarding external information that is crucial for local hikers. Alaska’s active fires during the drier times of the summer can occur across many popular hiking trails and conditions can change quickly. Ensuring hikers are aware of any active fires within their planned trail proximity could be a very valuable tool for planning a safe hike. This application also contains a “Crowdsource” function for user-submitted trail updates. Clicking on this tab within the map directs users to another application that allows for users to provide photos and information on trail conditions. There is great potential for this to be a valuable component within their site, but it does not appear to have much active user input. While reviewing the available submitted trail updates, it was unclear as to whether the information is recent as submission dates were not provided. 22 Figure 4. Idaho Trails mapping application 2.2. VGI As seen in the Idaho Trails app, it can be valuable to crowdsource changing trail conditions through VGI for trail users to properly plan routes and bring necessary gear for expected conditions. VGI is described by Goodchild (2007) as the creation of geographic information by private citizens with little formal qualification or experience in the field. A well- known example of this phenomenon is Wikimapia, which has built upon the concept of Wikipedia to develop a mapping system of user provided data points and information. This section explores concerns and research of VGI’s accuracy, and the different roles it can or has played in outdoor recreation. 2.2.1. VGI Quality The use of VGI is a promising addition to this project to keep users notified of recent changes or hazardous conditions, but due to the nature of VGI coming from potentially inexperienced sources, concerns of quality of information can arise. As VGI has become a more 23 prevalent source of data among the geographic information system (GIS) industry, many studies have tried to understand the accuracy of this data and whether this wealth of data is valuable, or whether the ability for inexperienced users to provide potentially inaccurate information skews the quality of data to an extent that it becomes irrelevant. There are six general components for evaluating data quality and accuracy as defined by the International Organization for Standardization (ISO) 19157 (ISO 2013) standard that are often applied to the evaluation of VGI data quality. The components of quality defined by this standard are completeness, logical consistency, positional accuracy, temporal accuracy, thematic accuracy, and usability (Antoniou and Skopeliti 2015). Completeness is defined by the ISO standards as “the presence and absence of features, their attributes and relationships” (ISO 2013, sec. 7.3.2). This definition of completeness can not only include a lack of data provided, but also an overabundance of data or information. The logical consistency component is a measure of how well the data adheres to the logical rules of thematically similar data. These consistencies are measured across conceptual, domain, format, and topological consistency of the data sets and schemas (ISO 2013, sec. 7.3.3). Positional Accuracy as defined by the ISO (2013, sec. 7.3.4) is a measure of the data’s accuracy of position within a spatial reference system and measures absolute or external accuracy, relative or internal accuracy, and gridded data positional accuracy. The thematic accuracy of data is a measure of “the accuracy of quantitative attributes and the correctness of non-quantitative attributes and of the classifications of features and their relationships. The elements that comprise this measure of accuracy are classification correctness, non-quantitative attribute correctness, and quantitative attribute accuracy (ISO 2013, 7.3.5). The assessment of temporal quality involves the evaluation of the temporal quality of the attributes and the relationship of temporal attributes of other features. This quality is measured by the 24 accuracy of a time measurement, the temporal consistency, and the temporal validity (ISO 2013, sec. 7.3.6). The final measure of data quality is the usability element of the dataset. This element of usability is defined by user requirements and can be applied to all of the previously mentioned quality elements. This assessment is based purely on the suitability of the data to a particular application or the ability of the data to conform to a specific set of predetermined quality requirements. While studies continue to research the validity of VGI data amongst these components, a belief held by some is that across all of these measures, the more users that contribute, the more the data will converge on the truth, commonly attributed as Linus’ Law from research in debugging program code. Goodchild (2012) discusses that in the realm of VGI this theory also applies, and as user contributions increase the accuracy of the data also increases. This theory was evaluated by Haklay, Basiouka, Antoniou, and Ather (2010) through a literature review and found that while this theory does seem to hold merit for VGI positional accuracy, the relationship is not linear. They posit that while having beyond 15 contributors per square kilometer increases accuracy, the first five contributors appear to provide the highest positional accuracy. Haklay (2009) discusses how this belief raises concerns for certain areas within the Open Street Map (OSM) platform that are not covered by as many users and how it leaves large gaps in data’s positional accuracy, thematic accuracy, and completeness. This has the potential of being a relatively common issue within this project’s VGI data, as many trails occur in remote areas and may not see the frequency of traffic that trails closer to populated areas, like Anchorage, will see. Opening an application to the public does come with hazards when the validity of contributed data is difficult to verify. One perspective of identifying indicators to data quality is by understanding the users contributing. Haklay (2009) discusses this within his research of users 25 in OpenStreetMap and identified that the type of user and their reputation within the application has a strong correlation with the quality of the data. This may provide a consideration for this application development for giving higher weight to certain users and developing a system for evaluating reputation. Those who contribute more frequently and with high quality data may be given more trust for input than an unknown user who may be inputting data with nefarious intent. Other research has expanded on the concept of user reputation in addition to how and when features are edited to estimate quality of data. Antonio, Fogliaroni, and Kauppinen (2014) propose a formula that calculates a features “trustworthiness” based on its versions, or modifications. This calculation accounts for: the similarity of the modification to the previous version; indirect effects, such as, if a user is contributing a large amount of nearby local knowledge improving the fitness level of the version; and temporal accuracy elements, assuming that the longer a feature goes without modification the more trustworthy the feature version is in relation to the actual feature. Their final calculation incorporates a factor for the user’s reputation to determine an overall proxy value for data quality. Brown’s (2017) research of sampling effects and response bias in VGI data found that sampling design was shown to play a role in the mapping effort, and therefore data quality, of contributing users. When the sampling group was targeted at users whose livelihoods were closely related to the purpose of the study, an increased mapping effort was displayed which can be attributed to the participant motivation and familiarity with the study area. Studies such as these focus less on the comparison of the contributed features to their real-world counterpart and focus more on the “who” and “how” these features are created and modified to determine the reliability of VGI. Research such as this will play an important part in quality control of the VGI 26 features as monitoring versions may become a consideration to understand how features may be changing and whether they seem to be converging on true positional accuracy. Socio-economic and demographic factors have also been shown to play a role in the quality of VGI data contributed. The role of the digital divide and access to technologies often show a disparity in the contribution of data from users in areas of lower education and income. McLafferty, Schneider, and Abelt (2020) studied the VGI quality and demographic bias of data based on bed bug reports from New York’s “311” system. The research displayed a strong geographic variation in credibility of reports, with negative reports (reports of bed bugs) generated more frequently from high-income neighborhoods with a predominate white population. Hiking in Alaska is an inexpensive activity available to all demographics, and information on hazards is important and relevant to all users regardless of socio-economic status. Finding ways to provide this information that overcomes the digital divide and concerns of access will be a consideration for future work to market this application. While all components of data quality will play a role in the consideration of accuracy within the VGI hazard data, temporal and completeness have potentially more relevant factors in this dataset. Since wildlife activity submissions are recording a highly mobile dynamic feature, the temporal accuracy of these features is generally short lived. Within days these animals could migrate from the hiking trail area and no longer be a concern for other trail users. Assessing the temporal accuracy of this dataset will play a role in the planned maintenance of this application and data as discussed in Chapter 5. Completeness also has high relevance as many trails are located in far more remote regions of Alaska and may see far less visitors and therefore less submissions of trail hazards. This lack of data does not indicate the lack of trail hazards in these regions but obtaining data is a difficult obstacle to overcome in data quality when the higher 27 population density of hikers is not available. Warnings as to the risks of using the data in this application will be a method of cautioning the user from making assumptions as to lack of data completeness equating to lack of hazards. VGI accuracy for hiking can be crucial when it plays a role in determining the type of gear and routes that are planned. This accuracy can also play an important role in navigation while on trail if hikers encounter unexpected obstacles, miss poorly marked turns, or are unable to identify important landmark features. 2.2.2. VGI for Planning The planning phase of a hike is a vital part of a successful and safe trip in the outdoors of Alaska. When a user can infer dynamic trail conditions from VGI and combine that with their own personal knowledge of the area and trail, a clearer picture of the hike can be developed and a stronger plan for a safe trip can be made. Parker, May, and Mitchell (2013) show in a study of experienced river guides planning trips, that the use of VGI can have a greater impact on the planning portion of activities than the professionally collected data available. The information that the VGI provided to the river guides in the study became a more valuable tool due to the ability of the guides to make inferences on the data from volunteer sources combined with their personal experience. This allowed them to gain a clearer picture of the environment as they were planning their trips. This research found that the use of professionally obtained GIS data alongside VGI provides the clearest picture of an unfamiliar environment allowing the users to have the most clarity of judgement in their decisions. 2.2.3. VGI for Trail Management VGI can also provide a useful tool for trail and park managers to assess where unauthorized trails and activities are occurring to allow for proper management decisions. Korpilo, Virtanen, and Saukkonen (2018) studied the use of VGI by trail managers and 28 discovered that by researching how trails are being used through VGI data, trail managers can work to anticipate user needs and expectations. Pickering, Castley, Hill, and Newsome (2010) collected and analyzed Global Positioning System (GPS) locations and descriptive information of unauthorized features, such as ramps, developed by trail users on mountain bikes within an endangered forest in the Gold Coast of Australia. Their analysis was able to locate 116 unauthorized features and assess the amount of degradation and disruption to the natural ecosystem that this had created. While this study performed an analysis by employing paid workers to perform “boots on the ground” inspections and research, it provides an example of where VGI could potentially provide a system for park managers to be made aware of unauthorized activities developing earlier than through typical word-of-mouth channels. These free resources of data can provide trail managers a way to keep up with functional trail management as budgets tighten and resources to keep data current become unavailable. Bil, Bilova, and Kubecek (2012) noted that as population increases and the existing trails experience more stress from use causing development of new trails and new attractions, it is hard for managing authorities to keep the data up to date. This is where VGI can provide a valuable tool, to show where new areas may be developing, and not only where development is happening, but maybe due to degradation of the trail or the surroundings, where trail abandonment may be occurring by assessing for lack of VGI data. As Santos, Mendes, and Vasco (2016) concluded within their research of trail use by VGI, this data can help trail managers to design proper infrastructure for outdoor activities by analyzing how their existing system is being used within or outside of its intended design. 29 2.3. Web Application Development The final goal of this project is to deliver the tools and functionalities within a web mapping application. This section discusses traits of successful web applications and the value they provide to users who would like to discover a hike that meets their interest and skills. 2.3.1. UX Design The user experience (UX) design describes the experience a user has when interacting with an application based on the products look, feel, and usability (Interaction Design Foundation 2020) and can often be the driving factor in success or failure of an application. The goal for a UX designer is to ensure the user can successfully interact with the product and that they find value within the application. UX design was an important consideration in this application as it was believed that the user base could potentially contain a wide range of age, hiking experience, and technological skill and therefore, the application would need to serve a user within any combination of these groups. Because this application is directing people to explore potentially unsafe areas and directed to users of all ages and technological capabilities, it was important that the information provided is clear and concise. Belanche, Casalo, and Guinaliu (2012) state that functionality and intuitive design drives consumer satisfaction and plays into decision making as to whether users return to the website. Since implications of larger numbers of users suggests higher quality of VGI data (Goodchild and Li 2012) it was important that this web application met user needs in a way that encourages repeated use and contribution. Belanche, Casalo, and Guinaliu conclude that a website that is simpler to use will be more effective than a highly sophisticated site. Due to trails attracting a variety of users of different education and backgrounds, it was important to 30 ensure this website was intuitive to the widest range of users. Therefore, function and simplicity were the emphasis for design in this project. The web application design within this project is targeted at a wide range of users of differing technical skill levels, so it is necessary to ensure that all users are able to understand the website. Newman et. al (2010) evaluated a web-mapping application for citizen scientists and determined a set of guidelines for a successful VGI system. Of the guidelines developed, an important aspect to be implemented within this project was the need to clearly communicate the intent and purpose of the website. This ensures the data provided by users is meeting the goals and objectives of the mapping application. Clear communication is also necessary to ensure that users who are less technologically savvy can easily manipulate the application and understand the features. Gottwald, Laatikainen, and Kytta (2016) found among surveys of an older population, explanation boxes and video tutorials were important to help users understand the functions provided. This study also suggested that route mapping or sketching tools should be avoided for users who are less GIS-savvy. There is evidence that GIS designers of web mapping applications may encounter issues with terms that are heavily engrained within the GIS language, but are unfamiliar to users with little GIS experience. Getto and Moore (2017) observed these types of disparities within their study of the UX design of an Atlas mapping application to identify areas for improvement. Terms like “data layers” and “basemaps” and their related icons can be mundane, everyday terms for a GIS professional, but can be an obstacle for users with low GIS expertise. This experience of users of the Atlas indicated that GIS expertise was often a defining factor in the perceived benefit of the UX, and for those with little GIS experience, a barrier to a positive experience. These user skills will be evaluated within the pre-development user survey to understand the skill 31 level and experience of those using the applications. Results will drive whether the more typical GIS icons and language will need to be removed and replaced with general language and terms as well as the extent of instructions for tool use to be required. 2.3.2. Application Platform Selection Several mapping platforms were considered for the development of this application before the ArcGIS API for JavaScript was eventually selected. ArcGIS Web AppBuilder, Mapbox, and the Google Maps API were the other popular platforms considered that provide tools for custom development of web mapping applications. Table 2 displays the applications considered and their limitations. While the pricing structures of these platforms would not pose an issue for the initial development and testing of this application, the future direction of design for this application was kept in consideration for final selection. The ArcGIS Web AppBuilder was tested for a preliminary run of this application but was determined to not provide enough customization for the desired final product of this project. Ultimately, the ArcGIS API for JavaScript was selected for its VGI tool capabilities, pricing structure, out-of-the-box tools and widgets, and functionality with ArcGIS Server representational state transfer (REST) services and the ArcGIS Online platform. 32 Table 2: Mapping application platforms comparison Free Capabilities Limitations ArcGIS API for JavaScript Free to use and design. Limited number of users to manage data. Some limitations encountered from the built in API tools. ArcGIS Web AppBuilder Free to use and design. Limited number of users to manage data. Limitations to customization of the interface. Mapbox Views based: 50k views per month More advanced development environment. Google Maps API Views based: 1k views per month Limited tools and functionalities. 2.3.3. Trail Selection and Planning This web application was designed with the intent of enabling resident or visiting hikers to plan their trip based on their location, skill, and desired trail features. Dye and Shaw (2007) explore a framework for design of a spatial decision support system for users in the Great Smoky Mountains National Park. Their design was for an application for tourists that allowed the user to define the features they were most interested in exploring and then assign a value indicating level of interest, to design an output of trails and features that matched the user’s desires. The authors’ application has not seemed to advance past the application development phase or have been implemented into any sort of online application available to the public but provides a design framework for advanced search tools for trail selection and what features users may value. Aside from facilitating proper planning for hikers, this project also aims to help users discover new hikes and expand their trail experiences. Chhetri and Arrowsmith (2008) attempted to determine new areas of recreational attraction based on what is considered high points of interest for beauty within the natural surroundings. Ranking of slope, features of the topography, and existence of water features all totaled to a score that pointed to areas of higher potential 33 interest. While this is beyond the current research in this project, its implications for planning could be of great use for designing the trail selection tool or future implementation in a “featured/suggested trails” analysis. 34 Chapter 3 Methods This thesis was designed to provide hikers with an additional tool for planning successful trips along Alaska’s trails through a web-map application built on the ArcGIS JavaScript API. This chapter documents the methods used for acquiring data and application development through these subsections: (1) Intended users and scope; (2) Data acquisition; (3) Geodatabase creation and design; (4) Web application design; (5) UX Design; and (6) User Testing. 3.1. Intended Users and Scope This application was designed to assist all trail users of any experience level in Alaska. While the focus of the data and trail style is geared towards hikers, this application can also be used by Nordic skiers in the winter season and bikers year-round. Familiarity with the trails is beneficial but not necessary as this project’s combined work with AHS aims to educate users to obstacles and unique challenges that the Alaska hiking experience presents. Through VGI provided updates on trail conditions and hazards and detailed information as to the expected length and intensity of a trail; this Web GIS application provides residents and out-of-state visitors with the information necessary to plan a successful hiking trip. To establish an understanding of the types of users that this application would serve, a pre-development user survey was sent to a group of 28 people. This survey was developed within Google Forms and users were able to provide names or submit anonymously. Eleven responses were received. Questions in the survey asked about: users hiking experience in various regions of Alaska, experience with other hiking applications, limitations they have experienced with other applications, and their likelihood of using an application that is mainly web based. The responses to these questions would lead to an understanding of the archetypes and personas of the users of this application. Details on the questions and results of the survey can be viewed in Appendix B. 35 The responses to the question concerning trail experience (Figure 5) were a driving factor for design of the database and application as this displayed the importance of what kind of trail data would be most valuable to the hikers. A beginner hiker may have very different interest in the data and information provided due to an introductory knowledge of trail characteristics and hiking experiences. They may be purely interested in the ability to find trails that are classified as “Easy” and whether there are any hazards they should be aware of. This would elevate the importance of making this information obvious and easy to understand. On the other hand, an experienced hiker may be looking for more information on the physical characteristics of the trail such as elevation, slopes, and distances for planning intense multi-day hikes. Figure 5. User trail experience responses Another valuable question in the pre-development user survey for UX design was the user’s technological skill. Responses can be seen in Figure 6. The responses to this question indicated a user base with an intermediate to advanced range of skill towards technology, with no users indicating a “Beginner User”. This understanding of skills of the users would drive the level of tool instruction provided within the application on the initial load. 36 Figure 6. User technological skill responses Additional questions in this survey were directed towards the user’s experience with other mapping applications. Users were asked as to which applications they were familiar with, how often they use them, what features they think are most valuable, and what features they would like to see that are not currently available in other applications. The responses for valuable features that are available or missing would help determine the tools and functions of this application to focus on implementing and ensure are fully functional. 3.2. Data Acquisition and Management In order to create a comprehensive database of trails for the application, trail point, line, and polygon data was collected from federal, state, and local government agencies. These agencies included the State of Alaska Department of Natural Resources (DNR), the National Park Service (NPS), the USFS, the US Fish and Wildlife Service (USFWS), and the Municipality of Anchorage (MOA). If an area did not have publicly available trail line data from a local governing agency, or did not respond to a request, the data was then collected from AllTrails. 37 3.2.1. State of Alaska The DNR hosts all publicly available geospatial data through the Alaska State Geospatial Data Clearinghouse. This data can be downloaded by making a request on the webpage by providing an email address, where a zipped shapefile of the data is then sent. Data collected from this site included trail lines, trail point features, and Alaska State Park polygon boundaries. All shapefiles are projected in NAD83 Alaska Albers Equal Area Conical. 3.2.2. National Park Service The NPS provides access to their GIS data from their “Tools and Data” (NPS 2019b) resource page. This webpage points to various GIS informational pages such as the NPS Story Map Gallery, a public REST services directory for ArcGIS Server web services, and their Common Spatial Data Standards. Several resources on this site also provide access to data for download such as the Integrated Resource Management Applications Portal which hosts the NPS Data Store and contains a variety of geospatial and non-geospatial data. The park boundary data was obtained from the NPS Data Store as a zipped shapefile. Trail line data was obtained from the “National Park Service: Official Service-wide Datasets” page on the ArcGIS Online platform from the Tools and Data page. In order to access the trails data within the feature class, the feature layer was downloaded as an “ArcGIS Portal Item” and opened within ArcMap. In ArcMap, the Definition Query “REGIONCODE = ‘AKR’” was applied to the feature layer to narrow trails to just those that occur within Alaska, then exported to a new feature class. 3.2.3. US Forest Service The United States Department of Agriculture USFS agency provides spatial data through their “FSGeodata Clearinghouse” (U.S. Department of Agriculture Forest Service 2019). This 38 webpage provides a Data Extract Tool that connects the user to an Esri web application for downloading datasets based on forest service boundaries. Data was extracted by selecting from the only two National Forest Service boundaries in Alaska: Chugach National Forest and Tongass National Forest. The geospatial data downloaded from this web application included trails and forest service boundaries. The trail lines dataset includes information on conditions of the trail such as surface type as well as allowed uses (such as by ATV or snow machine) and their regulated time frames through the year. In order to narrow this line dataset to hiking and non-motorized trails, the following queries were applied: TRAIL_SURFACE <> 'SNOW' AND MOTORCYCLE_RESTRICTED = '01/01-12/31' AND ATV_RESTRICTED = '01/01-12/31' AND FOURWD_RESTRICTED = '01/01-12/31'. 3.2.4. US Fish and Wildlife Service The Department of the Interior’s USFWS manages trails across the country that occur within National Wildlife Refuges (NWR). Trails data from the USFWS was found on the “Data.gov” web portal through a trail keyword search. This search yielded a REST uniform resource locator (URL) for all trails in the US which was imported into ArcGIS Pro through the “Add Data from Path” function. These trail lines were then exported to a new feature class and clipped to a State of Alaska boundary feature. The NWR boundary data was retrieved from the “USFWS National GIS Data” page (USFWS 2019). By selecting the “USFWS National Cadastral Data” and “FWS Interest Shapefile”, a zipped shapefile of all USFWS boundary data was downloaded. This polygon data was then queried for “’RSL_TYPE’ = ‘NWR’” to obtain all NWR polygons, then clipped to the State of Alaska boundary. This dataset was highly segmented with a single NWR containing 39 multiple polygons, so a dissolve was performed on the ‘ORGNAME’ and ‘UNITNAME’ fields to simplify the final boundary data. 3.2.5. Municipality of Anchorage The MOA manages trails within their “Geographic Data and Information Center” ArcGIS Hub. From this webpage the “Parks and Recreation” map gallery contains a “Park and Facility Information” web mapping application which contains layers for trails, park boundaries, and trailheads. To use this data, layers were downloaded as a portal item and opened in ArcMap then exported to a new feature class. 3.2.6. Missing Trails After all trail lines from authoritative agencies and entities were compiled, a check of trails covered by the AHS website was necessary to ensure all trails described within the website had a corresponding spatial feature. An Excel spreadsheet of all 129 trails within the website was created and compared to the downloaded trail lines to assess which trails still needed a line feature. These 20 missing trails were then downloaded from the AllTrails website as a GPS data file saved in the GPS Exchange (GPX) format. The “GPX to Features (Conversion)” tool in ArcMap was then used to convert the GPX file to a point feature class. The point feature classes were then converted to line features through the “Points to Line (Data Management)” tool. The next section discusses how the downloaded data was compiled and prepared for consumption within the web application. 3.3. Geodatabase Design After all data was compiled from the managing entities discussed above, standard feature classes were created for trail lines, trail point features, and boundaries. The defined projected 40 coordinate system for this data was set to NAD83 Alaska Albers Equal Area Conic. This coordinate system was selected due to its use for statewide data by the State of Alaska DNR. Each downloaded dataset, aside from data from the DNR, required projection into the appropriate coordinate system before data was loaded into the corresponding feature class. The following subsections will describe how these datasets were then compiled and standardized. 3.3.1. Trail Lines Data Compilation Of the trail line datasets downloaded, no two had a matching schema to allow for a standardized attribute table within the master trail line feature class. After assessing the existing data for similar fields that occur throughout, the following fields were added (by Alias): Trail Name, Trail Type, Trailhead, Trail System, Park System, and Entity. Line data was then loaded into the feature class by the “Load Data” function and existing fields were matched where applicable. Once the downloaded data was loaded into the master trail line feature class, additional fields were created, attributes calculated, and further analysis for surface information was performed. The final list of fields of the master trail line feature class can be seen in Figure 7. The “Route Type” field is a description of the trail as “Out and Back” or “Loop” and was completed through visual analysis of each trail system. The “Length (mi)” field was completed through “Calculate Geometry” and specifying miles as the unit of measurement. The “AHS Link” was manually filled in with the URL to the AHS description page for the trail. The “Alternate Name” field was also completed manually when the AHS trail name differed from the official name provided by the downloaded data. All other fields regarding surface information and difficulty will be described in section 3.3.4 as to how they were calculated. 41 Figure 7. Master trail line feature class attribute fields 3.3.2. Trailheads and Trail Features In addition to the downloaded trail lines, trail feature points were also available from the State of Alaska DNR, USFWS, USFS, and the MOA. From these points, trailheads were queried and exported into separate feature classes. A master trailhead feature class was created with the attributes seen in Figure 8, where data was loaded, and fields were matched to existing fields or calculated based on the source of the data. Figure 8. Master trailhead feature class attribute fields 42 This compilation of trailhead data did not cover all trail lines and manual analysis for missing trailheads was necessary. Since the web application is focused only on AHS trails, the trail lines data was queried for all trail features with a completed “AHS Link” field. These trails were then inspected for trail lines that did not have a matching trailhead feature. Trailheads were then created for these missing locations based on imagery inspection for parking areas, trail intersections with road features, and street view photos of trailhead signs where applicable. In addition to the trailhead points, a feature class of trail features was created. The only organization that provided a compiled dataset of these features was the State of Alaska DNR. This data set was published as “trail features” and the original attribute fields and values were maintained as provided by the state. These fields can be seen in Figure 9. Figure 9. Trail features feature class attribute fields 3.3.3. Park Boundaries The final data to be compiled were the boundary features downloaded from the various managing entities. These features were combined into a master boundary feature class with the fields shown in Figure 10. These fields were completed based on matching existing fields from the downloaded data or calculated based on the source of the data the features were loaded from. 43 Figure 10. Master park boundaries attribute fields 3.3.4. Surface Information Analysis and Difficulty Ranking The final analysis of the trail lines involved calculating surface information and difficulty based on the change in elevation over distance. To determine elevation of the trail lines, the “Add Surface Information” tool was used. This tool requires a raster feature layer with z-values for elevation to tie to the line feature class as it crosses the surface. The surface used to calculate elevation and slope was the ArcticDEM Dynamic Image Service created by the Polar Geospatial Center at the University of Minnesota from the DigitalGlobe satellite imagery (Polar Geospatial Center et al. 2018). Output fields selected from the tool were: Z_MIN, Z_MAX, Z_MEAN, MIN_SLOPE, MAX_SLOPE, and AVG_SLOPE. Defaults were accepted for the optional parameters within the tool. The values created from this surface analysis were important features to calculate the difficulty of these trails. The output elevation fields from this tool were calculated in meters, so new fields were created for these elevations to be converted to feet. These fields were then calculated through the field calculation tool, multiplying the related elevation field in meters by 3.28. An elevation change field was also added and calculated based on a field calculation of the maximum elevation minus the minimum elevation of each trail. The “Difficulty Score” field was calculated based on the following equation: √(𝑒𝑙𝑒𝑣𝑎𝑡𝑖𝑜𝑛 𝑔𝑎𝑖𝑛 (𝑓𝑡 ) 𝑥 2 𝑥 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 (𝑚𝑖 )). 44 This score was then converted into a classification in the “Difficulty” field by selecting values within the ranges specified in Table 3 and field calculating the classification text. Table 3: Shenandoah National Park hiking difficulty rating system Classification Numerical Rating Average Pace Easiest Less than 50 1.5 mph Moderate 50-100 1.4 mph Moderately Strenuous 100-150 1.3 mph Strenuous 150-200 1.2 mph Very Strenuous Greater than 200 ≤1.2 mph Source: NPS 2017 3.3.5. VGI Hazards Feature Class In addition to the data collected for trail lines, points, and polygons, there was a need to design a feature class for containing the VGI data collected from users within the web application. Before a VGI feature class could be created, an enterprise geodatabase within a relational database management system must be created. This was accomplished by using the “Create Enterprise Geodatabase” tool in ArcMap and specifying SQL_Server as the database platform. This enterprise geodatabase was then registered with ArcGIS Server. With the enterprise geodatabase created and registered on the server, the VGI feature class could now be added and designed within. To maintain simplicity of the tool for users, the attribute fields of the feature class were narrowed down to a few fields for input. These fields are shown in the table in Figure 11. The “HazardType” field had a coded domain applied in order to provide a defined selection of hazard type when users add features within the application. The following coded values were defined within the domain: [Bear Activity: Bear(s) sighting], [Moose Activity: Moose sighting], [Warning: Trail hazard]. Due to known limitations of the current version of the ArcGIS API for JavaScript’s inability to display the label within legends 45 and the editor widget, it was decided to use a text code instead of an integer. The following fields were created to allow the user to provide information on the hazard: Date Observed, Comment, and Location. The ability to add attachments was also enabled on the feature class through the “Create Attachments” function in ArcMap. Figure 11. Trail hazards VGI feature class attribute fields 3.3.6. Publishing Services Once all feature classes had been finalized and before design of the application could begin, it was necessary to define how the data would be visualized and publish all accumulated and created feature classes to the ArcGIS Server for consumption within the map. Datasets were added into an ArcMap document where symbology and the level of zoom that the features would be visible at was defined before publishing. Trail lines within the first versions of the application only include those trails described within the AHS website. Therefore, a query and export of a new feature class was performed to include only features where “AHS Link IS NOT NULL”. All data was published to the University of Southern California (USC) ArcGIS Server as REST features services. 3.3.6.1. Trails Data Visualization and Publishing A single ArcMap 10.8 Map Exchange Document (MXD) was created for publishing trail features, lines, and boundaries excluding the VGI trail hazards. Within this MXD the symbology 46 for all features was defined as well as scale visibility. For trailheads, trail features, and boundaries a scale visibility was set to maintain an efficient loading time within the web application. Boundaries are not visible at scales less than 1:600,000 which was determined by the extent that allowed users to view the Municipality of Anchorage and southern region of the Matanuska-Susitna Borough. This area contains the Chugach State Park, a highly popular park system for hikers. Trailheads are not visible at scales less than 1:200,000 as this is the extent set for the view when the application first opens. Trail features are not visible at scales less than 1:50,000 as this was determined to be the average extent for viewing most trails from start to finish. Trail lines were not given a visibility scale as it was determined that this would be the most reliable dataset published to the map and should be visible at small scales to visualize the density and trail areas. With the consideration that the user would be able to select from a library of basemaps within the web application it was important to use a symbology that would be obvious on a variety of color schemes. A purple color was selected for trail lines with a width of “2.0”. Park boundaries were symbolized by color based on their “Managing Entity” and given a dashed outline so as not to overwhelm and overpower the trail lines and map. Trail features were symbolized by their “FEATURE” field and symbols were manually selected based on the type of feature, and trailheads were given a hiker point symbol. After all visualization properties were set for these feature classes the map was published as a map service to ArcGIS Server. 3.3.6.2. Trail Hazards VGI Feature Service The trail hazards VGI feature service was created and published in one map document where symbology was defined based on the coded “HazardType” field. This feature class also had a visibility scale set to not display at scales less than 1:500,000. After the visualization of the 47 feature class was defined, the map was published as a service with feature access enabled. The capabilities defined were to allow a user to create and update features, but the ability to delete features was not selected. 3.4. UX Design How the widgets and tools were compiled within the application and webpage was driven by the predetermined UX design. From the pre-development user survey, questions that focused on the users’ experience with technology and other applications were applied to determine the design that would provide the best UX. As discussed in Section 3.1, for technological skill most users fall within the “Advanced” category with 34% in the “Intermediate” category and no users reporting a “Beginner” level. This understanding of skills of the users would allow the application design to move towards a slightly more function and tool driven map that relies on an intuitive understanding of these types of applications rather than a page that contains multiple directional screens and tutorials. This would also allow to design a more minimalistic look and feel of the application and webpage. There were several considerations involved in determining the look and feel of the web application. The first consideration involved matching the design of the application to the existing AHS website. The existing landing page for the AHS webpage leans towards a simplistic feel to allow users to search for their trails of interest by name or through a trailhead selection. The website becomes more complex with more information as a user explores the individual information pages for the trails. It was determined to maintain this simple feel to allow users to focus on the map application and explore the spatial interactions between the features within the map and information provided within the pop-ups. The title bar design was also maintained to provide a uniform match between the site and application. This design was 48 implemented through a full extent display of the map and implementing a collapsed version of the widgets within the application. The other consideration with development was that while it was being designed for a web browser application, in order to encourage user accessibility and satisfaction, mobile browser compatibility would be important. Implementing all widgets in a collapsed style, as well as keeping them mostly grouped on one side of the application, ensured a smooth transition between web and mobile platforms. The splash screen was also manipulated within the CSS script to ensure that it was functional and visible on a mobile platform. For many intermediate to advanced users, the widgets in a collapsed icon with a “tooltip” pop-up when they mouse-over are enough for them to understand purpose and use. To help beginner users or those less familiar with these type of mapping applications the splash screen provides a quick “How To” on the tools specific to this application such as the “Add Trail Hazards” function. This splash screen also plays a role in liability, as users must click a box that they acknowledge the risks of hiking in Alaska before they can access the application. 3.5. Web Application Design The goal of this project was to develop an application that was designed primarily to be used within a web browser but could also be functional on a mobile device. As design moved forward the function of the application and design centered on a successful web experience, but tests were performed on a mobile device to ensure at least baseline functionality such as viewing and querying trails and features. Using HTML, JavaScript, and cascading style sheets (CSS), this web application was designed within the Atom source code editor from GitHub. All code written for this application can be found in Appendix A. 49 The data and functionality for this mapping application concept was originally tested within the ArcGIS Web AppBuilder platform. With the limitations on customization within the Web AppBuilder beta testing, it was determined that development within the ArcGIS API for JavaScript would provide the best final experience for the application. The final website was published to the USC gis-web.usc.edu web server at: https://gis- web.usc.edu/wilsonre/Thesis/AlaskaHikeSearch.htm. 3.5.1. ArcGIS API for JavaScript In order to begin writing script with the ArcGIS API for JavaScript 4.14, it is necessary to call in the source of the API by an HTML <script> src attribute that defines the API file found at "https://js.arcgis.com/4.14/". Once this source was defined, the widgets and tools from the ArcGIS API for JavaScript library were then available to be called in. To call in the map within the application, a MapView was defined. The MapView properties define the initial zoom, center, and popup capabilities of the map (ArcGIS API for JavaScript. 2020-a). This MapView does not provide any features or data, but only defines the web map to be displayed. All feature services were then called into the script by new FeatureLayer variables that referenced their individual REST service URL. These FeatureLayer variables also defined the popupTemplate for each feature service’s pop-up functionality that will be discussed in more detail within the Widgets section. 3.5.2. Widgets and Web Application Features In order to implement the library of functions it is necessary to use the require() function to load modules from the ArcGIS API. Each widget was added to the map and on-screen location specified through the add() method which requires input of the component to be added and its position. When the Expand widget was applied to a tool, the defined variable for the Expand 50 widget was referenced as the component (ArcGIS API for JavaScript. 2020-b). In the following subsections, these widgets will be defined as to their use within the web application. 3.5.2.1. Pop-ups The pop-ups widget functionality is defined within three places within the script. The first place the pop-ups are given definition is within the MapView when the location of the pop-up is defined and whether it is docked. In this application, the pop-ups are docked in a fixed position at the bottom left of the screen to allow the users to continue to explore the trail while viewing attribute information. The popupTemplate variable for each feature layer is defined when the layer is added to the application as described above. The pop-ups are customized by referencing the popupTemplate variable. The fields to be displayed or hidden are defined here as well as how they are displayed is specified. For example, the trail lines features display the “Difficulty” field with a hyperlink to the Shenandoah National Park Hiking Difficulty rating page so that users can understand how the rating is defined and how it is determined. 3.5.2.2. Expand To provide a cleaner, more streamlined view of the mapping application, the Expand widget was applied to all tools except for the measure toolbar and search bar. The Expand widget applies a collapsed clickable button to each widget with a default icon that allows the tool to be expanded when in use and hidden when no longer needed. Within each widget, a block of script defines the expansion variable and the widget that it contains (ArcGIS API for JavaScript. 2020- b). This new expansion variable is then called within the add() method as the new component for the widget. For each widget that had this functionality applied, the “expandTooltip” property was applied to define the text that shows when the mouse hovers over the tool icon. These tools 51 automatically have a default icon applied for the collapsed tool display that is specific to each widget. The default icon was generally accepted for all except the Editor and Filter widgets. 3.5.2.3. Editor The Editor widget was an important functionality within the application as it provides the framework for the VGI data to be created and updated. This widget has a high level of automation built in and can automatically identify layers within the application that have feature editing enabled requiring little customization within the script (ArcGIS API for JavaScript. 2020- c). In order to denote this widget as the tool to add hazards when collapsed (by default), the “expandIconClass” property was defined as “esri-icon-notice-triangle” to change the icon from the default pencil symbol to the Esri triangle with exclamation point symbol. 3.5.2.4. Filter An important feature identified by users in the pre-survey was the ability to filter trails within the map for a customized level of difficulty. The Filter script provided by the ArcGIS API for JavaScript (2020-d) tutorial was able to provide this functionality when implemented within the script but required some customization and modification in order to provide a clean and understandable display of the different options. This script creates a class that defines parameters for setting a client-side filter on a layer view (ArcGIS API for JavaScript 2020-e). Instead of providing simple strings within the “var sqlExpressions” definition, it was necessary to create objects that define each filter’s SQL expression along with a defined label for each expression that displays in the dropdown menu. 52 3.5.2.5. Layer List The LayerList widget creates a dropdown list of all layers currently visible within the map and symbology of the features (ArcGIS API for JavaScript. 2020-f). The addition of the LayerList widget provide functionality in a way for users to not only control which layers are visible on the map, but also provided a combined legend functionality. Initially, the widget displayed the map service name as well as the feature service causing a rather messy label system. To override this display issue, the “item.title” property was called upon and overwritten to display a custom defined title for each layer. 3.5.2.6. Search Bar The Search Bar widget by default uses the ArcGIS World Geocoding Service and comes fully functioning to search through this service initially. This widget can be customized to search layers within the mapping application by defining sources within the script (ArcGIS API for JavaScript. 2020-g). The default search service was deactivated by setting “includeDefaultSources” to “false”, then defining the trails and trailheads layers as the sources to search. The search bar looks within the defined fields for each layer set by the “searchfields” property for features that match the input keywords. Setting the “exactMatch” property to “false” allows for a more flexible search function and makes it unnecessary for the user to provide an exact match to the words within the field. The prompt within the search bar to assist users with what to type was also updated within the “allPlaceholder” property to “Trail Name”. When a user selects a layer to search, the “placeholder” property is updated based on the feature layer to provide more assistance on the type of keywords to use to search. 53 3.5.2.7. Measure Toolbar The Measure toolbar contains three functions for measuring lines, measuring area, or clearing the existing measurements on the screen. The toolbar is designed by adding a toolbarDiv id to the HTML script. Within this script, placeholders for the DistanceMeasurement2D widget (ArcGIS API for JavaScript 2020-h), AreaMeasurement2D widget (ArcGIS API for JavaScript 2020-i), and a clear() function are created. The CSS script is used to define the position and placement of the toolbar in the upper right-hand corner of the application. Within the JavaScript, the variable “activeWidget” is used to define the active widget through the “addEventListener” method that responds to a click event on the selected tool. When a measuring tool icon is selected it defines the function for “setActiveWidget” as the specified Esri widget or calls the “clear()” function which sets the “activeWidget” to “null” and clears the measurements from the screen. 3.5.2.8. Other General Map Widgets Aside from the more complex widgets described above, several others were implemented for general functionality and manipulation of the map. These widgets include a custom coordinates widget, Locate, Measure, Basemap Gallery, Print, and Home. The coordinates status bar widget within the application tracks the location of the mouse and displays the Lat/Lon of the pointer at its current location on the map. This status bar also displays the current scale and the zoom level of the map. This tool was designed in JavaScript as a custom widget by modifying the base class for widgets in the API (ArcGIS API for JavaScript 2020-j). Within the function to “showCoordinates” a definition is created for the latitude and longitude of the point The Locate widget provides a button that adjusts the view extent to the center on the user’s location at a scale specified within the script. The Bookmarks widget is a relatively simple 54 functional out-of-the-box widget that allows for pre-defined widgets as well as users to create bookmarks within the map (ArcGIS API for JavaScript. 2020-k). Bookmarks created by users within the application are erased when the tab is closed, or the page is refreshed. The only issue is that the widget does not allow for bookmarks to be defined unless the application is referencing an existing webmap created in ArcGIS Online. This alone was the driving force behind the webmap used that this mapping application is built upon. Rather than designing this application on a blank map within the script, this webmap was created with customized bookmarks for locations across the state and referenced as the base map display. The Print, Home, Measure, and Basemap Gallery widgets did not require any customization for use within the web application. While the Print widget (ArcGIS API for JavaScript. 2020-l) accepts custom print services, this application used a print service URL provided within the tutorial (ArcGIS API for JavaScript. 2020-m) that creates a basic map in multiple formats with a view of the map from the current extent and legend of visible features. The Home widget zooms the view back to the original viewpoint and scale that the mapping application opens on (ArcGIS API for JavaScript. 2020-n). The Basemap Gallery widget allows users to select from a variety of basemaps including imagery and topographic to display in the application (ArcGIS API for JavaScript. 2020-o). 3.5.3. Splash Screen To ensure that new users to the page had the information they needed to understand the mapping application’s purpose and how to use Editor widget, a splash screen information window was designed using a Snackbar. A Snackbar (also referred to as a Toast) is a contextual notification user interface component, often designed through CSS and JavaScript, that is used to call up a pop-up window on a screen. These windows are often used for information or tooltips 55 on webpages (w3schools.com 2020). Within the HTML the content of the Snackbar was created and defined. This window contains an introduction to the page and its purpose, a warning for hiking on Alaskan trails, and then instructions for how to use the Add Trail Hazards tool. This section also references a button that users must click in order to acknowledge they understand the risks of hiking in Alaska and close the screen. From here the CSS was used to customize the Snackbar’s font, box size and design, margins, color, how the Snackbar animates in when the page loads, the button design, and the style of various text elements within the HTML. A CSS media query was also defined for when the window is less than 600px to ensure that it would still be fully visible and maintain scrolling functionality when viewing the application on a mobile device. Within the HTML, a button was added to the header of the webpage that also references this Snackbar, triggering the window to reappear when clicked. Finally, JavaScript functions were required to define functions for how the Snackbar displays on screen load, displays when the header button is clicked, and closes when the button within the window is clicked. 3.6. Application Evaluation The application was evaluated based on the functional requirements described in Section 3.6.1. These requirements were designed at a high level so that they could be easily verified by the user in a post-development survey. The design of this post-development user survey is described in Section 3.6.2. 3.6.1. Functional Requirements A primary functional requirement that a user will encounter that this application must fulfill is the display of trail lines and information for trails within AHS. The application must show all trails that are cataloged within the AHS website and provide a link to the information page for each individual trail. These line features must also display attributes within a pop-up for 56 general physical characteristics of the trail. This requirement for the view of trails will begin with an initial extent displaying trails within the MOA area. The user must also be able to implement several tools within this application that allow them to investigate and discover trails. These tools include zooming in and out in the map, viewing and adding personal bookmarks, changing the basemap, turning layers on and off, filtering trails by difficulty, printing paper copies of the map view, and use a search bar to search the map for trails and trailheads. The final functional requirement that this application must fulfill is the ability to add VGI for trail hazards on the map. The Editor widget will be the tool that enables the user to add these hazards and provide information as to the characteristics and location of the hazard. 3.6.2. User Testing The final steps of this development and design involved providing the application link to the original set of 28 users who had been provided the pre-development survey. Users were asked to test all functionalities of the map and use it as if they were planning a hike for the weekend. They were also directed to submit as many VGI points as they desired to ensure functionality and that the tool was clear as to its use. Due to the application development occurring in winter, many users could not access trails to assess actual hazards, so users were encouraged to enter as many fictional hazards and wildlife sightings as they desired. If a user was entering a warning that they knew was a real existing hazard, they were asked to denote this in the comments field so that this would flag the hazard to be saved when the fictional hazards are deleted. After users had a chance to test the functionality of the application, they completed an additional survey. This survey was again created within Google Forms, and users could elect to 57 respond anonymously. The full set of questions from the survey can be seen in Appendix C.1 and results of this survey will be discussed further in Section 4.3. 58 Chapter 4 Results This chapter will detail the results of the data creation and application development methods described in Chapter 3. Section 4.1 will describe the results of the database created. A tour of the web application and all functioning tools will be described in Section 4.2. The results of the user survey and how feedback was managed is described in Section 4.3. 4.1. Trails Database The data collected and compiled as discussed in Section 3.3 was successfully published to and accessed through the USC ArcGIS Server REST features services. The datasets consumed within the application as REST services include trails (lines), trail hazards (points), trailheads (points), trail features (points), and park boundaries (polygons). The trail hazards feature service is the only dataset with editing enabled and allows for points to be added and updated. All other datasets are restricted from editing but can be viewed and queried. 4.2. Web Application Tour This section describes the web application design and functionality through a tour of the page. This tour will start with the loading screen and continue with how a user may interact with the various tools and widgets. 4.2.1. Initial Page and Splash Screen The webpage and application initially load with a simple header describing the “Alaska Hike Search” page, a “Map Help” button on the right edge of the header, and the mapping application. As the tools and data loads into the map, the splash screen appears through a fade-in from the bottom screen (Figure 12). This splash screen details the intent of the webpage and provides a disclaimer of the risks of hiking in Alaska. The user must click the button 59 acknowledging that they understand the risks of hiking in Alaska or continue further down the splash screen for directions on adding trail hazards. The user can access this splash screen again at any time by selecting the “Map Help” text button (Figure 13). The initial map load displays at an initial extent centered on trails near Anchorage, a zoom level of 12, and with the “Topographic” basemap turned on. This extent was chosen as it displays approximately 50% of the trails in the database as well as the most populated municipality in Alaska. The tools and widgets displayed in the application can also be seen in Figure 12. On the left-hand side of the screen the following tools can be found from top to bottom: zoom in, zoom out, home (return to original extent), bookmarks, basemap gallery, layer list and legend, filter, and print. On the right- hand side of the screen the following tools can be found from top to bottom: search bar, add and edit trail hazards (editor), linear distance measurement, area measurement, and clear measurements. The bottom left-hand corner contains a coordinates bar that displays the latitude and longitude of the current position of the mouse, the scale of the map, and the zoom level. The tools listed above, and their functionality will be discussed in more detail in later sections. 60 Figure 12. Loading page with red arrow and box highlighting the button users must click to use application. Left side of figure shows the available tools. Figure 13. Map Help button highlighted in red box and arrow 61 4.2.2. VGI Trail Hazards Editor The Editor widget which allows users to add or edit trail hazards within the map can be found under the search bar on the right-hand side of the screen (Figure 14). Clicking on the triangle icon pulls up the editor screen where users can select to “Edit Feature” or “Add Feature”. When a user selects “Add Feature”, the next editing screen appears directing the user to select the type of hazard they would like to add to the map. Users can select from “Bear Activity”, “Moose Activity”, or “Warning” and then place the point on the map. Once the point is placed, users are prompted to submit information about the hazard such as date, time, comments on hazard, and locational information. The flow of the screens for adding a feature can be seen in Figure 15. Once the point is placed users can click on the newly created hazard and see information about the point in the pop-up that displays on the bottom left-hand portion of the screen (Figure 16). Figure 14. Location of Trail Hazard Editor tool within the application 62 Figure 15. Flow Diagram of Trail Hazard Editor tool Figure 16. Result of trail hazard added on a map with pop-up displayed in bottom left. 63 4.2.3. Pop-ups While navigating through the map and application, the user can select trails, trail features, hazards, trailheads, or park boundary areas to learn more information on the attributes of the feature of interest. When a trail is selected a pop-up displays as docked on the bottom left hand of the screen. The docked pop-ups allow users to continue to investigate the trail on the map while they view attribute information for the feature until the “x” at the top-right of the pop-up window is clicked to close the view or another feature on the map is selected. Figure 17 shows a pop-up window for a typical trail line feature. Within these pop-up windows for trails, the user can view various information on the trail as well as click hyperlinks on some fields to view more information on another webpage. By clicking on “Difficulty” within the pop-up, the user is directed to a new tab or window that opens the Shenandoah National Park’s Hiking Difficulty webpage (NPS 2017) describing how the ratings are calculated. When a user selects the “View” link within the “Alaska Hike Search Info Page” field, a new tab opens for the information page for that specific trail within the AHS website. Figure 17. Trail information pop-up 64 4.2.4. Measurement Toolbar Users may have an interest in measuring distances between certain trail features or areas within the application. As seen in Figure 18, a measurement toolbar is available with three measuring functions available: linear distance measurement, area measurement, and clear measurements. The linear distance measurement and area measurement tools begin with the user selecting the tool icon then clicking points on the map to measure a line or polygon. Once a measurement is initiated, a window appears in the bottom right-hand corner displaying the current length or area and allows the user to define the unit of measurements. For each new measurement initiated and added to the map, a new pop-up window is created. To finish measuring, the user can double click to leave the measurement visible on the map or select the clear measurement tool to clear all measurements displayed. Figure 18. Measurement toolbar and measurement window 4.2.5. Search Tool Figure 19 shows the search bar functionality. Before a user begins typing, the search bar prompts them to enter “Trail or Trailhead Name”. As a user types, a list of matching trails or trailheads appear in a dropdown menu. When a feature of interest is found and selected from the dropdown, the application zooms to the trail and displays the pop-up for the trail of interest. If 65 desired, the user can narrow the search functionality by clicking the arrow on the right side of the search bar and selecting to search only within one of these layers instead of both simultaneously. Figure 19. Search bar functionality 4.2.6. Additional Tools Figure 20 shows the display and function of the other tools available within this application. These additional tools include bookmarks, basemap gallery, layer list and legend, print, and filter. Within the bookmarks tool, users can select from a list of predefined bookmarks of popular towns and parks across the state. Users can also create their own bookmarks for areas of interest they may be researching, but these new bookmarks are erased when the web page is refreshed. The basemap gallery allows users to change the background basemap reference layer and includes 24 options of various topographic, imagery based, and community information basemaps. 66 Figure 20. Other tools in application The layer list and legend tool show the legend for all layers that are turned on and visible at the current map extent. Some layers have scale level visibility set and will not display in this list until the user zooms into that pre-defined scale level. From this tool users can also toggle layers on and off. The filter function provides the ability to define what trails a user wants 67 displayed on the map based on the level of difficulty defined in the attributes. The user can select one level of difficulty to display at a time and can reset the filter by selecting “All Trails (reset filter)”. The final tool available on the left-hand list is the print tool. When selected, this tool provides a custom output of a digital map document or image based on the current visible extent of the map. The user can define a title, the page setup, and the file format of the map. The “Advanced Options” drop-down menu provides additional settings for defining the scale, Author, Copyright, dots per inch, and whether the legend is included. Once “Export” is selected, an icon appears below with the title of the document which is greyed out until the document is finished being created. Once the document is created the user can click on the title and a new window will open with the final map document in the defined file format. Figure 21 shows a “Test” map that was created from this print tool. Figure 21. Example of map created from the print tool 68 4.2.7. Mobile Browser Functionality This application was designed with a focus on functionality within a web browser but based on feedback in the pre-development user survey, 45% of users stated they were “Not Likely” or only “Somewhat Likely” to use an application that was web based. This response elevated the importance of ensuring that the application was also usable within a mobile browser. A media tag that was applied within the CSS script for screens less than 600px defined new sizing for certain elements in the application to be scaled down, such as the title, “Map Help”, and splash screen. This allows all elements to still be visible within the mobile screen and prevents tools from being hidden or overrun from shifting container sizes. Figure 22 displays the various tools and screens as seen on a mobile device. 69 Figure 22. Mobile device application display 70 4.3. User Testing and Feedback Once application development reached a stable point for deployment, a post-development user survey was sent to 28 participants as discussed in Section 3.6. From these 28 participants, seven responses were collected via the Google Forms user survey, and three other participants provided feedback via email due to issues accessing the survey. All responses from the survey can be viewed in Appendix C.2. Users that indicated any issues with using the application were contacted via email to troubleshoot and determine solutions. One user indicated the inability to add a trail hazard, but when they returned to the application, the issue had resolved, and they did not encounter the same problem again. Overall, feedback was positive with 80% of responses from participants indicating that they would consider adding it to their list of applications they use for hike planning. For the “Add Trail Hazard” tool, 85% of participants responded that they were successfully able to add a hazard (Figure 13), and of those 85%, 100% scored the ease of adding a trail hazard as a “5” with “1 = Difficult” and “5 = Easy”. Detailed feedback from users provided insight on some features that were not operating as expected and required troubleshooting to fix issues or develop. No users were able to use the “My Location” feature, as it was later determined that due to privacy settings defined within the ArcGIS API, this widget is only available in the application when accessed via secure connection. When not accessed through a secure connection the tool did not appear, and users were not aware of its existence until asked about it in the survey. This issue was resolved by providing a URL to the website beginning with a “https://” protocol. The measurement tool was another feature that three users indicated a struggle to successfully implement without frustration due to lack of instruction and intuitive workflow. The 71 default functionality of the widget requires users to double click to end a measurement and once a measurement is made, it remains on the map until the page is refreshed. To make this tool more functionally intuitive, a “toolbar” of line measurements, area measurements, and a “clear measurements” function was created. While this tool still operates with the “double click to end measuring” functionality, users now can alternatively click on the trash can icon to stop their current measurements and will also clear any measurements on the map. 72 Chapter 5 Conclusions This chapter outlines the success and challenges faced with application design, built-in widget implementation, and lessons learned through the project. The challenges discussion includes concerns for accuracy of user created trail hazards through VGI in Section 5.2.1. The final section discusses future developments of the application and how it can be improved and translated for implementation within the AHS website. 5.1. Application Successes This project successfully created a prototype web mapping application for the AHS website that met all functional requirements discussed in Section 3.6.1. This application allows users to explore trails in Alaska from various managing authoritative data sources within one application and provide warnings for dangerous trail conditions. Within the application, users can navigate across the state and identify trails in their area of interest, discover information about the trail within the pop-up, and click to go to the description page on AHS for more details. The trail information provided in the application includes difficulty ratings, trail management entities, trailheads, and a description of a trail’s physical and spatial features. Users can query through the search bar for trails and trailheads by name and filter for trails based on desired difficulty through the Filter widget. This project also implemented an Editor widget within the application for users to provide warnings of dangerous conditions on trails. Users can provide point locations as well as comments and location descriptions for activity of bear and moose near trails and any unexpected hazardous trail conditions such as erosion or fallen trees. 73 5.2. Limitations and Challenges There were several challenges encountered through the development of this project, many of which were easily rectified, but some issues have been identified as needing more time and attention. Several users mentioned frustration with the Measure widget built-in functionality as it was not easy to understand how to stop measuring, and measurements were not able to be cleared from the map once complete. This issue was solved by creating a standalone toolbar that included a “Clear Measurement” tool, but still creates some problems as the pop-up window does not always clear from the screen, especially when adding more than one measurement at a time. Several other tools provided some challenge in how their “Out of the box” functionality operates and required manipulation of the script to adjust the display and operation to be more user friendly. Improvements will continue to be made on these tools to ensure a positive and streamlined user experience. Further discussions in this section will focus on the challenges encountered and inherent to the VGI component of this application. 5.2.1. VGI Trail Hazards Accuracy There are multiple challenges present for obtaining accurate locations of trail hazards due to the nature of the encounter on a trail combined with the limited mobile functionality of this application. First, with the lack of a mobile application that allows users to drop a point based on the location of the device, the accuracy of the hazard relies on the user’s spatial awareness and ability to translate their location onto a topographic or imagery-based map. Second, when a user confronts a hazard such as a moose or bear, their first consideration should be for their safety and ensuring they move to a safe location and away from danger. This action is highly encouraged, but in the concerns for accurate location placement this movement and high stress interaction can lead to questionable spatial recall. 74 The application attempts to overcome these issues by providing guidance in the splash screen, and functionality in the Editor tool to allow users to provide the best information they can through a comment field and location description field. Users are encouraged in the splash screen instructions and map help to place points at the trailheads or trail entrance with descriptive locational information when they are unable to recall an accurate location. While this provides an alternative for users who may not be able to remember the exact location while still warning other users on that trail and trailhead area, it does contain inherent flaws. Multiple trails in the state can be accessed from more than one trailhead location and therefore this style of placement may not alert all users on that trail of the hazard. Future work to remedy this could involve designing a relation between the trail hazard location and the trail line feature class, allowing users to be made aware of hazards on the trail from the trail line feature attributes pop-up. However, this still presents problems where a trail may exist as a segment that does not extend to the trailhead, requiring the relation to extend to all connected trails that may be used for access, potentially resulting in alerts on many trails in large inter-connected trail systems. 5.2.2. Editor Widget Another issue that was detrimental to the functionality of the VGI hazards was a limitation for adding attachments within the Editor widget in the current ArcGIS API version. When providing information on trail hazards, a useful function to enhance the description of the hazard and provide visual cues as to the location, is the ability for users to submit a photograph with the point. Unfortunately, during development it was discovered that the ArcGIS API for JavaScript 4.14 Editor widget does not currently support attachments (Figure 23). While feature attachments were enabled for the trail hazards VGI feature class in the enterprise geodatabase, this limitation within the widget rendered this functionality as unavailable. Considerations for 75 improving this functionality and designing a solution to work around this limitation are discussed in Section 5.3.3. Figure 23. Editor widget known limitations. Source: ArcGIS API for JavaScript (2020-c) 5.3. Future Improvements This section will discuss the concepts and ideas for future improvements to the extent of data provided, the data quality, and application functionality. 5.3.1. Database Expansion and Data Quality The goal of this database and application was to encompass the library of trails described within the AHS website, which was successfully accomplished. However, future improvements include expanding the database to include all trails in the State of Alaska that have available spatial information to improve the application’s utility and expand its user appeal. The dataset of trail data collected from authoritative sources contained 1,012 trails in Alaska, which was then queried down to only trails with an AHS information page link. Future development will involve integrating the remaining 883 trails across the state into this database and application, as well as downloading missing trails data from other spatial trail applications. Future trail data will be gathered through a GPX download from various existing applications, such as AllTrails, or through user submitted files. To simplify this data-integration, a ModelBuilder tool within ArcGIS will be developed to automate the process of importing a GPX file and performing the necessary steps to format, analyze physical properties, and append the new trail to the existing 76 data. The final goal of this database will be a comprehensive collection of hiking trails in the State of Alaska that covers trails and regions often missed by existing applications. Future improvements to this database will also include expanding attribute information of the datasets as well as expanding the collection of trailhead data. One user provided positive feedback on the list of trailheads available within the trail line feature attributes. Future trail line additions will include a process to ensure the database contains this attribute information and corresponding trailhead points are added as necessary. Continued attribute enhancement will also include adding reference links for the managing entity of a trail or trailhead so users can find more information about fees and regulations. One user expressed an interest in having the fee information available for display in the trailhead point data. In the beginning of this project development, it was believed this could simply be spatially related to the boundary and managing entity that a trailhead was located in. Research in trail management discovered that there were several instances of trailheads located in a State Park boundary that were maintained and regulated by the local borough and therefore followed their fee structure, complicating this process. Fee structure information will be added in future implementations through selection of features by their managing entity and updating fields for fee structures within the park or reserve. 5.3.2. Advanced Search An important feature of searching hiking trails is the ability to identify which meet a user’s desired interests and physical abilities and are within a reasonable distance of travel. Future work will continue development of an “Advanced Search” tool that was unable to be implemented within this version of the application. The current tool, as seen in Figure 24, is designed within ArcMap’s ModelBuilder functionality and allows a user to specify their location on a map, desired distance to drive from their location, and then select one or more options from 77 a list of trail difficulties. When the tool is run, the user location is buffered, trails queried by difficulty, and a selection is performed for queried trails that fall within the buffer. This tool then creates an output layer of the selected trails that is added to the map for a user to explore. Development of this tool so that it can be used within the application will require publishing to ArcGIS Online as a custom geoprocessing service. Once this tool is published it can then be consumed and manipulated within the application code for integration. Unfortunately, due to constraints in software errors and time this feature was unable to be added in the current implementation. Figure 24. Advanced Search tool designed within ArcMap’s ModelBuilder 5.3.3. Add Trail Hazards As discussed in Section 5.3.1, limitations were encountered within the Editor widget for adding trail hazards with feature attachments due to limitations within the API. A possibility for working around this issue is to develop a separate application within Esri’s Web AppBuilder for ArcGIS as this framework does not have this limitation within its built-in editing widgets. This new application could then be linked to through a CSS and HTML designed tab at the top of the AHS application directing users to “Add Trail Hazard”. These trail hazards added from the Web 78 AppBuilder application would then be displayed within the initial AHS application, with the Editor tool removed, allowing for viewing and querying purposes only. 5.3.4. VGI Trail Features Continued work with expanding the information available for trails will include implementing a VGI “trail features” dataset. This dataset will allow users to provide point data on trail features such as benches, water crossings, trail cairns, points of interest, turns or forks in the trail, and any other important or interesting feature a user may encounter that do not fall within the realm of the Trail Hazards dataset. The current trail features dataset available within the application only provides trail feature data for State Parks. This dataset could be used as the base for this VGI dataset with the current data open for editing, allowing users to provide updates to existing data as well as providing new data points. 5.4. Future Direction for the Application The first step will be the migration of the data and application from the USC ArcGIS Server and geodatabases and onto personal hardware. The current plan for migrating this application to the AHS website is to continue development within the ArcGIS framework. The AHS website does not generate any revenue and does not advertise for any outside services, thus allowing the developer of this application to use all services provided within an ArcGIS Personal Use license. The ArcGIS Personal Use license provides the user with a free ArcGIS Online Organizational Account, ArcGIS Desktop Software, ArcGIS Pro, and 100 service credits each year for the cost of $100 annually (Esri 2020-a) Preliminary investigation and testing shows promise that this license will provide all the capabilities necessary to run this application. The largest concern that this license style provides is the limitations of storage. ArcGIS Online charges “2.4 credits per 10 MB stored per month, 79 calculated hourly” for feature storage and “1.2 credits per 1 GB stored per month” for attachments in a hosted feature layer and any other content outside of hosted feature layers (Esri 2020-b). A review of the data file sizes for the existing data in the application can be seen in Table 4. With the park boundaries constituting most of the total MB, this dataset may be excluded from future iterations of the application or queried down to a small collection of popular parks. This may mean that users will not be able to query park information within the map, but many basemaps available on ArcGIS Online display park labels for reference. Since the feature attachments have not yet been functional within the Editor widget, it is unclear how quickly this storage will add up and will require monitoring as users provide photo attachments to trail hazards and feature points. ArcGIS Online does provide warnings to the administrator of the organizational account when credit usage reaches 75% and 100% and will then place the account into a “Restricted” or “Negative balance” status. Additional service credits can then be purchased at the rate of 1,000 credits for $100 (Esri 2020-c). Table 4: File sizes for current datasets Dataset Size (MB) Trail lines (AHS) 2.30 Trail lines (All) 8.20 Trail features 0.90 Trailheads 0.03 Park boundaries 166.00 Total 177.43 Routine maintenance for this application will require updating trail data and information as well as monitoring and cleaning VGI data. Planned routines for maintaining the trails database will include uploading new trails and trailheads as information is provided by users and removing or editing any erroneous trail data. The VGI data for warnings will require weekly 80 checks for maintenance to identify any points that have been updated to indicate the trail hazard no longer exists. The trail features VGI to be implemented will also require weekly reviews to ensure relevant data is provided and available. This application will continue user testing as new features are added and follow suggestions from the research by Getto and Moore (2017) on GIS and UX design. This research suggests moving away from large single usability testing rounds and to operate development in a more iterative, lean design model, where user testing is performed in more frequent rounds with smaller groups. Wildlife activity points will be removed after a time period of 2 weeks as a general rule with some points being left longer to be determined on a case-by-case basis. Based on a study by the USFS (Innes 2010) moose have an approximate home range of 20 miles depending on season and availability of food, with these ranges extending for males and decreasing for females during the mating season. Black bears exhibit a home range of 10 or more square miles for females and up to 122 square miles for males annually (Mass Audubon 2020). Brown bears have a far more variable home range, exhibiting anywhere from 23 square miles to 345 square miles (Dahle and Swenson 2003) depending on mating season and food source availability. Based on this data it is difficult to estimate how long these animals may stay in an area to provide a time range for this dataset. While they may exhibit extensive home ranges, bears that are closer to populated places may have less motivation to leave an area if they have identified a reliable food source due to poor management of trash by the local neighborhood. Two weeks was estimated to be enough time to allow for an animal to move on or be identified as a “nuisance” if it has exhibited aggressive behavior, requiring action by ADF&G officers. This time frame may be revisited on a case-by-case basis during special situations such as salmon spawning season which leads to 81 bears staying in areas for longer periods of time or reviewed as more activity data is input and a clearer picture of the volume of use for this tool develops. Future development of this application will include continued improvements on the mobile format of the existing web application. Feedback from the user surveys provided strong evidence that while a web browser application would still be used, there are many users that perform hiking trail research almost solely on a mobile platform. This feedback will continue to drive work on the mobile UX design to ensure the mobile experience is functional and easy to use. As discussed in Chapter 1, much of Alaska is not reliably covered by a cellular network, especially in many areas where hiking trails occur. In order for this application to be valuable to users on the trails, capabilities for offline use of the data and map will be an important implementation in development. The Collector for ArcGIS application provides a potential avenue for the VGI aspects of the application to collect information on hazardous and non-hazardous features on the trail. This application is typically marketed and geared towards utility workers in the field collecting information on infrastructure but could provide a mobile application format that is ready to use and requires little scripting and customization. Alternatively, a mobile application designed through AppStudio for ArcGIS and the ArcGIS Runtime Software Development Kit would provide a more customized design and mobile application but would require more time for development. Finally, this application could be a beneficial resource for stakeholders outside of hiking trail users. Parks and recreation management organizations can use this application as an external tool for awareness of activities and degradation of trail conditions. This application could also be easily repurposed or accessed for use by the ADF&G for their annual “Anchorage Moose 82 Survey” that is fueled by community input for moose locations within the municipality. Maintaining a historical record of VGI data points of wildlife activity could be provided to the department for analysis and planning. This application provides the framework for a tool that can not only be used for discovery of outdoor recreational opportunities, but as a line of communication between outdoor enthusiasts and natural resource management. 83 References Alaska Department of Fish and Game (ADF&G). 2019. “Aggressive Moose.” What to Do About Aggressive Moose. Accessed September 23, 2019. Alaska Department of Fish and Game (ADF&G). 2004. “Alaska’s 32 Ecoregions.” Alaska Ecosystems. Accessed November 11, 2019. http://www.adfg.alaska.gov/index.cfm?adfg=ecosystems.ecoregions. Alaska Hike Search (AHS). 2020. “About this Site.” Accessed May 4, 2020. https://alaskahikesearch.com/about. Alaska State Troopers (AST). 2009. “Alaska State Troopers 2009 Annual Report.” 2009. https://dps.alaska.gov/ast/pio/archive. Alaska State Troopers (AST). 2012. “Alaska State Troopers 2012 Annual Report.” 2012. https://dps.alaska.gov/ast/pio/archive. Albert, David M., and Terry R. Bowyer. 1991. “Factors Related to Grizzly Bear: Human Interactions in Denali National Park.” Wildlife Society Bulletin 19 (3): 339–49. Anchorage Daily News. 2019. “Couple missing in Hatcher Pass turn up in good condition after 2-day bushwhack.” Last Updated September 5, 2019. https://www.adn.com/alaska- news/mat-su/2019/09/04/search-underway-for-hiking-couple-missing-in-hatcher-pass- area/. Antoniou, V., and A. Skopelitri. 2015. “Measures and Indicators of VGI Quality: An Overview.” ISPRS Annals of Photogrammetry, Remote Sensing and Spatial Information Sciences. 2:345-351. ArcGIS API for JavaScript. 2020-a. “MapView.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed May 6. https://developers.arcgis.com/JavaScript/latest/api- reference/esri-views-MapView.html. ArcGIS API for JavaScript. 2020-b. “Expand.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed May 6. https://developers.arcgis.com/JavaScript/latest/api- reference/esri-widgets-Expand.html. ArcGIS API for JavaScript. 2020-c. “Editor.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/api- reference/esri-widgets-Editor.html. ArcGIS API for JavaScript. 2020-d. “Filter features by attribute.” JavaScript API / 4.14 / Sample Code, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/sample-code/featurefilter- attributes/index.html. 84 ArcGIS API for JavaScript. 2020-e. “FeatureFilter.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/api-reference/esri-views-layers-support- FeatureFilter.html. ArcGIS API for JavaScript. 2020-f. “LayerList.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/api- reference/esri-widgets-LayerList.html. ArcGIS API for JavaScript. 2020-g. “Search.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/api- reference/esri-widgets-Search.html. ArcGIS API for JavaScript. 2020-h. “DistanceMeasurement2D.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/api-reference/esri-widgets- DistanceMeasurement2D.html. ArcGIS API for JavaScript. 2020-i. “AreaMeasurement2D.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/api-reference/esri-widgets- AreaMeasurement2D.html. ArcGIS API for JavaScript. 2020-j. “Widget.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/api- reference/esri-widgets-Widget.html. ArcGIS API for JavaScript. 2020-k. “Bookmarks.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/api-reference/esri-widgets- Bookmarks.html. ArcGIS API for JavaScript. 2020-l. “Print.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/api- reference/esri-widgets-Print.html. ArcGIS API for JavaScript. 2020-m. “Print widget.” JavaScript API / 4.14 / Sample Code, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/sample-code/widgets-print/index.html. ArcGIS API for JavaScript. 2020-n. “Home.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/api- reference/esri-widgets-Home.html. ArcGIS API for JavaScript. 2020-o. “BasemapGallery.” JavaScript API / 4.14 / API Reference, ArcGIS for Developers. Accessed April 3. https://developers.arcgis.com/JavaScript/latest/api-reference/esri-widgets- BasemapGallery.html. 85 AT&T. 2020. “Wireless coverage.” AT&T Maps. Accessed April 11, 2020. https://www.att.com/maps/wireless-coverage.html. Belanche, Daniel, Luis V. Casalo, and Miguel Guinaliu. 2012. “Website Usability, Consumer Satisfaction and the Intention to Use a Website. The Moderating Effect of Perceived Risk.” Journal of Retailing and Consumer Services 19: 124–32. Bil, Michal, Martina Bilova, and Jan Kubecek. 2012. “Unified GIS database on cycle tourism infrastructure.” Tourism Management. 33: 1554-1561. Brown, Greg. “A Review of Sampling Effects and Response Bias in Internet Participatory Mapping (PPGIS/PGIS/VGI).” Transactions in GIS. 21(1):39-56. Chhetri, Prem. 2015. “A GIS methodology for modelling hiking experiences in the Grampians National Park, Australia.” Tourism Geographies. 17(5): 795-814. DOI: 10.1080/14616688.2015.1083609. Chhetri, Prem, and Colin Arrowsmith. 2008. “GIS-based Modelling of Recreational Potential of Nature-Based Tourist Destinations.” Tourism Geographies. 10(2): 233-257. Coltrane, Jessica A., and Rick Sinnott. 2015. “Brown Bear and human recreational use of trails in Anchorage, Alaska.” Human-Wildlife Interactions. 9(1): 132-147. D’Antonio, Fausto, Paolo Fogliaroni, and Tomi Kauppinen. 2014. “VGI Edit History Reveals Data Trustworthiness and User Reputation.” Proceeding of AGILE 2014. Dahle, Bjørn, and Jon E. Swenson. 2003. “Seasonal range size in relation to reproductive strategies in brown bears Ursus arctos.” Journal of Animal Ecology. 72: 660-667. Dye, Andrew S., and Shih-Lung Shaw. 2007. “A GIS-based spatial decision support system for tourists of Great Smoky Mountains National Park.” Journal of Retailing and Consumer Services. 14: 269-278. Esri. 2020-a. “ArcGIS for Personal Use.” ArcGIS Online. Accessed April 3, 2020. https://www.esri.com/en-us/arcgis/products/arcgis-for-personal-use/overview. Esri. 2020-b. “Understand credits.” ArcGIS Online Help Documentation. Accessed April 3, 2020. https://doc.arcgis.com/en/arcgis-online/administer/credits.htm. Esri. 2020-c. “Credits Pricing.” ArcGIS Online Credits. Accessed April 3, 2020. https://www.esri.com/en- us/arcgis/products/credits/buy?rmedium=esri_com_redirects01&rsource=/en- us/store/arcgis-online/arcgis-online-credits. Foster, Mollie. 2017. Hiking Alaska. Connecticut: FalconGuides. GCI. 2020. “Mobile Coverage Map.” GCI Mobile. Accessed April 11, 2020. https://www.gci.com/mobile/coverage-map. 86 Getto, Giuseppe, and Christina Moore. 2017. “Mapping Personas: Designing UX Relationships for an Online Coastal Atlas.” Computers and Composition. 43:15-34. Goodchild, Michael F. 2007. “Citizens as Sensors: The World of Volunteered Geography.” GeoJournal 69: 211–21. Goodchild, Michael F., and Linna Li. 2012. “Assuring the Quality of Volunteered Geographic Information.” Spatial Statistics. 1: 110–20. Gottwald, Sarah, Tiina E. Laatikainen, and Marketta Kytta. 2016. “Exploring the Usability of PPGIS among Older Adults: Challenges and Opportunities.” International Journal of Geographical Information Science. 30 (12): 2321–38. Haklay, Mordechai. 2009. “How Good Is Volunteered Geographical Information? A Comparative Study of OpenStreetMap and Ordinance Survey Datasets.” Environment and Planning B: Planning and Design. 37: 682–703. Haklay, Mordechai, Sofia Basiouka, Vyron Antoniou, and Aamer Ather. 2010. “How Many Volunteers Does it Take to Map an Area Well? The Validity of Linus’ Law to Volunteered Geographic Information.” The Cartographic Journal. 47(4): 315-322. Heggie, Travis W., and Michael E. Amundson. 2009. “Dead Men Walking: Search and Rescue in US National Parks.” Wilderness and Environmental Medicine. 20: 244-249. Hjerpe, Evan E. 2018. “Outdoor Recreation as a Sustainable Export Industry: A Case Study of the Boundary Waters Wilderness.” Ecological Economics. 146: 60-68. Hugo, M. Leon. 1999. “Energy equivalent as a measure of the difficutly rating of hiking trails.” Tourism Geographies. 1(3):358-373. https://doi.org/10.1080/14616689908721327. Interaction Design Foundation. 2020. “What is User Experience (UX) Design?” User Experience (UX) Design. Accessed March 25, 2020. https://www.interaction- design.org/literature/topics/ux-design. Idaho State Parks and Recreation. 2019. “Idaho Trails Map.” Idaho Trails. Accessed November 12, 2019. www.trails.idaho.gov. Innes, Robin J. 2010. “Alces americanus.” Fire Effects Information System (online). www.fs.fed.us/database/feis/animals/mammal/alam/all.html. International Organisation for Standardisation (ISO). 2013. ISO19157:2013 Geographic Information – Data Quality. Geneva:ISO. Irmischer, Ian J., and Keith C. Clarke. 2017. “Measuring and modeling the speed of human navigation.” Cartography and Geographic Information Science. 45(2):177-186. 87 Kienast, Felix, Barbara Degenhardt, Barbara Weilenmann, Yvonne Wager and Matthias Buchecker. 2012. “GIS-assisted mapping of landscape suitability for nearby recreation.” Landscape and Urban Planning. 105: 385-399. Korpilo, Silviya, Tarmo Virtanen, Tiina Saukkonen, and Susanna Lehvavirta. 2018. “More than A to B: Understanding and managing visitor spatial behavior in urban forests using public participation GIS.” Journal of Environmental Management. 207: 124-133. Lawson, Steven R., and Robert E. Manning. 2002. “Tradeoffs Among Social, Resource, and Management Attributes of the Denali Wilderness Experience: A Contextual Approach to Normative Research.” Leisure Sciences. 24: 297-312. Mass Audobon. 2020. “About Black Bears.” Learn: Nature and Wildlife. Accessed April 5, 2020. https://www.massaudubon.org/learn/nature-wildlife/mammals/bears/about. McLafferty, Sara, Daniel Schneider, and Kathryn Abelt. 2020. “Placing volunteered geographic health information: Socio-spatial bias in 311 bed bug report data for New York City.” Health and Place. https://doi.org/10.1016/j.healthplace.2019.102282. Meijles, E.W., M. de Bakker, P.D. Groote, R. Barske. 2014 “Analysing hiker movement patterns using GPS data: Implications for park management.” Computers, Environment and Urban Systems. 47: 44-57. National Park Service (NPS). 2017. “How to Determine Hiking Difficulty.” Shenandoah National Park Virginia. Last Modified December 5, 2017. https://www.nps.gov/shen/planyourvisit/how-to-determine-hiking-difficulty.htm. National Park Service (NPS). 2019-a. “Backpacking in Alaska.” Lake Clark National Park & Preserve. Last Modified January 29, 2019. https://www.nps.gov/articles/backpackingak.htm. National Park Service (NPS). 2019-b. “Tools and Data.” GIS, Cartography & Mapping. Accessed April 11, 2020. https://www.nps.gov/subjects/gisandmapping/tools-and- data.htm. Neunhauserer, Daniel, Josef Sturm, Mira M. Baumgartlinger, David Niederseer, Eveline Ledl- Kurkowski, Eva Steidle, Martin Ploderl, Clemens Fartacek, Karl Kralovec, Reinhold Fartacek, and Josef Niebauer. 2013. “Hiking in Suicidal Patients: Neutral Effects on Markers of Suicidality.” The American Journal of Medicine. 126(10): 927-930. Newman, Greg, Don Zimmerman, Alycia Crall, Melinda Laituri, Jim Graham, and Linda Stapel. 2010. “User-Friendly Web Mapping: Lessons from a Citizen Science Website.” International Journal of Geographical Information Science. 24 (12): 1851–69. Olafsdottir, Rannveig, and Micael C. Runnstrom. 2013. “Assessing hiking trails condition in two popular tourist destinations in the Icelandic highlands.” Journal of Outdoor Recreation and Tourism. 3-4: 57-67. 88 Parker, Christopher J., Andrew May, and Val Mitchell. 2013. “The role of VGI and PGI in supporting outdoor activities.” Applied Ergonomics. 44: 886-894. Petzoldt, Paul. 1976. “Petzold’s Teton Trails: A hiking guide to the Teton Range with stories, history, and personal experiences”. Wasatch Publishers. Pickering, Catherine, J. Guy Castley, Wendy Hill, and David Newsome. 2010. “Environmental, Safety, and Management Issues of Unathorised Trail Technical Features for Mountain Bicycling.” Landscape and Urban Planning. 97: 58–67. Polar Geospatial Center, C. Porter, P. Morin, I. Howat, M. Noh, B. Bates, K. Peterman, S. Keesey, M. Schlenk, J. Gardiner, K. Tomko, M. Willis, C. Kelleher, M. Cloutier, E. Husby, S. Foga, H. Nakamura, M. Platson, M.J. Wethington, C. Williamson, G. Bauer, J. Enos, G. Arnold, W. Kramer, P. Becker, A. Doshi, C. D’Souza, P. Cummens, F. Laurier, M. Bojesen. 2018. “Arctic DEM.” Harvard Dataverse, V1. Accessed January 14, 2020. https://doi.org/10.7910/DVN/OHHUKH. Rutherford, J., H. Kobryn, D. Newsome. 2015. “A case study in the evaluation of geotourism potential through geographic information systems: application in a geology-rich island tourism hotspot.” Current Issues in Tourism. 18(3): 267-285. Santos, T., R.N. Mendes, A. Vasco. 2016. “Recreational activities in urban parks: Spatial interactions among users.” Journal of Outdoor Recreation and Tourism. 15: 1-9. Saupe, Julie. 2019. “Visit Anchorage: 2018 Report to the Community.” January 17, 2019. https://assets.simpleviewinc.com/simpleview/image/upload/v1/clients/anchorage/Visit_A nchorage_Report_to_the_Community_1_17_2019_ccdea845-a2a4-4fe7-a815- 92043ab7572e.pdf. Schultz, Courtney, Robby Layton, Michael B. Edwards, Jason N. Bocarro, Roger L. Moore, Stephanie Tepperberg, Attila Bality, and Myron F. Floyd. 2016. “Potential Measures for Linking Park and Trail Systems to Public Health.” Journal of Park and Recreation Administration. 34 (1): 4–23. Troy Maridy McNeff, and Maurice Phipps. 2010. “The validity of Petzoldt’s Energy Mile Theory.” Journal of Outdoor Recreation, Education, and Leadership. 2(3):245+. U.S. Department of Agriculture Forest Service. 2019. “FSGeodata Clearinghouse.” Accessed December 15, 2019. https://data.fs.usda.gov/geodata/. U.S. Fish and Wildlife Service. 2019. “USFWS National GIS Data.” USFWS Geospatial Services. Accessed December 16, 2019. https://www.fws.gov/gis/data/national/. Vries, Sjerp, Robert A. Verheij, Peter P. Groenewegen, and Peter Spreeuwenberg. 2003. “Natural environments – healthy environments? An exploratory analysis of the relationship between greenspace and health.” Environment and Planning A. 35: 1717- 1731. 89 w3schools.com. 2020. “How To – Snackbar/Toast.” Accessed May 7. https://www.w3schools.com/howto/howto_js_snackbar.asp. White, Eric, J.M. Bowker, Ashley Askew, Linda Langner, J. Ross Arnold, and Donald B.K. English. 2014. “Federal Outdoor Recreation Trends: Effects on Economic Opportunities.” National Center for Natural Resources Economic Research. 1: 1–37. Wimpey, Jeremy, and Jeffrey L. Marion. 2011. “A spatial exploration of informal trail networks within Great Falls Park, VA.” Journal of Environmental Management. 92: 1012-1022. 90 Appendix A. Web Application Scripts A.1 Script import of ArcGIS API for JavaScript 4.14 and AMD module 91 A.2 Create new webmap that references a portalItem and define the view 92 A.3 Define layers and add to map 93 A.4 Layer pop-up design 94 95 96 A.5. Locate widget (my location) A.6 Home widget A.7 Bookmarks widget 97 A.8 Basemap Gallery A.9 Search bar 98 A.10 Layer list widget with legend 99 A.11 Filter widget 100 A.12 Coordinates widget A.13 Measuring toolbar HTML 101 JavaScript 102 103 A.14 Editor Widget A.15 Print widget 104 A.16 Snackbar Splash Screen JavaScript HTML (some text has been clipped) 105 A.17 Media tag in CSS for mobile browser functionality 106 A.18 Example of CSS used for webpage style 107 B. Pre-Development User Survey B.1 Questions 108 109 B.2 Responses 110 111 C. Post-Development User Survey C.1 Questions 112 113 114 C.2 Responses (1 = Difficult to navigate, 5 = Easy to navigate) 115 116 (1 = Difficult, 5 = Easy) 117 118

Abstract (if available)

Abstract Alaska is home to an extensive network of hiking trails that navigate a remote and diverse wilderness. Mapping applications are currently available to trail users, but each available option lacks either spatial extent of coverage, accuracy of data, or detailed descriptions of the conditions on the trail. Users can spend significant time researching descriptions and current trail conditions across websites and mapping applications in order to make proper decisions for planning routes and equipment. The website Alaska Hike Search (AHS) provides detailed descriptions of popular hikes across the state but lacks an in-depth mapping application for searching trails. The lack of information on current trail hazards and wildlife activity compounds the concerns for proper trip planning, creating concerns for the safety of hikers and other trail users. ❧ In this project, a web application was designed as a prototype for the AHS website that also allows for contribution of volunteered geographic information (VGI) of trail hazards and warnings. This project gathered spatial data available from the agencies and organizations that manage trails, with a focus on the 129 trails described on AHS. Where authoritative data was not available, spatial and feature data was collected from other hiking trail applications to complete the database. Alongside the creation of this database, a web application was designed through hypertext markup language and the ArcGIS Application Programming Interface for JavaScript 4.14. This web application allows users to discover trails near them, search for trails by name, and filter trails that meet their desired difficulty. Through an editable VGI dataset, users can provide hazards as point features for warnings to unsafe conditions, or wildlife activity, such as bears or moose near trails. This data is instantly displayed on the map for other users to view. Future work will include implementing this application on the AHS page, enriching data, designing additional tools and functionality, and developing a mobile application.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Generating trail conditions using user contributed data through a web application

PDF

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

PDF

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

PDF

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

PDF

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

PDF

Roadway hazard analysis: a safe ride for motorcycles

PDF

Silicon Valley construction project web mapping application

PDF

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

PDF

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

PDF

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

PDF

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

PDF

Developing improved geologic maps and associated geologic spatial databases using GIS: Candy Mountain and Badger Mountain, WA

PDF

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

PDF

Analysis of park accessibility in Redan, Georgia Web GIS application

PDF

Mapping punk music and its relative subgenres

PDF

GeosocialFootprint (2103): social media location privacy Web map

PDF

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

PDF

Finding your best-fit neighborhood: a Web GIS application for online residential property searches for Anchorage, Alaska

PDF

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

PDF

The role of precision in spatial narratives: using a modified discourse quality index to measure the quality of deliberative spatial data

Asset Metadata

Creator Wilson, Rebecca Michelle (author)

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

School College of Letters, Arts and Sciences

Degree Master of Science

Degree Program Geographic Information Science and Technology

Publication Date 07/14/2020

Defense Date 04/24/2020

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

Tag Alaska,ArcGIS,ArcGIS API,Javascript,OAI-PMH Harvest,trails,VGI

Language English

Contributor Electronically uploaded by the author (provenance)

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

Creator Email rebecca.m.wilson11@gmail.com,wilsonre@usc.edu

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

Unique identifier UC11664326

Identifier etd-WilsonRebe-8677.pdf (filename),usctheses-c89-329374 (legacy record id)

Legacy Identifier etd-WilsonRebe-8677.pdf

Dmrecord 329374

Document Type Thesis

Rights Wilson, Rebecca Michelle

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