Web GIS Lab 7

Goal and Background

This weeks lab was working with volunteered geographic information or VGI applications. VGI apps allow the general public to collect and upload features which are geo-located and add attribute information to it. These features combine to make GIS data so this VGI app allows for crowd sourcing data collection. 

In this lab we developed a web GIS application that allows the general public to collect and upload geographic information in the application. In other words we created a VGI application. These apps are very important in the field of GIS because they allow collection of data that without the help of the general public may not be able to be collected. 

There were 5 main goals for this lab.

1. Get experience setting domains and sub types for enterprise geodatabase features. 

2. Prepare a feature template for the types of VGI data that we want the public to collect.

3. Create feature editing services for the data to be collected.

4. Develope a simple user interface for the VGI app using ArcGIS API for JavaScript.

5. Verify the integrity of data added by the public.

Methods

Part 1 Authoring a map document to support feature services and web editing

Once again as in weeks past Dr. Wilson gave a scenario for what we would accomplish during this lab. It read as follows "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."

The first part of the lab ivolved creating a map document in ArcGIS that will be used to allow the public to add point, line and polygon features to in a VGI web GIS app. The step to doing this is set up the domains and sub types in our geodatabase. In order to this we right click on the geodatabase we want to use and select the domain tab. In this tab we are able to set up domains which will later be linked to new feature classes that will be created with the features for the map. Figure 1 is showing what the domain set up looks like in the geodatabase properties. These domains are telling ArcMap what kind of inputs allowed in to the feature and help when it comes to symbolizing the features. If you look at figure 1 you see that I have the condition domain selected. Condition means we are describing what shape something is in. For this app we are looking at sidewalks and whether they are in good shape or need to be repaired. The coded values 0 and 1 come into play in the next step when new features are created and we go to symbolize the features.

Figure 1 This is the domain setup in the geodatabase properties

Once the domains are set up the next step is to create the new features. First a grey scale base map is added. Then in the geodatabase we created a new feature class. Figure 2 is the first window that opens when creating a new feature. This is where you name the feature and choose if it is a line, point or polygon feature. For this example we created a feature for fire hydrants and made it a point feature. Then we choose the coordinate system in this case we used WGS 1984 Web Mercator because this app is going to be dealing with the whole world because any one anywhere can add data. Then the window in figure 3 opens. This is where you match up the feature class with the domain we created earlier. Right now the box is showing the field properties for the comments field name we added but when working with the feature class there would be a choice of which domain to link the feature class to and in this case we chose the type domain which is dealing with the color of fire hydrants.

Figure 2 First window for feature creation

Figure 3 Window for linking the new feature class to
the domains

Next step is to symbolize the new feature classes. This is done by opening the feature properties and going to the symbolize tab and then categories and unique values. When you hit add values the coded values from the domain will be loaded. If this doesn't work something isn't set up right. Those values can then be symbolized in any way you like but the symbols should make sense with what the feature is displaying. Figure 4 shows the symbology properties for the fire hydrant feature where I applied different colors to the two coded values for hydrants.Figure 5 is showing how the symbology will show up in the contents side bar. The sidewalk and green space features were created the same way I have described. The sidewalk is a line feature class and the green space is a polygon feature.

Figure 4 Symbology properties for feature classes

Figure 5 The symbolized features show in the table of contents

Once the feature are complete and symbolized correctly we can go ahead and add some to the map. This is done by starting an editing session and selecting the feature you want to add. To add it click on the map and the symbol will appear. Then you can add information about the feature by clicking the attribute editor this allows you to add information like when and where the point was collected and even attached an image if you feel is necessary. Figure 6 shows the feature I created in my map in an editing session.

Figure 6 Features added to the map in ArcMap before publishing

Part 2 Prepare your enterprise geodatabase feature template for publishing

Once your mxd. file is complete and set up the way you like you are ready to publish. This is done by connecting to an ArcGIS server and publishing this mxd. as a service. We name the service how we want and it is stored in the REST location where it can be accessed for use in the VGI app. We made sure that the features in this service are accessible to anyone using the app. If they are not set up correctly the general public would not be able to add data to the app and it would be useless. We are done with ArcMap portion of the lab and now move to the online set up.

Part 3 Consuming the feature service in a web GIS application

This portion of the lab is all about setting up a website where the app will be hosted. Again as in previous labs coding was needed. We set up an HTML document, JavaScript and CSS style sheet which you can see further details on how to do this in my labs 3, 4, and 5. Figure 7,8,9,and 10 are the code documents created to make this app work in a web browser and also for mobile applications, set up to work with both Android and iOS devices. As in the last couple of labs we pulled stylesheets and functionalities from the Dojo and ESRI libraries however we did create a CSS file for the coloring and other styles of the webpage in which the VGI app is included.

Figure 7 The HTML document for my VGI app 

Figure 8 The first half of the JavaScript code 

Figure 9  The second part of the JavaScript file

Figure 10 The CSS file we created to style the webpage the VGI app sits in

These code files are very similar to the codes for the last 3 labs but I want to point a one thing that I don't think I did in the last labs. Figure 11 is a portion of the JavaScript code that is used to put the features we created in ArcMap in part one and published to the REST into our app. Each one is linked to separately and are even separated by what kind of feature they are point, line, and polygon. If this portion of the code was not here or not working correctly when the app opened there would be nothing in the legend and the end user would not be able to add features to the map. When done correctly the exact same symbology the features were given in ArcMap will display in the VGI legend.

Figure 11 The JavaScript for bringing in the features created in ArcMap

Once the scripts are complete the index can be opened and the app should open in a web browser.If not there is an error in the code. Once you check if it works there is one more step we did. We took our files and placed them in the live server here on campus by doing this the app can be accessed over the internet by anyone.  Once our applications were in the liver server and tested to make sure they work we went out and collected some data on our smartphones which can be seen later on in my results section.

 Part 4 Developing an independent VGI application to collect additional data

After we finished our first VGI apps we got a chance to make our own. Following the instruction for the first 3 parts of the lab I created a VGI to aid in monitoring roads, boulevards and medians. I set up point feature classes of out door lighting types and trees. The lighting types are for reporting what kind of light street lights contain. The user can choose LED, fluorescent or incandescent lighting systems. This could be used to update the cities street lights all to LEDs saving power and increasing brightness. The trees feature is created to aid in monitoring the health of trees throughout the city. The end user can select healthy, dying or dead features to place on the map so that the city knows where trees need help or should be replaced. The final feature class is the roads which contained 3 rankings, smooth streets, some potholes and bumps and needs replacing. The public can aid the city in reporting sections of road ways that need work or could be replaced as well as comment on good section of road. For all of the additions the end user can add photos and additional information about the point. Figure 12 are the symbolized features in my app as well as basic instructions for the user. 

Figure 12 Some of the symbolized feature and instruction in my VGI app 

Results

These are the two resulting apps from this lab. Figure 13 is a link to the live VGI app created in parts 1 to 3 and figure 14 a screen shot of the VGI app I created.

Figure 13 VGI app created from part 1 to 3 of the lab
Please click here to go to the VGI app (In another browser other than chrome)

Figure 14 This is what my custom VGI app looks like

Sources

Red Fire Hydrant. (2015). Retrieved from http://www.dreamstime.com

Also made use of ESRI geometry services.

Web GIS Lab 6

Goal and Background

Last week in lab we used ArcGIS API for JavaScript in creating a couple of apps that were designed for non-mobile platforms. This week we used some of those same skills but will be adding some additional skill sets to take those non-mobile apps and make mobile responsive Web GIS apps. By adding additional pieces of code to the API and DOM our apps will be responsive on smart phones, tablets and other mobile platforms.

Under this overall goal there were two specific goals for this lab. First is the creation of a search app which end-users can use to search addresses, congressional districts, info about senators and universities. The second goal was to create a query app that will return both graphical and textual census info for counties in Wisconsin. 

Methods

Part 1 Creating a search app

As in the past couple of labs Dr.Wilson gave a scenario for this weeks 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." 

The first thing to do is to start creating the HTML and JavaScript codes that make the app functional. For this lab like lab 5 our css or style sheets will be coming from ESRI so we don't have to code those, instead we reference them in html code. Then we set the view port which is the extent that you see on a mobile device. It is important to set this so that the app displays correctly and is fully functional. Next is creating the search box where the end user will enter their search words. Figure 1 is the resulting html code for these first steps. At the bottom of the code you see a reference for a JavaScript file that we created as well as divisions between the search bar and map which will be displayed in the web app.

Figure 1 HTML code for part one of this lab. 

Once the HTML code is written the next step is to write the JavaScript file that will be referenced in the HTML. The JavaScript code is what contains all the code for the functionality of the search app. The features included in the JavaScript file are as follows.

1. The base map which in this case is a gray scale map which we have centered over a certain portion of the U.S and set a zoom extent. This ensures the map opens to this same location every time it is opened.

2.  The next portion of coding is for the search bar. In particular the congressional districts and information about the senators. This will allow the end user to search by the number of a district, the map will zoom to that district and highlight it.

3. A info template is set up so that when the map zooms to a district the end user can click on it and a box pops up which displays the district number, name of the senator as well as their party affiliation.

4. Additional search criterion are added so that universities of the U.S. are also searchable. In the same way that map zooms to districts it also zooms to searched universities and displays information including state, city and the last 4 digits of the zip code for the university.

Figures 2 and 3 are the JavaScript File for this portion of the lab which includes all the functionalities described above.

Figure 2 The first portion of the JavaScript

Figure 3 The other half of the JS file. All of this code is referenced by the HTML to give the app functionality. 

The combination of both of these files give you a mobile search app. Figures 9,10 and 11 in the results portion of my blog post show the functionalities of the app.

Part 2 Creating a query app

This portion of the lab is creating a simple mobile responsive app. The end user will use this app to see how the populations of the counties in Wisconsin compare to the population of the most populous county which is Milwaukee county. By touching the county in the mobile version or hovering over it in the desktop version the county information will display in an info window and population comparison will be displayed in a gauge.  

Just like in part one the first step is set up the HTML document for the mobile app. Figure 4 is the first portion of the HTML document where the relevant meta and external style sheets are referenced similar to part 1.

Figure 4 This is the HTML code for the first portion of part 2.

The next step is setting up the functionality of the app which is again done as JavaScript file. The functionalities we coded for include the following.

1. First is setting up the basemap which for this map is the oceans base map. Again the center and zoom extent is set and because this app focuses on the state of Wisconsin the map is centered over Wisconsin and set to a zoom level where the whole state is visible.

2. Next is linking to the selectable counties of the United States. This is done by referencing a county map server in the ESRI database. 

3. Next is setting colors for the borders of the counties. When the county is not being selected or hovered over the outline will be white. When it is being selected it will turn yellow. The counties themselves are set to gray with a percentage of transparency so that the base map is still visible through them.

4. In order for population comparisons to be performed we need to know which county has the highest population. All the other counties will be compared to this county. We write code in the JS file for the app to find the county with the max population in 2007 which in this case is Milwaukee County.

5. Next is making sure that only the data for Wisconsin is part of the query. The data set that the app is retrieving the stats from is data for the whole country so we set up a query filter which limits what data can be accessed. In the same way we want to make sure that only the counties of Wisconsin show up on the map. This is done by saying that any county in the state of Wisconsin should be displayed and no counties outside of Wisconsin.

6.Next is the gauge which shows what percentage a counties population is of Milwaukee County's population. We set up how the gauge will look with a background color of white, how big the gauge is, and what percentages show up. We have it displaying 0 to 100 percent in increments of 25. We also chose the gauge itself to be yellow and it will change instantaneously as different counties are selected. We also choose where the percent is displayed and in this case we chose to be in the middle of the gauge. Figures 5 and 6 are the JavaScript file for part 2.

Figure 5 The first half of the JS file.

Figure 6 The second half of the JS file.

A css style sheet is created that corresponds with all the functionalities and how they should appear on the app (Figure 7).

Figure 7 The style sheet for the functionalities of this query web app.

After the JavaScript and CSS files are written they need to be referenced in the HTML code. Figure 8 is the HTML code in its entirety for part 2 of the lab.

Figure 8 The HTML document for the mobile query app.

Results

For the first part of the lab creating the search app the resulting app and functionality is seen in figures 9, 10 and 11.

Figure 9 This is district 3501 you can see the district is highlighted a different color and when clicked on the text box pops up with information about the district.

Figure 10 This is using the university search functionality. I search for the University of Miami. Even when zoomed out the info box stays the same size so the info is legible.

Figure 11 This is the zoom extent that is set for when the end user searched a university. It zooms way in to the location of the school but is still visible zoomed out like in figure 10.

For the second part of the lab the app generated displays and functions as show in figure 12 and 13.

Figure 12 This is what the query app looks like when it is first opened. The counties of Wisconsin are gray but transparent enough to still see the base map. They have white boundaries. The info box and gauge are blank because no county is selected.

Figure 13 This is what it looks like in the app when a county is selected or hovered over. The county boundary turns yellow and the info box and gauge are filled with information about the county.

Sources

University feature class is obtained from Esri InfoGroup Business Locations dataset.