Beyond Mapping II

Topic 3 – Implementing GIS



Spatial Reasoning book



Question GIS before You Start  discusses the importance of an Information Needs Assessment (INA) and a GIS Reality Assessment (GRA)

What Can GIS Do for You?  identifies and discusses the seven basic types of questions addressed by GIS technology

Build It and They Will Come  describes the tactical and conceptual considerations in GIS implementation


<Click here> for a printer-friendly version of this topic (.pdf).

(Back to the Table of Contents)

Question GIS before You Start

(GeoWorld, April 1994)  

(return to top of Topic)


GIS can answer all of your questions— at least that's what we hear from overzealous marketers.  True, GIS has resounding success in many areas, but it also meets with expensive and embarrassing failures in others.  Is there any pattern to the technology’s successes and failures?  What types of applications have high probability of success?  Which are doomed to be duds?  What conditions affect the likelihood of success?  How can you mitigate these conditions? 


These are the real questions surrounding GIS; you need to grapple with them before you break the shrink wrap on your new system.  The starting point is an Information Needs Assessment (INA), which envisions GIS products, then works backward to derive the intermediate and base maps supporting each product.  The process involves four steps: 


1.      List the application areas to which GIS might contribute.

2.      For each application area, describe specific GIS outputs to include a sketch and legend of the final map.

3.      For each final map, determine its base maps by successively deriving its supporting maps (with sketch and legend) and the GIS analysis tools needed at each step.

4.      Construct two tables summarizing the number of times each base map and each GIS tool are referenced in the various proposed applications.


The INA process is best done with a large group of end users, rightly sprinkled with GIS specialists.  The role of the end users is to “blue-sky-it” and envision what they need, not simply state what they do and currently produce.  The role of the GIS specialist is to stimulate new approaches and assist in deriving the supporting maps and identifying the GIS tools required.  In most instances the INA is where the GIS rubber finally meets the application road.  It translates GIS rhetoric into the specific context of the organization.  Often the INA also can transform into a psychological home run, because it encourages end-user participation and builds a vested interest in GIS at the grassroots level. 


As an example of the thought process, consider a map of sensitive areas for resource planning.  An end user might envision the map as a set of contiguous polygons that divide a project area into high, medium, and low sensitivity.  The user sketches such a map and assigns values l, 2, and 3, respectively.  Next, consider what sort of maps might contribute to the final map.  These might include a map of relative visual exposure to roads with areas of high visual exposure identified as high sensitivity. 


Now you've identified your first GIS tool (renumber) and supporting map (Vexpose).  Sketch the map of visual exposure to roads.  It is continuous data expressed in raster format, with values increasing from zero (never seen) to large values (seen a lot) assigned to each grid space.  So how could you create such a map?  You need to RADIATE a map of roads over a map of elevation.  This step identifies two input maps (Roads and Elevation) and another GIS tool (radiate).  Sketching these maps focuses attention on the level of detail required.  Are different types of roads needed?  What about trails?  Are there special scenic turnouts you need to consider?  Relate these concerns to the actual numbers that will represent the map features. 


Now where are you going to get the maps?  Buy them if you can; encode them if you can't.  They represent base maps (facts on the landscape), the lowest level of abstraction in a spatial model.  You have hit ground zero for this component of mapping sensitivity.  What other factors need to be considered— terrain steepness, special habitat areas, proximity to human activity?  Repeat the process of distilling the base maps from the conceptual maps for each consideration.  Then tackle another GIS product in a similar manner. 


When you complete them all (or reach the point of exhaustion), summarize the results.  The listing of base maps gives you a handle on database design-which maps are needed, their relative importance, what level of detail, etc.  The listing of GIS tools gives you a handle on system design— data loading levels, networking requirements, functionality needed, etc.  The "logical fabric" from the distillation of each GIS product gives you a handle on the application modeling effort-type of model, relative degree of difficulty, common intermediate maps, etc.  More importantly, the intellectual exercise raises the general awareness of GIS, generates vested interest in its successful implementation, and identifies in-house zealots/champions who will carry the flag.


The results of the INA process directly lead to a second phase of analysis: the development of a GIS Reality Assessment (GRA).  That is where the "blue-sky visions" are hammered into a business model commensurate with the organization's resources and culture.  The process involves three steps: 


1.      Develop an implementation scenario for meeting the GIS products identified in the INA process.

2.      Determine how and how much it will cost to acquire the data and capabilities implied by the scenario.

3.      Repeat steps l and 2 until a "realistic" implementation plan emerges. 


The GRA process is best done with a working group of managers and a small contingent of GIS specialists.  The managers identify the various priorities and tradeoffs among the array of possible GIS products.  The GIS specialists tackle the cost of the system, database, and application modeling implied for each scenario.  The "realistic" implementation plan should contain a timeline that meets all of the viable GIS products needed— it's just how and how quickly you buy into it.  For example, a solution might fully implement one unit (e.g., research), then bring on the other units.  Another organization's solution might be to partially implement all units (e.g., inventory capabilities), then expand to more advanced capabilities and applications identified in the GIS products. 


An alternative to the INA/GRA process is the "fish-or-cut-bait” scheme of buying a GIS and seeing what happens.  Like casting a seed to the wind, if it happens to land in a fertile place a sturdy tree will grow.  But keep in mind that nature produces thousands of seeds so just one might flourish. 


Author’s Note: see Both Dreams and Nightmares Are Born of Frustration, May-July 1992 that discusses the limitations of traditional cost/benefit analysis in evaluating the adoption of a radically new technology like GIS).



What Can GIS Do for You?

(GeoWorld, May 1994) 

(return to top of Topic)


GIS raises as many questions as it answers— maybe more.  As a general rule, the confusion surrounding GIS implementation is inversely proportional to the effort spent in assessing what it can do.  Some say it can do everything; some say it can only mess things up.  The previous section described a two-part methodology for realistically assessing what GIS can do for you.  An important ingredient of the process is an understanding of the basic questions GIS can answer.  Table l identifies seven questions encompassing most implementations.  The questions are ordered progressively from inventory-related (data) to analysis-rerated (understanding) as identified by their function and approach. 


The most basic question, “Can you map that?” is where GIS began thirty years ago— automated cartography.  A large proportion of GIS applications still involve updating and outputting map products.  As an alternative to a room full of draftspersons and rapidograph pens, the digital map is a clear winner.  Applications that respond to this question are identified easily in an organization and productivity "payoffs” are apparent.  These mapping applications often are restatements of current inventory-related activities.


Questions involving “Where is what?” exploit the linkage between the digital map and database management technology.  These questions are usually restatements of current practices and can get a group to extend their thinking to geographic searches involving coincidence of data they never thought possible.  The nature and frequency of such questions provide valuable insight into system design.  For example, if most applications require interactive map queries of a corporate database from a dispersed set of offices, you have a major networking headache in store.  If the mapping and geo-queries are localized and turn-around for the products not demanding, a simple “sneaker net” might be adequate. 


Table 1.  There are seven types of questions addressed by GRA. The first is three are inventory-related; the latter four are analysis-related and investigate the interrelationships among mapped data beyond simple coincidence.


What GIS Can Do for You

Questions for GIS




1.  Can you map that?

2.  Where is What?

3.  Where has it changed?

4.  What relationships exist?

5.  Where is it best?

6.  What affects what?

7.  What if…?






Spatial Interactions


System Dynamics













Where has it changed?” questions involve temporal analysis.  These questions mark the transition from inventory-related data searches to packaging information for generating plans and policies.  Such questions usually come from managers and planners, whereas the questions noted previously tend to support daily operations.  A graphic portrayal of changes in geographic space, whether of product sales or parts per million of lead in well water, affords a new perspective on existing data.  The concept of "painting" data, which normally are viewed as tables, might initially be a bit uncomfortable.  That's where GIS evolves from simply automating current practices to providing entirely new tools for visualizing and analyzing mapped data. 


Questions of “What relationships exist?” draw heavily from the GIS toolbox of analytic operations.  How far is it from here to there?  Can you see the development from over there?  How steep is it?  Is the cover type more diverse here or there?  These are a few examples of that type of question.  Whereas the earlier questions involved querying and repackaging base data, spatial relationship questions involve derived information.  Uncovering these questions is a bit like the eternal question “Did the chicken or the egg come first?  If you don't know what GIS can do differently, chances are you aren't going to ask it to do anything different.  How many times have you heard a land use planner say, "I need a weighted visual exposure density surface before we can locate the power”? 


Suitability models springs from questions of “Where is it best?  Often these questions are the end products of planning and are the direct expression of goals and objectives.  The problem is that spatial considerations historically are viewed as input to the decision process— not part of the "thruput."  Potential GIS users tend to specify the composition (base and derived maps) of "data sandwiches" that adorn the walls during discussion.  The idea of using GIS modeling as an active ingredient in the discussion is totally foreign.  Suitability questions usually require the gentle coaxing of the INA process described in the previous section. 


Questions of “What affects what?” involve system models— most frequently the realm of the scientist and engineer. In a manner of speaking, a system model is like an organic chemist's view of a concoction of interacting substances, whereas a suitability model is analogous to the recipe for a cake.  The tracking of "cause and effect" and reliance on empirical relationships are the main ingredients of what affects what modeling.  The same hurdle in identifying these applications exists: the perception that GIS simply provides input.  The last 100 years have been spent developing techniques to best aggregate spatial complexity (e.g., stratified random sampling).  The idea that GIS modeling retains spatial specificity and responds to spatial autocorrelation in geographic space is a challenging one for scientists, as well as for managers and the general public. 


Questions involving “What if...?” involve the iterative processing of suitability or system models.  For suitability models, they provide an understanding of different perspectives on a project.  If visual impact is the most important consideration, where would it be best for development?  What if road access is most important?  For system models, they provide an understanding of uncertain or special conditions.  What would be the surface runoff if there was a 2-inch rainstorm?  What if the ground was saturated? 


In asking what GIS can do for you, the first impulse is to automate what you do.  The stretch to find if any of the other basic questions apply to your business model will give you an idea of what GIS can really do for you— likely a lot more than you initially think as it a whole new way of doing business. 



Build It and They Will Come

(GeoWorld, June 1994) 

(return to top of Topic)


To many people, GIS is simply a hot new technology that should be implemented in every organization.  To the more deliberate types, it is a new technology that should be viewed with great suspicion.  Regardless of your orientation, it's the implementation phase that makes or breaks GIS in any organization.  There are four basic considerations in implementing GIS: hardware/software, database, appreciation models and human impacts (see figure 1). 



Figure 1. There are four basic considerations in implementing GIS: hardware/software,

database, application models and human impacts.


Selecting appropriate hardware/software often receives disproportionate attention.  In part, the technical aspects provide a comfortable setting for meticulous evaluation-storage capacity, processing speed, and real dollars easily are defined.  What is often overlooked, however, is the dynamic nature of hardware/software factors.  Hardware is in constant flux, and what's considered a technical (or price) barrier today becomes commonplace in tomorrow's boxes.  The same holds true for software, as GIS packages continue to leap-frog capabilities with each update. 


As a general rule, the larger the organization the more effort is spent on scoping hardware/software.  Large government procurements approach "cyber-seizer," because by the time they finally compile a detailed specification, a new generation of technology hits the street.  GIS software, however, still commands product loyalty amid a quagmire of different user interfaces.  This Tower of Babble has yet to be breached, but the exchange of data is a nonissue.  Keep in mind that you can't go too wrong, because when you scrap your computer in a couple of years you can jump to a new GIS package without losing your database as hardware/software is semi-fluid, but not necessarily quicksand. 


Your database, however, is a long-term commitment.  Also, it represents the lion's share of the bag of gold necessary to acquire GIS.  The best advice is to buy it if you can; encode it if you have to.  An increasing amount of mapped data is available in digital form, such as the U.S. Geological Survey's Digital Line Graph (DLG) and Digital Elevation Model (DEM) maps.  These data have two advantages— they are cheaper and sanctioned.  In-house encoding has such a steep learning curve that it's impractical in most instances.  Out-house encoding is viable for special maps and data not available in digital form.  However, keep in mind that any specially encoded map could be questioned as to whether it's as accurate as the de-facto standard everyone else uses.  Can you afford to be the oddball?  A wary eye should be cast upon any specialty map nominated for encoding. 


The technical considerations of hardware/software and database development usually consume most (if not all) of implementation planning.  In reality, the conceptual considerations have a greater impact on successful GIS implementation.  As shown in figure 1, most GIS costs are hidden and difficult to estimate, with the readily identifiable hardware/software costs just the tip of the iceberg. 


The previous two sections emphasized that scoping of the GIS products and procedures needed in your organization should drive the implementation process, not system considerations alone.  GIS comes with "some assembly required" beyond system setup and database compilation, and model development often sinks the ship. 


The development of application models is where GIS's return on investment occurs.  The process involves writing command macros in the selected GIS language.  For the uninitiated, that step seems nearly impossible, with a stack of reference manuals sustaining the steep learning curve.  For the cyber-phobiac, the step is impossible and met with fervent resistance. 


As with database encoding, you can choose to develop your application models either in-house or out-house.  If you choose in-house development, you need to allow for new hires or considerable time for retreading existing personnel.  If you choose out-house development, you need to factor in the difficulties in communication, lack of self-determination and a continuous cost stream.  Most organizations straddle the issue and hire a consultant to develop a basic set of application models with the active participation of their own GIS specialists in waiting.  These on-the-job-training expenses (both in dollars and time) take many GIS planners by surprise.  In addition, application models are software specific and increasingly lock you into your GIS package.  You can easily flush your platform and transfer your database, but reworking your models into another GIS package is a major undertaking. 


Keep in mind that without useful models, the GIS platform and database is like an expensive boat gassed up with high octane fuel, but missing a driver and place to go.  Application models provide the utility to a GIS.  But even with the best platform, database, and models, you still aren't assured success.  The human factor is like a floating mine waiting to sink the ship.  If end users see GIS as unfamiliar, overbearing, obtrusive, and threatening, you're doomed from the start.  The problem is that's an accurate description of GIS for someone outside the technology. 


As much attention and concerted effort is needed for developing user acceptance as is paid to the hardware/software and database issues.  The social sciences have been wrestling with the human impacts of technology for years.  However, most GIS planning pays little more than lip service to these concerns.  Traditionally, the technical considerations receive the most attention in GIS implementation planning.  But in reality the conceptual considerations are the real determinants of success.  Therein lays the weak link in GIS implementation.  It's like the field of dreams prophecy— “build it (a GIS) and they (uses and users) will come.” 


        (return to top of Topic)


(back to the Table of Contents)