cartome.org
14 November 2001
The Role of GIS on the Electronic Battlefield
an ESRI White Paper 1998
The need to understand terrain has always been an essential skill for the military commander. Understanding has been supported by paper mapping for at least 1,000 years at the strategic level and at least 300 years at the tactical level. Indeed, the first national survey of the United Kingdom and, specifically, Scotland was conducted 250 years ago this year in order to better support military operations following some embarrassments during the Jacobite rebellion!
The innovative methods employed by General Roy to map Scotland were followed for the next 250 years by other methods to better support the commander's decision-making processes with spatial information. Throughout, the imperative to evolve the paper map has been other military advances such as motorized vehicles, aircraft, global positioning system� and now digitization.
Digitization of the battlefield�" The Electronic Battlefield"� is now demanding the next technological leap, which is the embracing of digital geographic information (DGI) and the means of exploiting DGI, which is the geographic information system or GIS. Note that I do not indicate the replacement of the paper map with DGI and GIS. That will not happen until GIS runs on an infrastructure that can be folded up into a side pocket, get soaking wet, require no external power, and be disposable� that is some distance in the future. For the foreseeable future, the paper map and GIS will be complementary.
While the exploitation of DGI on the battlefield may be new, defense has been using DGI for many years but its use has been confined for the main part to strategic and air systems. Its use on the battlefield has been long predicted but it is only recently that the first truly deployable systems exploiting DGI have emerged. They are only a small part of what will happen in the next ten years, as most battlefield systems become spatially aware and exploit DGI.
This introduction is best summarized by pointing out that just as paper maps have made and recorded military history, so the military future will be made and recorded using GIS.
Paper Map Substitute� Spatial Wallpaper
The function of the map is to represent the real world (or the narrower focus of the battlefield) in a way that can be readily interpreted by the user. The map production process is extremely expensive, and economics demand that all users get the same view, or same map. This leads to the first major limitation of the map in that the same product cannot meet all the differing needs of different users. Every paper map therefore represents a compromise between the needs of differing users, none of whom receive the ideal product.
GIS will allow users to create (or have created) custom products that depict information exactly as they need to see it. It does not mean that users will receive all the information they need. Decisions will still need to be made about the affordability of collecting and maintaining data. Even with this constraint, users will still see enormous advantages as their map display emphasizes information that they need to better support decision making. Challenges remain; maps are currently the product of highly skilled designers (cartographers) whose years of experience determine the optimum way of displaying information while avoiding clutter. The end user will not have this training and there is a risk that maps will become individually customized to the extent that other users will not understand them. Map design wizards may be one approach to assisting the end user in creating professional-looking maps.
The next problem is that the real world changes and the map product cannot. New editions can be produced but these must replace the existing map. Because of the cost of map production, not every change results in a new map. The map is allowed to drift from reality until the usability is reduced to the extent that a new edition is justified. Thus no map is really a reflection of the current real world: it is a historic snapshot. This can be a critical limitation on today's fast-moving battlefield where weapon ystems are capable of significant alteration of the real world.
GIS can only solve this problem if the problem is acknowledged and addressed. A frequent comment is that GIS could be allowed to drift as out-of-date as mapping did without imposing additional risk. This is incorrect because of the nature of computer processing. Geographic analysis is invariably based on fuzzy data that are processed to give a fuzzy answer. Humans conduct this processing taking account of fuzziness, one element of which is the validity of the data. A GIS (or any other computer system) takes a mechanistic approach and computes an answer based on stark data and stark algorithms. The "answer" actually represents one possibility out of a range of possibilities. This is fine if all the data are correct since the answer should lie in the middle of the range of possibilities. If data are wrong, because they are incorrectly maintained, then the errors caused in the answer will be passed forward to the next step in the decision support process. The errors then compound in a highly unpredictable manner. The end result conforms to chaos theory where small variations in input create huge and unpredictable variations in output. Two things must happen to mitigate this risk. First, data must be properly maintained. Second, human intervention must apply a sanity check after each step in the decision support process.
One of the main needs for a map is to support situational awareness. All commanders and their staff need to understand the battle situation. The map acts as the spatial framework upon which the situational display is built. This is typically in the form of an acetate overlay, pinned over the map, upon which symbology is drawn to represent the disposition of forces. The aim must be for all headquarters and cells within headquarters to share a common view of the situation and, more importantly, plans for future operations. The paper map is incapable of doing this because the plan is transmitted by reproducing the trace (itself a potential source of error) and then taking it by courier to other headquarters. This process can take many hours in the chaos of war during which time the situation and, indeed, plans may have changed. Faxing the overlay by cutting it into strips and then reassembling in the receiving headquarters is a measure of the desperation to find a faster solution.
GIS has an important role to play in holding a digital representation of the battlefield that can then be transmitted over the communications infrastructure. This is NOT just a list of coordinates sent as a location status (LOCSTAT). Graphic order overlays will comprise a range of elements, some of which will need to have a more complex spatial representation. Movement axes, boundaries, routes, and minefields are examples of elements that should be passed in a structure that can be readily integrated into the receiving unit's GIS.
Digital Geographic Information and GIS
DGI will fulfill the function of a paper map on the digitized battlefield, but only when supplemented by the software tools that exploit DGI: the GIS.
DGI does not in itself equate to the paper map. The paper map contains geographic information but the important point to note is that the map embeds the geographic information into a framework that provides a grid system, a scale, an orientation, correctly placed names, marginalia, and metadata. When a mapping agency provides a CD� ROM containing DGI, there is no inherent grid system, no scale, no orientation, and no ready means of accessing marginalia and metadata. Indeed, drawing an analogy with the paper map, receiving DGI is rather like receiving a printed list of coordinated points, being given a blank sheet of paper and some ink, and being told to draw your own map.
The GIS Provides Many Things
It provides a mechanism for exploiting DGI in a predictable, repeatable way. Note that in this definition, GIS need not be the exploitation mechanism. A GIS can, for example, be used to pass spatial information to a messaging system that exploits it by passing textual information to appropriate addressees.
It places the DGI into the correct framework for exploitation. This is a complex area and one that is frequently overlooked because the problem rarely arises when using a paper map. To place the importance in context, if DGI is placed into the wrong spatial framework (defined with parameters such as grid system, projection, spheroid, and datum) then it is extremely unlikely that real-world locations will be correctly represented by the map display in the system. This function of the GIS is probably the most important and yet the most frequently overlooked. One of the skills that a professional GIS company brings to the battlefield is knowledge of spatial frameworks. There is little doubt that a competent system integrator could place DGI into the most common spatial framework of Universal Transverse Mercator on World Geodetic System 1984. When a conflict starts on a native grid of Modified Gauss-Kruger on European Datum 1950, as was the case in the former Republic of Yugoslavia, system integrators will struggle to cope with the specialized issues.
A GIS provides the tools to create, maintain, and distribute geospatial data. These are not activities confined to specialist agencies. Every time a unit position changes, that is a change to the geospatial database. When a graphical overlay is transmitted from one headquarters to another, geospatial information is being distributed. Some of the activities can be conducted outside a GIS but reintegrating the information into another system is much more difficult.
Finally, the GIS exploits data. This goes beyond the scope of spatial wallpaper and is covered in the next section.
GIS Analysis
Explicit Analysis� Implied Needs
A key function of a GIS is to analyze spatial data. This covers a range of activities ranging from the simple "where is?" to the more complex "show me all (things) within (a distance) of (another thing)." There are many military requirements that clearly undertake this analysis and for which it is difficult to deny the need for a GIS.
Examples of applications with explicit GIS analysis requirements are cross-country movement analysis, intervisibility, and radio propagation analysis. There are many others. Unfortunately, it does not suffice to merely state the need for a GIS and let the developers loose.
A GIS is a system in its own right that comprises hardware, software, data, human resource, and organizational issues. The software and data issues are particularly important in assessing the feasibility of meeting a requirement.
The feasibility of meeting a GIS requirement depends on a number of related factors including
The level at which the functionality is required (corps, division, brigade, etc.)
--The nature of the analysis
--The data types required
--The resolution of data required
--The quality of available data
--The timeliness of available data
--The method of data collection
--The algorithms required
--The quality of the algorithms
--The handling of data quality by the algorithms
--The presentation of the result to the user
--The extent to which the result meets the requirement
The analysis of feasibility is an iterative process that may change the requirement or eliminate it altogether. An example might be a requirement to analyze beach-landing characteristics in order to support planning of section level operations. This will require vector, raster, and elevation data from both hydrographic and topographic sources. The resolution of data is going to need to be equivalent to 1: 5,000 scale mapping and the timeliness is critical because of the rapidly changing beach environment.
The initial conclusion is that data at that resolution and involving underwater features will need to be populated by putting surveyors on the beach. The timeliness requirement demands that they be put in place immediately before the operation. That then demands the question, "If men are being put ashore to collect data in order to support the planning process, why not send reconnaissance troops capable of selecting the optimum course of action?" This would then eliminate the requirement to include the analysis functionality.
An alternative conclusion would be to alter the requirement from analysis to visualization. That would then only require elevation data (albeit including underwater information) and imagery. Those are more easily collectable and would negate the need to place surveyors on the beach. The computer is then only presenting available information instead of attempting to derive new information. This compromise then conforms to the top-level need of the system that was to provide the commander with information to support his decision making processes. Note that it would be a foolish commander who used visualization to replace reconnaissance. It would be wiser to use visualization to focus reconnaissance.
Implicit Analysis
Most GIS analysis requirements are not so obvious. The requirement for a GIS is implicit and thus ignored.
One example is convoy planning. The need to plan shortest or optimum routes involves GIS functionality. Note that the GIS need not involve a map interface. Route planning software often has its interface through a text listing that gives directions. A frequent response is that "I have route planning software at home and that's not a GIS." It is! Most commercial route planning software comes packaged with preprepared data and thus runs straight out of the box. This is an example of a highly tailored GIS that does one thing and one thing alone. It cannot be amended to undertake different functions nor can data easily be added for new areas. Limited editing can be done but geographic management and maintenance are not easily undertaken. The package is expected to be disposable because the computer on which it runs is unlikely to have a life of more than three to six years.
The military will require route-planning functionality that is much more flexible. The software must be capable of using data wherever the operation is being conducted. These data should be common to other applications so that the same data are used to display roads on the situation display as are used to create an optimum routing. All applications exploiting that route data require GIS functionality.
Many of the requirements specified for a command and control system demand GIS functionality. The problem is that if that common GIS foundation is not acknowledged at the specification stage, that foundation is likely to be fragmented and poorly constructed.
A bigger problem concerns the contract stage. If the GIS requirement is not explicitly specified as a foundation component then a contractor may be tempted to build a separate GIS for each element. This might just meet the requirement statement but future enhancement will be extremely difficult and it is extremely unlikely that user expectations will be met. Problems with inconsistent handling of geographic data, geographic data version management, and geographic data maintenance are unlikely to be exposed during contract acceptance. It is even possible that these problems may survive the artificial environment of exercise. Problems will occur (and matter) when the system is deployed operationally.
A key problem is how to specify the GIS requirement. Attempting to write a cardinal point specification for core GIS services is an incredibly difficult task. It would be akin to having to write a cardinal point specification that covered UNIX, Windows NT, and VMS. That doesn't happen with the operating system that is now specified as the industry leader: Microsoft's Windows NT.
It may be that this is the preferred method for selecting a GIS. Let external market forces determine the best solution and then back the industry leader. The alternative is years of chaos as different systems select different GISs thus precluding software reuse, complicating the process of sharing geospatial data and raising costs. There is little prospect that the absence of competition will raise prices since defense remains a small part of the overall GIS market that remains an aggressively competitive environment.
The United Kingdom has taken a compromise route. It has specified the GIS industry leader as the interim defense standard (ESRI's ARC/ INFO � and ArcView � GIS products) but that decision was based on a competition conducted by Military Survey. Contractors are now mandated to use those products as the basis for GIS functionality unless there are demonstrable reasons why they are not suitable for a particular project. There has been very little dissension.
Defining a GIS
GIS as a Science
GIS is a relatively new discipline and as such retains some scientific mystique. Many GIS vendors have developed their businesses in a scientific or academic environment. The civilian marketplace has bought GIS as turnkey solutions to be operated by GIS professionals from the same scientific or academic background.
Defense is now demanding GIS as transparent tools for mission-oriented users. This has proven to be an insurmountable challenge for some vendors. Fortunately this demand comes at a time when advances in processing power and continued falls in information technology (IT) prices are bringing GIS-capable infrastructures onto the desktop. There is a growing awareness that GIS has a role to play in an incredibly diverse range of applications throughout society.
This vision of GIS making a difference and becoming a societal agent will inevitably result in the tools approach sweeping aside the scientific mystique. This will offer significant advantages to defense as less and less work becomes necessary to create a transparent geographic tool set.
The growing use of GIS in society is also offering unexpected benefits. Many of the requirements that defense believed to be unique to that market such as intervisibility, cross-country movement analysis, and high-resolution image analysis are now finding parallels in the civilian market. Environmental impact studies, oil and gas exploration, and commercial satellite imaging are all now contributing to the range of tool sets available to the military. This military/ civilian synergy is an excellent illustration of the advantages of following a commercial off-the-shelf (COTS) approach to development.
GIS as a System
Just because a tool is transparent to a user does not mean that it will be transparent to either the developer or the financier! Indeed it is possible that more planning and resources will have to be applied in the short term to meet that long-term goal. A properly implemented GIS will appear serene to the user while behind the scenes a complex range of interactions between system components is taking place. A GIS, whether part of a bigger system or not, remains a system in its own right. For successful implementation all components of the system must be considered throughout the development, implementation, and deployment phases. The five elements that must be considered are hardware, software, data, human resource, and organizational issues.
Hardware
The military environment already places significant demands on hardware. GIS imposes significant additional burdens. A GIS that provides a map display requires a high-resolution display. A pixel resolution of 1024 x 768 is generally accepted as the absolute minimum to achieve a sensible map resolution and area. Lower resolution than this produces a postage stamp map display that then requires fast graphics architecture to allow rapid panning and zooming facilities.
DGI is also voluminous, particularly when dealing with raster mapping. Raster mapping is the easiest form of DGI to produce since it is just a scan of a paper map. In order to retain the detail of the map it is necessary to scan at high resolution. This, combined with the need to capture the large format of a map and the large numbers of maps required to provide theaterwide coverage, creates significant data volumes.
There are two hardware choices. Data are either stored locally or centrally. Local storage demands significant hard disk capacity (typically gigabytes for theaterwide cover) but spares network bandwidth. Central storage reduces the requirement for local storage but can place a significant demand on network bandwidth. A typical compromise will involve central storage with local caching. This cannot be done without a clear understanding of data requirements and availability at the earliest stage of design.
There are many other examples of specific demands that GISs place on hardware infrastructures. This is not the place to expose them all. All involve complex interactions between data, software, and hardware, and will involve compromises that may impinge on training requirements and organizational issues.
This theme of competing demands and iterative development is central to the design of GIS. This requires realistic test beds and prototyping to ensure that operational demands on the system are understood before deployment. While these issues are pertinent to the whole Command Control Communication Information (C3I) system development, they are particularly acute within the GIS components.
Software
GIS vendors tend to supply software packages that provide a foundation on which to develop specific functionality. Unless they are properly implemented as a cohesive part of the C3I system, they are likely to impose significant burdens on other parts of the system.
The most vulnerable part of the system in this respect is the human resource. A poorly implemented GIS solution will impose significant training burdens on the end user. This is at odds with the need to provide a tool, not a system, to the user.
One particular challenge is the burden of managing DGI. There had been a hope that a single CD� ROM containing DGI would replace the rolls of paper mapping scattered throughout a headquarters. Unfortunately, not only will the DGI be in addition to the paper map, it may well take up to 100 CD� ROMs to provide theaterwide coverage of all forms of DGI required. Even if DGI management is only thought of as keeping the CD� ROMs stacked tidily and shuffling them in and out of CD� ROM drives, this is a significant burden. When the management of DGI decides to include the version management, importing, projecting, and maintenance of DGI, the burden on each user is unrealistic.
An alternative approach is to centralize the management of DGI and leave the task to specialists. Not only does this affect the organization in needing to identify the resource to undertake this task, it also affects the hardware infrastructure as highlighted above. If the centralized approach is taken then the software on the user's computer can be focused on exploitation rather than management functions.
Again, the aim is to highlight the issue, using one of many examples.
Data
Without DGI there is no GIS. This fact immediately sets the GIS apart from many other battlefield applications such as word processors, spreadsheets, and messaging. In these other applications, data are created or populated by the user. A GIS demands data from an external source.
A key question to be addressed at the earliest stage of system design is what data are required and who will provide it. Unfortunately, this is rarely a straightforward process since data requirements may be constrained by what the producer can afford to produce, which is in turn determined by the strategic importance of the particular function that demands the data. The chicken and egg cycle is challenging to break into.
The budget structures within defense often work against a compromise solution. A military mapping agency will typically have its own central budget. The project requiring data will be funded from a separate budget. Deciding where the costs of providing mapping data to meet project requirements lie is challenging!
Sweden has addressed this problem in an extremely efficient way by establishing a central agency that carries responsibility for GIS implementation across defense. This agency can then act as a broker to consider both the provision and exploitation of data at the design stage of C3I systems. The result of this innovative approach is that Swedish defense now has the world's most advanced headquarters decision support tools in the form of the GeoPres C3I GIS tool set.
People
While the GIS must be a tool to the end user, it will invariably require raining to get the most from the new capabilities. The challenge for system developers is to minimize that training demand.
Training takes many forms. Users must be made aware of the systems that they will receive before they arrive so that they can amend their methods of working. Prototyping is the ideal mechanism for doing this, but it must be accompanied by more than pure technical training. Doctrinal adjustments must be made and taught during this phase.
The hardware, software, and data components of the system must be developed to minimize the training burdens. This development activity must happen concurrently and iteratively with training development. Much of the training activity must be based on a foundation of spatial concepts and GIS expertise since, even if the user does not have to be a GIS expert, the training development organization will be expected to understand the development issues.
Training must focus on the need to apply common sense to system answers. This must involve an understanding of DGI issues such as data sources, resolution, and quality. This is no different than the current need to train users how to use a map. It is a core skill for all soldiers. Using a GIS will become a complementary skill that must also be incorporated into basic training syllabuses.
Organization
The organizational issues involved in implementing a GIS are so significant that they warrant a separate section later in this paper. They are similar to, but built upon, the organizational issues that have to be addressed in implementing any IT solution.
The reason for discussion in this section is that the organizational issues are an integral part of system design, implementation, and deployment. The compromises necessary in hardware, software, data, and personnel components will in turn demand compromises in organizational issues. The organizational changes that will occur as the system deploys will likely impose new demands on all other elements. This iterative development requirement will continue throughout the system life cycle.
GIS as an Infrastructure
While GIS must be considered as a system during design, development, and implementation, it is also an essential part of the C3I infrastructure. As an infrastructure component, GIS should be common to as many application areas as possible. Adopting this approach ensures that
--Software components can
be reused.
--Spatial components of different applications can communicate with one another.
--Geospatial data can be centrally managed.
--Training requirements are standardized across all applications.
--All applications have a common look and feel.
Just because a GIS appears as an infrastructure component does not imply that it must be constructed as an integral part of the infrastructure. Indeed, to do so risks development by nonspecialists. The GIS is a specialist component that must be developed by specialists that understand the integration issues. Moreover, there will be parts of the GIS infrastructure that will need to be manned by specialists. Geographic data management, geographic data creation, and geographic data distribution all are activities that demand specialist operators.
Organizational Issues of GIS
Decision Making Facing In
Team-Support Decision Making
A military headquarters currently focuses in on the bird table (map board). It is around the bird table that group decision support processes take place and where the commander's intent is passed to his staff. The acetate sheets on the bird table have primacy for displaying the current operational picture. The map backgrounds and acetate layers will become the DGI displays in the GIS.
The GIS is therefore at the center of system capabilities. This is at odds with the current perception of a GIS as a peripheral to be addressed later. The design of the system must be based around the GIS in the same way that the design of a current headquarters is based around a map.
An uninitiated systems analyst trying to model the flows of information flowing over and around the bird table is unlikely to succeed. Too much is based on personal contact, gestures, and inference. This creates problems in the migration to IT since the current system analysis is a critical step toward designing the future system. Introducing IT will change the data flows within a headquarters and thus change the methods of working. This in turn is likely to change the command structures within a headquarters. Thus, the reliance on modeling current data flows is not just difficult; it may also be a poor basis for system design.
The introduction of IT into a headquarters demands a top-down approach. This should examine the top-level requirements of a headquarters and then design to meet these high-level requirements. This approach cannot work in defense until there is acknowledgement that IT is inevitable and that it will change the way we do business.
The commercial world has faced this challenge with the management-speak of reengineering the business. In the commercial world those who failed to respond went out of business. The consequences of failing to acknowledge the role of IT in defense would be more serious.
Iterative Decision Making
The Observation� Orientation� Decision� Action (OODA) cycle does not happen just once. The whole mechanism of decision support within a headquarters relies on this mechanism to iterate toward the optimum course of action. Each individual cell conducts its own OODA cycle that interacts with all the other cells' OODA cycles. At present the interaction is based on human contact: visiting other cells to determine how a particular action may impact others. Much of that contact revolves around the map: "We want to do this here� how will it affect what you are doing here?"
GIS can be made to share information via an acetate layer but it is very difficult to conduct that transaction in the fast, iterative way that typifies human interaction over a map. This goes beyond the sharing of documents in an office application environment. The key difference is the spatial framework within which the transactions are taking place. The design of this spatial framework and the spatial database that will build upon it are not optional extras in the design of a C3I system. They must be the foundation upon which other functionality will be built.
This foundation has yet to be set in place. As an example, although there are standards for the passage of background geographic data between headquarters (and indeed, internationally), there are no accepted standards for the passage of spatial overlay information embedded in messaging. While individual unit positions can be passed via Situation Report (SITREP) messaging, there is no mechanism for passing of arrows, boundaries, and other overlay information essential for discussing intentions. Until this shortfall is addressed, there can be no progress toward the ideal of sharing spatial decision support processes around the cell computer systems.
The work-around will have to involve ad hoc groups gathered around monitors. The limitations of screen size and resolution will frequently involve the transfer of information onto the paper map, the making of a decision, and then the transfer of that decision from paper map into the computer. The scope for error is considerable.
Slow Decision Support
One of the limitations of the current process is the time to conduct the OODA cycle. The human interaction takes time and mistakes are inevitably made.
Decision Making Facing Out
Cell-based Decision Making
Currently proposed IT solutions distribute decision support processes to individual cells within a headquarters. There is a danger that the human interaction that provides the current checks and balances will be diminished as a result. The individual cells will provide better individual solutions but the overall solution may not be better because of the lack of interaction between cells.
The sharing of information amongst the cells does not suffice. It is the sharing of the processes that creates a group decision support process. The sharing of processes is difficult because of the limitations of current display technology. Imagine the difficulties if all maps in a current headquarters could only be viewed through a screen-sized window. Consider the bird table viewable only through such a limited window and now preclude anyone from gesturing as they share information. That is the reality of cell-based processing.
This argument appears to lead to a rejection of IT. This is not the case. IT is essential but it must not be introduced as a panacea. The limitations above must be acknowledged and mechanisms established to ensure that their effects are minimized.
Procedures will be needed to establish a formal relationship between the common operational picture as held on the computer database and that displayed on the bird table. Responsibilities for update of the database and bird table must be defined. The primacy of the two mechanisms must be established for a range of contingencies.
Training is particularly important. Users must understand the implications of undertaking planning processes on the computer and must be taught how to balance use of the computer with manual methods.
All of these issues are directly related to the GIS. It is the GIS that will display and exploit all the positional information, and it is the GIS that will provide hard-copy output of the common operational picture. Other parts of the C3I system may contribute to that process but it is the GIS that will maintain a spatial framework throughout.
Doctrine Then Technology or Technology Then Doctrine?
Blitzkrieg Then Tank or Tank Then Blitzkrieg?
Current military IT planning tends to be based on fitting the technology to the existing doctrine. This approach, although understandable, ignores the revolution that IT will cause on the battlefield. The military ignores the inevitability of this at its peril.
Why a revolution? Many will counter that IT is merely an evolution from paper, an evolution from wire to wireless to network, and an evolution from map to GIS. It is all of those things, but all those evolutions happening together and building on one another create a revolutionary technology. IT will be as significant a battlefield development as was the advent of gunpowder, the machine gun, the tank, and the aircraft. The challenge with IT is that since it can't be sat in or fired, it is easier to ignore.
Those who ignore or dismiss the significance of IT are in the same category as those who continued to employ the longbow in the face of gunpowder, those who failed to adapt the tactics of infantry in the face of the machine gun, and those who dismissed the tank as lacking the style of a horse! That is harsh, but there is an opportunity to learn from history as opposed to waiting for history to happen and then learning from it.
Why has this issue been highlighted in a paper that aims to focus on GIS? Unless IT is taken seriously, the difficult components of IT are the first to be neglected. GIS is a complex component that exposes some potentially expensive questions. The availability of terrain data to support mapping functionality is a good example. Terrain data are hugely expensive to collect; so much so that even the United States is forced to compromise in the data it makes available to systems. At least those compromises are made in the light of acknowledgment of the importance of GIS and DGI in the digitization process.
In the United States, General Sullivan, when Chief of Staff of the U. S. Army, made the statement "Terrain data is the long pole of digitization." It does not suffice to leave this sort of recognition to the heads of specialist agencies such as the U. S. National Imagery and Mapping Agency "who would say that, wouldn't they." This is the type of statement that is required from military commanders who will be the real stakeholders. This acknowledgment and the direction that comes from it must happen before doctrinal change can happen.
Evolutionary Cycle
Technology cannot be just placed into a void. It has to meet a stated need. What must be recognized is that the need will rapidly evolve. IT life cycles are measured in months and this is the pace that defense must maintain. The alternative is to return to bespoke developments and thus remain well behind the IT curve.
GIS is recognized to be at an earlier stage of evolution than IT is generally. GIS demands a sound IT infrastructure to build upon, and it is only recently that processing power on the desktop has been able to support GIS. Now that such a point has been reached, an increasing number of users are appreciating the benefits that spatial referencing brings. That point has yet to be reached in other than specialist areas of defense.
The analogy is general office applications. Processing power (and software developments) created generally usable office applications about five years ago. They have now taken off, and there are few headquarters where office applications are not regarded as an essential part of doing business. Now that networks are spreading through defense and E-mail is beginning to connect people and organizations, the importance of the technology is growing rapidly.
The key question is one of how to keep pace in the most cost-effective way. The evolution is so fast that it is difficult to maintain a sense of evolution rather than revolution. If every three years the look and feel of all hardware and applications change and require retraining it is not evolution, it is revolution. This is particularly true now that more complex systems such as GIS are being introduced. There has to be a mechanism for maintaining a fast evolutionary cycle without it turning to revolution.
Assuming that an evolutionary approach is accepted as inevitable there is one certainty: that hardware platforms will be expected to carry an increasing burden of functionality over their life cycle. This functionality increase is particularly likely in areas where users do not understand the benefits that may emerge. GIS specified to mimic the capabilities of a paper map pin board will offer glimpses of benefits that the user had not expected. When the user demands implementation of these new capabilities, he/ she will be frustrated if the evolution cannot take place without a change of hardware platform.
The message is that evolution of software capability will demand overspecified hardware.
Interoperability
Flexible Systems
One mechanism for ensuring ongoing evolution is to build flexible systems. IT has now evolved to the stage where certain standards (some de facto, some de jure) are emerging with some hope of medium-to long-term stability. Stability is a relative term and medium-to long-term translates as three to five years. Systems that are built in a modular fashion using these components as building blocks stand a reasonable chance of evolutionary success.
GIS is no different. The next few years will see an inevitable growth in component-based GIS solutions. Instead of large, amorphous GIS packages that lend themselves to turnkey solutions we will see toolboxes of geographic components that can be built into larger systems. ESRI's products have always been based on this toolbox approach and the introduction of MapObjects � software in 1995 builds further on this approach.
There are many issues to be resolved before GIS components achieve their full potential. Some are commercial (such as how to earn revenue from widely distributed components) and others technical (such as the CORBA versus ActiveX arguments raging between UNIX and Windows NT proponents). One key question for developers and project staff to address is the extent to which chosen GIS solutions will offer a migration to a component-based future.
Open Systems
Defense imposes some severe demands on IT vendors. Interoperability per se is not one of them. The nature of open systems computing today ensures that most vendors deliver interoperability out of the box. The annual Joint Warrior Interoperability Demonstration (JWID) has successfully demonstrated (certainly for the last two years) that by gathering modern systems and a few technicians together anything can be connected to anything!
Hardware connection represents the simple part. Software interoperability is much more complex. Demonstrating an open computing approach is now becoming a requirement to stay in business as a software vendor, but not openness at any cost. Users will be reluctant to see performance or functionality suffer in pursuit of openness. Openness will never mean in GIS terms that all vendors will share a common data structure. That would be the equivalent of the car industry agreeing to share common body panels, common engines, and common wheels. The cost savings would appear attractive to the financiers, but the developers, marketers, and most importantly the user would be dismayed at the concept of a "one car for all" approach. A Trabant is likely to emerge from this approach to openness!
A sensible approach to openness is to agree on a lower level of commonality and generic metadata standards that ensure that data can be transferred between systems without loss. By focusing on the ability to import and export different data formats while developing capabilities to directly read third party data structures, ESRI is able to satisfy its large customer base's requirements for performance and functionality while ensuring interoperability in the defense community. It is important to note that the user retains the choice between direct reading, which may involve compromising performance or functionality, and importing into ESRI's own data structures, which will optimize performance and functionality but is at odds with the interoperable ideal.
It is important to note that this approach to openness cannot result in common applications that can sit over a variety of vendors' GIS packages. It does mean that different vendors' data can be accessed by applications that are built using ESRI's GIS solutions. Some users require a lean, high-performance GIS, while others require a high-functionality, utility GIS. While ESRI's data structures will support both extremes, few other vendors offer the same flexibility.
JWID represents an excellent example of ESRI products fitting into an interoperable environment. This fit is aided by ESRI's wide range of products� from lean desktop GIS through full-functioning enterprise GIS� which ensures that this geospatial interoperability occurs at all levels and between all levels of defense systems. This success is based on ESRI's extensive experience working with international defense standards bodies such as the NATO Digital Geographic Information Working Group (DGIWG) to develop product standards such as the ubiquitous Vector Product Format (VPF).
The Future of GIS� A Vision
One Data Store For All Users
Defense GIS users currently see a representation of the real world as portrayed by a cartographer. There is some way to go before all users see the same representation of the real world. This is critical since without a common background there can be no common view of battle activities: the common operational picture.
That, then, must be the first aiming point: establishing a distributed geographic data architecture that ensures that all users view a common database. That needs moderating since it is unlikely that communications bandwidths will allow full distribution of geographic data for five to ten years. So a reasonable midterm vision may be to have an infrastructure based on a work group approach. A work group in this model equates to a deployed headquarters. The deployed headquarters have high-bandwidth internal networks with comparatively low-bandwidth external connections. Users within a headquarters view a common geographic database. Work groups' geographic databases are maintained and kept in synchronization by geographic specialists.
The long-term vision is that users see the real world in the way that they choose to see it. Users have access to a contiguous high-resolution image archive that is constantly updated with change information. Automatic feature-extraction algorithms are tuned to users' particular needs and extract features as required in a repeatable and predictable way. Bandwidth, processing, knowledge base generation, and obscuration are only some of the issues standing in the way of implementing the vision.
Visualization
Processing power has increased to the level where the benefits of a visualization approach are becoming more obvious. The most powerful function of the brain is its image processing capabilities and visualization is a mechanism that presents information in the most easily assimilated way.
The growth in processing power can only continue and it is likely that more and more workstations will have visualization capabilities. At present, visualization is confined to terrain. Very few systems allow the integration of all battlespace information into a visualization environment. Those systems (primarily in the United States) that are demonstrating this capability are persuading commanders that battlespace visualization is going to be an important component of digitization.
Battlespace visualization is more than just the integration of all battlespace information into a three-dimensional model space. It introduces the time dimension. One significant limitation of today's situation displays is that they are not recording the current operational picture. They are recording snapshots taken at different times depending upon when the last SITREP was sent or recorded. Naval systems have for many years used track management software to extrapolate the current picture from past reports of position, bearing, and speed. This type of functionality must appear for land systems before battlespace visualization becomes a reality. There are significant problems to be overcome with extrapolation based on terrain, route, and vehicle characteristics.
Having introduced the time element, probably in the three-to five-year timeframe, it will become possible to rewind and fast-forward the battle picture. The rewind capability will allow the visualization of enemy movements to build up a picture of future intentions. Fast-forwarding will allow options to be war-gamed against the computer to understand strengths and limitations before selection of the preferred solution.
The merging of technologies is inevitable. Already there are enormous parallels in the visualization, simulation, mission-rehearsal, and war-gaming environments. It is likely that differences will disappear in time.
The acronym "GIS" has not appeared in this section. That is deliberate and reflects the likelihood that interfaces to geographic information will be so natural and intuitive that users will not think of maps, GIS, current operational pictures, or even computers. They will just be immersed in commanding and controlling the battle. That doesn't mean that these components will not be present; it does mean that they will be so good that they will be transparent to the user.
Another reason why the term GIS may become less visible is the continued migration from large software packages to component building blocks. These geospatial components are likely to become distributed over the network and called upon to perform a function as required.
This network computer vision will place significant demands on network bandwidth, especially since large-area, high-resolution screens are going to demand large volumes of data attached to the component object. Panning and scrolling about a map display will involve huge volumes of data passing over the network. Caching locally may be one mechanism for evening out the flow of data but one certainty of a military headquarters is that where the General scrolls, his staff will surely follow. This may impose unmanageable demands even on future network infrastructures.
A Ubiquitous Tool
Terrain is the bottom line for defense and most personnel in defense will need systems that are spatially aware. This is likely to migrate down to the weapon system and infantry section as technology evolves. The United Kingdom's Bowman communications systems will provide GPS receivers down to section level. More is required though. There is a considerable difference between knowing one's position and knowing how one is situated!
It is the GIS that will tell an infantry section where known threats are located. That may not be based on a map display. Inside an armored personnel carrier it may suffice to have a tube running around the troop compartment that displays red in various sectors to indicate the direction of the enemy threat. Research is also ongoing to link external video cameras into a central processing unit that will feed appropriate displays into soldiers' display headsets. The soldiers will be able to look around and see "through" the vehicle to the outside world. This offers significant advantages in reduced motion sickness and improved situational awareness. At the heart of the advanced graphics processing system will be GIS components that maintain a spatial reference. This may appear to be science fiction but it is technically feasible today. Whether it is affordable, survivable, or sustainable involves other issues.
Weapon systems are likely to develop more spatial awareness. The advantages of having a weapon system that maintains awareness of the locations of friendly forces are obvious. Small, embeddable GIS software components that can be placed in systems ranging from defensewide C3I systems down to individual weapon systems will ensure interoperability between systems. Above all they will provide repeatable and reliable performance in a wide range of mission-critical applications. This is unachievable today but is likely to become feasible within a five-to ten-year time frame.
Conclusion GIS, whether defense appreciates it or not, will be a critical foundation technology for the electronic battlefield. This paper has deliberately focused on the organizational challenges because these are the issues that must be addressed by the user community. In parallel with this, GIS vendors will continue to develop software functionality to meet rapidly evolving user requirements.
In order to fully satisfy these requirements, GIS vendors will endeavor to understand the language and needs of the military. The military in turn must work to understand the organizational issues that lie at the heart of GIS implementation.
For more than 25 years ESRI has been helping people manage and analyze geographic information. ESRI offers a framework for implementing GIS in any organization with a seamless link from personal GIS on the desktop to enterprisewide GIS client/ server and data management systems. ESRI GIS solutions are flexible and can be customized to meet the needs of our users. ESRI is a full-service GIS company, ready to help you begin, grow, and build success with GIS.
ESRI 380 New York Street Redlands, California 92373-8100 USA
Telephone: 909-793-2853 Fax: 909-793-5953
For more information on ESRI software call ESRI at
(1-800-GIS-XPRT) Send E-mail inquiries to info@ esri. com
Visit ESRI's Web page at www. esri. com
Corporate 1-800-447-9778
ESRI� Minneapolis 612-454-0600
ESRI� Alaska 907-344-6613
ESRI� Olympia 360-754-4727
ESRI� Boston 978-777-4543
ESRI� California 909-793-2853 ext. 1-1906
ESRI� Denver 303-449-7779 ESRI�
San Antonio 210-499-1044
ESRI� Charlotte 704-541-9810
ESRI� Washington, D. C. 703-506-9515
Australia 61-9-242-1005
Canada 416-441-6035
France 33-1-46-23-6060
Germany 49-8166-677-0
Hong Kong 852-2-730-6883
International India 91-11-620-3801
Italy 39-6-406-96-1
Poland 48-22-256-482
South Asia 65-735-8755
Spain 34-1-559-4345
Sweden 46-23-84090
Thailand 66-2-678-0707
United Kingdom 44-1-923-210450
Venezuela 58-2-285-1134
Outside the United States, contact your local ESRI distributor.
For the number of your distributor, call ESRI at 909-793-2853, ext. 1-1235
ESRI� St. Louis 314-949-6620
Printed in USA No. GS-35F-5D86H 24
The information contained in this document is the exclusive property of Environmental Systems Research Institute, Inc. This work is protected under United States copyright law and other international copyright treaties and conventions. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, or by any information storage or retrieval system, except as expressly permitted in writing by Environmental Systems Research Institute, Inc. All requests should be sent to Attention: Contracts Manager, Environmental Systems Research Institute, Inc., 380 New York Street, Redlands, CA 92373-8100 USA.
The information contained in this document is subject to change without notice. U. S. GOVERNMENT RESTRICTED/ LIMITED RIGHTS Any software, documentation, and/ or data delivered hereunder is subject to the terms of the License Agreement. In no event shall the Government acquire greater than RESTRICTED/ LIMITED RIGHTS. At a minimum, use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR �52.227-14 Alternates I, II, and III (JUN 1987); FAR �52.227-19 (JUN 1987) and/ or FAR �12.211/ 12.212 (Commercial Technical Data/ Computer Software); and DFARS �252.227-7015 (NOV 1995) (Technical Data) and/ or DFARS �227.7202 (Computer Software), as applicable. Contractor/ Manufacturer is Environmental Systems Research Institute, Inc., 380 New York Street, Redlands, CA 92373-8100 USA.
ARC/ INFO, ArcCAD, ArcView, ESRI, and PC ARC/ INFO are registered trademarks; 3D Analyst, ADF, AML, ARC COGO, ARC GRID, ARC NETWORK, ARC News, ARC TIN, ARC/ INFO LIBRARIAN, ARC/ INFO� Professional GIS, ARC/ INFO� The World's GIS, ArcAtlas, ArcBrowser, ArcCensus, ArcCity, ArcDoc, ARCEDIT, ArcExplorer, ArcExpress, ARCPLOT, ArcPress, ArcScan, ArcScene, ArcSchool, ArcSdl, ARCSHELL, ArcStorm, ArcTools, ArcUSA, ArcUser, ArcWorld, Atlas GIS, AtlasWare, Avenue, BusinessMAP, DAK, DATABASE INTEGRATOR, DBI Kit, ESRI� Team GIS, ESRI� The GIS People, FormEdit, Geographic Design System, GIS by ESRI, GIS for Everyone, GISData Server, IMAGE INTEGRATOR, InsiteMAP, MapCaf�, MapObjects, NetEngine, PC ARCEDIT, PC ARCPLOT, PC ARCSHELL, PC DATA CONVERSION, PC NETWORK, PC OVERLAY, PC STARTER KIT, PC TABLES, SDE, SML, Spatial Database Engine, StreetMap, TABLES, the ARC COGO logo, the ARC GRID logo, the ARC NETWORK logo, the ARC TIN logo, the ARC/ INFO logo, the ArcCAD logo, the ArcCAD WorkBench logo, the ArcData emblem, the ArcData logo, the ArcData Online logo, the ARCEDIT logo, the ArcExplorer logo, the ArcExpress logo, the ARCPLOT logo, the ArcPress logo, the ArcPress for ArcView logo, the ArcScan logo, the ArcStorm logo, the ArcTools logo, the ArcView 3D Analyst logo, the ArcView Data Publisher logo, the ArcView GIS logo, the ArcView Internet Map Server logo, the ArcView Network Analyst logo, the ArcView Spatial Analyst logo, the ArcView StreetMap logo, the Atlas GIS logo, the Avenue logo, the BusinessMAP logo, the BusinessMAP PRO logo, the Common Design Mark, the DAK logo, the ESRI corporate logo, the ESRI globe logo, the MapCaf� logo, the MapObjects logo, the MapObjects Internet Map Server logo, the NetEngine logo, the PC ARC/ INFO logo, the SDE logo, the SDE CAD Client logo, The World's Leading Desktop GIS, ViewMaker, Water Writes, and Your Personal Geographic Information System are trademarks; and ArcData, ARCMAIL, ArcOpen, ArcQuest, ArcWatch, ArcWeb, Rent-a-Tech, www. esri. com, and @esri. com are service marks of Environmental Systems Research Institute, Inc.
The names of other companies and products herein are trademarks or registered trademarks of their respective trademark owners.