GIS professionals in any field have similar responsibilities with regard to data development, analysis and presentation. In an established GIS, these tasks are ongoing, and are at different phases for different sets of data. Often, the requirements of each of these are in conflict for analyst's time and system resources. In a centralized GIS, the analyst is also responsible to the clients of the database who have varying experience with the system. While there are many tools available to aid the GIS analyst in the development, analysis and presentation of data, until recently, there were few options to help the analyst bridge the gap between the database and its clients. This paper outlines the development of several ArcView2 applications whose purpose is to allow clients of a surface water management GIS to perform many tasks for themselves. Applications such as an online data dictionary, automated data export and common map templates, are used as examples of ArcView2 applications that improve client access to data while freeing up valuable analyst time and system resources.
GIS professionals operating a centralized client-oriented database are expected to do it all. We are responsible for data development, maintenance, analysis and presentation. Often, we are also responsible for the smooth running of the operating system as well. Most importantly, and sometimes overlooked, we must serve our clients. To be successful, we need to take advantage of any tools that provide more benefit than the effort required to learn and use them.
During the last two and a half years, the King County Surface Water Management (SWM) division GIS staff has had a constant struggle to keep a balance between the time we spend on special requests and the time required to develop and maintain our GIS database. We saw a great opportunity to use Esri's second release of ArcView as a tool for our client's GIS projects. We hoped by using ArcView we could reduce the amount of time we spend on special requests, improve our client's access to our database, and educate our clients about GIS analysis.
We would like to share our experiences developing ArcView applications for our clients, and the extent that we were able to realize our goals. If you are in a similar situation, perhaps you can learn from our mistakes and benefit from a discussion of our design approach.
SWM's GIS Unit provides geographic analysis support for the entire division of over 200 staff. Our clients include basin planners, project engineers, billing staff and policy analysts. Their project requests to date reflect the wide range of their needs in terms of scale, analytic complexity and resource demands. Despite the variety of applications, projects tend to fall into three broad classes: data requests, mapping requests and analytic requests. The first two types of projects consume the majority of our time, and are probably the easiest to address with an application like ArcView.
Our clients request data when they intend to do their own data development, analysis or presentation work. Most of our data requests are for ArcCAD projects, graphics files or tabular extracts from the database. Of these, the majority are ArcCAD requests. These projects consist of clipping a set of coverages to a study area such as a basin planning area. Once clipped, the coverages must be projected to the proper geographic projection, converted to single precision if necessary, exported and converted to DOS format. These types of requests are very straight-forward and typically do not take long to complete, unless the client wants a custom clip area. In this case, ArcView's shapefile feature will allow the client to define their own area.
Mapping requests make up most of the projects that we completed in 1994. When we receive a mapping request, our clients either want a custom map, or a copy of another client's custom map. A significant amount of time can be wasted making a custom map resulting from miscommunication. Sometimes we don't understand what the client wants, or the client doesn't understand what we say we are going to do. In either case, producing multiple drafts of maps that aren't correct is a waste of time that might be prevented if the client could make the map for themselves.
Finally, analytic requests are the type of work that we are uniquely trained to do, but spend the least amount of time doing. These requests require the use of a fully functional GIS such ArcInfo by a trained GIS analyst. We would be able to more of this type of work if we can provide our clients with the tools to help themselves a greater percentage of the time.
As with every GIS shop, we have limited resources to meet our clients needs. Our system consists of a Sun Sparc 10, a Sun IPX, two X-terminals and a number of PC's all connected by an NFS local area network (See Fig. 1). We have a staff of four people, but we only have the equivalent of two full-time staff available for GIS special requests. In addition we are responsible for the development and maintenance of several of the county's datasets including hydrology, topography, and geology.
SWM's GIS was initiated in the fall of 1992. As an organization, we are in the transition phase between implementation and mature operation and maintenance. Currently, our small scale data base is nearly complete for the entire county, while our large scale data is still under development. Our efforts are changing focus from data development to data analysis and maintenance. With this in mind, we are looking for ways to inform our clients about our data and GIS capabilities, and how they can be used in their projects.
There are a wide range of excellent tools available for data development, analysis and presentation, but until recently, there have not been many tools available to help bridge the gap between our GIS database and our clients who have varying levels of GIS experience. The second release of ArcView finally provides a GIS client tool that may be worth the time to learn and use. ArcView has a wide range of functions that allow a user to create custom views of datasets that can be turned into satisfactory maps. ArcView also includes tools for elementary GIS analysis which go a long way to enabling the user to serve themselves. For a GIS analyst, ArcView's most interesting feature is Avenue, which holds the promise of creating custom applications tailored to meet our client's needs.
We hope to use ArcView as the primary tool to allow our clients access to our GIS database. We intend to do this by developing a growing set of modular applications that will not only enable our clients to help themselves with their projects, but will begin to teach them how to integrate GIS tools into their initial project plans.
We approach the development of ArcView applications in a three step process:
1. Define the client's needs;
2. Create step-by-step scripts;
3. Code the applications in Avenue.
During the whole process, it is important to keep in mind the goals of your applications, and design them accordingly. In our case, we are most interested in creating something that will enable our clients to help themselves, giving priority to efforts which will reduce our special request workload. In addition, we do not have the luxury to spend more time creating fool-proof routines than it would take to have one of our staff simply process a special request.
Determining the client's needs is arguably the most important step of any design project. The next most important step is to design an application to meet those needs, and where appropriate, modify the client's expectations in the face of data and software limitations. This step amounts to an education process for both the designer and the client. The designer must learn what the client wants and then teach the client what is possible to produce. When designing a GIS application, teaching the client what is possible is usually very important, since many of our clients do not have a clear understanding of what is available, both in terms of data and analytic capabilities.
It is tempting to develop applications based on the experience of previous requests alone. After all, if people have asked for something in the past, they probably will in the future. This may be true, but it is important to get input from your clients when developing these applications. When doing something for themselves, they may want a slightly different product than when they submit a request for the work to be done by GIS staff. In addition, in the process of doing geographic analysis for themselves, your clients will begin to learn what is possible, changing their expectations at the same time.
For a GIS analyst, understanding what a client wants is a two part process. First you need to get a clear articulation of what the client really requires, then translate this into geographic terms to determine if it will be possible. Often, our clients cannot clearly articulate what they want. At this point, it is often helpful to introduce the data and explain GIS capabilities. Once they see some examples, they often find something that meets their needs.
When the client knows exactly what they want, it will either be quickly understandable, or it will be fairly complex. When faced with a complex request, break it up into discrete tasks. Then each of these tasks can be considered separately.
Unfortunately, many of our clients come to us late in their projects for data, either because they weren't aware of what we could do for them, or they can't get the information they want by themselves, or they had set ideas for figures that they left until the last minute. With luck, we can fill their needs. Sometimes we can't, either because of limitations in our data or analytic capabilities. This could be avoided, and hopefully better analysis performed, if we could get our clients to consider GIS input for their projects during their initial scoping process. However, this may not happen unless we educate our clients about our data and GIS capabilities.
Familiarizing your clients with the data is an ongoing process, as GIS data sets are usually dynamic and have a complexity that can be viewed from a variety of levels. A complete data inventory is a good place to start for most people. It is enough for many users just to know where to find the data they need. We began our data inventory with a simple list of the data sets that we have. For each data set we listed its file name, a brief description, usually just a title, and the data set's location in our file system. We made this list available both in paper copies, and in digital format on our network.
Many of our clients do not want, or do not have time to learn more about our data than its name and where to find it. For those that do, the next step is to learn the rudiments of geographic data representation and analysis. The danger at this point is to overwhelm people with more information than they need about the wonders of GIS. For the most part, just getting across the basics of feature topology and relational databases is enough.
An introduction to the basics of GIS data and analysis should at least include a discussion of digital geographic data structures, focusing on the analytic strengths and weaknesses of different approaches. When working with our clients, we have usually found confusion about the database aspect of geographic information, and the differences between raster and vector data structures.
We try not to burden our clients with jargon filled descriptions of the mechanics of GIS, but use terms and ideas with which they are already familiar. Most of our clients understand the idea of a database, so in explaining a GIS we show the connection between features they see on a map to records in a database, each record containing fields for the feature's location, it's relationship to other features and attributes describing the feature itself. The next step is to explain how things they are interested in can be represented geographically by a database, either as points, lines, and areas, or as a grid of values. The pros and cons of each system are best stated in terms that are relevant to their daily work. For instance, to a basin planner, using lines to represent a stream network has clear advantages over a grid, while a grid may be better if they are interested in exploring the relationship of riparian habitat to surrounding land cover.
Once your client understands GIS basics, you can discuss the available data in terms of their project's requirements. Usually, your clients only want to know if you have a certain set of data. However, if we have the data, it is up to us to ask more questions about their project's data and analysis needs, for instance: Is the data at an appropriate scale? Does it represent relevant information? Is the information too out of date to be useful? Can we answer the questions they pose with the available data and software? By answering these questions, the GIS application needed for the client's project begins to take shape.
At each step in the design process, it is worthwhile to keep in mind the goal of your application. We want to create ArcView applications for our clients only when it will be most beneficial for both our staff and the client. We would like to reduce the percentage of staff time spent on custom requests, so that we can spend more time on neglected database maintenance and system administration tasks. However, at some point it is easier for all concerned if we have our own staff do all of the work. This point is sometimes difficult to define. Our approach to application development has been to break a project up into discrete tasks. It is then easier to determine who can and should be doing each task.
The key to our application development process is the creation of modular scripts for each project task to be performed by the client using ArcView. Most projects share some of the same basic tasks, so that one set of instructions can be used by many different people. Each project may only have a handful of tasks that are unique, one or two of which may be appropriate for the user to complete. These tasks can then be turned into scripts. After a while, you have developed a library of modular instructions that can be combined together in different ways depending on the project.
Each script is a set of step-by-step instructions needed to complete the task ( See Fig. 2). The instructions assume the user has no experience using ArcView, or any fluency with GIS terminology. Above all, the scripts are for a standalone task that is not specific to any one project. Ideally, a user should be able to sit down, follow the script's instructions and complete the task without any help or explanation from the GIS staff. For example, we have created scripts for logging-in and starting ArcView, saving projects to your own workspace, creating views, tables, charts and layouts, and doing various tasks such as selecting features and creating shapefiles or exporting tables.
Now, when a client comes to us with a special request, we first try to determine if their needs can be met completely, or in part by existing ArcView Scripts. Where appropriate, we create new scripts for tasks unique to their project. Then we give them a list of scripts to follow in the correct order which will produce the desired results, or produce an interim product that can be used by our GIS staff to complete the project.
It is very difficult to write clear instructions that are perfectly understandable on the first try. Shortcomings in our scripts become clear by the questions and problems that arise when our clients attempt to follow one. We encourage our clients to make comments, and suggest changes to our scripts. Over time the wrinkles in our scripts are straightened out, reducing future coding problems.
Just as there are tasks that are shared by different projects, we have requests for projects that are the same or have similar components as past projects, but focus on a different area. These script combinations are saved and given appropriate names such as: Hydrologic Base Map Creation, Sub basin Land cover Area Calculation, or Clip Basin Data and Export to ArcCAD. These often repeated script combinations are the basis for Avenue-coded ArcView applications.
Our hope is that, over time, frequent users of these scripts will learn how to use GIS tools to serve themselves, without having to ask our GIS staff for help until it is needed. This process of education is our main strategy to reduce the time we spend on repetitive special requests.
The latest release of ArcView has several characteristics which greatly improve on its desktop GIS predecessors. First of all, there is a greatly expanded toolbox of functions to choose from to view and analyze GIS data. Each of these comes complete with a fairly friendly user interface. But, by far ArcView's greatest advantage is the ability to customize it and develop applications with ArcView's scripting language, Avenue. With these tools, you can make a custom interface, eliminating tools and buttons that aren't needed. You can also create custom tools that are designed for a specific task. With Avenue, you can create a custom application that leads a user through a specific set of tasks.
In theory, ArcView brings sophisticated GIS analysis into the realm of custom push- button applications. However, after using ArcView for several months, we have found that some Avenue applications take more time and effort to put together than they are worth. For one thing, object-oriented programming scripts, such as Avenue, are very different from linear programming scripts, such as the ArcInfo Macro Language (AML). As a result, our staff, trained to develop AML applications, has had a difficult time making the transition to Avenue. Second, ArcView includes such an assortment of tools, sometimes it is easier to make do with them than to spend the time to make a custom tool that does exactly what you want it to. These two factors led us to the practice of making step-by-step instructions rather than Avenue-coded applications in the first place.
A case can be made for taking the time to develop an Avenue-coded application if its use will reduce the number of special requests we receive over the long-term. We identify potential Avenue applications by tracking the use of different scripts and applications. Potential candidates include scripts which are used frequently, and would require minimal coding or customization to make them easier to use, possibly to the point of eliminating the need for instructions altogether. An example of this might be a frequently requested map layout, where individual requests differ only by their location and scale. This could be easily customized so that a client would only have to provide the area and the scale, and the application would do the rest.
Another class of potential applications are those frequently used scripts that currently require our GIS staff to process some of the tasks. These are tasks which either there aren't any ArcView tools to do them, or they must be done in ArcInfo. In the first case, a tool could be customized to allow the user to do the task without GIS staff help. In the second case, both an Avenue script and an ArcInfo AML macro must be developed. The Avenue script must both provide the input for the AML, and accept the AML output. To be effective in reducing special requests, the AML must be able to run unassisted with the Avenue script input, so that a user can complete the entire task without any help.
A good example of this is an application that would allow a client to clip out a set of data to be used in ArcCAD. Without an application, the client could be instructed by a script to create a shapefiles of the data that they want, but an ArcInfo operator would be required to build feature topology for the shapefile, export the coverages in single precision and convert them to DOS format. An Avenue/AML application pair could be developed that would allow the user to define their shapefiles, send them to ArcInfo for processing and receive ArcCAD compatible export files.
Whatever type of application you create, it is best to keep your Avenue scripts simple and modular. Be sure to take advantage of the library of routines that are included with Avenue. A great deal can be done by simply combining these into useful applications.
ArcView offers a useful set of tools that can potentially allow GIS clients to perform many of the projects that currently take up much of our GIS staff's time. This can only be accomplished if our staff takes the time to understand what our clients need, breaking complex projects down into manageable tasks.
Flexible, reusable applications can be developed by creating modular sets of ArcView instructions to perform our client's project tasks. Where appropriate, popular sets of scripts can be coded with Avenue into push-button style GIS applications. However, coding with Avenue can take a significant amount of time, so care must be taken to choose which applications to create.
We have found that, as much as having a new tool will be helpful, teaching our clients the fundamentals of GIS analysis and familiarizing them with our data is just as important. If we can educate our clients, then perhaps they will begin to integrate GIS into the earliest phases of their projects, resulting in improved analysis, and a more effective use of our time.
I missed the opportunity to thank the people who deserved it when I recently completed my thesis, so I'd like to try and make up for it here. I'd like to thank my family for getting me to where I am, all of my GIS mentors, Frank Westerlund, Earl Bell, Miles Logsdon, Anne Boyd, John Schlosser, Rick Gambrell and Dick Thomas, and especially my partner Jill for puting up with my absent-mindedness.