Print
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.