Lab 7: Volunteered Geographic Information (VGI)

Goals

Volunteered geographic information, or VGI, is a form of geographic data collection which allows the general public to both collect and upload GIS data. The main goal of this lab was to learn how to develop a web GIS VGI application which can be used by the general public to report GIS data. First, we were given a hands-on experience of how to create the necessary domains and subtypes for enterprise geodatabase features. Next we prepared a feature template specifically for the type of data we wanted the end-user to collect. Then we created editing services to allow the data to actually be collected and developed a user friendly interface for the app, verifying the integrity of the data which is added by the public via the application. 

Methods

Part 1: Authoring a Map Document to Support Feature Services and Web Editing
In the first part of this lab, we authored a map document in order to enable end-users to add points, lines and polygons to a VGI Web GIS application. For example, we will allow for users to add different types of features including fire hydrants, sidewalks and green spaces as well as assign them attribute data. 

We were given the follow scenario to develop our VGI application:
"The City of Eau Claire has contracted your geospatial company to efficiently collect information about the status of public infrastructure in the city within a two week period. The city only has limited amount of money to pay you for this project. You have examined the money your company will make from this project and realized that the most economically feasible way of executing this project is to crowd source the task to the general public as you won’t afford to hire field workers or send your staff members to the field. A VGI app is absolutely essential for a successful completion of this job. You will use and accentuate your web GIS app development skills in this project."

To start we needed to create attribute domains and subtypes for the three main features we will be incorporating in to this VGI application: fire hydrants, sidewalks and green spaces. Domains are simply rules which are placed on the values that are accepted within fields of a feature class. To do this we used ArcMap and created a new geodatabase. In this new geodatabase we defined the domain properties for our three feature classes (Fig. 1). It's important to define the domains in order to limit the amount erroneous information entered by end-users collecting information using this app. 

(Fig. 1) This displays the database properties defined when creating our VGI application feature classes.

Once this was done we added an Esri basemap and focused on the UW-Eau Claire campus to collect our data. Next we created a new point feature class named Fire_Hydrant. In the process of creating this new feature class we added different fields and were able to determine their properties. For the fire hydrant fields we added a TYPE field and set its properties to be the same as the ones we defined in the domain of the geodatabase specifically for fire hydrants. This includes two coded values which classify the fire hydrant as either red or yellow. We also added a COMMENT field so when the end-user is in the field they are able to add comments if they wish to. Once this feature class was created we then made another new feature class for sidewalks. The fields included in the line feature class was a coded CONDITION field which allows the end-user to classify stretches of sidewalk based on their condition of either being very good or needs repair and also the COMMENT field. The final feature class we created was a polygon feature class for green space. The fields used in this class were again the COMMENT field and a HEALTH field which allows the users to describe the health of the vegetation in the green space as either lush or needs fixing. 

After these properties were added and the feature classes were created we wanted to allow the end-user to upload attachments to the data they collect. To do this we needed to create attachments for each of the three feature classes. 

Since creating a simple and easy user interface is of great importance when developing a VGI for the general public as we are we needed to change the symbols of our features. We did this to make it clear what type of data the end-user is collecting (Fig. 2).

(Fig. 2) To increase the usability of this VGI application we changed the colors of the symbols in order to make it more clear to the user what type of features they are creating when adding data using the application.

Part 2: Prepare your Enterprise Geodatabase Feature Template for Publishing

After creating the feature classes we need to prepare the document to be published via ArcGIS server. To do this we connected to the ArcGIS server on our campus and shared the files as services and then published them to our personal folder within the Geography department enterprise geodatabase. Just before publishing the features however we need to edit the service to enable feature access capabilities. This will allow users to edit, delete and add data in each of the feature classes. Once this is done the services can be published and will be incorporated into the coding in part 3 where we produced the application itself. 

Part 3: Consuming the Feature Service in a Web GIS Application

The first step in creating a VGI Web GIS application was designing the webpage which will host it. We started by creating an HTML 5 document including relevant meta tags like the ones which will make the application compatible on both iOS and Android mobile devices. We also referenced the dijit claro and Esri stylesheets (Fig. 3).

(Fig. 3) The start of the HTML code for our VGI application includes meta tags to make our app compatible on a variety of mobile devices and also references stylesheets we will use.

Next, we started to write the internal stylesheet which we used as a part of the VGI app user interface. We incorporated properties for the user interface body, template picker and panel header (Fig. 4). 

(Fig. 4) This is the internal CSS document created in this lab to enhance the design of the VGI web GIS application we are creating in this lab.

The next code document we created was the JavaScript in order to program the behavior and function of the VGI app. We started the JavaScript document by declaring the "map" variable and importing several modules and dijits from the Dojo library as well as modules from Esri. After the map variable was declared and we imported the necessary modules we declared a function to define several definition parameters (Fig. 5).

(Fig. 5) At the start of the JavaScript code for our VGI application we imported various modules as well as dijits from the Dojo library and Esri and also declared a function to define the parameters of these modules.

Then we called the parse() function in order to execute the dojo dijits as well as enabled the snapping, identify proxy and reference the Esri geometry service. After this we created a new map object and set the values of the map to make sure that the map is centered on the UW-Eau Claire campus (Fig. 6). 

(Fig. 6) This block of code shows the enabling of the Esri geometry service and other features.

Next, we incorporated the feature classes we created in parts 1-3 to our VGI app. To do this we needed to assign the editing module imported from the Dojo library to each of the feature objects individually. To do this we created three variables, one for each the point, line and polygon feature access service we published previously. As seen in Fig. 7 we referenced the feature services. 

(Fig. 7) These lines of code show how the feature classes we created in part 1 and published in part 2 were linked to the VGI application.

Once this is done we called the method which adds these features to the map, resizes the infowindow  and creates an event function. The event function works to "listen" for interactions between the end-user and the VGI application (Fig. 8). After this we added some additional map and parameter settings as well as parameters used in the editor widget and the snapping function of the map (Fig. 9). That was the end our our JavaScript document. The final step was connecting our CSS and JavaScript documents to the original HTML code we started. The output of this map can be seen in Fig. 10 under the results section of this report.

(Fig. 9) This code enables the app to incorporate the feature services in Fig. 8.

(Fig. 10) This image shows additional code used to add extra settings to the VGI application.

Part 4: Developing an Independent VGI Application to Collect Additional Data
In the final part of the lab, we were tasked with the job of using the skills we learned in parts 1-3 to create our own VGI application. The final product can be seen in Fig. 11 the results section.

Results

(Fig. 10) This is the output of the VGI application we created for the City of Eau Claire in parts 1-3.

(Fig. 11) This image shows the VGI application I created in part 4 of this lab report.

Sources

Data for this lab was collected from the following sources:

• Geometry service from Esri
• Red fire hydrant picture from www.dreamstime.com

Lab 6: ArcGIS API for JavaScript 2

Goals

The main goal of this lab exercise was to learn how to create Web GIS applications responsive in mobile platforms. First, we developed a search app which the end-user can interact with in order to search for addresses of places, information about senators, congressional districts and institutions of higher education. Secondly, we made a query application which returned both text and graphic census information for counties in the state of Wisconsin. 

Methods

Part 1: Creating a Search App

We were first presented wit a scenario for this part of the lab:
"The geospatial company which you established in Lab 4 is slowly taking root in the geospatial business. It is now time to expand your services from only desktop Web GIS applications to mobile responsive apps. In this lab, you will gain some of the skillsets required in developing mobile responsive Web GIS apps. In a year, you want your company to be large enough to be able to buy Virtual Geospatial Analytics your initial employer. You will acquire the necessary skills required in building a search app and a query app which should form part of your company’s services to clients in the near future."

In this portion of the lab we created a basic search applications which end-users can utilize in order to find locations of a variety of information including congressional districts, senator locations, addresses and the location of universities throughout the United States. To do this the end-user will simply just have to type in an address and the application will do the work of locating the point on a map. To create this app we first created an HTML 5 document and referenced the Esri stylesheet. Next we added a header tag which included a great deal of information. This tag contained meta information which was able to make the application responsive in a number of different platforms. Viewport for iOS, applie mobile web responsiveness and Chrome for Android were added in particular as well as a reference to the claro stylesheet (Fig. 1)

(Fig. 1) This image shows the start of the code used to create the HTML document for a search application. In order to make it accessible to mobile devices meta information tags are added in the header.

Unlike in previous labs, most of the CSS styling we used in this particular application was created and referenced from external sources. We did however need to write some style information in the HTML code in order to make sure the application fills the entire webpage (Fig. 2).

(Fig. 2) Even when CSS styling for an application comes from external sources it is important to include the necessary information under the style tag to make sure that the extent of the application fills the screen of the user.

The next step was to write the JavaScript code to implement the search capabilities to the application. We imported the map, search, FeatureLayer, and InfoTemplate from the Dojo library and made the DOM ready to start this script. After that we created a function with the four parameters which would be used with the four modules we initially imported. In addition to this we created a local scope variable which assigns values to variable properties in the basemap like the type, center and zoom (Fig. 3). 

(Fig. 3) The imported features we used for this JavaScript code are from the Dojo Library, they include the map, search, FeatureLayer and InfoTemplate parameters.

In order to implement the search feature we needed to declare a new variable and assign it to an object called search. We then designed the button so that the search widget would be displayed as a single button. To set the information which will be able to be searched by the end user we created the source.push object. This first object utilized the congressional district service. We then created another similar sources.push object for the US Senator names and location followed by another object to display university data (Fig. 4). Finally, once this was done we linked the JavaScript file to our HTML document and the application was created (Fig. 5)

(Fig. 4) This image shows the source.push objects which were used to incorporate the data into the application which would be able to be searched by the end user.

Part 2: Creating a Query App

In part 2 of this lab we created a mobile responsive query application which allow for the end user to see the population of each county in the state of Wisconsin as well as how the population of each county compares to the most populous county in the state. This also incorporated hovering which enables the user to see the data without actually needing to click on a specific county. 

Once again, to start this lab we created a new HTML 5 document and entered in the relevant meta and external stylesheets similar to how we started part 1 (Fig. 6).

(Fig. 6) This is the start to the HTML 5 code created for part 2 of this lab.

After the HTML code was started we then began to develop the JavaScript document needed to produce the query application. We imported tools from Esri, Dojo Libary and two widgets from the DojoX sub-library. These tools included the map, FeatureLayer, query, ContentPane, BorderContainer, AnalogGauge, and AnalogArcIndicator (Fig. 7).

(Fig. 7) This shows the list of tools imported to the JavaScript document for the query application.

Next we needed to create a list of variables. The first was a variable called countiesUrl which was assigned a hyperlink which was linked to census data. Another variable we created was called statList which we gave a value of 'Wisconsin'. The rest of the variables can be seen below in Fig. 8. This included the variables for the query definition, the fields where records were to be extracted from, the design of the graphics for the returned records and more.

(Fig. 8) In these lines of code we defined a number of important variables for this query application.

After all the variables were defined it was time to initialize the query task. To do this we created a new variable called popQueryTask and to it we assigned the value of the Esri service we referenced previously. We then created another separate variable called popQuery to assign it the query task method and statDef to assign the query task definition. Once these three variables were configured in the JavaScript document we created a query filter for string, number and geometry (Fig. 9).

(Fig. 9) To actually initialize the query task we needed to add more specific query variables to the JavaScript document we were writing.

Once this was done we needed to create a layer in order to show the result of the query. For this app we used the analog gauge widget which was imported as a part of the DojoX sub-library earlier. The code used to create this widget as well as the design elements which it was composed of can be seen in Fig. 10 below. In addition to this we needed to specify in our code how we wanted this gauge widget to be displayed within our application. The detailed code of how this was done can be seen in Fig. 11.

(Fig. 10) This code shows how the analog gauge widget, from the DojoX sub-library, was utilized for this query application.

(Fig. 11) These lines of code within the JavaScript document detail how the analog gauge widget will be displayed in this query application window.

We also wanted to develop a styling for the map, the text, gauge result, county result and the margin for the webpage which will house the application. To do this we created our own CSS document (Fig. 12).

(Fig. 12) The image above shows the CSS code used to design the style of the application.

The final step in creating this query application was to link our JavaScript and CSS files to the original HTML 5 document we created at the start of part 2. Once this was done our application was created and was very user interactive (see Fig. 13 in the Results section).

Results

(Fig. 5) This is the output of Part 1 of this lab once the University of Wisconsin Eau Claire was searched for by the user.

(Fig. 13) This shows the result of the query application we created in part 2 of this lab exercise.

Sources

Data for this lab was collected from the following sources:

• University feature class obtained from Esri InfoGroup Business Locations dataset

Lab 5: ArcGIS API for JavaScript 1

Goals

The goal of this lab was to use the ArcGIS Web AppBuilder, as we did in Lab 3, to create an app which has operational layers, is time aware aand has feature access services. The JavaScript API is an interface which allows programmer to build themes, widgets and other analytics from scratch based on components of existing apps. ArcGIS API for JavaScript is a simple way o embed maps and tasks into various web GIS applications and in this lab we will learn use the skills we have previously learned such as HTML, CSS and JavaScipt coding. 

Methods

Part 1: Creating a Basic Web GIS Mapping App

In the first part of this lab exercise we completed the following list of tasks:

• Set up a basic HTML document
• Set up a basic JavaScript document
• Reference the ArcGIS API for JavaScript in your HTML document
• Use a basemap from ArcGIS Online
• Specify the map zoom level and center point
• Display the map full screen

We first set up a basic HTML document and then referencing an external CSS style sheet as well as the style sheet for web maps created by Esri. We linked the CSS style sheet by using the link tag which connects our individual application to the Dojo Dijit theme, particularly in this case the claro theme. The Esri style sheets are used to style features on a web map and since most of the styling for this map was done externally using the claro style sheet we wrote a CSS file to include it (Fig. 1).

(Fig. 1) To create the HTML document for this portion of the lab we linked various external style sheets.

Based on the code which we used to define the style (lines 10-14 in Fig. 1) the map will fill the web browser. Next we referenced the ArcGIS API for JavaScript version 3.14. For the body of the script we are using the claro stylesheet as mentioned above and therefore define "claro" as the body class (Fig. 2). 

(Fig. 2) The body class was defined as claro and referenced the JavaScript file to be used in this part of the lab.

Once the HTML document was complete we created the JavaScript code which would be used with this Web GIS application. We connected to the Dojo library by using the "require" tag in order to import the modules which we used for the map as well as the document object model (DOM) of our HTML file. Next we added the map by declaring the map variable and specifying the specific properties and property values to ensure the following values: the zoom level, center coordinate of the map and that the map type was street basemap. After all this was complete we were finished with our JavaScript file for this portion of the lab, (Fig. 3).

(Fig. 3) This shows the JavaScript used in part 1 of this lab.

Before deploying the web application we needed to make sure that we linked the JavaScript text to our HTML document. The result of part 1 can be seen in Fig. 4 in the results section of this blog post.

Part 2: Build a Web GIS App with Operational Layer Functionality

In this part of the lab we first developed a JavaScript method to display tree species and attributes for the City of San Francisco. To do this we started by creating a new HTML 5 document and referenced two different external stylesheets. 

After getting the HTML document set up we then started the JavaScript text. We entered the require command to access the modules for dojo DOMs, dojo string, myModules and Esri. Once this was done we created a function with the parameter definitions for the various components of the app as listed in the previous sentence (Fig. 4). Next, we created an infoWindow variable with arguments  in order to create a new infoWindow. Then we declared a map variable that was assigned the value of a new map object with coordinates specific to Eau Claire. Once this was done we declared the new template variable which was used to display the popup content when an end-user clicks a feature on the application. The final variable we declared was the featureLayer which referenced a feature service of the study area (Fig. 5). After we linked the Eau Claire schools feature class to the JavaScript document we were able to view the output (Fig. 6).

(Fig. 4) This shows the list of modules accessed for this lab.

(Fig. 5) This is the JavaScript used for part 2 of the lab.

Part 3: Developing a Simple Routing Application

In developing a simple routing application we wanted to accomplish three main objectives. First, we wanted the user to be able to click on the map and add stops to a route, we also wanted a route to be calculated after at least two stops were added and finally we wanted the route to be extended when subsequent stops were added to the map. 

After setting up the basic <html>, <head> and <meta> tags we added the viewport tag in order to make the application responsive in ISO devices (Fig. 5). Next we referenced two external style sheets which we have used in the past, the esri and claro style sheets. 

(Fig. 7) The start of the HTML code for part 3 of the lab.

The next step was to create a new document to write our JavaScript code. The first thing we did once the document was started was to connect to the Dojo library using the "require" command which allowed us to connect to graphics, route task and modules for maps and other routing parameters which we needed for this app. We then added code to also added lines of code to invoke the Dojo modules for color as well as the dijit registry. This dijit registry gave us the ability to invoke modules for design features like the horizontal label rules, horizontal slider and border containers. 

We then needed to write a function with multiple definition parameters to close the require command and leverage the Dojo modules we did in the previous step. These variables included the stop symbol, lastStop, routeSymbol etc. 

Next we created a new map object in the JavaScript code in which we used the "streets" basemap via Esri and we centered the map to the Eau Claire area by entering in the latitude and longitude for Eau Claire. Then we created an event which would cause a stop to be added when the end-user clicks on a particular portion of the map. We then referenced the network service from the Esri sample server 3. To further set up the route parameters we used the following code seen in Fig. 8. In addition to this we wrote an argument to solve the route task and show the results on the map within the application. 

(Fig. 8)

The final step was to create an errorHandler function with the error (err) definition parameter so that an error message is sent to the user if an erroneous route is requested (Fig. 9).

(Fig. 9)

After linking the JavaScript file to our original HTML document created in the beginning of this part of the lab our application was launched with routing capabilities. (An image of the output of this can be seen in Fig. 10 in the results section of the lab.)

Results

(Fig. 4) This is the output image of the first part of the lab.

(Fig. 6) This is the output of part two of this lab.

(Fig. 10) The final routing application created in this lab in part 3 can be seen here.

Sources
Sources for this lab are listed below:

• EC_Schools feature class was obtained from MapCruzin.com at: 
• http://www.mapcruzin.com/geographic-names-shapefiles/#School
• EC_Schools_Address was assembled by GEOG 455 class, fall 2013Widget_infowindow files   were provided by Esri at :
• https://developers.arcgis.com/javascript/jssamples.html

Lab 4: Basic HTML, CSS and JavaScript

Goals

The objective of this lab was to introduce us to languages including JavaScript in order to give us a better understanding of how to develop Web GIS applications using the ArcGIS API for JavaScript. Not only were students exposed to the basic coding techniques and syntax of HTML (hypertext markup language) and JavaScript but also CSS (cascading style sheets). The overall goal of this lab was to give us the ability to develop our own website using all three languages from scratch.

Methods

Part 1: Developing a Web Page Using HTML Tags

In this first part of the lab we used Notepad++ to write basic HTML tags in order to introduce our web page with some basic information. Notepad++ is a text editor which is used for coding and editing various script languages including HTML, JavaScript and more. The first part of our code (Fig. 1: left) and the output (Fig. 1: right) defined the script as HTML code as well as created a set of three headers. Every additional header from the first one is smaller than the next because of their hierarchical nature. 

(Fig. 1) This image shows the first set of code we created on the left and the output of this code in a web browser on the right.

Next, we created a new paragraph using the <p> tag and created an unordered list with a title which was bolded using the <strong> tag. To create the unordered list we used the <ul> tag and before each line of text used the <li> tag . As can be seen in Fig. 2 on the left is the code used to create the list of my hobbies for this part of the page and on the right is the output. 

(Fig. 2) On the left is the code used to create the output HTML page on the right.

Part 2: Styling the Various Sections of a Webpage
Once the base of the webpage is created we created the CSS to stylize it. To do this we again used Notepad++ but created a new document which we titled "overall design" in order to keep track of what the purpose of each text file was. We started out buy giving the body a background color as well as defining the font for the webpage text. Then we adjusted the wrapper and header. After the CSS file has been created the next step is to link it to the HTML file created in Part 1. Once this is done we can see the results of the styling code in the HTML code (Fig. 3). We are then able to continue to edit the CSS by adjusting the settings of the footer and sidebar. 

(Fig. 3) The upper left screen shows the overall HTML code used to create the webpage on the bottom while the code on the right hand screen is the CSS file which was used to add the colors to the webpage.

The next thing we can do to improve our webpage is adding forms to the HTML code. To do this we simply use the <form> tag and specifying the labels for the input value and the type of information to be inputted into the form field. The code for this step can be seen in Fig. 4 on the left and the output can be seen in Fig. 4 on the right. 

(Fig. 4) On the left hand side of this image the coding used to create the form field can be seen while the result of the code can be seen on the webpage on the right.

Another feature we added an image of the web application we created in Lab 3 as well as the link which would directly link the end user to the application itself. We were even able to add a border to the image in the CSS file. The code for this step can be seen in Fig. 5 on the left and the output can be seen in Fig. 5 on the right. 

(Fig. 5) This image shows the complete list of code for the CSS.

Part 3: Introduction to JavaScript

In part 3 of this lab we developed a simple way to fix the results box which was not formatted correctly in step 2. To do this we created a new Notepad++ file and declared the JavaScript language by applying the function of write results. The writeResults function in JavaScript gives a function a definition or parameter named a result. Then the variables which are declared and the arguments are executed by the function and are written within the { curly brackets }. We then wrote out our code and added comments to describe each step so if we reviewed it later we would understand our process. The Code for this process can be seen in Fig. 6. The final step in this process was to link the JavaScript file to the original HTML document we created in step 1 to include the code of the JavaScript file.

(Fig. 6) The screen on the left shows the working HTML code used to produce the webpage and the image on the right displays the JavaScript which was created and linked to the HTML code.

Results

The ultimate goal of this lab was for us to be able to create our own customized webpage. After being given the following scenario: 

"You have just started a company that provides Web GIS solutions to customers in a county and state of your choice. One of the most important method of disseminating your company’s services to existing and prospective customers is through a website. You will develop a webpage with the following features. 

 The name of your proposed company and other relevant information. 
 Company Logo. 
 Links to resources that will be useful to your end-users. DR. CYRIL WILSON UNIVERSITY OF WISCONSIN-EAU CLAIRE 28 
 Links to the Web GIS application you developed in Lab 3 and two non-secured Web GIS applications from Esri JavaScript website.
 An ordered list of six services that your company will be delivering. These services should be highlighted with a catchy color other than black. 
 A form that will enable end-users to search your website and company services. 
 At least two pictures that are of importance to your proposed company."

The result of this portion of the lab and the final goal can be seen in the image below along with the code which was used to create it. 

NOTE: I did have some fun with this activity and it is a bit silly. I did that by choosing a fun design and the idea, the skills I learned really stuck with me. 

(Fig. 7) The webpage I created from scratch using the skills I learned throughout this lab exercise.

Sources

The UWEC logo was obtained from the UW-Eau Claire website and part of the codes which were used in developing the applications were from Sylvia Richardson of Girl Develop It via Github (2015).

Lab 3: Web AppBuilder for ArcGIS

Goals

The goal of this lab was to introduce us to the process of building Web GIS applications with the Web AppBuilder for ArcGIS. In learning how to do this we were able to create our own applications, as well as author and add our own services like those we created in Lab 2: Geospatial Web Services. We also learned how to configure and integrate custom widgets the apps we created and were able to deploy the finished Web GIS application so it can be used by an end-user. The second goal of this lab was to give us some experience in conceptualizing about the coding which goes into the process of creating a Web GIS app, which is something we will be creating later using coding in future labs. 

Methods

Part 1: Building Web GIS Apps through Web AppBuilder Integrated Edition

In part one of this lab exercise we were given the following scenario: 

"You have been employed by Virtual Geospatial Analytics and you are tasked with creating a web
GIS application that displays historic earthquakes and hurricanes to the public. Your supervisor
want the web GIS app to be able to perform the following:

• Provide pop-up windows to show earthquakes and hurricanes.
• Zoom to the entire United States in its initial view.
• Provide bookmarks so that users can easily zoom to predefined areas.
• Allow users to chart and compare the selected attributes of selected earthquakes.
• Allow users to query for features based on their attributes.
• Display appropriate logo, title, subtitle, and links in the banner.
• Allow users to update recent earthquake information through batch editing."

The first step in this process was to create an app using the Web AppBuilder which is apart of ArcGIS Online. Once the Web AppBuilder was launched we were able to select one of our previous maps, in this case it was specifically the Natural Disasters map we created in lab 2. After our map was added to the app builder we then selected a theme. There are a variety of themes offered via ArcGIS Online including the billboard, box, dart, foldable, jewelry box, launchpad and tab but in this lab we used the foldable theme. 

(Fig. 1) The interface and setup to create the a web app using ArcGIS Online.

In addition to selecting a theme and color scheme we also added widgets to our web application. We first added the basemap gallery widget which allows the end user to view the map with a variety of different basemaps which they are able to chose themselves. Next we added the measurement widget which gives the end user the ability to take accurate measurements based on the map data. The bookmark widget is interesting because it allowed us to pan and zoom into a particular area of the map and create a bookmark of an area, in this case the western states. This bookmark is then available to the end user and will zoom them into the particular region we selected. 

Next we changed the attribute information for our web map and changed the title to "Historic Earthquakes and Hurricanes" and linked them to the UWEC Geography and Anthropology website.

We then added the chart, draw and query widgets. We were able to configure the chart widget by selecting the earthquake layer and choosing the location category and under the value fields selecting the magnitude data and creating a bar chart type. Next we created another chart which showed the earthquake locations as well as depth (km)  in the form of a column chart. 

(Fig. 2) A chart is a widget which can be created using the ArcGIS Online Web AppBuilder to display a more organized view of the earthquake data.

The query widget also needed to be configured. To do this we first needed to make sure that the option to "select from map" was checked and next we added an expression set. The expression we wanted to create was to select the earthquakes with magnitudes with a value of at least 4. Next we created a second query to select data with a location that contains Alaska and another which selected earthquakes with occurred in the year 2000. 

(Fig. 3) This is the window used to configure the query widget.

(Fig. 4) This image shows the output data from the query widget.

Part 2: Customizing WebApp Builder for ArcGIS (Developer Edition)

In part 2 of this lab exercise we learned how to use the developer edition of the Web AppBuilder which can be used to create a more customized web map. The developer edition is able to be run locally on the computer. To do this we first ran the developer start up file, specified the URL and began creating the web app. After registering the app we imported the app created in part 1. We were then able to edit and customize the app. In customizing the web app we added the batch attribute widget by selecting local file and it will then become a functioning attribute in the web app. 

(Fig. 5) The batch attribute editor utilized within the web app builder.

Results

Throughout this lab we learned how to create web applications using ArcGIS Online as well as how to integrate and customize widgets within these web maps. 

The map can be viewed at the following link: Historic Earthquake and Hurricanes

(Fig. 6) The final map can be seen above.

Sources

The data used in this lab was from the following sources and provided by Dr. Cyril Wilson of the University of Wisconsin - Eau Claire:

• Fu, Pinde (2015)
• \\EsriPress\GTKWebGIS\Chapter3\Data.gdb\Earthquakes, courtesy of USGS National Atlas
• \\EsriPress\GTKWebGIS\Chapter3\Data.gdb\Hurricanes, courtesy of NOAA National Climatic Data Center