Web Services

Telling a Story with GIS – The Creation and Implementation of ESRI Story Maps

Problem Description

Every year, buoys managed by the National Data Buoy Center (NDBC) become unmoored and go adrift.  The purpose of this project was to show how server hosted information could be used to create an application usable by the public for education purposes.  The created ESRI Story Map uses hosted data in a user friendly application where people can read and learn about oceanic buoys and how they become unmoored.

Analysis Procedures

Information about National Data Buoy Center buoys was downloaded from the NDBC website located at http://www.ndbc.noaa.gov/.  The site allows users to query buoys that are currently in maintenance and queries can be sorted based on the issues that are requiring them to undergo maintenance.  Buoys were selected that had become unmoored, or went adrift, and their locations downloaded in a csv file.  Five buoys met this criteria, one of them having become unmoored due to Hurricane Harvey.  These locations were plotted in arcmap making a point feature class for each buoy.  These feature classes were then uploaded into ArcMap and shared to ArcGIS Online (AGOL) as hosted feature services.  These services were then used to make an ESRI Story Map titled National Data Buoy Center Buoys Adrift in 2017.

Results

The images in Figure 1 below show screen captures of the front page of the Story Map and one of the information pages about a buoy in the Gulf of Mexico.   The buoy in the Gulf was the one dislodged by Hurricane Harvey and was adrift for 3 days before being picked up by a Coast Guard ship.  For more information, the Story Map can be accessed at http://ncsu.maps.arcgis.com/apps/MapSeries/index.html?appid=aac5a71116ba45188d0ba10b5b3bfb71.

Figure 1. The two images above are screen captures from the ESRI Story Map.  They show the front, or overview, page plus one of the pages dedicated to discussing each of the five buoy’s stories.  

Reflection

This was a fun project and the first time I created an ESRI Story Map.  It was of particular personal interest as it combined three of my favorite scientific fields: weather, the ocean and GIS.  It involved coming up with a scientific story, finding the information, downloading the information (in this case in text file format), creating a georeferenced dataset and hosting the information on AGOL.  Their visually appealing format makes Story Maps a great educational tool.  Also, they are immersive allowing readers to become a part of the story.  Adding configured pop-ups to the map is a quick way to create an interactive platform.  I found this an informative exercise in creating an interesting scientific story by using dynamic maps.

A Comparison of a Geoprocessing Service and the eSearch Widget

Problem Description

A geoprocessing service was developed to determine the most ideal location for a new high power transmission line within New River Gorge National River (NERI) located in West Virginia.  In addition to the geoprocessing task, an eSearch Widget was downloaded and configured to query locations within the NERI area.  The construction of this line was necessitated by a widespread black out that occurred along the east coast in 2003.  Since the transmission line is crossing a natural area, the impact of the line’s construction needed to be determined on aquatic and terrestrial animal species and on tourism as there are historic buildings located within the New River Gorge area.

Analysis Procedures

To create the geoprocessing task, a model was created in ArcMap’s model builder.  The goal was to define a corridor for a new transmission line then return the vertebrate observations, aquatic observations and historic buildings within that corridor.  Figure 2 shows the geoprocessing task viewed in model builder.  After creating a new power line project using the Smart Editor widget, the geoprocessing widget allows the user to choose a layer (the new power line project) to create a corridor around (buffer) then clips the buildings, vertebrate observations and observation sites layers to that buffer.  The three clipped layers are displayed using different symbology to highlight their proximity to the projected power line.  Figure 2 also shows the Geoprocessing widget dialog box where the ‘HPT Line Project’ layer has been selected.  Only one feature is present in the layer for this example but the widget allows for selection of a single feature when multiple projects have been defined.  The default distance is 2 Miles (the numerical value and units can be changed).

Figure 2. The images above show a model builder version of the geoprocessing service and the dialog box that opens when the service is clicked in the online web application.

The web app also includes the independently created eSearch widget.  This was downloaded and added to the Web AppBuilder 2.3 edition.  As with the geoprocessing task, the user must first define a high power transmission line project using the Smart Editor widget.  The first step in using the eSearch widget is to select the feature to be buffered (again the new power line project).  This is done through the ‘By Shape’ tab in the widget.  Next, a buffer is created around the selected shape.  The ‘Results’ tab shows the features within buffer created around the power line plus the ability to display an attribute table of the selected observations and buildings.

Results

Figure 3 shows the results of the geoprocessing task and the eSearch widget.  The results of the geoprocessing buffer and clip show the observations, observation sites and buildings within a 2 mile wide buffer around the power line.  The eSearch widget results screen capture depict a 1 mile corridor (defined by the user) around a projected power line location with a list of the vertebrate observations within that corridor.

 

Figure 3.  The above screen captures were taken from the NERI web application after running the geoprocessing service and the eSearch widget over projected high transmission power line locations.

Reflection

For future studies, I’d lean towards using the eSearch widget as it’s more intuitive then a geoprocessing task.  Plus, the eSearch widget allows the user to have more freedom to conduct analyses that may be useful to them then whatever is ‘hard coded’ within a geoprocessing task.  Many different types of selections can be made (spatial or by attribute) where a geoprocessing task limits the user to only the variables or analysis methods chosen by the developer.  When considering the process of analyzing a problem, the developer must decide on a process for geoprocessing while the user can decide on their own process using the tools a developer provides in the enhanced search widget.

The fundamental difference between configuring a geoprocessing widget and the enhanced search widget involves the amount of decisions a developer lets the user make.  The geoprocessing widget is ‘hard coded’ to choose certain layers and has limited variables that can be modified by the user.  Therefore, configuring the widget mainly involves aesthetics like label names and symbology.  The eSearch widget configuration has the developer choosing layers for the widget and deciding what functionality the user will have available.  More time is spent adding spatial tasks to the eSearch widget then the geoprocessing widget.