UDOP: Final Review and Recommendations

Thermopylae PhD Consulting Team

Sean C. Ahearn, Joshua S. Campbell, André Skupin & Juan­Carlos Villagran

19 July 2010

2

Table of Contents

Executive Summary ………………………………………….……………………….….…………….…………………4

1. Introduction ………………………………………………………………………………………………………………5

2. Review……………………………………………………………….…………………………………………………….. 6

2.1 The UDOP Vision………….………………………….…………………………………………………… 6

2.2 UDOP Overview ………………………………………..………………………………………/………..6

2.3 Analytic Framework …………………………………………………………………….……………….7

2.4 Content Issues with UDOP ………………………………………………………….………………..8

3. Role of the UDOP Ontology ……………………………………………………………………………………….10

3.1 Directory Structure ……………………………………………………………………………………….14

3.2 User Profiles …………………………………………………………………………………………………18

3.3 Search based on Tagging ………………………………………………………………………………21

3.4 RDBMS Implementation………………………………………………………………………………. 22

3.5 Semantic Web Implementation …………………………………………………………………….26

3.6 Collaborative Ontology Development…………………………………………………………… 27

4. Symbology ………………………………………………………………………………………………………………….29

4.1 Physiological and technological constraints………………………………………………….. 29

4.2 Symbology standards……………………………………………………………………………………. 30

5. Data Issues …………………….……………………………………………………………………………………………30

5.1 “Sources” ……………………………………………………………………………………………………….31

5.1.1 Network links…………………………………………………………………………………………….. 31

6. Process Issues ……………………………………………………………………………………………………………..32

6.1 Types of data and users ……………….………………………………………………………………….33

6.2 Work flow of input process ……………………………………………………………………………..33

3

7. UDOP Architecture ……………………………………………………………………………………………………….35

7.1 Architecture ……………………………………………………………………………………………………..35

8. Conclusion ……………………………………………………………………………………………………………………..38

9. References ……………………………………………………………………………………………………………………. 39

10. Appendix A: Ontology Tutorial (attached) …………………………………………………………………….39

11. Appendix B: Key data sets for military and HA/DR applications …………………………………….39

4

Executive Summary

The UDOP Ph.D. team was tasked with providing guidance for improving the 3D UDOP geospatial portal

though a set of short term solutions and long term recommendations for its future development. It examined

the strengths and weaknesses of UDOP and interviewed system users to obtain their perception of the

problems. Two issues stood out: (1) the lack of a scalable paradigm for content management and (2) the

limitations of the system architecture which relies on a file­based approach for representing geographic layers,

rather than an entity­based approach afforded by a geo­spatial database management system. Other issues

related to: data used in UDOP and the need to understand and represent its providence, accuracy and

reliability; the need for processes associated with data input and management; and an approach to symbology

that was user­appropriate.

The first step the team made was to establish a vision for the analytic evolution of UDOP which fulfills its

promise of providing the user with an environment that filters and synthesizes a myriad of spatial/temporal

data points, from a wide variety of sources and modalities, into a coherent understanding of the user’s area of

operation. The vision we present shows the potential roadmap for evolution from where the system was at

the project’s inception through the development of domain ontology, the introduction of a spatial database,

and creation of an environment that provides “situation awareness”, “sense­making”, prospective analysis and

simulation. At the foundation of this evolution is the domain ontology which organizes HA/DR domain

knowledge in a coherent hierarchy/network of classes and relationships among classes (i.e. concepts). The

root “concepts” for this ontology were established to be ActorConcept, DataConcept and SituationConcept. From these three concepts over 750 concepts that capture the knowledge domain of UDOP were created

during the course of this project. This ontology was used as the basis for reorganization of the folder structure

of UDOP midway through the project. An ontology tutorial was developed to enable SouthCom to continue

the development of the ontology in a collaborative manner.

A fundamental tenet of UDOP is to get the right data to the right user for the problems at hand. This is

exemplified by the interplay of the concepts of actors, situations, and data in the domain ontology, aimed at

capturing the idea of a user profile directing a user towards a basket of relevant data/services. We make two

recommendations to implement the ontology and the concept of a user profile: one using an RDBMS and for

which we have developed a scheme for implementing aspects of the ontology; the second using a semantic

web environment which we believe to be the more powerful of the two approaches but perhaps the more

difficult to implement in the shorter term.

The current UDOP system architecture is a single­tier, file­based system that has significant limitations with

respect to data management, spatial/temporal analysis and modeling. To make UDOP more versatile and

powerful, we propose a three­tiered OGC compliant architecture composed of the data tier, the web services tier and the client tier. The data tier consists of one or more PostgreSQL/PostGIS databases (e.g. separate

databases for different classification levels or networks) which form the heart of the geospatial system. The web service tier is an OGC Web Services layer that provides a range of services supporting various types of

geospatial data. The client tier includes the UDOP and additional thick, thin, and mobile clients. The advantage

of this architecture is that it places all of the development efforts in the data and web services tiers and gives

flexibility in choosing a client that is optimal for a particular set of functionality. The implementation of UDOP

within this framework will take it further down the evolutionary path outlined above.

Finally, we discuss data issues, processes and symbology in the context of improving UDOP’s reliability,

integrity and interpretability. Infused throughout our discussion is the importance of interoperability at the

system level, syntactic level and semantic level.

We believe that the solutions and recommendations described herein provide a path to achieving the

promise of the UDOP to create a unique and powerful user­centered environment for situation awareness,

sense­making and complex modeling.

5

1 Introduction

The primary goal of this report is to suggest short­term solutions to enhance the capability of the 3D UDOP

and long­term recommendations for its future development. UDOP is an integrative platform that brings a

wide range of data and services from disparate sources together into one user defined operational picture.

We believe the key to success of UDOP is a framework of interoperability. Interoperability is the ability of

systems to provide services to, and accept services from, other systems and make them to operate effectively

(Sen, 2005; Wei Xu and Sisi Zlatanova, 2008). Interoperability can be characterized at three levels: system (i.e.

structural), syntax and semantics (Sheth, 1999; Mohammadi et al., 2010). At the system level, geospatial data

integration is based on technical specifications defining file standards, communication protocols, and access

technologies such as XML/GML, JavaScript and AJAX (Yang et al. 2010). Syntactic interoperability is enabled

through data representation, data model protocols (e.g. OGC simple feature specification) and language

protocols (i.e. SQL). Semantic interoperability focuses on aspects of meaning that are expressed in language

codes, messages, or other forms of representation (Sheth, 1999;Mohammadi et al., 2010). Sen (2005)

identifies these as levels of interoperability reaching an ideal pinnacle of spatial data harmonization (figure 1).

Figure 1: levels of interoperability (from Sen 2005)

Within the context of interoperability, the team made two major recommendations: the development of a

UDOP ontology, and the migration of UDOP to a three­tiered open architectural platform. Significant progress

has been made in developing the ontology during the course of this project.

The team’s strategy was to first lay out a framework for the “optimal” UDOP (Figure 2) and provide a roadmap

for getting there through improvements in content management, architecture and processes. Improvements

in content management were implemented through the development of a UDOP ontology which informed the

reorganization of the file structure at the midcourse of the project. The ontology can be defined as the formal

description of the Humanitarian Assistance / Disaster Response (HA/DR) knowledge domain through a

6

network of concepts (e.g., “Country”, “Transnational Organization”), instances (e.g., “United States”, “NATO”),

and relational properties (e.g., “contains”, “needs data about”). The UDOP ontology discussed below now

includes over 750 concepts and over 1100 relationships between those concepts. Recommendations for

architectural changes are focused on the introduction of a spatial database at the top of a three­tiered

structure for data management, web services and clients. Additionally, recommendations are made for

addressing data issues, like metadata requirements and data currency, process issues associated with data

access and input, and symbology. The following recommendations are given in the context of fulfilling the

vision of UDOP that is discussed below.

2 Review

2.1 The UDOP Vision

The promise of the User Defined Operating Picture (UDOP) is to create an environment for the user that filters

and synthesizes a myriad of spatial/temporal data points from a wider variety of sources and modalities into a

coherent understanding of the user’s area of operation. The term sense-making has been coined to capture

this concept (Pirolli and Card, 2005). The intent of UDOP is to enable sense-making at different levels of

abstraction and geographic/temporal scales. Levels of abstraction may range from the person in the field who

needs information about what is happening around them and is tapping into the core data more directly, to

those operating at a higher level of abstraction that require more complex interpretations and

transformations of the data. An analogy for this type of abstraction is the difference between tactical, and

strategic thinking; tactical thinking tends to be “closer” to the data, while strategic thinking tends to be a

further abstraction of the data into more complex ideas and concepts.

These hierarchies of abstraction also correspond to different spatial and temporal scales. For example, a

logistical manager needs access to the real­time data on transportation networks and the number of people in

an IDP camp. A theater commander correspondingly needs a weekly summary of all logistics shipments and

the location of all IDP camps. In this example, the information required for sense­making is user dependent; it

is this notion that forms the foundation of the UDOP’s “user defined” concept. Therefore an operational UDOP

system requires an intelligent user profile component that defines the appropriate data a user needs. Other

key characteristics of UDOP are that it is a “net­centric” environment that enables shared situation awareness

or sense­making among many individuals, and that it is a dynamic environment in which real­time events can

be monitored and the significance of change can be understood.

2.2 UDOP Overview

The 3D UDOP is currently built on a Google Earth (GE) Enterprise core, in the form of the GE web browser

plug­in, with customized ExtJS controls for the Table of Contents (TOC) and other user­interface controls.

Certain base layers, primarily imagery, are custom loaded into the GE Enterprise server. Additional datasets

can also be created and stored within the 3D UDOP. These are generally created by digitizing and annotating

areas on screen. Individual files created within the 3D UDOP are stored in the Keyhole Markup Language

(KML/KMZ) format as flat­files on the UDOP backend. Storing datasets, which are essentially collections of

7

geographic objects and their attributes, as KML files poses some challenges for improving the UDOP. It means

that geographic data layers are file­based; any feature­based information associated with an individual

geographic data entity (i.e., individual points, lines, or polygons) are ‘locked’ in the file and cannot be handled

individually. Given the rapid stand­up of the 3D UDOP application after the Haitian Earthquake, this was the

logical framework for development. However, the lack of entity­level processing imposes significant

constraints on the evolution of UDOP as a robust system for data organization, access, management, sense

making, and analytic modeling.

2.3 Analytic Framework

The analytic framework suggested by the team is meant to provide a vision for the development of UDOP

from its origins as a Google Earth Plug­in to its endpoint as a complex modeling environment. The vision as

shown in Figure 2 shows an analytic framework for a geospatial portal from a simple data viewing and

visualization platform to a complex modeling platform that supports sense­making, decision support,

prospective analysis and simulation. The current UDOP architecture either supports or could potentially

support aspects of the analytic capabilities along the yellow line including: data viewing and visualization,

delivering user relevant data, intelligent browsing, and situation awareness. However even these functions are

restricted given the current architecture. The use of the ontology will enhance all of these functions but the

constraints associated with the lack of a feature­based spatial database management system limit what is

possible. The more complex, higher level functionality shown along the white portion of the arrow are not

supported in the current architecture of UDOP and would require a spatial database management system.

8

Figure 2: UDOP Evolution and Analytical Framework

2.4 Content Issues with UDOP

In this section we discuss current impediments to achieving the UDOP vision of delivering the right

information to the right person at the right time. It should be noted that the UDOP vision taken to its fullest

extent represents a ‘grand challenge’ in information science; solving this problem is a major research initiative

for many organizations. However, improvement to the current 3D UDOP is an iterative process and we have

identified several areas that can be rapidly improved. These areas can be condensed into three general

categories: content access, content organization, and content management. Ultimately these categories are

inter­related, as are the solutions for improving them. Specifically, we proposed to generate an overall UDOP

ontology that will simultaneously address content access, organization, and management. In fact, during the

course of this project, we initiated the development of such a UDOP ontology (see also the appended tutorial).

Its first iteration already informed a first set of modifications to how data are organized in the UDOP table of

contents (TOC), implemented in mid­June. We have since continued to modify the ontology, based on client

input. Continued evolution of the formal ontology – combining stakeholder knowledge feedback and IT

capacity building – will be crucial in addressing content access, organization and management, towards a more

“user defined” environment.

9

Before we describe the initial use of ontology as an organizing force for UDOP, it is useful to see the solution in

the context of the problems we documented during our examination of UDOP and in our discussions with

SouthCom personnel. We divided these issues into problems associated with content access, organization and

management. In Table 1 problems associated with content access are clearly the most pressing problem from

the UDOP users’ perspective. Finding specific content within the mass of data that is accumulating in the

system is a major challenge for users. Because of how the 3D UDOP is currently constructed, users have

difficulty navigating through the table of contents interface, finding data related to their specific interest,

knowing if data is current, organizing new data, and extracting data for use in presentations. Of the five

content access items in Table 1: (a – c) are search related problems, which may have short term fixes, (d) is a

fundamental problem which strikes at the foundation of the current systems and its lack of a “user defined”

operational picture, and (e) and (f) relate to the limitations of the system architecture and the lack of a spatial

database management system as a back end. Of the seven content organization items in Table 1 all are

related to the lack of a consistent methodology for organization which we believe the development of the

ontology can address. The thirteen items in content management can be grouped into administrative issues

(a­e), data issues (f­k) and system management issues (k­j). These items are all process related that can be

addressed through procedures, work flow and data policy. Some of the issues like k and l could be addressed

with the ontology.

1. Content Access

a. Sort by Name and Sort by Date within individual folders

b. Keyword search within folders is lacking

c. iHarvest search

i. returns top level of folder hierarchy in which search item was found

d. file organization display is the same regardless of user type

e. Feature and attribute­based queries aren’t possible

f. Spatial queries aren’t possible.

2. Content Organization

a. lack of naming conventions (file names)

b. single tag­based classification

c. easier way to find data (data v. actor v. situation)

d. current organizational structure doesn’t place layers at the appropriate level of the

information hierarchy.

e. current organization doesn’t place similar layers under the same parent in the hierarchy

f. content is not tailored to user specific needs

g. organization is not intuitive

10

3. Content Management

a. no required information when loading data

b. too many administrators

c. no policy on privileges

d. approval process of data sets entered

e. no guidelines or structure for entering data or linking data sets

f. data currency ­ time expiration

g. data quality

i. metric

ii. corroboration

h. data: archive vs. presentation views

i. duplication of data for presentations

j. deleted layers (handling?)

k. unnamed layers default to misc. folder

l. harmonization (same hospital, multiple files and attributes)

m. synchronization (multiple UDOP deployments)

Table 1: Summary of UDOP Content Issues

3 Role of the UDOP Ontology

The formal description of the UDOP knowledge domain undertaken in this project is in the form of an ontology

coded using the Web Ontology Language (OWL). This ontology incorporates three main elements of the UDOP

domain: (a) data, (b) actors, (c) situations. Ultimately, the idea is to have a single repository of data – or data

access points, to be precise, since some data may come in the form of distributed data services – that users

can integrate within views that are automatically tailored according to the users’ situational and actor

condition. Actor conditions may indicate whether users come from the military or civilian domain, from

governmental or private organizations, etc. There also will be situational filters, largely based on the thematic

and geographic particulars of an event (e.g., earthquake in Haiti), but also recognizing the domain­specific

approaches in responding to an event (e.g., HA/DR phases). Note that actor and situation conditions will work

in conjunction to drive the selection of particular data sets to be used in a display, and will also play a role in

the tagging of datasets, which enables more advanced data insertion/search procedures. Aside from the

data/view filtering effects of actors and situations, another guiding principle is that users should be enabled to

interact with UDOP in their own, domain­specific language and yet have underlying data be structured such

that maximum sharing and minimum duplicated storage occurs. This is an example for what is meant by

semantic interoperability and will be a key advantage to the evolving ontology (see Figures 3­5 and the

appended ontology tutorial).

11

Figure 3. The actor portion of the UDOP ontology.

12

Figure 4. The data portion of the UDOP ontology, with focus on the current folder structure.

  13 

 

Figure 5. The situation portion of the UDOP ontology

  14 

Note that the hierarchical structure that formed the backbone of the initial ontology design (following an 

industry­standard approach), has been accompanied by a large number of functional cross­connections. For 

example, specific phases during the response to an event (i.e., what defines a situation) will have particular 

data needs. The ontology attempts to make those links explicit. That is what will enable advanced situation­

driven filtering. It will also make shared data access the norm, while allowing modulation in terms of access 

permissions via the actor component. 

Among short­ to mid­term implications of the ontology, three stand out: (1) reorganization of the “directory” 

structure presented to UDOP users, (2) user profiling in generation of key view defaults, and (3) support for 

advanced tagging. 

3.1 Directory Structure

The table of contents (TOC) presented in the UDOP interface is the main organizational instrument in a 

particular UDOP view. It is the user’s view onto the existing data ontology and shapes his/her perception of 

how UDOP could [not] support a particular application requirement. Note that, in that sense, an ontology 

already exists – as far users are concerned, the current TOC is the UDOP data ontology! The problem is that it 

was initially devised in accordance with the main actor’s organizational structure, as opposed to the inherent 

ontology of the data or situation (Figure 6).  

 

Figure 6. Initial ontology of UDOP as reflected in the TOC folder structure.

That single­actor, shallow­structure ontology was the root cause for the eventual devolution of the data 

organization and the ensuing difficulties experienced by users. To begin addressing these issues, we compiled 

various sources about data requirements of military and civil users into the data concepts portion of the 

ontology. In the mid­effort report we proposed a separation of core data from event­ and actor­specific data 

(Figure 7). Core data would be characterized by (a) having a very large user base, (b) correspondence to 

commonly and often openly available sources, and (c) the ability of being generated/maintained before an 

event/action. Core data can thus serve as base line data. During an event/action, such core data may be 

supplemented with additional attributes (e.g., damage estimate attached to hospitals) or more 

comprehensive, event­specific data generation may be required (e.g., damage assessment based on new 

aerial photography) and put in relation to core data (e.g., pre­event imagery).  

  15 

 

Figure 7. Coarse and Fine­grained views onto data concepts in the UDOP ontology, as introduced in the mid­

effort report.

Note the scalable make­up of the organization allowing for data to be placed/accessed with varying 

conceptual granularity. For example, currently a user might deal with a single kml file containing buildings of 

various types. For such a heterogeneous file, the “CoreData/Building” concept location would be most 

appropriate. On the other hand, if the user wants to add a file containing only hospitals, then the 

“CoreData/Building/Hospital” would be more appropriate. Anyone looking for buildings would now be able to 

get more specific files as well (assuming proper permissions).  

Duplicate access without duplicate storage is another important aspect. For example, the “Hospital” concept 

may be found in multiple places in the ontology, including “CoreData/Building/Hospital”, 

“CoreData/Infrastructure/Medical/Hospital” and “CoreData/Population/Health/Hospital”. Inserting a file 

under any category will make it accessible under all of the others. This will make it easier to find data, both by 

browsing and by search (where searching for “Building”, “Health”, or “Hospital” would all be able to yield data 

on hospitals). It is all about enabling users to think more about what data they want and less about where in 

the system it might be located. Note that there must be an indication to the user regarding this ontological 

structure, to avoid confusion, along the lines of “also in ‘Building’ and ‘Health’”, plus linked checkboxes, etc...  

  16 

Apart from a concept pointing to multiple super­classes, the ontology also supports equivalence of concepts, 

such as when “Imagery” is explicitly modeled to be equivalent to “Remote Sensing” or “Sewage” being 

equivalent to “WasteWater”. That feature is especially useful for search functionality. 

Following the mid­effort report, an initial reorganization of the UDOP TOC occurred that partially reflected our 

initial vision. In turn, that new TOC folder structure was then formally captured in the ontology (Figure 8).  

Figure 8. Coarse and Fine­grained views onto data concepts in the UDOP ontology, reflecting changes in the

TOC folder structure (captured as of 06/16/2010).

In making those modifications, we were able to let the new structure semantically align and connect itself with 

the previous structure (Figure 9). Whenever the new folder structure referred to a concept that had already 

been captured in the previous structure, then this became a natural hook for linking old and new knowledge 

representations. This demonstrates a key advantage of using a formal ontology: support for semantic

interoperability. When a new folder structure is introduced – perhaps to accommodate a particular 

application scenario – it is not necessary to impose that structure on all users! The existing knowledge 

structure does not have to be thrown out, but can continue to be used. One just has to perform semantic 

linking between concepts. When the mid­effort and current folder structures are juxtaposed in one 

  17 

visualization (Figure 9), one can see a number of semantic links between them, including such concepts as 

“Medical”, “TerrainFeatures”, “Commerce”, and “PhysicalEnvironment”. 

 

Figure 9. Semantic alignment between different folder structures.

This semantic alignment allows reuse of domain knowledge (i.e., concepts) and reuse of data sources. An 

example for reuse of domain knowledge is the automatic appearance of the “Hospital” class at 

“CoreData/CombinedPosture/Medical/Hospital” (see right side of Figure 8), even though it had not been 

contained in the specifications for the new UDOP folder structure. The detailed break­down of sub­concepts 

for “Agriculture” is another such example of reused knowledge. Semantic linking also means that data sources 

can be automatically reused in multiple ways. The detailed view in Figure 10 shows that the five data sets that 

had originally been characterized as belonging into the “CoreData/CombinedPosture/Medical” class – and 

labeled accordingly with the prefix “1I_MEDC” – are automatically accessible from several other folder 

locations. One implication is of course that tailoring of what users see in the UDOP interface could be done in 

a fluid and transparent manner.  

  18 

 

Figure 10. Semantic alignment allows inserted data to be simultaneously accessible to multiple folder

structures.

Despite the highly interlinked ontological structure, we would recommend to display the TOC in hierarchical 

form, by following the concept hierarchy. However, it would be advisable to filter the concepts to be explicitly 

displayed in the TOC based on (a) user profiles and interactions (see next section for an example) and (b)  the 

degree to which data classes are actually “occupied”, i.e., have data sources associated with them. Empty 

classes can be hidden. Sparsely populated classes could be hidden (perhaps revealed on request) and their 

content subsumed by their parent classes. For example, if there were five data sources immediately inside the 

“Medical” class and only one inside the “Hospital” class, then perhaps that one data source could be directly 

added to the list of “Medical” data in the TOC.  

The ontological approach also supports more sophisticated TOC displays, such as a visual indication of data 

volume (e.g., how many data sets are inside a folder listed in the TOC) and data currency (based on time 

stamps). 

3.2 User Profiles

One goal of 3D UDOP to be supported by the ontology is to enable views driven by user profiles, especially 

with respect to generating default displays and under consideration of default permissions. The ontology 

  19 

supports this through linking of actor concepts to situation concepts and data concepts. It must be made much 

easier for given users to see a good first starting visualization based on who they are and what situation they 

are addressing. The following is a possible scenario: 

1) User logs on  

2) User indicates the attribute, space, and time parameters of event/action they would like to 

address 

­example: user inputs “earthquake”, “Haiti”, “January 2010”  

3) Based on their actor profile, a particular situation perspective is suggested by the system  

­ example: military user gets led to the HA/DR perspective, with other perspectives  

shown as options (US Military campaign perspective, OCHA perspective, etc.) 

4) User agrees to work within that perspective or chooses a different one  

­ example: user agrees to keep HA/DR perspective  

5) System displays a list of possible phases. User chooses which phase he/she is engaged in. 

  ­ example: user chooses “Response” 

6) System displays possible considerations with respect to the chosen phase. User chooses one or 

more consideration to pursue. 

  ­ example: user chooses “Health / Medical Care Assets” 

7) System finds matching data concepts by following ontological links from the situation section to the 

data section 

  ­ example: system finds links from “Health / Medical Care Assets” to data concepts of 

“Ambulance”, “Hospital”, “Health”, and “Medical” 

8) User can add/subtract further data concepts as seen fit 

9) System finds actual data sets that correspond to the automatically found and added concepts 

10) System creates a default Google Earth view displaying those data sets 

In terms of the user experience/interface, these would not be discrete steps, like a series of windows. Instead, 

steps 2 through 8 would certainly be in a single window, with the ontology driving the necessary filtering, 

similar to the pizza selection example shown in the ontology tutorial (see appendix). 

  20 

 

Figure 11. Use of the UDOP ontology to automatically match available data to a user/application scenario.

In terms of the ontology, such operation is already supported, as illustrated in Figure 11. The seemingly (i.e., 

from the user’s point of view) hierarchical flow of operations is actually derived from a large number of cross­

linked items (see Figures 3­5) by following this simple sequence: user � perspective � consideration � data. 

Four different types of relationships are involved, each indicated by different link symbols in Figure 11: 

1. “subclass” relationship involving different types of perspectives and different types of phases for each 

perspective; 

2. “considers” relationship between phases and considerations; 

3. “needsDataAbout” relationship between considerations and data concepts; 

4. “has individual” relationship between data concepts and data sets.  

The key principles behind this design are: 

- users can keep speaking their domain language 

  21 

- users can get meaningful views faster 

- data remain separate from situation and actor, which enables reuse across situations and actors 

 

3.3 Search based on Tagging

Effective search and retrieval is a crucial impediment to continued growth of 3D UDOP. Tagging of individual 

data items is seen as a key strategy for addressing current shortcomings. To be most effective, we propose 

attaching to each data item up to nine different types of tags, as indicated in Table 2. The nine tag types come 

about as the intersection of tags being potentially generated by three different parties, namely the user, the 

system (driven by the ontology), and an administrator. Each of the nine tags addresses particular issues and 

has a particular generation mechanism. The only thing a user absolutely has to input when uploading a data 

set is a data tag or multiple data tags (e.g., “Prisons” and “Detention Center”). The system will store those and 

use them to automatically generate ontology­based data tags, which is when notions of “concept hierarchy” 

and “concept equivalence” become important. Those tags will identify relevant locations in the data concepts 

portions of the ontology (see Figure 7), such as “Population/PublicSafety/Prison” and “Building/Prison”. 

Meanwhile, an administrator might decide that “Jail” is an additional useful tag. Thereby, sets of tags with 

three different tag types are generated, all of which will be searchable. 

 

Based on logon status and interactions, the system will then attempt to generate actor and situation tags 

automatically. Users may however input their own as well. In addition, an administrator may choose to add 

additional tags, as seen fit. Note that the separation of user tags, system tags, and administrator tags is 

designed to allow maximum flexibility in data insertion and retrieval. Users from a given actor domain will be 

able to insert/retrieve data sets via familiar terminology, while users from another domain are still able to get 

to the same data via their respective vocabulary. For example, one would be able to find “PublicSafety” data 

sets even if no data­generating user ever used that term! The overhead costs for users and administrators are 

small, with the ontology driving most of the integration. Furthermore, storing of user tags allows the UDOP 

system to accumulate domain knowledge, e.g., how groups of users refer to certain types of data and in which 

situations they do so. That knowledge can then be used to incrementally modify the ontology itself, leading to 

further improved usefulness and user satisfaction. For example, based on accumulation of evidence from user 

tags and administrator tags, one may want to add “detention center” and “jail” to the ontology, possibly as 

equivalent classes to “prison”. 

 

Major Ontological Aspect

Tag Source  Data Situation Actor

User manual/required  manual/optional  manual/optional 

System automatic  automatic  automatic 

Admin manual/optional  manual/optional  manual/optional 

Table 2: Major Ontological Aspects and Tags

  22 

3.4 RDBMS Implementation

The redesign of the folders based on the ontology developed by the team was the first step in implementing a 

coherent approach to content organization. Management and access for the UDOP data layers (i.e. KML 

documents) is possible through the use of a relational database management system (RDBMS).  The database 

structure described below makes it possible for KML documents (or any other entities) to be associated with a 

flexible categorization scheme, which can be changed freely without altering the documents themselves, and 

which can be arbitrarily complex.  Both hierarchical relationships and network relationships are supported. 

The schema we are proposing has four entities: users, profiles, categories (i.e. concepts or classes in the 

ontology) and documents (i.e. KML files).  Any particular user’s view of the structure can be controlled by 

profiles, which can allow for user­centric views into the hierarchy, and can also be used to restrict access to 

documents in designated categories. 

Relationships

Figure 12 shows the schema for the proposed conceptual model. The USER_TO_PROFILE relation establishes a 

many­to­many relationship between profiles and users, wherein each user may participate in multiple profiles, 

and each profile may have multiple users.  The PROFILE_TO_CATEGORY relation similarly associates each 

profile with multiple categories (i.e. concepts), and vice­versa.  The CATEGORY_TO_CATEGORY relation 

contains relationships between categories.  This allows each element in the category hierarchy to contain zero 

or more parents and/or children.  With this structure a hierarchy of categories is supported as well as category 

associations, enabling the linking of categories across the hierarchy.  The USER_TO_CATEGORY relation allows 

users to be associated with categories without requiring a profile.  This may be useful for cases where more 

flexibility is required, for example when users may select their own categories of interest, outside of their 

profiles.  The DOCUMENT_TO_CATEGORY relation enables each category to contain multiple documents, and 

a single document to belong to multiple categories.  Each entity can have attributes associated with it. For 

example meta­data information can be an attribute of the document entity and could include multiple tags 

that were not already included in the category hierarchy (see section 3.3 for discussion of user, system (i.e. 

category), and administrator tags). 

Naming the document by using DOCUMENT_ID only ensures that each document will be unique, and also 

ensures that changes in metadata or categorization need not affect the documents themselves.  KML 

containing categorization information can be generated from the database dynamically, or pre­generated as 

needed. 

 

 

23

CATEGORY

PK CATEGORY_ID

CATEGORY_NMOthers...

DOCUMENT

PK DOCUMENT_ID

FK1 UPLOADED_BY_IDOther metadata...

DOCUMENT_TO_CATEGORY

PK,FK2 CATEGORY_IDPK,FK1 DOCUMENT_ID

USER

PK USER_ID

USER_NMFIRST_NMLAST_NMTITLE_TXTELEPHONE_TXEMAIL_TXOthers...

PROFILE

PK PROFILE_ID

PROFILE_NMOthers...

USER_TO_PROFILE

PK,FK2 USER_IDPK,FK1 PROFILE_ID

PROFILE_TO_CATEGORY

PK,FK2 PROFILE_IDPK,FK1 CATEGORY_ID

USER_TO_CATEGORY

PK,FK1 USER_IDPK,FK2 CATEGORY_ID

KML filenamedusing

document id

CATEGORY_TO_CATEGORY

PK,FK2 CATEGORY1_IDPK,FK1 CATEGORY1_ID

Figure 12. RDBMS implementation of aspects of the UDOP ontology

An example implementation of the schema is show in Figure 13 where we show an arbitrary relationship

between users, profiles, categories, and documents. Documents are named using a unique document ID only;

metadata is stored in the document table; categorizations are stored in database tables. KML data containing

these relationships and documents can be generated as needed.

24

Figure 13. User, Profile, Category and Document relationships

An example of a hypothetical user’s view is shown in figure 14. The example shows the categories associated

with the profile of this particular user. It also shows subcategories with multiple parent references, to

demonstrate the networking aspects of this model. The idea of restricting access to a user based on their

profile is shown with those categories displaying in light grey and finally the example also demonstrates how

categories not in the user’s profile can be added to the user’s view

25

Figure 14. Sample view that a user might have, with annotations.

26

3.5 Semantic Web Implementation

An RDBMS approach to ontology implementation limits the type of relationships that can be exploited among

elements (e.g. classes in the ontology) to “has Subclass” or “has Superclass” type relationships. As indicated

above, the variety of the types of relationships potentially supported by the ontology is however much larger,

with examples like “hasJurisdictionOver”, “isPartOf”, or “needsDataAbout”. The ability to automatically infer

implicit relationships – as opposed to tracing just the asserted ones ­ is also executed with greater ease within

a full semantic web software development environment.

In order to support practical deployment of the ontology in support of automatic reasoning, user interface

integration, and database integration, we would recommend the following elements (Figure 15):

a) ontology editor, such as Protégé, as shown in the tutorial;

b) ontology reasoner, such as Pellet;

c) semantic Web programming framework, for which the Jena semantic Web framework is

recommended;

d) code editing, compilation and execution tools, such as Java 1.x SDK and Eclipse IDE.

Figure 15. Ontology deployment within a full semantic Web development framework.

Certainly, deploying an ontology – and one including 700+ classes – tends to be a completely new endeavor

for most IT professionals. Semantic Web software development constitutes a sometimes dramatic departure

27

from traditional database design and computer programming. Here are some key readings for technical

professionals involved, especially when there is no or limited previous exposure to the topic:

� Hitzler et al (2010) Foundations of Semantic Web Technologies. CRC Press.

� Allemang & Hendler (2008) Semantic Web for the Working Ontologist: Effective Modeling in RDFS and

OWL. Morgan Kauffman Publishers.

� Hebeler et al (2009) Semantic Web Programming. Wiley Publishing Inc.

With respect to the end users and other stakeholders, technical aspects of ontology deployment should be

largely transparent. However, that is not the case for the content of the ontology. This is where UDOP users

must be intimately involved, and in a highly collaborative manner.

3.6 Collaborative Ontology Development

As a formal description of a knowledge domain, any ontology can only be useful to the degree that it succeeds

in capturing explicit and implicit knowledge held by a given community. The ontology presented in its current

form was created on the basis of only limited interaction with and with practically no feedback from the

community of UDOP stakeholders. As far as receiving input from the stakeholders, we utilized a number of

documents put together by TST (especially regarding the military side of the UDOP community). This greatly

helped in shaping the broad structure – especially the division into actor, data, and situation components –

and in incorporating military­specific aspects, especially with respect to Humanitarian Assistance/Disaster

Relief (HA/DR). In addition, we profited from information that was provided regarding UN­based approaches.

The proposed work flow “user � perspective � consideration � data” was the results of our

conceptualization of UDOP use, based on the available sources of domain knowledge.

In addition to actually incorporating community knowledge, we attempted to build into the ontology a variety

of different elements that point to the range of potential applications, beyond the more immediate goals. The

location concepts are a prime example for this pedagogic goal, with its incorporation of the hierarchical

organization into “country­province­county­municipality­neighborhood”. It is an example where the

hierarchically nested real­world organization of administrative entities should actually not be translated into a

hierarchy of concepts, despite the temptation. Instead, the real­world hierarchy is expressed through

dedicated object properties (see the appended tutorial for details). Seeing this in action is meant to make it

easier to envision the scope of future UDOP ontology efforts.

With the combination of actual domain knowledge (as conceptualized by the consultants) and the

demonstration of broader uses and ontological design patterns, the UDOP ontology is now at a stage where

collaborative inspection, reflection, feedback, and modification by the stakeholders is of the utmost

importance, with the following steps:

(1) Stakeholders should become familiarized with the ontology via the tutorial. Ideally, this should occur in

conjunction with having the ontology file (UDOP.owl) and the editor application (Protégé) available, though it

may not be necessary for all parties and at this immediate stage.

  28 

(2) The ontology has to be checked for correctness, i.e., whether its formal content is in accordance with 

community knowledge. This should start with the most obvious elements, i.e., classes, individuals, object 

properties, data properties on their own (e.g., naming), followed by simple class hierarchies and membership 

of individuals in classes, and then followed by investigation of how object properties have been used to link 

different elements.  

(3) The ontology has to be checked for completeness, i.e., whether classes, instances, object properties and 

data properties are missing. Different aspects of the ontology may require more of such vetting. For example, 

situational considerations were populated with information provided to the consulting team and may thus be 

quite complete (see orange links in Figure 16). However, without concrete information we had to guess at the 

data needs of those considerations and how they relate to data concepts actually contained in the ontology 

(see yellow links in Figure 16) and we would thus expect those data needs to require thorough revision. Only 

stakeholders can determine which data types are necessary to support certain tasks. For example, which data 

types are precisely necessary to support consideration of “TrendsInTrade” or “CivilAffairsOperations”? If those 

data types already exist in the ontology, then they just have to be linked via the object property 

“needsDataAbout” (see tutorial). Else, the new concepts first have to be added to the data portion of the 

ontology. 

 Figure 16. With the ontology as a formal description of UDOP community knowledge, only that community

can judge its correctness and completeness and contribute to improving it.

  29 

 

(4) The ontology has to be checked for consistency, such as in terms of the granularity of concepts. Is it ok if 

some data types have a detailed break­down into sub­types while others remain at a coarser level? Again, it is 

impossible to answer this without detailed stakeholder involvement. 

(5) It should be identified which additional features the ontology should support and how. For example, it 

might be useful to integrate permissions, presumably originating with actors, but what is the appropriate 

granularity at which to differentiate actors in terms of permissions? 

(6) The questions, concerns, and critique raised by stakeholders may point towards a need to import existing 

ontologies (e.g., for geographic names and coordinate systems) and how to prioritize such imports. Not that 

the current ontology utilized no formal ontology import (apart from informal incorporation of country names), 

in order keep complexity manageable.  

4 Symbology

One of the critical factors in successful and continued adoption of the 3D UDOP system is the use of effective 

symbol sets. Currently, default symbol sets are used whose generic nature does not allow quick visual 

recognition of the underlying meaning. That is why users currently have to rely on TOC interaction to associate 

given symbols with their meaning, for example by switching layers on/off. Ideally, one would have symbol sets 

that satisfy physiological, technological, and standardization requirements.  

4.1 Physiological and technological constraints

Physiological constraints play a role mainly in terms of minimum symbol size in conjunction with symbol

complexity. Simple geometric symbols (e.g., circles, squares, triangles) are recognizable at relatively small size, 

which enables placing larger numbers of symbols and potentially less crowding/overplotting. However, such 

symbols nearly always require explanation via legend or TOC, since their meaning is completely ambiguous 

(apart from certain accepted standards, like blue/red for different forces). 

Graphically more complex symbols (e.g., pictographic signs) are meant to be more easily associated with a 

particular meaning. However, their graphic complexity requires them to have larger symbols size, which 

means that one can only display a smaller number of features, as compared to simple geometric symbols. 

The specific display technology, especially display resolution, plays a role in determining whether symbols of a 

given size can actually be graphically reproduced. For example, symbols on a paper map can be comparatively 

small, as compared to a computer display. Consider that paper maps reproduced by inkjet, laser, or offset 

printing technology typically have a resolution of 300­600 dpi (dots per inch), while most computer monitors 

have around 100­150 ppi (pixels per inch). A small number of smartphones are approaching 300 ppi, but are of 

course highlighting another technology constraint in symbol design, display size. 

  30 

4.2 Symbology standards

Standardization of symbols is particularly important in time­critical applications, as exemplified by emergency 

response and military combat situations, in other words, exactly the scenarios that 3D UDOP is meant to 

address! However, we do not recommend pursuing a single standard for 3D UDOP symbology, due to (1) the 

variety of user groups and application scenarios and (2) the evolving nature of standards in this area. 

Note that symbol standards should never be imposed onto users, due to the factors mentioned above 

(physiological and technological), not to mention organizational factors (i.e., stakeholder engagement). 

Stakeholders must be consulted in­depth, and any proposed symbol set must undergo serious user studies 

involving real­world data sets and use scenarios (e.g., testing for how well symbols can actually be detected 

and deciphered by users). Since such studies would seem outside the scope of 3D UDOP, our recommendation 

is to avoid generating new symbol designs whenever possible and to either use simple geometric symbols or 

turn to existing standards.  

Research on existing map symbology standards relevant to UDOP is currently ongoing (and not yet published), 

for example one at Pennsylvania State University funded by DHS. These efforts are motivated by the lack of 

standardization in map symbols used across DHS and the simultaneous realization that ANSI INCITS 415­2006, 

while intended for emergency management mapping, has in practice been poorly adopted. Results from that 

study should be published in the near future and should be considered then. 

At this point, it is advisable to incorporate into UDOP a small number of existing standards according to their 

current specifications and in recognition of their ongoing evolution. “Incorporation into UDOP” here refers to 

making it easier for users to use those symbol sets with their respective UDOP layers, if they so choose. 

The two most obvious standards to make available to UDOP users are ANSI INCITS 415 and MIL­STD­2525. 

ANSI INCITS 415 is meant to support cross­agency coordination during emergency response and was 

developed by the FGDC (Federal Geographic Data Committee) Homeland Security Working Group and Kent 

State University. Symbols can be freely downloaded at http://www.fgdc.gov/HSWG/index.html. MIL­STD­

2525, also known as DoD Common Warfighting Symbology, is accessible by searching for Document ID “MIL­

STD­2525C” at http://www.assistdocs.com/search/search_basic.cfm. 

Other relevant standards to consider include the Australasian All­Hazards Symbology Project 

(http://www.anzlic.org.au/symbology.html), which has symbol sets downloadable at 

http://www.anzlic.org.au/get/2456956750.zip, and – especially for demining purposes – the Information 

Management System for Mine Action (IMSMA ­ http://www.gichd.org/operational­assistance­

research/information­management­imsma/imsma/symbology/), with symbol sets at 

http://www.gichd.org/fileadmin/user_upload/zip/IMSMA%20V4%20Symbology%20font%20files.zip 

5 Data Issues

Three issues associated with data quality were identified that impact the UDOP: data providence, accuracy, 

and currency. Data providence relates to the source and continuity of the data; this is complicated by the fact 

the UDOP can import data from outside sources. Accuracy involves the reliability of both the spatial and 

  31 

attribute components of data. Data currency relates to the changing nature of data and the ability of the 

system to identify and symbolize outdated data. The relative importance of each issue is also influenced by 

who the user is, and for what purpose it is being used. These qualities and a host of others are usually 

contained in the meta­data associated with a given data set. Meta­data is literally “data about data”. The most 

widely accepted format for metadata is the International Organization for Standardization metadata standard 

(ISO 19115). Many of the requisite data fields for ISO 19115 (user, content, extent…) could be collected 

implicitly by the system as data is uploaded or digitized on screen. Most data released by government 

organizations have a complete set of metadata, so the focus of metadata collection is on the user submitted 

data. Not tracking or providing metadata is cause for questioning the reliability of the data. 

5.1 “Sources”

The UDOP system has three “sources” of data that populates the system:  data “layers” that are brought into 

the Enterprise server, user­digitized entities on­screen (i.e. “heads­up digitizing”), and ‘network links’ to data 

that are served from other systems. Using network links, the UDOP only stores a small KML file containing the 

URL address of the server that is providing the data. The critical difference between these methods is how 

data are stored in the UDOP system. Data layers brought into the Enterprise server and on­screen digitization 

of the actual data entities, are stored within a kml file on the UDOP, and in the latter only the URL to the data 

is stored.    

Data layers 

These layers can be characterized as “base map” or foundational layers that include infrastructure, 

topography, demographics and hydrography. The “core layers” are those that are in place prior to an event 

and “event layers” are those that are created post event. . Meta­data associates with the “core layers” tends 

to more complete and reliable whereas meta­data associated with the “event layers” tends to be less 

complete and reliable if processes to insure standardization, integrity and completeness aren’t followed in its 

collection, compilation and quality assurance.  Having a sound organizational structure in place to insure 

adherence to the ontological framework and the processes to conform to it is even more critical in emergency 

situations. 

Data created  from “heads­up digitizing” is highly dependent on the accuracy of the basemap used for the 

digitizing and needs some form of quality control if it is to be a reliable source of information to the UDOP.   

5.1.1 Network links

By opening the UDOP platform to outside users, the UDOP hopes to utilize data streams were previously 

difficult to tap into. Opening the UDOP to outside users follows a software paradigm generically known as 

Web 2.0; one tenet of Web 2.0 principles is that users provide value by contributing to the system. Exploiting 

‘user­generated content’ or ‘crowdsourced’ data has proven very successful for firms, but its use in disaster 

situations has raised questions about the accuracy and timeliness of crowdsourced data. The issue of 

intentionally bogus data has been a significant criticism to the use of crowdsourced data in disasters. 

Addressing this issue has been a major focus of the Ushahidi team (http://ushahidi.com/), and Patrick Meier, 

an Ushahidi team member and outspoken proponent of crowdsourcing, has written of the utility and accuracy 

  32 

of crowdsourced data (http://irevolution.wordpress.com/2010/04/16/photosynth­to­allsynth/). Another blog 

post by Anahi Ayala details how the Chile Ushahidi instance received intentionally misleading information and 

how that was discovered (http://crisismapper.wordpress.com/2010/06/28/ushahidi­chile­an­example­of­

crowd­sourcing­verification­of­information/) 

Assessing the accuracy and expiration of user­generated content has elsewhere been accomplished using two 

general approaches. The first uses a Wikipedia­type approach in which ‘editors’ are responsible for reviewing 

all incoming information. This approach has been adopted for the geospatial world by Open Street Map 

(OSM), which uses a wiki­style approach where users can modify any map element in the database. The wiki 

tracks all the revisions and an editor can revert to a previous version if an edit is wrong (Answer 1.3 in 

http://wiki.openstreetmap.org/wiki/FAQ). In this case, it does not matter if the error is for malicious or 

unintentional reasons. By tracking the number of inputs, edits, and revisions, users with a quality record 

bubble to the surface. For the UDOP, the question of who should be the editors is a tricky issue, specifically as 

it relates to possible military oversight and trust issues from both military and non­military users, with editors 

representing heterogeneous user groups. 

The second approach would track the reliability of a user through some form of online reputation system, 

similar to systems employed by Amazon.com or Ebay.com. In this case the collective users of UDOP would be 

responsible for providing feedback on the quality of data a user provides. In this way quality data (and the 

submitting user) would be ranked higher than lower quality data (and users). This method relies on a human 

evaluation and ranking of the information. It may also be possible to adopt some automated methods for 

evaluating data quality. The Ushahidi project has released an alpha version of software called ‘SwiftRiver’ 

(http://swift.ushahidi.com/) that uses algorithms and statistical verification of crowdsourced data. While 

SwiftRiver is focused on text, it may be possible to adapt this type of approach for spatial data.  

While either of the above methods could track the reliability of a user and contributed data, the use of 

network links creates an additional issue: data continuity. In a network link, the UDOP would simply store the 

URL of a data resource that another user was publishing. The UDOP could import that link and display the data 

in the network link. However, the UDOP would not store the data in its native form, nor have a mechanism to 

control the data that gets displayed, or more importantly, control the update cycle of the data. The fear here 

is that a UDOP user would rely on a dataset that could change significantly or be removed with no warning or 

recourse. This downside stems for the same factor that provides the benefit of using network links. From the 

positive perspective, the military gains access to datasets that it does not have to maintain and because the 

network link is a type of web service, the data can update on the backend and reflect that change immediately 

without the user having to worry about downloading the latest copy of the data or multiple users having 

different copies of the data. This is the double­edged sword: how does the military open its platform to 

outside users and also be able to rely on contributed information it does not control? 

 

6 Process Issues

One of the problems recognized by the team early on was the need for process associates with data input and 

access.   Read and write permissions need to be set for each user profile.  Those profiles reference types of 

33

data layers that are accessible or writeable by the users that are included in that profile as well as the

individual data layers themselves. These constraints can all be modeled by the ontology.

Through our interviews of SouthCom users, we identified two main ways the UDOP is used, specifically, as a

geospatial input and viewing tool, and as a tool for generating briefing documents. Recognizing these different

uses has implications for the way user profiles are constructed and how data layers are structured within the

UDOP. The ontology and system architecture components of this report deal directly with these topics,

however, issues associated with the current configuration of the system should be highlighted.

Because the UDOP currently uses the file­based architecture for data storage (as opposed to an entity­based

approach), there is a significant degree of data duplication. In a briefing document, the user may only be

interested in a few entities within several different files. Producing a graphical view of the data means the user

has to duplicate the entities of interest and produce a new kml file to contain them. Besides the extra effort

involved in duplicating existing entities, these ‘one­off’ kml files begin to accumulate on the system backend

and tend to have a rapid expiration date. The short relevance duration of these duplicated kml files bring the

issue of temporal expiration and data overload to the fore.

Fully implementing the ontology and system architecture changes recommended herein will ameliorate some

of the duplication issues, but it is also important to recommend that files created for the purpose of briefing

documents be stored separately from ‘core’ datasets, and that some notion of the temporal duration or

update frequency of a data entity be recorded when loaded into the system. Recording an expiration date for

a dataset would inform a user that the information may be out of date, and help data administrators

understand when a dataset should be removed from the system.

6.1 Types of data and users

To address these issues the ontology dictated three types of system data: core/event data; user data and

ephemeral data. Processes managing the core/event data would be the strictest requiring administrative

approval and input by a “super user”, which have the highest level of accuracy and management approval;

user data which would have an intermediate level of management and ephemeral data which may have the

lowest level management oversight and would generally be used for briefings and have a short lifespan (figure

17).

6.2 Work flow of input process

If we simplify the user types to include regular users, super users and administrators a workflow for each of

the different data types can be defined. For “core/event data”, only a super user could populate the data base

with required administrative approval (Figure 17a). This could also be the case for “linked data” from external

URLs. For “user data” super users could create layers without administrative approval but with possible

administrative review (17b). For “ephemeral data” an any user could create the data which would be viewed

34

solely by them or another user of their choice (17c). Permanency of the data would be assured by long­term

archival of core/event data (17a), optional archival of user data (17b), and time limited persistence of the

ephemeral data. Both the data types and user roles can be modeled by the ontology.

Figure 17. Workflow for users given data layer types.

35

7 UDOP Architecture

7.1 Architecture

As discussed in Section 2.2 UDOP Overview, the current UDOP software architecture has significant limitations

and cannot support the sophisticated ontology­based data management scheme, or the spatial/temporal

analysis and modeling capabilities we recommend. In order to create the software environment capable of

achieving the UDOP vision of a system “that filters and synthesizes a myriad of spatial/temporal data points

from a wider variety of sources and modalities into a coherent understanding of the user’s area of operation”

and can handle complex spatial analysis, we believe that UDOP needs to evolve to a multi­tiered service­

oriented architecture. This evolution would enable our recommendations and increase the interoperability of

the UDOP to interface with a range of other systems. The recommend architecture is composed of three

layers: the data tier, the web services tier and the client tier (Figure 18). Communication between layers in the

stack is based on open standards and protocols.

The data tier is composed of a spatially­enabled relational database, specifically the combination of a

PostgreSQL database and the spatial extension PostGIS. This combination offers the most mature open source

object/relational solution available for DBMS and that supports the OGC Simple Features Interface Standard

(SFS), the industry standard for representing spatial data types. The GiST indices within PostGIS provide for

high­performance spatial indexing and have been tested for performance on large geospatial data sets.

PostGIS is also built with the GEOS (Geographic Engine – Open Source) library which provides the full suite of

spatial predicate functions and spatial operators found in SFS. The end result of this combination of

technologies is an enterprise­level spatial database capable of supporting large numbers of simultaneous

users, transactional edits, and conducting standard vector spatial operations in the database using SQL

commands.

The web service tier is based on a series of OGC Web Services that support the range of spatial data formats.

The goal of the web services tier is to act as an intermediary between client applications that want access to

the data and the data itself. Supporting the range of OGC Web Services (web mapping service, web feature

service, web feature service­transactional, web coverage service, and web processing service) is all about

interoperability and providing access to the greatest range of client applications possible. The recent

announcement by ESRI that it will openly publish its heretofore proprietary REST interface means the web

services tier could also directly support ESRI applications.

In the current UDOP, when a user requests a file it is downloaded in its entirety from the server and rendered

on the client side. This can result in significant lag time on the network and can require the rendering of a

large amount of vector objects, occasionally overloading the Google Earth plug­in. Using a web service, the

client application would make a structured request to UDOP for a specific configuration of view extent and

data layers. The web service tier would interpret that request, make the corresponding SQL call to the PostGIS

database, and return the data in the format requested by the client. The range of formats includes map tiles,

raster values, or actual vector features; the range of outputs is extensible, meaning new output schema can be

written in as needed. It is also important to note that KML is also an accepted OGC standard, and while it is

typically used at the client tier, it is possible to setup web services that render data stored in a PostGIS

36

database into KML. Therefore, these changes do not mean that the Google Earth plug­in component of the

UDOP has to change. To the contrary, performance would like increase as the rendering component is off­

loaded from the UDOP client.

The client tier is shown here with a UDOP client and both thick and thin clients as well as mobile apps. The

OGC protocols are used to communicate between the web services tier and the client tiers. Using OGC

services means the UDOP is open to any client that supports OGC services. The advantage of this architecture

is it places all of the development efforts in the data and web services tiers and gives flexibility in which client

is useful for a particular set of functionality. For instance, it may make sense to use uDig or ArcMap for data

entry into the UDOP Stack rather than create a new data entry tool from scratch. This will be true with many

other functions and the ability to support a range of clients will give maximum flexibility and functionality to

the UDOP stack. The web service tier would also open the possibility of advanced geoprocessing operations in

thin clients and the UDOP itself. Using the web processing standard, thin clients can provide the requisite

inputs for geoprocessing operations carried out in the spatial database, and visualize the output.

Figure 18. Proposed UDOP 3­tiered architecture.

Separating the processing of the UDOP into multiple tiers makes the system modular, scalable and extensible.

Each of these aspects is important for laying the foundation for the UDOP to grow as a platform. In figure 18,

the assumption is for a single deployment or a single security classification of the database. By modularizing

the stack, the UDOP platform could grow to include multiple separate instances and/or include multiple

37

database with different security requirements. Figure 19 demonstrates how a second, secured PostGIS

database could be integrated into the stack. Securing the second database behind authentication modules

between the client and web services tier (or web services and data tier) would allow certain users access to

classified materials in the same UDOP session with other non­classified data.

Figure 19: Proposed UDOP 3­tiered architecture using multiple PostGIS database.

This modular architecture would also allow the replication of the UDOP system into self­contained, offline

systems. The software stack could be installed on a single system that is field deployed with limited or no

internet connectivity. Although the system would be disconnected from the central UDOP servers, it could still

function as a stand­alone unit that could be synchronized later. Figure 20 shows a generalized schematic of

several disconnected, field­deployed UDOP systems and the mechanisms by which they could synchronize

data. A critical component for low or no bandwidth synchronization is software developed by InSTEDD called

Mesh4X (http://instedd.org/mesh4x). It is open­source software and can be freely used. Harnessing the UDOP

potential in offline situations could be a tremendous boost to both HA/DR and development operations

carried out by a range of organizations. However, the architecture is the key; modular software components

held together by open standards are the requisite pieces to enable open communication amongst platforms

and transforming the UDOP into a viable platform for data sharing.

  38 

 

Figure 20: UDOP replication and synchronization.

 

 

8 Conclusion

This report has given an overview of the current issues associate with the 3D UDOP environment and posited a 

number of possible solutions for making it reach its potential. Primary among our recommendations are to use 

the ontology developed by the team to structure the content access and organization of UDOP. The other 

major recommendation was to have UDOP evolve into a three­tiered stack composed of: a data tier, a web

services tier and a client tier. We believe this architecture will support better data management, system 

integration and much more powerful analytics.  Finally, we discuss data issues, processes and symbology in 

the context of improving UDOP’s reliability, integrity and interpretability.  Infused throughout our discussion is 

the importance of interoperability at the system level, syntactic level and semantic level.  We believe that the 

solutions and recommendations described herein provide a path to achieving the promise of the UDOP to 

create a unique and powerful user­centered environment for situation awareness, sense­making and complex 

modeling.  

  39 

 

 

9 References

PIROLLI, P., AND CARD, S. Sensemaking Processes of Intelligence Analysts and Possible Leverage Points as 

Identified Through Cognitive Task Analysis. In Proceedings of 1st International Conference on Intelligence

Analysis (2005). 

 Hossein Mohammadi, Abbas Rajabifard* and Ian P. Williamson, Development of an interoperable tool to 

facilitate spatial data integration in the context of SDI2010 International Journal of Geographical Information 

Science Vol. 24, No. 4, April 2010, 487–505 

Sen, S., 2005. Semantic interoperability of geographic information. GIS Development, 9, 18–21.Sheth, 1999; 

Xu, W and Sisi Zlatanova, Modeling emergency response processes: Carative study on OWL and UML, 

Proceedings of the joint ISCRAM­CHINA and GI$DM Conference Harbin, China, 2008 

Yang C. , Robert Raskin, Michael Goodchild, and  Mark Gahegan. 2010.  “Geospatial Cyberinfrastructure: Past, 

present and future”, Computers, Environment and Urban Systems 34 (2010) 264–277 

 

10 Appendix A: Ontology Tutorial (attached)

11 Appendix B: Key data sets for military and HA/DR applications

The increasing value of geospatial data in HA/DR events has been demonstrated repeatedly throughout the 

last ten years (9/11, Katrina, Indian Ocean Tsunami, Haiti, etc...). As identified in the literature, and built into 

our ontology, critical datasets are divided into several categories. While conceptually similar, the various 

classification schemes contain slightly different ways of parsing the HA/DR knowledge domain into groups. In 

this section, we will review specific datasets that apply to HA/DR events, discuss the relative importance of 

each given the changing disaster cycle, and list where to acquire them. 

 

The disaster cycle is a conceptual model for describing the phases of response after a disaster occurs (Figure 

7). The cycle analogy provides a mechanism for linking together disaster response with the longer­term 

activities of development. Each of the phases of the cycle (Response, Recovery, Mitigation/Prevention, and 

Preparedness) can overlap in time and space, and often have different data needs. The role of individual 

datasets, and their value, is often dependent upon the current phase of the disaster cycle . 

 

In the initial response phase, understanding the situation and quickly accessing baseline information is critical. 

Information needs in this phase are based on speed and temporal currency; situations change quickly, so a 

rapid update cycle is needed. In the transition to the recovery phase the focus changes to logistics and 

managing the situation. Temporal frequency of updates begins to slow, but is still a priority. The mitigation 

phase is the beginning of a systemic shift to deeper processes, those associated with spatial modeling and 

  40 

infrastructure projects. Finally, the preparedness phase is more closely associated with development goals, 

the temporal frequency of updates slows and the focus is on longer­term projects. Preparedness also involves 

an early­warning and detection component, meaning that observation systems can be deployed to give a 

greater lead to time for future disasters. The variation in these phases means the importance of a dataset may 

fluctuate throughout the cycle or could be high throughout.  

 

 Figure 14: The Disaster Cycle

The Haiti Earthquake disaster demonstrated the growing power of imagery and a new mechanism for 

acquiring data. ‘Crowdsourcing’ of data came of age in the Haiti Earthquake, as evidenced by the development 

of the Open Street Map (OSM) database and the use of the Ushahidi platform for aggregating SMS / text 

messages on a map display. Ushahidi is credited with saving many lives and provided the type of high­

frequency update information needed in the response phase. The success of the OSM database is just as 

significant, and by most accounts, is the de facto basemap for the country. Volunteers from throughout the 

world worked to build the Haiti OSM basemap from nearly nothing before the earthquake to a high­quality, 

incredibly detailed basemap that will likely become the operational basis for the next Haitian government. 

OSM is more than a road map, almost any entity can be mapped in the database, so it also contains structures, 

IDP camps, facilities, and walking trails to name a few. While the volunteer efforts of both these projects 

should be applauded, what often gets left out of the story is the large­scale infrastructure required to make 

them happen. In the case of Ushahidi it is the cellular network and for OSM it was the release of publicly 

available high spatial resolution satellite imagery. 

 

The value of imagery in disasters has grown alongside other geospatial data, and is perhaps more important 

because it can be used to generate many derivative data products. With the Haiti example, it is clear that the 

release of imagery can mobilize a global volunteer force capable of producing high­quality geospatial datasets. 

The question for the 3D UDOP (in Haiti and going forward) is what imagery to use, how to handle the 

collection and dissemination of imagery, and how to participate in the communities using imagery to produce 

  41 

derivative products. Answering these questions requires a bit of background on the nature of remotely sensed 

image data and a review of some lessons learned from previous disasters. 

 

Remotely­sensed imagery is collected by a range of different sensors that each have a unique set of 

capabilities. Potential variations include whether it is an ‘active’ or ‘passive’ sensor, meaning does it measure 

reflected sunlight (most sensors) or provide its own energy source (radar or microwave), is it airborne or 

satellite, and the various resolutions intrinsic to the senor. These resolutions are critical to determining the 

utility of a given sensor and are described in four ways: 

  Spatial: what is the pixel size 

  Spectral: what wavelengths are being collected 

  Temporal: how often does the sensor pass overhead 

  Radiometric: how finely does it measure the intensity of the incoming signal 

 

There are often trade­offs inherent to these various resolutions, meaning if you want a sensor with a high 

spatial resolution, it likely has a lower temporal resolution (or takes more time to pass overhead again). 

Determining the appropriate mix of capabilities is dependent upon the needs of the user, which is dictated by 

the disaster cycle. The immediate needs of the response and recovery phases are best met with high spatial 

resolution (0.5 meter) color imagery. Contrast this with the development­type needs of the preparedness 

phase; for example, if a given crisis is caused by a drought or deforestation, then you need a significantly 

different sensor to monitor these situations. Often this sensor would have a higher temporal frequency (daily 

or with weekly composites), a lower spatial resolution (250­1,000 meters), and record spectral wavelengths 

outside the visible spectrum (near and middle infrared). The mitigation phase could fall somewhere in 

between the two and require some high resolution imagery as well as some with a moderate spatial resolution 

(30 meters) with a two week temporal frequency and infrared spectrum.  

 

This variation in needs and capabilities means that the ‘best’ imagery is depends on the situation. However, it 

is clear that many different types of imagery are valuable and need to be available throughout the disaster 

cycle. Much of the coarse spatial resolution imagery if freely available from NASA and other space agencies, 

however, the value of that data is the analytical products derived from it. This requires professional expertise 

typically found in universities with established research agendas in specific topics (agricultural modeling, 

drought modeling, deforestation, ...). Encouraging and/or financing academic research groups would be the 

best mechanism for producing the types of imagery­derived analytical products that would either function in 

the early warning and detection phase of a disaster 

 

If the 3D UDOP is to be adopted as a standard for NGOs, then there needs to be an explicit benefit to using it 

over comparable open­source projects. This benefit comes from information sharing. The military benefit will 

be increased access to NGO data, but the military must give something back. The most valuable thing would 

be imagery, and high spatial resolution imagery at that. By working with NGA and DoS, the 3D UDOP could be 

the delivery platform for the most valuable (most expensive) datasets, and empower the volunteer movement 

to generate much needed derivative products (i.e., OSM) from that imagery.  

 

  42 

One lesson learned from the use of geospatial data in disaster response is the need to pre­position data 

assets. Meaning that data needs to be collected, processed and packaged prior to the disaster. In this way 

when a disaster strikes the response community can focus efforts on responding, rather than compiling data. 

This has implications for several other types of spatial data, besides imagery 

 

Assessing the damage caused by a disaster requires imagery collected before the event, therefore it is 

important to have a standing body of high resolution imagery available. In areas where understanding 

structural damage is critical, LiDAR (Light Detection and Ranging) data is a key dataset. Modeling landslide risk 

from a hurricane requires digital elevation models, soils and geological data. Knowing how many supplies to 

ship to a given location requires a population dataset combined with a damage assessment, and then 

intersected against a transportation dataset 

 

The pre­packaging of data is an activity that requires a fair amount of expertise. It’s utility would be quickly 

recognized in both the response phase when time is critical, and in the subsequent phases when having data 

for geographic modeling becomes more important. With the idea of adding in more data to the 3D UDOP, the 

list below contains links to several different types of data resources. 

 

Data Catalogs: 

� GeoCommons Finder! (http://finder.geocommons.com/) 

� GeoNetwork metadata catalogs (many different URLs, used by most UN agencies) 

� World Bank (http://data.worldbank.org/) 

 

Imagery: 

� Commercial Sources (Digital Globe, GeoEye, RapidEye) 

� International Charter Space and Major Disasters 

� National Geospatial­Intelligence Agency  

 

Population:  

� LandScan 30 arc second resolution (http://www.ornl.gov/sci/landscan/index.html) 

� Populations at Risk, Demobase, US Census, 100 meter resolution (https://www.geoint­

online.net/community/haitiearthquake/default.aspx) 

 

Transportation:  

� Open Street Map (OSM) (http://www.openstreetmap.org/) 

� UN Spatial Data Infrastructure for Transportation (UNSDI­T) 

o (http://www.logcluster.org/tools/mapcentre/unsdi/unsdi­t­v2.0) 

� Commercial Providers (NavTeq and TeleAtlas) 

 

Infrastructure:  

� Open Street Map (OSM) (http://www.openstreetmap.org/) 

43

Human Health:

� Sahana ­ missing people registry and medical facilities (http://haiti.sahanafoundation.org/prod/)

� Ushahidi ­ sms based reporting of events (http://haiti.ushahidi.com/)

Physical Environment

� Geology: OneGeology (http://www.onegeology.org/)

� Soils: Global Soils Map (http://www.globalsoilmap.net/)

Elevation

� SRTM 90 meter global (http://srtm.csi.cgiar.org/)

� ASTER GDEM 30 meter global (http://www.gdem.aster.ersdac.or.jp/)

Hydrology

� Atlas of the Biosphere, Univ. of Wisconsin (http://www.sage.wisc.edu/atlas/maps.php)

Land Cover

� USGS Landcover Institute: Landcover data page (http://landcover.usgs.gov/landcoverdata.php)

� 2004/2005 Global Land Cover data from European Space Agency (http://ionia1.esrin.esa.int/)

Geographic Names:

� GeoNames (http://www.geonames.org/)

National Boundaries:

� U.S.­sanctioned world boundaries maintained by the Office of the Geographer and Global Issues, US

Department of State (high­resolution boundaries)

� ESRI boundary data (~1:2,000,000)

Cadastre: locally derived

Weather: Radar, Satellite, Forecasts

Economic Development

� World Bank (http://data.worldbank.org/)

Map Resources:

• Joint Operations Graphic topographic maps (1:250k)

� Defense Mapping Agency topographic maps

� Perry­Castenada Map Library, University of Texas (http://www.lib.utexas.edu/maps/)

� ReliefWeb (http://www.reliefweb.int)

Table 3: List of Data Sources and Links