Department Of Defense Usage of FalconViewTM 

Chris Bailey 

Sr Research Engineer 

Georgia Tech Research Institute 

Overview 

FalconViewTM is a non-proprietary GOTS (Government Off-The-Shelf) application for 

analyzing and displaying geographical data crucial to the warfighter. Its ease of use and 

wide variety of applications have made it the system of choice for the warfighter and the 

standard for data interchange in Iraq and Afghanistan. This paper will outline some of 

the reasons that FalconView is the software of choice for displaying geographic 

information within the Department of Defense and how FalconView compares to various 

COTS (Commercial Off-The-Shelf) GIS programs. 

History 

Georgia Tech began development of 

FalconView in 1990 after being 

contracted by the Air National Guard 

(ANG) to create a mapping package 

that would run on a Personal 

Computer and be easier to use than the 

existing UNIX based system. Georgia 

Tech had a history of mapping 

application development as part of the 

Micro Fix and the FORSCOM 

Automated Intelligence Support 

System (FAISS) programs for the 

Army. The initial development was 

performed under an Army Research 

Lab contract. 

 The combination of FalconView and 

the Combat Flight Planning Software 

(CFPS) which was being developed 

by the 46th TS and TYBRIN Corp 

became the Portable Flight Planning 

Software (PFPS). 

FalconView Milestones 

 1990 First request from F-16 pilots 

 1993 Initial fielding for F-16 community 

 1994 C-130 moving map and intelligence 

feeds 

 1995 Initial SOF helicopter support / 

CHUM towers 

 1996 High resolution imagery / additional 

overlays 

 1997 Full scale adoption throughout Air 

Force 

 1998 Initial Navy release 

 1999 Incorporation into PCI-3, ACC 

standard Intelligence PC based system 

replacing CIS 

 2000 FalconView for NIMA released 

 2002 US Army release 3.2 as part of 

AMPS program 

 2003 USSOCOM and US Army Unique 

3.3.0 release 

 2004 FV mapping engine chosen as JMPS 

standard 

The initial versions of FalconView were simply a set of routines to display scanned raster 

maps such as CADRG with simple stick routes drawn on top, but the easy to use software 

was popular with the end users and more functionality quickly followed. Each new 
feature was developed with significant input from the user community and improved with 

feedback from a group of enthusiastic beta testers. Unlike most other DoD developed 

applications, the FalconView development team was given very general requirements by 

the ANG which were fleshed out into a product by the development team and mission 

planners who used the software for their daily activities. 

In the early years the software was distributed to other services from user to user because 

it made their jobs easier. As the program matured, USSOCOM adopted PFPS and added 

capabilities such as the Moving Map functionality and helicopter support. In 1997 the 

Air Force adopted PFPS into the AFMSS program, followed by the first Navy release in 

1998 and an Army’s release in 2002. Each adopter of the software funds new 

functionality to the program and expands the capabilities to interact with other systems. 

Version 3.2 released in 2002 was a milestone because it added significant third party 

programmer support to FalconView. As programmers learned how they could extend the 

functionality of FalconView, a plethora of new applications were developed by other 

government program offices and even by end users who used Microsoft Visual Basic to 

automate tasks for their specific needs. 

Today FalconView supports a robust set of programmer interfaces which allow diverse 

applications to fuse their information into a single coherent picture of the user’s area of 

interest. The users know that data produced on FalconView can be shared with other 

branches of the armed services and coalition partners who have PFPS through the 

Foreign Military Sales Program. 

Because the federal government has funded the development of FalconView, it is a nonproprietary GOTS application and is free of any license fees for government use. This 

includes the use of the Software Developers Kit (SDK) which documents the interfaces 

for use by government developers and contractors working on government programs. 

Finally, there are established end user support structures in place for all services 

including 24 hour help desks, and System Support Representatives in the field. 

Ease of Use 

Ease of use is not a discrete quantity that can be measured in a system. There are 

constant trade offs when mixing ease of use, functionality and flexibility. A tool like 

MapQuest®, is easier than FalconView within its domain but it obviously lacks the 

features and flexibility required for aircraft mission-planner and therefore would be very 

hard or impossible to use in the mission-planning domain. At the other end of the 

continuum are tools such as ArcViewTM or MapInfo® which expose many more options 

to the user but require a steeper learning curve than FalconView. FalconView’s goal has 

always been to allow a user to be productive with less than a half day of training while 

providing enough features and flexibility that the experienced user is not limited by the 

application. Today most FalconView users have never taken a formal training course and 

they are capable of installing their own software, managing their own map data and 

performing their day-to-day operations without outside help. 
As the DoD moves to a network centric architecture, there is often a belief that a thinclient such as an application running in a web browser, will assure ease of use, but if the 

functionality is missing in a thin client, the user is stuck with very few options. A thicker 

client can be easy to use but like any system, it requires significant dedication during the 

development to get the mix correct. A network architecture cannot assure software 

usability. 

Interoperability 

FalconView began life as a traditional “stovepipe system” but it was valued for its ease of 

use and functionality over other “stovepipe systems.” As more features were added and 

more communities adopted FalconView, it became obvious that all the communities 

could not be satisfied by a single monolithic program. Therefore, the interfaces were 

opened up, first by publishing Interface Control Documents (ICDs) on the data formats 

and later by creating programmers interfaces to the core software. 

TBMCS 

ATO 

ACO 

TaskView 

MCS 

AIM 

JCD 

XML 

MCS 

Light 

USMTF 

ASAS, TAIS, IMETS 

Radio 

JTT, 

MATT, 

TRS, 

VIPER 

TACELINT 

TDIMF 

TAB-37 

SADL Radio 

Predator 

(ESD Decoder) 

TRIXS 

TIBS 

TDDS 

PCI-3 

SIPRNET 

GPS 

PCI 

ArcView 

(C/JMTK) 

ADOCS 

TACFIRE 

OH-58D 

Raindrop 

Excel2F 

Shape 

M 

C2PC 

IMOM 

FPTAS 

Intel 

Office 

MIDB 

Shape 

Figure 1: Some of the systems currently sharing data with FalconView 

Today FalconView has been incorporated into a large number of systems many of which 

are not part of its initial target audience. It is used in applications as diverse as whale 

tracking, searching for MIA’s in Vietnam, tracking drug runners, and producing the 

President’s daily briefing booklet. The DoD contractor community now has many 

development groups who have used the Software Developer Kits to integrate FalconView 

with their applications. There are currently over 450 registered developers and since 
there are no license restrictions within the DoD, the actual number of developers is likely 

much greater. 

The following list shows a few of the programs, which are using these developer 

interfaces: 

• FPTAS – Calculates areas where enemy man-pad would likely be positioned to 

get a clear shot at an aircraft take off or landing 

• FBCB2 overlay in FalconView – Allows Army aviation to share FBCB2 blue 

force tracking on FalconView on a kneeboard computer 

• Multi-predator – Displays the location of multiple predator tracks in real time on 

FalconView 

• C130 EW trainer – Uses FalconView to lay down training threats which then 

become simulated for on board training. 

• Oilstock Overlay – Used by DIA to view intel data in Oilstock format on 

FalconView 

• Dynamic-Debrief tool –User developed tool to synchronize multiple GPS 

playback with video capture. 

• TopScene – Gives 2D feedback of 3D display on FalconView 

• Environment Processor (EPTM) - Evans & Sutherland’s interactive 3D 

visualization to FalconView 

• PCDS – Personal Computer Debriefing System displays output on FalconView 

• Pioneer UAV, Navy Swarm UAV – Planning and display of UAV positions 

• SADL Link – displays data sent across a SADL radio to a kneeboard computer 

But there is more to interoperability than just being able to pull or push data from one 

system to another. The users need to obtain information from the data, which requires 

the ability to view the data in a familiar context. The data must be timely and if it 

requires a separate analyst to massage the data, then it is very often not used or not 

available in time. FalconView’s ease of use enables the warfighter to perform the types 

of analysis that have traditionally only been available to the one computer expert in the 

back room. 

The Air Force Combat Support Office was charged with creating a suite of tools to 

integrate the wide variety of data sources available to the Combined Air Operations 

Center (CAOC) in a single program. In their first version they chose to use a powerful 

COTS GIS package that could perform ad-hoc analysis of the data. The problem they 

found was that the system required a dedicated operator with enough training on the 

software to make use of its power. Their next version of tools leveraged FalconView and 

while some of the flexibility may have been lost, the system can be used by a much wider 

audience. Today, both sets of tools are available, one for the advanced operator and one 

for the typical user. 

GIS Functionality 

A Geospatial Information Systems is a software system which combines a geographic 

display (a map) with a database which allows queries based on the geography. A 
simplistic GIS system might allow a user to collect and plot the locations of all Starbuck 

Coffee Houses and all Krispy Kreme doughnut shops and be able to do queries such as 

find all the places where a Starbucks and Krispy Kreme are within 1 mile of each other. 

There are obvious military applications for GIS systems for instance: 

• Find all the sensitive (non-combat structures) near a target of interest 

• Find areas where a route passes within a danger zone 

• Analyze a drop-zone to ensure the terrain is suitable 

FalconView is not a general purpose GIS tool but uses GIS techniques under the covers 

to perform similar analysis without adding complexity for the user. The user rarely 

knows or cares what algorithms are being used internal to the application. 

OGC Standards 

Recently the OpenGIS Consortium (OGC) has produced a number of standards which 

attempt to create a minimum level of interoperability among web-based GIS systems. As 

these standards are adopted by more systems, it becomes possible to automate the 

exchange information between OGC compliant systems. The DoD has been slower than 

the commercial world at adopting these standards but its recent focus on Network Centric 

Warfare is changing that. 

The OGC standards define two basic types of services Web Feature Services (WFS) and 

Web Mapping Services (WMS). Web Mapping Services allows a client to perform a 

query to a server and get back a picture (JPG or PNG) of an area of interest with desired 

data. Web Feature Services allow a client to perform a query and get back an XML 

description of the features in the area of interest. The OGC also defines the schema of 

the XML used to make the query and to return the results. This is known as Geospatial 

Markup Language (GML). 

Currently the OGC standards are fairly new and many venders support them to provide a 

minimal level of interoperability. Venders like ESRI support OGC standards but 

encourage developers to use their richer set of (non OGC compliant) interfaces for clients 

who want greater performance or flexibility. These interfaces typically use open web 

standards for the low level protocols such as XML, SOAP and WSDL but there is no 

commonality at higher levels. FalconView currently does not have a funded requirement 

that requires OGC interfaces but the internal architecture would support the addition of 

these interfaces if a new feature needed them. 

Web Based Interfaces 

Portable Flight Planning Software users have traditionally not had access to robust 

networks in the field or in flight. This has made most network centric functionality 

impractical. As the network infrastructure has evolved some of the technology has 

become more appealing. Time sensitive data such as threat and blue-force positions are 

currently readily available on FalconView through the SIPRNET, JWICS or through 
satellite radios. The next step will be to get and publish data through WMS and WFS 

services or by integrating technology such as ArcSDE and ArcIMS into FalconView. 

A likely architecture would use ArcSDE as a backend in FalconView and enabling 

queries to ArcIMS servers to fetch information such as weather or target information. 

This would allow users to keep static data, such as charts and imagery, local for fast 

access and query for data of temporal significance. It would allow users to continue to 

use their variety of tools available today while leveraging the growing number of 

networked services. 

A second paradigm for web access to data would be to allow a networked update of large 

data sets. Traditionally chart currency has been achieved by the National Geospatialintelligence Agency (NGA) producing chart update CDs which are mailed to users who 

insert the CD and use FalconView to copy updated data over any that was out of data. 

As connectivity improves these updates could be automatically download similar to the 

way most computers receive new virus signatures today. 

Comparing C/JMTK with FalconView 

C/JMTK and FalconView do have some overlapping functionality but there are also a 

number of complimentary technologies in both. C/JMTK is a “toolkit”, it is not an 

application. If you install C/JMTK on your computer there is no “exe’ to run. It provides 

a number of software modules which can be integrated into a program to provide 

mapping functionality. FalconView is an application with a number of modules designed 

specifically for use within the FalconView application. 

PFPS Application Suite Map Render/Display is common 

(e.g., CADRG, CIB, GeoTIFF, VMap, ...) 

FalconView Application C/JMTK Toolkit

•CFPS 

•Map Render/Display •Map Render/Display 

•CAPS 

•Map Data Mgr •Geodatabase Model 

•CWDS 

•DAFIF FalconView •GIS Analysis Tools 

•FV Mapping 

•Route Planning Engine •Web-map Services 

•etc. ... 

•GPS •Image Processing 

•Chart Update, etc. ... •Satellite model 

•other ... 

Figure 2: C/JMTK and FalconView functionality (based on a diagram by Paul Brown of MITRE) 
Figure 2 shows the relationship of some of the components of PFPS, FalconView and 

C/JMTK. Most of the overlap of FalconView and C/JMTK falls in the area of the 

FalconView Mapping Engine. The Mapping Engine is a set of COM components used in 

FalconView and JMPS for rendering map information as a background. Traditionally 

this data has been scanned paper maps (CADRG) or satellite imagery (CIB). It also 

supports Vector Product Format data (VMAP, DNC), and commercial standards such as 

GeoTIFF and MrSID data. C/JMTK can also display these formats of data. FalconView 

has traditionally been more focused on raster data and C/JMTK on vector data and both 

have some areas that are stronger than that of others. 

Outside the overlap regions is functionality such as robust route planning, large scale 

web-based map services, DAFIF, and CHUM handling. Incorporating C/JMTK 

functionality into the FalconView application and the packaging FalconView 

functionality for use in C/JMTK would enhance both products. 

Conclusions 

It makes sense to leverage all of the best technologies available to the DoD where one 

size does not fit all. FalconView meets much of the DoD’s user’s needs as a system 

which is easy to use, yet flexible and extensible enough to provide the functionality 

demanded by a mission critical application. 

Open web standards are making it easier to share data among systems. The 

transformation of systems to these new standards is making system level interoperability 

practical but there is still application level work required in each problem domain. 

Leveraging the technology available in FalconView and C/JMTK will allow this 

transformation to progress quickly while continuing to provide tools that the warfighter 

knows how to use.