Web services have the potential to expose your data to a much wider audience than may have previously seen it. But beyond allowing simple visualization of the data, web services can also permit editing and creation of data over the web. This type of "web editing" can allow field workers and people who typically don't use GIS to contribute valuable information to your database, information that you might not otherwise get.

For all its benefits, exposing a database on the web comes with some challenges. How do you protect your data from becoming corrupted? If you put a database on the cloud, how do you keep it in sync with the database in your office? And what happens if multiple users edit a feature at the same time?

This lesson explores some of the requirements and challenges related to making a GIS database available for editing on the web. You'll put some data in a SQL Server Express database on your EC2 instance, and you will use that data to design a map for web editing. You'll learn about how ArcGIS Server provides a special type of "feature service" that is engineered to allow editing through a web service. Finally, you'll make a web application that allows others to edit your data over the Internet.

Throughout this lesson, you'll be guided with step by step instructions. At the end of the lesson, you'll post a screenshot of your work. Pay close attention to what you are doing, because next week you will be assigned a project in which you will have to think through these processes on your own.

Lesson Objectives

At the successful completion of this lesson you should be able to:

• create a feature service;
• create an application for editing your feature service using Web App Builder;
• understand GIS databases and web editing;
• understand how to set up your ArcGIS Server for web and feature services; and
• understand how to design a web map to support editing.

Deliverables

• Complete: L03: Assignment
• Participate: L03: Discussion
• Complete: Lesson 1 - 3 Quiz

The ability to expose a GIS dataset to Internet users and allow them to modify it presents some enormous opportunities and challenges. A GIS professional needs to carefully understand and weigh these considerations before making decisions about how to make data available for web editing.

Opportunities

Web apps for editing GIS vector geometries were cumbersome and somewhat rare until about 2005. Attributes could be sent to a database through a web service fairly easily, but sketching geographic features on a screen posed some different problems. How could vertices be drawn in the web browser in real time as the user sketched them, without the entire page refreshing? Or how could a user view a snapping threshold on the screen while making a sketch? These problems were somewhat alleviated when AJAX came on the scene.

The bane of web developers up to this point had been the necessity of doing a full send and retrieval of information to the server in order to accomplish anything, with the ubiquitous "page blink" occurring in between. AJAX was not a particular product or feature, but rather a technique that web developers devised to work with existing technologies, with the goal of making their apps more interactive.

JavaScript is a language web developers use to program actions on web pages (in contrast to HTML, which is markup language used to lay out the static elements on the page). AJAX stands for Asynchronous JavaScript and XML. Web developers discovered that they could use JavaScript to send and retrieve XML packets of information from the server to create certain effects in their applications, without doing a full refresh of the page or requiring any type of browser plug-in. This revolutionized the interactivity of web applications.

Perhaps you remember the first time you saw Google Maps. This was actually one of the first programs, mapping-related or otherwise, to really give people an idea of the power of AJAX. Google Maps used AJAX requests to request pregenerated map images as the user panned and zoomed, creating a smoother web map navigation experience than most people had ever seen. Virtually all major commercial web mapping sites now use this approach.

AJAX techniques helped open the door for interactive editing of GIS geometries through web applications. Users could now sketch edits on their maps and see each vertex of the sketch drawn in real time without being interrupted by page blinks or waiting for the browser to respond. They could press a key and immediately see a snapping threshold that would be applied to a vertex. People began to think about the ways web browser-based editing could improve their GIS. In more recent years, people have also began to consider benefits of smartphone and tablet-based editing.

Tailoring GIS to other professionals

There are often many individuals within an organization who lack extensive GIS training, but could still contribute valuable information to the GIS. These include receptionists, field technicians, planners, and managers. Web editing comes with several advantages for these types of professionals.

First, virtually everyone has used a web browser, so an intuitively designed web application can be much less intimidating for them than a full-featured desktop GIS program like ArcMap.

Another advantage is that the web app can be specifically tailored to certain editing tasks that are within the audience's realm of expertise - no more, no less. If you need field technicians to sketch the locations of telephone poles, you can design a web app that allows sketching of telephone poles and nothing else. You can make the symbols big and round and even tappable on a smartphone by someone wearing large gloves. You can make the app as simple as needed, remembering that a simple app can still collect very valuable information.

Opening the door to crowdsourced GIS and volunteered geographic information (VGI)

Because everyone knows how to use a web browser, web editing gives you the potential to allow everyone to contribute to your GIS. When might this be a good thing? When everyone knows something that you don't! Or when the power of everyone can create something more complete, useful, or accurate than you can create on your own.

Enter two buzz terms that have crept into the GIS world in recent years with the advent of web editing, crowdsourcing, and volunteered geographic information (VGI). Crowdsourcing is the idea of allowing anyone to edit an information repository, with the faith that this will make the repository more complete and accurate over time. Wikipedia is an example of a crowdsourced online encyclopedia. In the GIS realm, OpenStreetMap is an example of a crowdsourced street map of the world. People hold mapping parties for OpenStreetMap where they ride and walk around a town collecting data and then enter it all into a database. Regardless of your feelings on using crowdsourced data, this type of activity undoubtedly increases the quantity and accuracy of the data already in the database (especially if the database previously contained nothing).

Similarly, VGI allows individuals to enhance a dataset with information that they alone may possess. Whereas the term crowdsourcing evokes images of mass participation in the creation of publicly-available dataset, VGI is more versatile in that it can contribute to private or temporary datasets. For example, a city might set up a VGI application to allow citizens to report broken streetlights, graffiti, overgrown trees, and so on. This information may remain proprietary to the city and it may go away over time, unlike a crowdsourced database that is expected to remain more or less available.

Editing on tablets and smartphones

You've learned that the beauty of web services is that they communicate by common architectures and protocols like REST and SOAP, that can be invoked by any device with a connection to the Internet. These devices include the numerous tablets and smartphones that have hit the market in recent years. The ArcGIS Server feature service that you will create in this lesson could potentially be used in editing apps for the iOS, Android devices, or Windows Phone.

Smartphone and tablet-based editing greatly facilitates the field work and crowdsourcing scenarios that you learned about above. It's a lot easier to record something you see on a street, such as a pothole, if you can send it to the database right away from your mobile device. The editing app may even allow you to attach a picture to your feature that you captured just seconds before with your phone!

Challenges

Along with the benefits of web editing comes a number of challenges. These need to be well-understood and dealt with appropriately by anyone planning a web editing implementation.

Security

When thinking about web security, it helps to consider all the different tiers, or levels, at which someone can access your system. Then consider how each tier might be vulnerable and how it might be secured. With web editing security, you need to at least consider the application tier, the web service tier, and the data tier.

If this sounds confusing to you, let's talk through them one at a time. First, consider the application tier. You need to decide which people will have access to your web editing application. Is it open to everyone on the Internet? This is the easiest to set up, but it also results in the most vulnerability. Your organization's existing firewalls might also make it fairly easy to set up an application that's only visible to members of your internal network, in other words, people who work for your organization. A trickier kind of application security to set up is one that has a login page where only certain members of your organization are allowed to log in, but not others. Setting up this type of security is certainly doable, but is beyond the scope of this course.

The next level of security to think about is the web service tier. An organization can set up its server such that certain services require a login to access. If the application itself also requires a login, the application developer must figure out how to get that name and password to be applied to the services accessed therein.

Regardless of whether you decide to require a login for your services, you should consider which layers should have editing allowed. There are some datasets that you'll want to expose for web editing, and others that you will not. You need to design your web services such that they only allow editing of those particular datasets that you want to have modified. Several days before writing this lesson, I came across a web map showing election results in a certain country. The authors of this map had used a feature service with popup balloons to display the election results. This was not a bad plan; however, the web service authors had inadvertently left the editing capability exposed on the feature service. I discovered that I could potentially click a popup balloon and literally rewrite the election statistics for any particular province!

Your software will give you controls over which features may be edited, and you must carefully understand and use these controls. Sometimes you may be required to group editable layers in one web service and non-editable layers in a separate web service that has different security settings.

The final tier of security to consider is the data tier. By exposing your dataset for web editing, you are opening your database to many more people than would otherwise have access to it. You need to plan for the scenario where a malicious party could corrupt or delete your data. Keeping a backup or replica of your data is recommended in web editing scenarios.

Data integrity

In addition to the threat of a malicious party corrupting your data, it's possible that a well-intentioned user could make a mistake and negatively affect your database. Before you take all the changes submitted by your web editors and push them into your on-premises database, you might choose to have a GIS analyst examine the edits and perform a quality check. This type of scenario is possible if you maintain separate replicas or copies of the database for web editing and for on-premises work.

You can reduce the possibility of data corruption by carefully limiting the types of features and attributes that web editors can access and create. Later in this lesson, you'll use feature templates that ArcGIS provides for editing. The feature templates help you give the web editor a palette of approved features that can be created, while making it impossible or difficult to create other types of features. For example, if you want your web editors to add only 8", 12", or 16" pipes to the database (no 20" pipes, or fire hydrants), you can create a feature template with only those three types of pipes, with the size attribute preset for each one.

Database maintenance

You've learned in this section that keeping a copy of your data for web editing and a separate copy for your on-premises work can be a good practice for maintaining security and data integrity. The tricky part is synchronizing the two copies at the appropriate times, with only the appropriate changes. ArcGIS contains a feature called geodatabase replication that can help with this.

The simplest option for replication is to make a one-way replica of the geodatabase, which is essentially a one-off copy made in a desired projection and format. This is useful for exposing a read-only database for web use. Some sites use one-way replication into the mercator projection for their web database, since they need to use mercator on the web but not in their office.

A more complex, but more useful action is to make a two-way replica of your database. This creates a copy of the database for web editing that can be synchronized with the original (or "production") database at intervals that you choose. A GIS analyst can potentially examine the web edits before synchronizing them with the production database. If the two databases are separated by firewalls or reside on different networks, an ArcGIS Server geodata service can be used to synchronize the two. This is beyond the scope of the course, but it's important for you to have a basic knowledge of these architectures in case you ever need to implement them.

If replication is a new concept to you, or you would like to learn more about it, you can read the first several topics in the ArcGIS help section Managing distributed data [1].

GIS vector datasets come in many formats. Some of these are better suited to web editing than others. Since we are working with ArcGIS Server in this exercise, we'll talk about some of the data formats that Esri offers and which ones are required for web editing. You'll then load some GIS data into a database on your EC2 instance.

Whether you're working with Esri software or not, one of the most ubiquitous formats for exchanging GIS datasets is the shapefile. This is a data format developed and openly documented by Esri, meaning that other software companies are allowed to use, create, and share shapefiles. A shapefile actually consists of multiple files with the same root name and different suffixes (.shp, .dbf, .prj, etc.) that store the data's geometry, attributes, projection information, and so on. You'll often see shapefiles available on GIS data warehouse sites that allow you to browse and download geographic datasets.

A shapefile is handy for exchanging data, but it's not very useful for web editing. Because the shapefile is an openly documented file format, it may be possible for a web developer to write an application that edits shapefiles. However, this would be a significant amount of work and ArcGIS does not supply out-of-the-box web editing functionality for shapefiles. Nor does ArcGIS support web editing with the shapefile's more advanced (but less openly documented) cousin, the file geodatabase.

In order to perform web editing with ArcGIS Server, your data must be stored in the ArcGIS Data Store or in a geodatabase hosted in a relational database management system (RDBMS). Here's what those terms mean:

• The ArcGIS Data Store is a built-in data repository that comes with ArcGIS Enterprise. You can read more about it on the ESRI website [2]. It's intended to support data hosting needs for installations that don't have a fully-functional relational database management system and geodatabases. For production data within an organization, a geodatabase is recommended because it possesses many data management capabilities. However, for use cases in which data simply needs to be uploaded or visualized in a less-critical manner (via apps, for example), the Data Store offers a simple way to create "hosted" services and store data in your server environment.
• An RDBMS is a heavy-duty database used by enterprises to store large amounts of data. This includes GIS data, but RDBMSs also store many other types of datasets. Anytime you apply for a driver's license, fill out a hospital admittance form, or buy something online, your information is probably getting pushed into an RDBMS of some sort. Common RDBMSs include Microsoft SQL Server, Oracle, and the open source PostgreSQL. ESRI also supports a scaled-down version of an RDBMS called SQL Server Express that is offered for free by Microsoft.
• Geodatabases (you may also recall the term ArcSDE) are an Esri technology that allows data stored in an RDBMS to be easily used within ArcGIS. It provides features such as versioning [3] and replication [4] that allow you to maintain different branches and copies of your data to accommodate enterprise workflows.

Why are these things required for web editing with ArcGIS Server? One thing you have to consider is that when you configure editing on the web, you may not want to expose your main production database to everyone on the network. Your data is valuable. You may have spent thousands of dollars collecting it. It may be required to meet certain quality standards. To protect your data, you'll probably choose to expose a copy, or replica, of it for web editing. This replica goes on your EC2 instance. You'll keep a separate replica of the data in your on-premises environment. This on-premises replica can be protected by your firewall, data quality checks, and so on.

From time to time, you can synchronize the two replicas using ArcGIS software tools. This means that one replica gets sent the changes that were made to the other replica, and vice versa. ArcGIS Server even provides a special type of web service for synchronizing two replicas, called a geodata service.

Terms you may see during this lesson include geodatabase and feature class. Geodatabase is an Esri-coined term to describe a database containing related GIS datasets, tables, relationship classes, topologies, and so on. A feature class is a vector dataset within a geodatabase.

Creating a geodatabase in SQL Server Express

Let's load some data onto your EC2 instance and prepare it for web editing. Your whole goal is to make a map on your instance and expose it through an ArcGIS feature service, which is the type of service that you can edit over the web. The first step is to get the data onto your instance and load it into SQL Server Express.

The first part of this process for us is to install SQL Server Express and its required licensing and system components.

1. Before we begin installing a database on your server, download the following files to C:\data from our course management system; we'll need them in the next few steps:
   1. SQL Server Express 2017 installer
   2. ODBC 17 Driver
   3. .prvc license file that you used to install ArcGIS Server using the Cloud Formation template
       
2. .NET Framework 3.5 is a required component of the Database Server, which we'll install first:
   1. On your EC2 machine, open Server Manager from the Start Menu.
   2. Click the Manage tab at the top.
   3. Click Add Roles and Features.
   4. Click Next until you get to the Features section highlighted along the left.
   5. Expand the .NET Framework 3.5 Features section, and check the box next to .NET Framework 3.5.
   6. Click Next and Install to finish the installation of the .NET Framework 3.5.
       
3. With the .NET Framework installed, proceed to install SQL Server Express:
   1. Right-click the SQL Server Express installer and Run as Administrator.
   2. Choose the Basic install and Accept the terms.
   3. Install to the default location.
   4. When the install finishes, you'll notice on the confirmation window that your database instance is called SQLEXPRESS and your local Administrator user is designated as a database admin.
   5. Click Close.
       
4. Finally, install the required ODBC driver so that ArcMap is able to communicate with the version of SQL Server we installed:
   1. Double-click the ODBC 17 Driver install file.
   2. Accept the terms, accept the default settings, and finish the install.
       
5. To create an enterprise geodatabase in SQL Server Express we will need to provide a keycode file. The following steps take us through the process of generating one from our license file.
   1. Obtain the Authorization Number:
      1. We already have an authorization file (.pvrc), but we need to retrieve an authorization number from it to create the required keycode file.
      2. If you haven't already, download the .prvc file you used to install ArcGIS Server using Cloud Formation and save it in the C:\data folder on your EC2 machine.
      3. Right-click it and Open With Notepad to view the text contents of the file.
      4. Scroll down to the Features and authorization numbers section.
      5. Copy the code number next to ArcGIS Server. It should have the form, ECP123456789.
   2. Now we'll run a Software Authorization program to generate the keycode file:
      1. Open Windows Explorer and browse to C:\Program Files (x86)\Common Files\ArcGIS\bin.
      2. Right-click SoftwareAuthorization.exe and Run As Administrator.
      3. Select "I have installed my software and need to authorize it."
      4. Choose ArcGIS Server as the Product to be Authorized.
      5. Click Next.
      6. Choose "Authorize with Esri now using the Internet", and click Next.
      7. Leave the default values on the next couple of pages and stop at the Software Authorization Number page.
      8. On the Software Authorization Number page, paste the authorization number you copied earlier in the ArcGIS Server box.
      9. Select the option that you do not want to authorize any extensions.
      10. Click Next without checking any of the boxes to evaluate other products.
      11. Click Finish.
      12. Open Windows Explorer and browse to C:\Program Files (x86)\ESRI\License10.7\sysgen.
      13. You should see a new file called, keycodes. This is the file you'll provide to the database installer in the next section.
           
6. Now that we have installed our underlying RDBMS (SQL Server Express), our keycode file, which we'll use to authorize the database, and the required system components, we can proceed to create an enterprise geodatabase:
   1. Open ArcMap.
   2. Open the Toolbox and find the Create Enterprise Geodatabase tool under Data Management Tools and Geodatabase Administration.
   3. Run the Create Enterprise Geodatabase tool and select SQL_Server in the Database Platform dropdown.
   4. For Instance, type the name of the instance of SQL Server Express that you just installed: localhost\SQLEXPRESS.
   5. For the Database, enter a name, such as geodata. This will be the name of the geodatabase we create in our SQL Server RDBMS.
   6. Check the box next to Operating System Authentication. This indicates that we'll use our Windows Administrator login to connect to the database, rather than a separate user that we create within SQL Server Express.
   7. Uncheck the box next to Sde Owned Schema.
   8. In the Authorization File box, browse to the keycode file you generated earlier (C:\Program Files (x86)\ESRI\License10.7\sysgen\keycodes).
   9. Click OK to issue the creation of your geodatabase in SQL Server Express.
       
7. Download the Bighorn Sheep data [5] to your EC2 instance and extract it so that the datasets lie immediately under C:\data\BighornSheep. You can choose to download the data onto your local computer and copy it to the cloud using Remote Desktop (like we did in the previous lesson), or you can try to download it directly onto the instance through this web page.
   
   The data is a map document and a bunch of shapefiles showing Rocky Mountain bighorn sheep habitat and sightings in Carbon County, Utah. These were obtained from the State of Utah Automated Geographic Reference Portal (AGRC) [6] except for the sightings, which are fictional.
   
   You will prepare a feature service out of this data and create a web editing application that people can use to report bighorn sheep sightings. You'll also see how to expose the habitat boundaries for web editing.
    
8. On your EC2 instance, start ArcMap with a new empty map and make sure the Catalog window is displayed (click the Windows menu, then Catalog).
    
9. Expand the Database Servers node of the Catalog tree. Double-click Add Database Server, enter the Database Server name "localhost\SQLEXPRESS" and click OK. You should see your 'geodata' geodatabase inside the database server connection you just made.
    
10. Right-click your geodatabase 'geodata' and click Import > Feature Class (multiple).
11. For Input Features, browse to the lesson data folder you extracted at C:\data\BighornSheep and select all the shapefiles contained therein. (You may need to add a folder connection to the C: drive.) Use the Shift key to help you select multiple shapefiles.
     
    

    Figure 3.1 Selection of Shape Files
12. Click Add, and then click OK.
    You won't see anything except a small status bar in the lower-right corner of your ArcMap window. ArcGIS is using one of its geoprocessing tools to import the datasets into the geodatabase, and ArcGIS 10 introduced the concept of background processing that allows you to continue using ArcMap while a geoprocessing job is running. After a few minutes, you should see a small success message appear in the lower-right corner temporarily. If you miss the message, or if you just want to see how things are going, you can click Geoprocessing > Results and expand the tree to see messages about the current job.
    
    When the job completes successfully, you should see your datasets appear in the Catalog window under "geodata".
    
    In the end, you are going to allow editing for the sightings and sheep habitat layers. Now that you are accessing your data through ArcSDE, you are required to register these datasets as versioned before you can edit them. Versioning is an ArcGIS feature that allows you to have multiple working versions, or branches, of your dataset available. Edits made to these versions can then be incorporated into the master database as needed. Versioning allows you to have multiple editors working on a dataset at the same time.
    
    Since you're required to register the datasets as versioned, perform the following steps.
13. In the Catalog tree, find the datasets you just imported. Right-click your dataset named <Database name>.DBO.Sightings and click Manage > Register As Versioned.
14. Check the option Register the selected objects with the option to move edits to base, then click OK.
15. Repeat the above two steps to also register <Database name>.DBO.RockyMountainBighornSheep as versioned. This is the habitat layer.
    
    You don't need to do any more work with versioning beyond the above steps. However, if you want to learn more about versioning, you can browse A quick tour of versioning [3] in the ArcGIS Desktop Help.
    
    Now that you've got the database all set up, you'll register it with ArcGIS Server.
16. Realize that during the preceding steps, we were running ArcMap under the Windows user, Administrator. This user had been granted access to the SQL Server Express database earlier in our setup process. ArcGIS Server, however, runs as its own user, arcgis, which we configured during the install of Server with Cloud Formation. Therefore, we need to grant the arcgis user access to the database so that ArcGIS Server can read and write to it.
17. Right-click your database Server (localhost_sqlexpress.gds) in the Catalog window of ArcMap and choose Permissions.
18. Click Add User and enter arcgis in the box.
19. Click OK, and you should see the arcgis user added to the list, along with your Administrator user.
20. Select the arcgis user, and check the box designating this user as a Server Administrator. This may not be the best practice in a production setting, but since we're using the same users to perform multiple tasks, we'll be generous and grant it admin privileges. Click OK to complete the process.
21. In the Catalog window, find the GIS Servers node and make sure you are connected to your ArcGIS Server (this requires double-clicking the node if you see a little red x). Then right-click your ArcGIS Server connection, and click Server Properties.
22. Click the Data Store tab, and in the top section Registered Databases, click the plus (+) button.
23. Enter a Name such as Carbon County sheep database, and click the Add button.
24. Enter the information as follows:

    Then click OK.

    • Database Platform - SQL Server
    • Instance - localhost\SQLEXPRESS
    • Authentication Type - Operating system authentication
    • Database - geodata
25. Ensure that Same as publisher database connection is checked, then click OK. However, please note that if you were going to be doing any service publishing from your home computer, or some computer other than the server, you would add database connection information in this lower section of the dialog box representing the database seen by the publisher's machine. Don't try this with this lesson. 
26. Click Validate All - and make sure you see a green checkbox next to your newly registered database. Click OK. If you don't see a connection, right-click your database geodata (VERSION:dbo.DEFAULT) and click Save Connection. This should make it appear in the Database Connections folder with a .sde file extension.

Your data is now loaded, prepared, and registered with ArcGIS Server. In the next section, you'll start working with some maps that use this database. You will prepare them to run as feature services that can be edited over the web.

You learned in the previous lesson how publishing a web service requires some extra thought beyond just taking your existing map document and putting it on the server. It requires that you think about basemaps and business layers and separate those out into different services. It requires that you think about the coordinate systems of your data and the services you will overlay. Throughout this course, you'll learn of even more things to prepare for as you design a web service. In this section, we'll cover some considerations for web editing.

There are perhaps some layers in your map that you will want users to edit, and other layers that you will not want anyone to modify. For the most fine-grained control, the editable layers should be isolated into their own web service, with the non-editable layers being published in a separate service.

Once you isolate the editable layers into their own ArcGIS map document, you can set up feature templates that determine the types of items users will be allowed to create. You can predefine the symbology and some of the attributes of these items to make the job of your editors (and, as you will see, your web application developers) as simple as possible.

When the map is ready, you publish it to ArcGIS Server with the Feature Access capability enabled.

Designing map services for web editing

Let's take a look at how you can design a map document (.mxd file) for web editing. You will start with an MXD that was included in the BighornSheep lesson data that you downloaded previously.

1. If necessary, start your EC2 instance and log in through Remote Desktop Connection.
   
   In the previous section of the lesson, you moved all the BighornSheep data to an ArcSDE workgroup geodatabase in SQL Server Express. Just to make sure we're using this database, we're going to "burn our bridges behind us" and delete the shapefiles you originally imported.
2. On your instance, start ArcMap, open a blank map and display the Catalog window if necessary.
3. In the Catalog tree, browse to the folder where you downloaded the BighornSheep data, probably D:\data\BighornSheep.
4. Using the Catalog tree, delete all shapefiles in the BighornSheep folder. Do not delete BighornHabitat.mxd or Metadata.txt.
   
   This will ensure that your MXD is not inadvertently pointing at the shapefiles.
5. Open BighornHabitat.mxd in ArcMap.
   
   You'll see some broken data sources because this map was originally pointing at the shapefiles. The first thing you need to do is re-point the layers at the feature classes you imported into SQL Server Express.
6. Click the red exclamation point next to one of your broken data layers.
   
7. In the file browser dialog that appears, change the Look in drop-down to Database Servers. Then double-click LOCALHOST.gds and browse down to your database named geodata.
8. Click the feature class corresponding to the layer you are repairing. For example, if you originally clicked the red exclamation point next to Springs, browse to the Springs feature class (which is named something like CarbonCountySheep.DBO.Springs), then click Add.
   
   This should re-point all your layers at the correct feature classes. Once you repair one broken data connection, ArcMap looks at the new correct path you chose and tries to find other datasets in the same location that would correspond to the other broken layers in your map document. In this case, it found similarly-named layers and fixed all the connections automatically.
   
   If, for some reason, all the connections are not repaired automatically, you can repair them one by one using the procedure above.
9. Zoom to the extent of the Carbon County boundary, and take a minute to examine this map. Think about things that have been done to prepare it for web editing, and things you still need to do.
   
   The most important thing in this map may be what's not there, which is an unwieldy number of layers. When you prepare a web map for GIS editing, you want only the layers that are most essential to the purpose of the app. Too many layers can slow down your app and create visual clutter that makes it difficult to perform the editing. In this map, I have chosen five vector layers that are essential for editing or providing reference.
   
   Once you've narrowed down your layer list, it's a best practice to give the layers some intuitive, readable names that would make sense to anyone, such as Sightings, Springs, and Carbon County Boundary. This may seem like a small thing, but when you consider that the original name in the Table of Contents might have been something like CarbonCountySheep.DBO.Springs, the name change goes a long way toward making your app feel approachable. Simple usability improvements like this are especially important if you are trying to pitch your app to your organization's upper management, who may not be familiar with GIS and could be wary of technical-looking names.
   
   Another preparation you should notice in this map is that the symbols have been chosen with large, bright symbols, colors, and labels that are easy to see (and tap if you are using a mobile device). I have symbolized the habitat by unique values based on the habitat classification (Crucial or Substantial). This will come in very handy when you look at the feature templates later on.
   
   Despite the above preparations, there's some work that still needs to be done. There are some features in this map that make sense for field workers to edit and some that should not be exposed for editing. Sheep sightings definitely need to be exposed. For the purposes of this lesson, you are also going to expose the habitat areas for editing.
   
   The remaining layers do not make sense to expose for web editing in this application. Probably no one using your application is going to have the authority to change the county boundary. You want to prevent the possibility that anyone could even do this. Other layers such as the springs and wilderness areas are included for reference only. Editing these is not the purpose of the web application.
   
   So you'll need to do some work to group the editable layers in their own map document, which you'll publish as a service with editing enabled. The other layers will go into a separate map document and service.
   
   Finally, there is the imagery layer. Because these services will typically be viewed on top of imagery in the final web application, some imagery has been put in the MXD to assist with map design. It's a lot easier to pick out colors and symbols ideal for overlaying imagery when you have some actual imagery in the background. However, this imagery is coming from an ArcGIS Online web service and, for various reasons, it is forbidden to publish an ArcGIS Server web service within another web service. Your editing web application will do the work of connecting to the editing web service and the imagery web service and overlaying them. In this way, you are performing the overlay at the web application tier instead of the service tier. This may become easier to understand when you build the application.
10. Right-click the World_Imagery layer, and click Remove.
    
    Now that you've removed the imagery, you'll take the layers you don't want to be editable and put them into a separate map document. You'll eventually publish both of your map documents as services, giving you an editable service called BighornHabitat and a non-editable service called BighornReferenceLayers.
    
    Let's take a detour for a few steps to prepare the reference layer map.
11. Start a second ArcMap session, and create a blank map document.
12. In the Table of Contents of your BighornHabitat.mxd, select the layers Springs, Carbon County, and Wilderness Area. Use the Ctrl key to do the multiple select.
13. Right-click the selected layers, and click Copy.
14. Now go to your blank map document, right-click the data frame name (it should be called "Layers"), and click Paste Layer(s).
15. Prepare this new map document for the web by doing the following things:
    • Change the data frame coordinate system to WGS 1984 Web Mercator (Auxiliary Sphere). If you get warnings about transformations or coordinate system mismatches, dismiss them and/or take the defaults.
    • Rename the data frame to something more descriptive (like "Carbon County Reference Layers").
    • Zoom the map to the Carbon County area.
    • Set the data frame background to a dark, earthy brown color. The antialiasing technique that you'll apply to your map blends the symbols with the background color to smooth out the shapes. If the background color is nothing, it will be treated as white, giving your symbols a light halo around the edge.
      

      Figure 3.2: Antialiasing effects with differing backgrounds
16. Save your new map document in your BighornSheep folder as BighornReferenceLayers.mxd and close it.
17. Return to your BighornHabitat.mxd and remove the Springs, Carbon County, and Wilderness Study Areas layers.
    
    This leaves you with just your editable layers: Sightings and Bighorn Habitat. Let's take a look at how ArcGIS exposes editing on these layers through feature templates.
18. In ArcMap, display the Editor toolbar. To do this, right-click any menu or toolbar and check Editor.
19. On the Editor toolbar, click Editor > Start Editing. You should see a Create Features window appear.
     
    

    Figure 3.3: The Create Features window with habitat and sightings template
    This window holds the feature template for your editing. The template defines the types of features that editors can create or modify. You should see three types of things you can create: a Sightings point location, an area of Substantial Habitat, and an area of Crucial Habitat.
    
    This template does not just apply in ArcMap, it applies to any web service that you publish with this map. The feature template helps you define and expose what web editors can do. Some web applications, like the one you will build later in this lesson, understand how to read and interpret the feature template to give the app user a palette of editing choices.
    
    Notice that when creating the feature template, ArcGIS uses the unique value renderer that is set on the habitat layer. There is only one habitat feature class, yet the feature template includes the two habitat types of Substantial and Crucial. This is because the ArcMap symbology is already configured with several different symbols based on the VALUE_ attribute of the CarbonCountySheep.DBO.RockyMountainBighornSheep feature class.
    
    If a user chooses to draw a feature using the Substantial habitat type in the feature template, the VALUE_ attribute for the new feature will automatically be set to "substantial". This saves a lot of effort editing the attribute table for each feature created. If there were seven unique values for the VALUE_ attribute, then you would see seven choices in the feature template instead of two. This is just one more way that the preparation you do in configuring the map document can affect your experience using the web service.
    
    You might ask, "Why did I go to all the effort to move the non-editable layers into another map document? Why couldn't I have just deleted them from the feature template?" This is a good question, and the answer lies in the fact that removing an item from a feature template does not prevent someone from making edits to the feature through direct web service calls. The feature template is something that is used for convenience only when designing and working with editing apps; it provides no measure of security to prevent people from making appropriately-formatted web service requests (for example, through REST-ful URLs) that would apply edits to layers outside the template.
20. After examining the feature template, click Editor > Stop Editing (without saving edits).
    
    You don't have to apply a dark background to this map document because you are eventually going to use these layers in a feature service. Therefore the web browser (not ArcGIS Server) will draw the features and you don't have to worry about artifacts of the data frame background color being introduced into these layers.
21. Save any open map documents. You'll be using them again in the next part of the lesson, so you don't have to close ArcMap.

In the next section, you'll publish both your maps to ArcGIS Server so that they can be used in a web editing app.

In order to get your maps into a web editing app, you need to publish them as services. Specifically, in ArcGIS, you publish your map as a map service, with the Feature Access capability enabled. This creates a feature service that can be used for web editing.

The terminology here can be confusing. Is it a map service or a feature service? The answer is...both. When you look at your GIS server as an administrator, you'll only see one service, a map service with the Feature Access capability enabled. However when you look at the GIS server as a consumer of the service, for example when you are developing a web app with the service, you will see two ways that you can access the service. You'll see the map service URL and the feature service URL. You need to use the feature service URL in order to access web editing functions. The feature service provides methods (or REST "operations") for editing. Take a look at this example feature service [7]. Click the Fire Perimeter link and examine the methods available for that layer, which are listed under Supported Operations. You should see: Add Features, Update Features, Delete Features, and Apply Edits. You have to enable the Feature Access capability and use the feature service URL (notice "FeatureServer" in the URL) in order to get these methods. They don't come with a regular old map service.

In the previous section, you created two maps: BighornHabitat.mxd and BighornReferenceLayers.mxd. You'll publish the BighornHabitat map as a feature service. The reference layers map also needs to be published, but it doesn't need to have the Feature Access capability enabled.

Try these steps:

1. If necessary, start your ArcGIS Server site and log in to your EC2 instance through Windows Remote Desktop.
2. On your EC2 instance, start ArcMap and open BighornHabitat.mxd that you saved in the previous lesson.
3. Click File > Share As > Service.
   You went through this wizard in the previous lesson, but we'll review the steps here once and then give you a chance to publish another service in your own.
4. Choose Publish a service, and click Next.
5. Choose your ArcGIS Server connection from the dropdown and name the service BighornHabitat. Then click Next.
6. Leave the folder as the existing [root] folder, and click Continue.
7. Click the Parameters tab, and set the Anti-Aliasing level to Normal.
   Now is the moment of truth when you allow the creation of a feature service.
8. Click the Capabilities tab and check Feature Access. Then click the Feature Access tab that appears in the left menu, and take a moment to examine the options that are available for feature services. Don't change any of them, though.
    
   

   Figure 3.4: Examining the feature services options
   Notice that Create, Delete, Query, and Update (under Operations allowed) are checked. The unchecked Sync operation is for offline editing workflows and was recently introduced in ArcGIS. It is beyond the scope of this lesson but important to note here if you plan on using this feature in your workplace. Also, if you ever want to publish a feature service without editing enabled, you can uncheck Create, Delete, and Update. Non-editable feature services are sometimes used for showing interactive graphics drawn by the browser, or for making queries in web applications.
   Also examine the REST URL and SOAP URL, which application developers can use to connect directly to your service. When you make your web app, you'll use the REST URL, which is formatted as: https://namegeog865.e-education.psu.edu/server/rest/services/BighornHabi... [8].
9. Click Publish to create the service. Some warnings and messages might appear in the Prepare window, but those are okay to ignore for this assignment.
10. Repeat the above steps to publish your other map BighornReferenceLayers.mxd as a service named BighornReferenceLayers; however, do not enable Feature Access on the service. Ignore the warnings and messages that appear in the Prepare window.
11. Recall that, by default, services are published without public access. To be sure that all clients are able to view your new services, visit the Server Manager page (https://namegeog865.e-education.psu.edu/server/manager [9]), view the list of services, click the Sharing icons, and select Everyone.

Taking into account the service you published in the previous lesson, your Services Directory should now look something like this:

Figure 3.5: Service Directory example

In the previous sections of this lesson, you have laid all the groundwork for allowing web-based editing of your GIS datasets. You've set up the database, prepared the maps, and published a web service that allows editing. Your final step is to make a web application that allows editing.

Web editing can be a successful or frustrating experience for users depending on how the web services and app are designed. You already did some work with your web services to make them easy to visualize and understand. For example, you made only a few layers editable and verified that a feature template was available, so that users could create only certain types of features and have some of the attributes pre-set.

In the same way that you made simple, focused services for editing, you also need to make a simple, focused application. An application that has too many buttons, functions, or GIS lingo can seem over-complicated to field workers and other professionals in your organization who may need to perform web editing. Fortunately, it's a lot easier to make a simple web app than a complex web app.

In this lesson, you'll build a web editing applications using the ArcGIS Homepage [10] (which we'll abbreviate as WABA for simplicity). WABA will let you build in a what-you-see-is-what-you-get (WYSIWYG) environment so you can quickly and easily create an app. For those of you that are interested in going beyond the simple functionality WABA has an "extensible framework" which means you can build your own custom widgets and themes if you have some programming knowledge. We won't cover those extensions in this class but you should know that you're not limited to the tools and templates that Esri provides. 

Creating the web map

Before we start creating the app, let's assemble the web map that we want to display inside of it. You'll do this using the same ArcGIS.com map viewer that you used in the previous lesson.

1. On any machine, open a web browser to the ArcGIS Homepage [10] and sign in using the Enterprise login with the Penn State credentials you used in the previous lesson.
2. At the top of the screen, click Map to open the map viewer.
3. Follow the procedure you used in the previous lesson in "Viewing your service in a web map" to add the following layers to the map:
     - Esri imagery in the background
     - BighornReference map service on top of that
     - BighornHabitat feature service on top of everything
4. Save this map as BighornWebMap. You can now close arcgis.com.

Creating the web app using Web AppBuilder

Now that you've got a web map set up, you can get down to the business of creating your web app.

1. In your ArcGIS Online website, click the menu at the upper-left, and choose Content.

2. Click the Create button, and select App Using the Web AppBuilder.

3. Choose 2D, enter a title (e.g., BighornSheepEditingApp), tags (again at least one is required), and a summary (e.g., Bighorn Sheep editing app using ArcGIS Online), click OK.
   
   You will see the Web AppBuilder for ArcGIS screen, and then you'll be redirected to a webpage displaying a theme and other graphical styles.

4. Choose a style and color scheme that you like. I'll leave it up to you to be creative. 
   
   The important elements live under the Map and Widget tabs. We'll start with the Map tab.

5. Click the Map tab, and click Choose Web Map.

6. Select the BighornWebMap you created above, and click OK.
   
   This will bring in all the layers that you configured in the ArcGIS.com map viewer. That's all you need to do for the map design. Now, let's add some widgets.

7. Click the Widget tab and click Set the widgets in this controller and then the +.

8. From the list of widgets that appears, add the Edit and Measurement widgets. Also feel free to choose a couple of others.

9. Click Save in the bottom of the pane and then Launch. The web app will open in a new browser tab (it might take a few seconds to start). Take a quick look around.

10. Now, go to your own local computer (not your EC2 instance), and log in to arcgis.com. Click Content, then click your BighornSheepEditingApp, and click View Application.
    
    From a look at the URL, you will see that your web app is, in fact, running on ArcGIS online servers via the Penn State URL (pennstate.maps.arcgis.com); however, it is still depending on services that are running on your EC2 instance. When you stop your instance, this app will not work as expected.
    
    If you wanted to download the source code for this app and host it on your own web server, you could easily do that using the Download link that appears by each app in your ArcGIS Online content.

11. Test out your Web App thoroughly by reading and following along below.

    Now that you have your app created, you can use your widgets to edit some of the underlying data. If you click the Edit widget, a sidebar window will appear with the list of editable layers within your feature layer. If you select the Sightings, you can add in some new sightings and some attributes. Try it!

    You can also add a habitat area by drawing a polygon on the map (follow the on-screen instructions). You can use the controls at the bottom of the edit window to modify those changes (just like you might in the Edit window of ArcMap).

    When you're done editing, click the X in the upper right of the window. These changes will be saved back to the server version.  You could open your database and look at it in ArcMap on the EC2 instance to prove that this is the case.

12. Take a couple of screenshots that give a tour of your ArcGIS Online app and its editing functionality, perhaps showing a before-and-after view of ArcMap on your EC2 machine that shows the Sightings layer before you make an edit via the Web App and after you make an edit in the Web App. Show how you made the app uniquely yours in design.
13. When you have finished with the above, stop your EC2 Instance in AWS.

Please create a new document or PowerPoint slide show. Paste your screenshots that you took from your app. Label each with a description of what is happening in the screenshot.

Also, answer the following question in a thoughtful paragraph: What things would you change about this walkthrough or the app design if this were a real-world deployment looking at animal sightings? If you're having trouble coming up with ideas, think about this question across several layers, or tiers, of the architecture, starting at the database tier and working your way up to the GIS server tier and the web application tier.

Upload this document to Canvas in the lesson drop box.

Cloud computing advocates often cite cost savings as a reason to adopt cloud computing. But, there is no guarantee that any given project can be more cheaply executed using cloud computing than using traditional IT provisioning. This week, we will discuss how cloud computing economics might apply to your organization or situation.

First, please read this white paper from Amazon: The Well-Architected Framework - Cost Optimization Pillar [11]. This document is part of a series available here [12] on best practices for using AWS's infrastructure services. Also, if you have purchased the optional textbook The Cloud at Your Service, please read chapter 3, "The business case for cloud computing". Despite the title, it gives a reasonably objective view of how cloud computing costs break out for different kinds of users (start-ups, small and medium businesses, large businesses).

Second, please post your reaction in the lesson discussion in Canvas on the topic below