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