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.
- 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.
- On your instance, start ArcMap, open a blank map and display the Catalog window if necessary.
- In the Catalog tree, browse to the folder where you downloaded the BighornSheep data, probably D:\data\BighornSheep.
- 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.
- 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.
- Click the red exclamation point next to one of your broken data layers.
- 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.
- 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.
- 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.
- 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.
- Start a second ArcMap session, and create a blank map document.
- 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.
- Right-click the selected layers, and click Copy.
- Now go to your blank map document, right-click the data frame name (it should be called "Layers"), and click Paste Layer(s).
- 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.
- Save your new map document in your BighornSheep folder as BighornReferenceLayers.mxd and close it.
- 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.
- In ArcMap, display the Editor toolbar. To do this, right-click any menu or toolbar and check Editor.
- On the Editor toolbar, click Editor > Start Editing. You should see a Create Features window appear.
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.
- 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.
- 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.