Recommendation for Inclusion of Geospatial Types in NIEM by yaosaigeng

VIEWS: 19 PAGES: 25

									RECOMMENDATION FOR INCLUSION OF GEOSPATIAL
             TYPES IN NIEM
                              AND
HOMELAND SECURITY INFRASTRUCTURE PROTECTION INFORMATION EXCHANGE
                            PACKAGE



      DHS Geospatial Management Office
                      DRAFT VERSION 0.3
                        January 24, 2005
                                                    CONTENTS
1     EXECUTIVE SUMMARY ......................................................................................................... 4
2     INTRODUCTION ..................................................................................................................... 5
3     BACKGROUND ...................................................................................................................... 6
    3.1       GEOSPATIAL ENTERPRISE ARCHITECTURE .......................................................................... 7
    3.2       FGDC, OGC AND ISO TC/211 STANDARDS ....................................................................... 8
    3.3       OASIS, W3C, AND OTHER STANDARD-SETTING BODIES ................................................... 10
    3.4       GEOSPATIAL CORE TYPES AND RELATED STANDARDS ....................................................... 11
4     ANALYSIS OF NIEM............................................................................................................. 13
5     GEOSPATIAL CORE TYPES ............................................................................................... 15
    5.1       SIMPLE GEOGRAPHIC FEATURE ........................................................................................ 17
      5.1.1          Description ............................................................................................................. 17
      5.1.2          Use Case Vignettes ............................................................................................... 18
    5.2       LOCATION ........................................................................................................................ 18
      5.2.1          Description ............................................................................................................. 18
      5.2.2          Use Case Vignettes ............................................................................................... 18
    5.3       COVERAGE ...................................................................................................................... 19
      5.3.1          Description ............................................................................................................. 19
      5.3.2          Use Case Vignettes ............................................................................................... 19
    5.4       OBSERVATION ................................................................................................................. 19
      5.4.1          Description ............................................................................................................. 19
      5.4.2          Use Case Vignettes ............................................................................................... 20
    5.5       ROUTE ............................................................................................................................ 20
      5.5.1          Description ............................................................................................................. 20
      5.5.2          Use Case Vignettes ............................................................................................... 20
    5.6       MAP ................................................................................................................................ 21
      5.6.1          Description ............................................................................................................. 21
      5.6.2          Use Case Vignette ................................................................................................. 21
    5.7       MOBILE OBJECT............................................................................................................... 21
      5.7.1          Description ............................................................................................................. 21
      5.7.2          Use Case Vignettes ............................................................................................... 22
    5.8       ALERT ............................................................................................................................. 22
      5.8.1          Description ............................................................................................................. 22
      5.8.2          Use Case Vignettes ............................................................................................... 22
    5.9       STRUCTURE..................................................................................................................... 23

Recommendation for Inclusion of Geospatial Types in NIEM                                                                                           2
Version 0.2                                                                                                               January 11, 2005
      5.9.1         Description ............................................................................................................. 23
      5.9.2         Use Case Vignettes ............................................................................................... 23
6  HOMELAND SECURITY INFRASTRUCTURE PROTECTION INFORMATION EXCHANGE
PACKAGE (HSIP IEP) .................................................................................................................. 23
7     RECOMMENDATIONS ......................................................................................................... 24




Recommendation for Inclusion of Geospatial Types in NIEM                                                                                      3
Version 0.2                                                                                                          January 11, 2005
    1 Executive Summary

There is a growing awareness that the vast majority of data used in government business has a
geospatial component or can be related to a geographic location or feature on the earth‘s surface
(presently estimated at 80%). Concurrently, the number of geospatial data, geospatial
applications (desktop GIS, web-mapping, geocoding, etc), and geospatial users, and the amount
of accessible or requested geospatial information are increasing. It is reasonable to assume that
the demand for a robust capability for exchanging information with geospatial content through
NIEM already exists and that this demand will increase.
There are clear advantages in planning for the development for this capability in a coordinated
and comprehensive manner rather than in an ad-hoc fashion. For NIEM to be of eventual benefit
to the greatest number of potential users, it must be augmented with a set of well-formed,
standards-based, geospatial data exchange components that have been carefully designed by
the broadest possible user and developer community and interoperate with current and future
information systems. Moreover, designing and testing a rigorous capability for the exchange of
geographic information across the HLS community, prior to the release of NIEM 1.0, and before
the development of NIEM Tools 1.0, is preferred.
To ensure interoperability with existing and new geospatial service components of federal
enterprise systems, as well as commercial GIS software, adherence to standards is necessary.
Much time and effort have been devoted in developing both the blueprint for the federal
geospatial enterprise architecture (GEA), and the industry-led geospatial standards upon which it
is based, as presented in Section 3, Background. Based upon the business requirements of
homeland security, the DHS GEA defines seven geospatial core data types: Simple Geographic
Feature, Observation, Mobile Object, Location, Route, Coverage, and Structure. With the
addition of Map and Alert, nine distinct Geospatial Core Types are proposed to provide full
versatility for the development of geospatially-enabled Information Exchange Packages (IEP)
within NIEM.
The geospatial standards community has developed data content standards and encoding
schema for these core types through consensus-based processes that included experts from
industry, a broad spectrum of users, government, and academia. By leveraging these resources,
model diagrams and XML schemas using standards-based definitions are being built for each of
the Geospatial Core Types for use in the NIEM framework. The logic and methodology for
developing these schemas are presented in Section 4. Definitions and brief use cases (vignettes)
have been generated to provide examples of and demonstrate the need for these nine Geospatial
Core Types and presented in Section 5. To date, XML schema have been produced for the
following six of the nine Geospatial Core Types: Simple Geographic Feature, Observation,
Location, Route, Coverage, and Map. The Mobile Object type requires further review and
requirements elucidation before a type is developed (please see section 5.7 for more
information). An Alert type already exists in NIEM, no further work is envisioned at this time
(please see section 5.8 for more information). The Structures type has been identified as the
subject of a near-term requirements gathering process by the DHS GMO, therefore work on the
development of the type will begin in the months following this recommendation.
In order to support the exchange of infrastructure protection information, an XML schema for a
Homeland Security Infrastructure Protection IEP have been developed. This is described in
Section 6.
Recommendations for integrating the Geospatial Core Types into NIEM are outlined in Section 7.
These include: (i) add all nine types into one schema file, (ii) include under one new and distinct
target namespace, (iii) reference by a shared target namespace prefix, and (iv) employ as new
domain-specific IEPs are developed. Likewise, business cases may warrant retrofitting existing
IEPs with the new standards-based definitions for geospatial components.


Recommendation for Inclusion of Geospatial Types in NIEM                                         4
Version 0.2                                                                      January 11, 2005
    2 Introduction

The NIEM is being developed in response to a requirement for a cross-domain information
sharing capability. This need is growing, concurrent with an increasing prevalence of data tied to
specific geographies. To successfully meet this need, NIEM must include a robust model for
sharing geospatial information.          The purpose of this document is to provide specific
recommendations regarding the incorporation of a set of new Geospatial Core Types into NIEM
which, if followed, would facilitate its successful implementation and rapid adoption by maximizing
its utility and benefits to existing and potential users with geospatial information exchange
requirements.

This document first briefly reviews the mission, activities, and body of specifications of the
geospatial standards community, as they relate to the federal government and NIEM. In
particular, the relevant base of geospatial data models and schema developed by the geospatial
industry standards community is presented. Second, the NIEM is analyzed for gaps in geospatial
information exchange capabilities as demonstrated through a comparison of industry-based
models and schemas that currently exist vs. those that are necessary to meet fundamental needs
in the EP&R, Law Enforcement, and Intel communities. Third, the following set of Geospatial
Core Types is proposed as the initial ―building blocks‖ for geographic information exchange,
which are derived from standards-based geospatial data models and schema: (Simple
Geographic) Feature, Location, Coverage, Observation, Route, Map, Mobile Object, Alert,
and Structure. These types were derived from analysis of HLS business requirements for
geographic information exchange. These business requirements are defined via abbreviated ―use
case vignettes‖, which are derived from analysis of the business activities defined in the HLS
Enterprise Architecture. Fourth, a Homeland Security Infrastructure Protection Information
Exchange Package (HSIP IEP) will be defined for use in pilot testing the use of the Geospatial
                                                                                       1
Core Types in NIEM v0.3. XML schemas are defined for each type, and for the HSIP IEP .

In sum, this document:

       leverages the work already done in the geospatial standards community through
        consensus-based processes, which take into account the requirements of a large number
        and wide variety of user communities, and more importantly, leverages the countless
        efforts of industry to incorporate these standards in their development efforts, thus greatly
        facilitating market uptake of these proposed new NIEM Geospatial Core Types;

       proposes the inclusion of a suite of Geospatial Core Types and related schemas that are
        available to the NIEM user community for developing new IEPs, and possibly for
        retrofitting existing IEPs for harmonization with existing industry standards as benefits to
        existing NIEM users are recognized;

       provides concrete examples of the business requirements (via use case vignettes) for
        information exchanges that require these Geospatial Core Types; and

       lays the groundwork for pilot testing of the Geospatial Core Types and related schemas
        for a vital federal business requirement.


1
  As of Version 0.3 of this report, six of nine of the Geographic Core Type schemas and a schema for
seventy-two HSIP feature types have been completed.


Recommendation for Inclusion of Geospatial Types in NIEM                                           5
Version 0.2                                                                       January 11, 2005
      3 Background

Standards organizations and consortia, including ISO/TC211, the Open Geospatial Consortium
(OGC), the U.S. Federal Geographic Data Committee (FGDC), the Urban and Regional
Information Systems Association (URISA), the Organization for the Advancement of Structured
Information Systems (OASIS), the Open Mobile Alliance (OMA), and the Emergency
Interoperability Consortium (EIC), have invested years, and in some cases more than a decade of
effort in developing consensus standards for geospatial information and technology, and
promoting the commercial adoption of those standards. Moreover, many of these organizations
have been pushing the cutting edge in using XML and other web technologies to develop
superior, well-defined geospatial capabilities. (For example, OGC, with an international
membership of 290+ organizations, has been working with XML technology for 6+ years, and
thus has very well-developed and proven geospatial models and schema.) It is our intent to fully
leverage this legacy in benefit to NIEM.
These standards and commercial implementations provide pedigreed information infrastructure
assets that can be leveraged for use in NIEM. They apply to data in NIEM IEP (Information
Exchange Packages), and to a variety of distributed, standards-based geospatial resources (i.e.,
databases, Web services, and live data feeds). Commercial off-the-shelf (COTS) software is
available that conforms to many of these standards. Its selection for NIEM processing will
facilitate interoperability with such standards-based geospatial resources, and speed the
deployment of geospatially enabled NIEM conformant applications. However, several issues
must be addressed to successfully integrate standard geospatial schemata with NIEM (see
Section 4, Methodology, below).
The advantages of adopting geospatial information and communication standards stem from the
resulting transactional level of interoperability. This capability allows interaction with remote web
services, enables bi-directional sharing of information between systems, and facilitates discovery
of and access to a wealth of data sources. Compliance with standards and/or using standards-
based products allows organizations to maximize the value of past and future investments in
                                       2
geoprocessing systems and data by :
          Developing architectures and procurement plans for systems that enable them to share
           and reuse data, thus decreasing costs (avoiding redundant data collection), getting more
           or better information, and increasing the value of data holdings. Vastly improved inter-
           organizational data sharing is a key benefit.
          Positioning their organizations to: choose the best tool for the job, optimize work flows,
           and reduce technology and procurement risk (i.e., avoid being locked in to one vendor or
           an unsatisfactory solution).
          Enabling more of their people with less training to benefit from using geospatial data in
           more applications: That is, they leverage their investments in software and data.
Although NIEM‘s current mission is directed at information exchanges within the US, it is
important to consider international standards for at least three reasons:
      
                                                                          3
           to be consistent with federal policy (i.e., OMB Circular A-119 , Section 6.h),
          the software and consulting industry supporting the applications that generate the content
           for the exchange packages and/or make the exchanges have markets that are not limited



2
    Adapted from http://www.opengeospatial.org/about/?page=benefits, accessed 9 January 2006.
3
    http://www.whitehouse.gov/omb/circulars/a119/a119.html


Recommendation for Inclusion of Geospatial Types in NIEM                                               6
Version 0.2                                                                           January 11, 2005
           to US borders, and are thus more amenable to adopting more ubiquitous international
           standards.
          the possibility of NIEM evolving into a mechanism for international governmental
           informational exchanges, and the business/cost advantages to the US government if that
           occurs.


3.1       Geospatial Enterprise Architecture

The Department of Homeland Security (DHS) is establishing the Baseline (‗As-Is‘) and Target
(‗To-Be‘) Homeland Security (HLS) Enterprise Architecture (EA), the Transition Strategy for
migrating from Baseline to Target EA, and the Governance Strategy for incremental
implementation of the Target HLS EA. The Target HLS EA is conceptual in nature and was
developed following a ―top-down, business-driven‖ process, thereby making it fully supportive of
the mission and business objectives of the Department, and the broader HLS community.
To carry out its mission and meet strategic objectives, DHS and the broader HLS community
must operate in a fully ‗location-enabled‘ environment. Therefore, it is crucial for the geospatial
context of the HLS enterprise to be fully represented and integrated within the HLS EA. As an
extension of the Target EA, the Geospatial Enterprise Architecture (GEA) adds a dimension of
depth by elaborating on the role of geospatial data and technology in HLS. The GEA provides
further detail on the nature of HLS business, data, applications and technology, and the context
for how geospatial capabilities permeate the Target HLS EA:
      • Provides an integrated view of the geospatial context across all facets of the HLS EA;
      • Presents recommendations for extending the HLS EA to address the role of geospatial data
          and technology;
      • Stands alone as a model for integrating geospatial technology across DHS and the broader
          HLS Community
      • Provides a baseline for governing geospatial technology insertions.
The GEA was designed as a blueprint to ensure geospatial interoperability and component
technology compatibility across the HLS community. Given that the implementation of a
standards-based EA will move forward in DHS, and for other department and communities in a
similar manner, it is in our best interest to develop the NIEM in parallel. In doing so, the NIEM will
support and be supported by government enterprise systems that leverage the suite of open,
consensus-based geospatial standards that provide the interoperability required to reap the
benefits described above.
One important body of work that was performed in developing the GEA (version 0.6.1) was the
identification and documentation of seven foundational ―Geospatial Entities‖: Location Object,
Feature (and Feature Collection), Coverage, Mobile Object, Observation, Route, and
Structure, which serve as the starting point for the Geospatial Core Types defined herein
(Section 5). These entities were identified in the GEA as the ―building blocks‖ for geospatial
content that would be shared amongst HLS users. Although not specifically identified as
Geospatial Entities in the GEA (version 0.6.1), subsequent analysis of HLS business activities
has revealed two additional types: Alert and Map, which are also defined in Section 5.




Recommendation for Inclusion of Geospatial Types in NIEM                                              7
Version 0.2                                                                        January 11, 2005
3.2   FGDC, OGC and ISO TC/211 Standards

Standards that specify encoding schemes for data with a geographic component are developed
by both federal agencies and non-governmental organizations. A simplified view of the
                                                               4
geospatial standards community, from a U.S. federal perspective , is presented in Figure 1.


       Figure 1: The geospatial standards community, from a US federal perspective.

                                              is U.S. member body of             ISO
                                                                                       is Technical Committee of
                                                                           ISO Technical                           is liason with
                                                                             Committee
                                                                              (TC) 211
                                                                                     Accredits U.S. TAG to
                                                     MOU                 American National
                                   NIST
                                                                      Standards Institute (ANSI)

                                       reports to                                      is accredited by


                                                                      International Committee
                                   OMB
                                                                           on Information
                                                                       Technology Standards
                                       sets policy for
                                                                              (INCITS)
                                                                                                                                              Consortia and
                Participates in                                                        is a Subcommittee of
                 standards
                                                                                                                                               Academia
                development                   is a voting member of                                   is an advisory member of Open Geospatial
      States                       FGDC                                  INCITS Technical
                                                                           Committee L1                                       Consortium (OGC)

      Municipalities                                                                                                                              W3C
                                                                                                                                                 OASIS
                                                                          is strategic member of                                                  etc.

       State/Local                 Federal                              Accredited Standards                                        Other Standards
        Standards                 Standards                           Development Organization                                       Development
                                                                                                                                     Organizations




ISO
ISO (International Organization for Standardization, www.iso.org) is a global network that
identifies what International Standards are required by business, government and society,
develops them in partnership with the sectors that will put them to use, adopts them by
transparent procedures based on national input and delivers them to be implemented worldwide.
ISO standards distil an international consensus from the broadest possible base of stakeholder
groups. ISO – a non-governmental organization – is a federation of the national standards bodies
of 149 countries, one per country, from all regions of the world, including developed, developing
and transitional economies.
Each ISO member is the principal standards organization in its country. The members propose
the new standards, participate in their development and provide support in collaboration with ISO
Central Secretariat for the 3000 technical groups that actually develop the standards. ISO
members appoint national delegations to standards committees. In all, there are some 50,000
experts contributing annually to the work of the Organization. When their work is published as an
ISO International Standard, it may be adopted as a national standard by the ISO members and




4
 Adapted from FGDC diagram found at http://www.fgdc.gov/standards/stds_orgs.jpg, accessed 5 January
2006.


Recommendation for Inclusion of Geospatial Types in NIEM                                                                                                      8
Version 0.2                                                                                                                           January 11, 2005
translated. ISO has a current portfolio of 15,036 standards that provide practical solutions and
                                                                                5
achieve benefits for almost every sector of business, industry and technology.
In 1994 the International Standards Organisation created technical committee 211 (ISO/TC 211)
with responsibility for Geoinformation/Geomatics. They are finalizing a family of standards; this
process involves a working group, the development of one or more committee drafts, a draft
international standard, and finally the international standard. Many common work items now exist
between the Open Geospatial Consortium (OGC) and ISO TC 211 that will result in OGC
specifications being balloted as International Standards or Technical Specifications.
ISO standards are voluntary, although some governments and agencies enforce their use for
specific areas. The European Union, for example, has mandated the use of ISO standards in all
application areas.
OGC
The Open Geospatial Consortium (OGC, www.opengeospatial.org) is a non-profit, international
consortium of more than 290 companies, government agencies, research organizations, and
universities participating in a consensus industry standards process to develop publicly available
                                                        ®
interface specifications. OGC specifications (OpenGIS ) support interoperable solutions that
"geo-enable" the Web, wireless and location-based services, and mainstream IT. The
specifications for open and extensible software application programming interfaces empower
technology developers to make complex spatial information and services accessible and useful
with all kinds of applications.
OGC has been working with ISO Technical Committee (TC) 211 on Geographic
Information/Geomatics for several years to insure the standard meets the needs of the
international community by addressing and reconciling different perspectives. Participants in the
process include governments, commercial companies, non-governmental organizations,
universities and research institutions, and the public.
To date, two OpenGIS Implementation Specifications have become ISO standards: Web Map
Service (2005) and Simple Features (2004); Web Feature Service, Filter Encoding (both in
progress), Web Coverage Service, and Catalog Service are expected to follow.
International organizations such as NATO already require adherence to OGC specifications in
their tenders; many other organizations are expected to follow suit.
FGDC
The Federal Geographic Data Committee (FGDC, www.fgdc.gov) is a 19 member interagency
committee composed of representatives from the Executive Office of the President, Cabinet-level
and independent agencies. The FGDC was organized in 1990 under OMB Circular A-16 which
promotes the coordinated use, sharing, and dissemination of geospatial data on a national basis.
The FGDC is developing the National Spatial Data Infrastructure (NSDI) in cooperation with
organizations from State, local and tribal governments, the academic community, and the private
sector. The NSDI encompasses policies, standards, and procedures for organizations to
cooperatively produce and share geographic data.
The FGDC develops geospatial data standards for the NSDI only when there are no externally
developed standards appropriate for Federal use. The FGDC Standards Working Group
develops standards in consultation and cooperation with State, local, and tribal governments, the
private sector and academic community, and, to the extent feasible, the international community.
FGDC standards are intended to be national in scope and go beyond individual agencies and the
Federal government enterprise. Federal agencies are required to use FGDC standards. State
and local agencies are not required to use FGDC standards, but are encouraged to do so to


5
    Statistics as of March 2005; text from http://www.iso.org/iso/en/aboutiso/isoinbrief/isoinbrief.html.


Recommendation for Inclusion of Geospatial Types in NIEM                                                     9
Version 0.2                                                                                    January 11, 2005
promote data sharing between different levels of government. The relationship between the
FGDC, OGC, INCITS, ANSI, ISO, and other standards organizations, as depicted in Figure 1, is
described in detail at the FGDC Geospatial Standards, Article 1 webpage.
The FGDC‘s Homeland Security Working Group (HSWG) has produced a FOUO ―Guidelines for
Homeland Security Geospatial Data Content‖ document (at v1.1 on 2 Nov 2005).


3.3   OASIS, and other Standard-Setting Bodies

OASIS
The Organization for the Advancement of Structured Information Standards (OASIS, www.oasis-
open.org) is a not-for-profit, international consortium that drives the development, convergence,
and adoption of e-business standards. OASIS is distinguished by its transparent governance and
operating procedures. Members themselves set the OASIS technical agenda, using a
lightweight, open process expressly designed to promote industry consensus and unite disparate
efforts. The consortium produces more Web services standards than any other organization
along with standards for security, e-business, and standardization efforts in the public sector and
for application-specific markets. Founded in 1993, OASIS has more than 5,000 participants
representing over 600 organizations and individual members in 100 countries.

On 30 November 2005, OASIS members approved the Common Alerting Protocol (CAP) version
1.1 as an OASIS Standard, a status that signifies the highest level of ratification. Developed
through an open process by the OASIS Emergency Management Technical Committee, CAP
provides a simple, general-purpose format for exchanging all-hazard emergency alerts and public
warnings over any network. See http://www.oasis-open.org/news/oasis-news-05-11-30.php for
details.
IAI
The International Alliance for Interoperability (IAI, www.iai-na.org) is a global standards-setting
organization representing widely diverse constituencies—from architects and engineers, to
research scientists, to commercial building owners and contractors, to government officials and
academia, to facility managers, and to software companies and building product manufacturers.
Alliance members are committed to promoting effective means of exchanging information
among all software platforms and applications serving the Architecture, Engineering and
Construction (AEC) and Facilities Management (FM) community by adopting a single Building
Information Model (BIM).
This mission is accomplished by defining, promoting and publishing specifications for Industry
Foundation Classes (IFC) as BIM and as a basis for AEC project information sharing through
the project life cycle, globally, across disciplines and technical applications. IFC BIM are
published in the EXPRESS language for software development and in eXtensible Markup
Language (ifcXML) for eCommerce and Internet purposes. aecXML derived from the IFC BIM is
also promoted and developers are encouraged to extend the IFC BIM through collaboration
with IAI.
LandXML.org
Launched January 2000, LandXML.org is committed to providing a non-proprietary data standard
(LandXML), driven by an open industry consortium of private company, university and
government agency partners. LandXML is an industry-driven, open XML data exchange standard
addressing the needs of private and public sector Land Development and transportation
professionals, software/hardware producers, and service vendors. In late 1999, the first draft
LandXML schema was derived from working with the authors of the earlier ASCII based initiative
EAS-E (Engineering And Surveying - Exchange) data interchange standard. LandXML.org has


Recommendation for Inclusion of Geospatial Types in NIEM                                          10
Version 0.2                                                                        January 11, 2005
482 members representing 357 organizations from 30 different countries, with 47 software
                     6
components registered .
LandXML Version 1.0 was ratified as a Land Development and transportation industry standard
format and published on July 17, 2002 by LandXML.org. The primary charter or goal for
LandXML is to specify a design data structure to 1) exchange civil engineering design data and
survey measurement data, and to provide both 2) a data format suitable for long-term data
archival and 3) a standard format for official electronic design submission. Potential secondary
uses of LandXML data include providing: 4) accessible design data from remote/field devices, 5)
a data extraction and submittal format for GIS databases, and 6) engineering design data
transport layer for collaborative applications.
URISA
The Urban and Regional Information Systems Association (URISA, www.urisa.org) is a non-profit
association of professionals using Geographic Information Systems (GIS) and other information
technologies to solve challenges in state/provincial and local government agencies and
departments. Formed in 1963, URISA‘s mission is to facilitate the use and integration of spatial
information technology to improve the quality of life in our urban and regional environments.
URISA promotes the effective and ethical use of spatial information and information technologies
for the understanding and management of urban and regional systems.
During the past year URISA, with the support of the National Emergency Number Association
(NENA) and the U.S. Bureau of the Census, has worked on the Street Address Data Standard.
This standard provides in four separate parts, data content, classification, quality, and exchange
standards for street, landmark, and postal addresses. This standard builds on the United States
Postal Service (USPS) Publication 28, and on the Address Data Content Standard previously
proposed by the Federal Geographic Data Committee (FGDC) (Public Review Draft, April 17,
2003). The FGDC effort led URISA to propose the convening of a Street Address Standards
Working Group (SASWG) to include representatives from a range of interested federal, state,
regional, and local government agencies, the private-sector, and professional associations. The
proposal was accepted by the FGDC Standards Working Group on April 13, 2005. The SASWG
will be synthesizing comments from a second public review and submitting a revised draft to
FGDC for full public review in early 2006.


3.4      Geospatial Core Types and Related Standards

The Geospatial Core Types were derived from analysis of the business activities contained in the
HLS EA. Furthermore, each of the types has a robust standards pedigree, which is based on
several years of consensus-based standards development and field testing.
The Geospatial Core Types, described in Section 5, are based on NIEM v0.2 [1] and the
standards pedigree shown in Table 3-1.
                   Table 3-1 Standards Pedigree for Geospatial Core Types


Type                  Standards

Feature               ISO Geography Markup Language (GML) [2], and
                      OGC GML simple feature profile [3]




6
    As of 28 December 2005, as reported at www.LandXML.org.


Recommendation for Inclusion of Geospatial Types in NIEM                                        11
Version 0.2                                                                      January 11, 2005
Location                  ISO GML [2], Open Location Services (OpenLS®) [4], and
(Object)
                          FGDC Street Address Data Standard [5]

Coverage                  ISO GML [2]

Observation               ISO GML [2] and OGC Observations and Measurements [6]
            7
Route                     Open Location Services (OpenLS®) [4], and
                          ISO Location Based Services – Tracking and Navigation [7]
                          ISO Location Based Services – Multimodal routing and navigation [8]
       7
Map                       ISO Web Map Server interface [9]
                          Open Location Services (OpenLS®) [4]
                          OGC Web Map Context Documents [10]
                          OGC Styled Layer Descriptor [11]
                          OGC Filter Encoding [12]
                     7
Mobile Object             ISO GML [2], and ISO Schema for moving features [13]
        7
Alert                     OASIS Common Alert Protocol (CAP) [14], and ISO GML [2]
                7
Structure                 LandXML [15] and ifcXML [16]

HSIP                      FGDC HSIP Geospatial Data Content [17] and the types: Feature, Location,
                          and Address



      1. U.S. Department of Homeland Security (DHS) and U.S. Department of Justice (DOJ),
         ―National Information Exchange Model, version 0.2,‖ December, 2005.
         http://niem.gov/niem02.php
      2. International Standards Organization, "ISO 19136: Geographic information - Geography
         Markup Language (GML)," February, 2004. This document is equivalent to following
         document.
                    a. Open Geospatial Consortium, Inc., "OpenGIS® Geography Markup Language
                       (GML) Encoding Specification, version 3.1.1," OGC Document Number 03-105r1,
                       http://portal.opengeospatial.org/files/?artifact_id=4700
      3. Open Geospatial Consortium, Inc., "GML simple features profile, version 0.0.28," OGC
         Document Number 05-033r18, not yet publicly available.
      4. Open Geospatial Consortium, Inc., "OpenGIS® Location Service (OpenLS)
         Implementation Specification: Core Services, version 1.1," OGC Document Number 05-
         016, http://portal.opengeospatial.org/files/?artifact_id=8836




7
    Standards listed for these Types are being investigated. Final candidate Standards are TBD.


Recommendation for Inclusion of Geospatial Types in NIEM                                              12
Version 0.2                                                                              January 11, 2005
    5. Federal Geographic Data Committee, Address Standards Working Group, "Street
       Address Data Standard, Working Draft 2.0," November 2005,
       http://www.urisa.org/FGDC_addr_standard/05-11.2ndDraft.CompleteDoc.pdf
    6. Open Geospatial Consortium, Inc., "Observations and Measurements, version 0.9.2,‖
       OGC Document Number 03-022r3
    7. International Standards Organization, ISO 19133 Geographic information -- Location
       Based Services -- Tracking and navigation,‖ [Date? I just have DIS from Jan 04]
    8. International Standards Organization, "ISO 19134: Geographic information – Location
       Based Services – Multimodal routing and navigation,‖ April, 2004.
    9. International Standards Organization, "ISO 19128: Geographic information – Web Map
       Server interface,‖ November, 2005.
    10. Open Geospatial Consortium, Inc., ―Web Map Context Documents Implementation
        Specification, version 1.1.0‖, OGC Document Number 05-005, May 2005
    11. Open Geospatial Consortium, Inc., ―Styled Layer Descriptor Implementation
        Specification, version 1.0.0‖, OGC Document Number 02-070, September 2002
    12. Open Geospatial Consortium, Inc., ―Filter Encoding ImplementationSpecification, version
        1.1.0‖, OGC Document Number 04-095, May 2005
    13. International Standards Organization, "ISO 19141: Geographic information – Schema for
        moving features,‖ May, 2005.
    14. Organization for the Advancement of Structured Information Standards (OASIS), ―OASIS
        Standard CAP-V1.1,‖ October, 2005. http://www.oasis-
        open.org/committees/download.php/14759/emergency
    15. LandXML.org, ―LandXML-1.1 Schema,― December, 2005.
        http://www.landxml.org/schema/LandXML-1.1/LandXML-1.1.xsd
    16. International Alliance for Interoperability (IAI), ―Industry Foundation Classes (IFC)2x2,
        Addendum 1― July, 2004. http://www.iai-international.org/Model/IFC(ifcXML)Specs.html
    17. Federal Geographic Data Committee, Homeland Security Working Group, "Guidelines for
        Homeland Security Infrastructure Protection Geospatial Data Content, Version 1.0
        (FOUO)," December 2005. Contact gmo@dhs.gov to request access.



    4 Analysis of NIEM

Standards from different organizations, and even different standards from one organization, may
have duplicate, partially overlapping, and to some degree inconsistent definitions of and usage
contexts for the same geospatial concepts and objects, such as location. The most appropriate
definitions must be selected for NIEM, or mechanisms for selecting among alternative definitions
must be provided. Both approaches have been employed here.
Geospatial standard XML schemas provide definitions that are beyond the current NIEM
information scope, and use different identity and metadata constructs and referencing
mechanisms. Profiles of these schemas are employed here to include definitions within the
current NIEM information scope, and to exclude optional metadata elements and attributes that
do not conform to current NIEM practices.
Geospatial standards have been developed at different times, and evolve at different rates.
Some of them have long histories of partially incompatible versions. Standards frequently cite
and directly use definitions from specific versions of other standards, which have been

Recommendation for Inclusion of Geospatial Types in NIEM                                         13
Version 0.2                                                                     January 11, 2005
superceded by newer versions. Integrating a wide variety of geospatial standards into a
compatible set of geospatial schemas for NIEM requires resolution of such version conflicts, so
that definitions from multiple versions of the same standard may be used simultaneously.
There is an XML/Schema issue involved here in that successive versions of the same standard
specify the same target namespace. Although users of XML schema definitions may use any
namespace prefix to refer to the definitions, only the organization that issued the standard has the
authority to change the target namespace.
There is also an implementation issue involved here. Although a number of geospatial services
standards provide protocols for schema version negotiation between client and server, none of
them currently provide a mechanism for simultaneous use of multiple versions of the same
standard in the same data set.
The approach that has been employed here moves deprecated or superceded definitions of
components referenced from earlier versions of schemas into draft revisions of the referencing
schema, and uses only the latest version of definitions from any one standard. Fortunately, in
all cases where this was done, the content model of the data components involved did not
change across versions. Mediator software will have to transform data instances that validate
according to the draft revisions of the referencing schemas to validate according to the standard
versions of those schemas. And data instances that validate according to the standard versions
of those schemas, e.g., those from existing Web Services and live data feeds, will have to be
transformed to validate according to the draft revisions of the referencing schemas. But in both
cases this will only involve changing either the namespace prefix or name of an XML element or
attribute, a simple and fast transformation that is readily accomplished using XSLT.
NIEM is being developed as an enterprise data model for information exchange by gathering data
definitions from various application domains, writing XML schema definitions for them, removing
duplication of identical or similar definitions from different domains, moving bilaterally shared
definitions into a common schema, and moving widely shared definitions into a universal schema.
Using the resulting NIEM schemas with legacy applications where the data definitions have been
modified and moved to the NIEM common or universal schemas will require either that the legacy
applications are modified to use the NIEM definitions directly, or that mediation translation
software be developed and interposed between the legacy applications and NIEM information
exchange packages.
The geospatial-to-NIEM gap analysis spreadsheet could facilitate taking the same approach to
integrating the geospatial schemas provided herein with NIEM, whereby geospatial component
definitions are moved into the common and universal NIEM schemas. However, substitution of
NIEM definitions for the geospatial standards definitions will break interoperability with existing
standards-based geospatial COTS software, and impede the use of information from existing or
new distributed, standards-based geospatial resources.
Instead, the recommended approach is to add the standards-based definitions from the
geospatial4niem.xsd schema provided herein in one schema file, geospatial.xsd, under one
target namespace, http://niem.gov/niem/gs, referenced by a shared target namespace prefix,
―gs‖, to the set of shared NIEM definitions from the universal, common, appinfo, structures, and
XML schemas for use in all NIEM domain-specific IEPs. Profiles of geospatial standards
schemas used by the ―gs‖ definitions would also be added in separate documents under their
standard target namespaces. Existing NIEM processes can continue to use existing NIEM
definitions for geospatial components, such as location, but those definitions should be
deprecated. Future NIEM processes should be designed and constructed to use the standards-
based, industry-compatible schema described herein.




Recommendation for Inclusion of Geospatial Types in NIEM                                          14
Version 0.2                                                                        January 11, 2005
    5 Geospatial Core Types

A Geospatial Core Types define the representation of a large domain of geospatial data with a
wide range of uses. Geospatial Core Types define geospatial data objects in the form of XML
data documents and fragments thereof that are used to identify locations on the Earth, model
real-world phenomena, and contain location representations that support transformations
between reference systems. There are nine of these core types: Location, Feature, Coverage,
Mobile Object, Observation, Route, Structure, Map, and Alert.
A Location references a site or place via (point) geometry, a point or area feature, an address, or
a combination thereof, in a normalized structure suitable for data interchange. A Feature
describes real-world phenomena in a geospatial context. It may have an associated Location
Object to support transformation between the two representations for the same real-world entity.
Other classes also describe real-world phenomena, but the Feature is typically used for immobile
phenomena or those that are slow to move or change. A Structure describes a building or other
structure in an engineering context with references to its geospatial location. An Observation
associates an observed or measured value with the geospatial and temporal context of the
observation. A Mobile Object describes real-world phenomena similar to a Feature that changes
position or state relatively rapidly. A Coverage associates a set of discrete values with a
geospatial area. A Route describes a path between locations. A Map represents select
geospatial-temporal data, annotated and symbolized for an intended purpose. An Alert
communicates a message with geospatial and temporal context related to a threatening event.
The Geospatial Core Types are essential for communication between individuals and among
systems: they define the foundational building blocks of applications that involve exchanging and
utilizing geospatial information. These components will be used in three different ways. First, the
data will be used independently of other data, as an individual item such as a request or response
parameter in a web service. Second, these units of geospatial information will be used in
conjunction with associated non-spatial data, such as a related table. Third, objects defined by
the Geospatial Core Types will be used in a compound manner such as a collection of objects,
either as a homogeneous set of the same type of object, or a heterogeneous set of objects
belonging to more than one type. The objects, taking the form of XML document fragments,
describe sharable geographic information that can directly be used in local applications or web
services.
Schemas for Geospatial Core Types: Schema Package Attachment
An important product of the work completed during analysis is the derivation of schemas for the
core types, and for the use of those core types in HSIP IEPs. Table 5-1 summarizes the contents
of the schema package associated with this report. Each schema file listed in the table defines
components in one XML namespace. The first two are GML Application Schemas for NIEM. The
others are edited profiles of supporting standard geospatial schemas containing the latest version
of the standard geospatial type definitions used by the first two.




Recommendation for Inclusion of Geospatial Types in NIEM                                        15
Version 0.2                                                                      January 11, 2005
                  Table 5-1 Content Summary of Associated Schema Package


File                              Contents

hsip.xsd                          The schema for the HSIP IEP. This was drafted as a
                                  separate schema under the assumption that it is for the
                                  NIEM HSIP domain, not part of the NIEM core. If that
                                  assumption is incorrect, the definitions in this schema can
                                  be moved to geoSpatial4niem.xsd and edited to share the
                                  core NIEM geospatial target namespace and prefix.
                                  The schema of core geospatial types for NIEM, including
geoSpatial4niem.xsd
                                  Feature, Location, Coverage, and Observation types. It is a
                                  GML Application Schema that defines types following NIEM
                                  conventions for identity, associations, roles and metadata by
                                  extending XML types from geospatial standards.
                                  A profile of Open Geospatial Consortium Geography Markup
gml4niem.xsd
                                  Language (GML) version 3.1.1 schemas for NIEM version
                                  0.2. Deprecated GML3.1.1 types like gid are eliminated
                                  because they will not be included in the ISO TC/211 19136
                                  version of the GML standard.
                                  Includes support for Feature, Location, Coverage, and
                                  Observation types.

xls4niem.xsd                      A profile of Open Geospatial Consortium OpenLS schema
                                  for NIEM. Supports the Location and Route types

om4niem.xsd                       Support for Observation type.

StreetAddressDataStandard.xsd     The schema for the FGDC Address Data Content Standard,
                                  used by the Location type.


context4niem.xsd                  Adaptation of OGC Web Map Context schema, that imports
                                  version 1.0.20 definitions from the StyledLayerDescriptor
                                  schema instead of the version 1.0.0 ones used by the
                                  standard. Used by the Map type.

StyledLayerDescriptor4niem.xsd    Supporting SLD schema for Web Map Context. Used by the
                                  Map type.


filter4niem.xsd                   Supporting schema for SLD. Used by the Map type.



xlinks.xsd                        Supporting schema for Observations, Context, and SLD.



hsipSample.xml                    Sample instance document for HSIP IEP.




Recommendation for Inclusion of Geospatial Types in NIEM                                        16
Version 0.2                                                                    January 11, 2005
Table 5-2 lists the existing version 0.2 NIEM schemas that are referenced by the schemas in
Table 5-1.

                 Table 5-2 NIEM Schemas used by Associated Schema Package


File                                     Contents
universal.xsd                            NIEM universal core
structures.xsd                           ID, metadata, and linkMetadata attribute definitions
appinfo.xsd                              resource and referenceTarget element definitions
xsd.xsd                                  Proxy types that carry dictionary metadata and have XML
                                         data type simple contents.


Requirements for Geospatial Core Types: Stated in the form of Use Case Vignettes
A series of use case vignettes have been developed for each core type to illustrate how these
common types are used in the HLS mission. These use cases reflect HLS business
requirements, as defined in the HLS Enterprise Architecture. Each vignette is captured as
―statements‖ that identify and specify the role of the Geospatial Core Types in accomplishing
these HLS business activities. The statements have the following general form:
           Modifiers, Subject-Predicate-Object, Modifiers
where Subject is an actor (person or thing) involved in a task to accomplish an objective, as it
pertains to an HLS business activity; Predicate is an action (function) the actor performs; Object
is the object of the action, which may involve another actor or data; and Modifiers represent
necessary context, conditions and qualifications for proper execution and understanding of the
activity (e.g., using a particular application, supporting actors, timeframe, preprocessing
requirements, needs for other data, environmental and location constraints, quality
considerations, etc.). The following is an example of a use case vignette in this structured
statement form:
         In responding to a fire suppression incident (modifier 1), the Incident Commander (subject) requests
                                                                                  8
         (predicate) the location and status of apparatus held in reserve (object ), from command post
         (modifier 2), at key intervals (modifier 3), during incident response (modifier 4).
In the subsections that follow, definitions of the Geospatial Core Types, as found in the HLS
Geospatial Enterprise Architecture, will precede the use case statements.

5.1      Simple Geographic Feature

5.1.1      Description

Feature: An abstraction of a real world phenomenon. A geographic entity with a location relative
to the earth. Usually represented by vector data (points, lines and polygons) with geometry,
topology and descriptive properties (attributes).




8
    The object is a Mobile Object.


Recommendation for Inclusion of Geospatial Types in NIEM                                                  17
Version 0.2                                                                               January 11, 2005
5.1.2     Use Case Vignettes

      1) DHS IA threat analysts share threat area delineations (polygon) with State Fusion
         Center(s), or directly with State, local, or tribal (SLT) emergency operations centers
         (EOC).
      2) Informed of changing wind direction / seeing an approaching squall line while responding
         to CBRN release, an incident commander requests an updated plume (i.e., several
         concentric polygons) derived by running a Toxic Dispersion Model from FEMA analysts
         equipped with modeling software.
      3) Analysts examining consequences requests updated set of construction activities along
         evacuation routes (i.e., impacted road segments) from state DOT.
      4) USCG operations center provides updated navigation aids, obstructions and depth
         contours to patrol vessels for onboard navigation systems.
      5) DHS IP accesses updated critical infrastructure data from USGS and NGA, on a daily
         basis, in order to update HSIP.
      6) FEMA requests natural gas distribution system data from regional utility for consequence
          assessment.
      7) Census Bureau submits block-level housing data to FEMA for performing preliminary
          damage assessment.
      8) Local authorities submit preexisting building footprint data to FEMA for tornado damage
          assessment.
      9) NRC provides plume extent polygon to EOC for reverse 911 callup, following radioactive
          release from nuclear power plant.
      10) FCC provides set of point locations and related information to IAIP for vulnerability and
          consequence assessment.

5.2     Location

Unifies location across URISA, NIEM, and GML.

5.2.1     Description

Location: Any place or site on the earth of interest in the HLS mission. Also, the location of a
person, thing or any other phenomenon referenced to the earth. A position with geospatial
coordinates. A (street) address. An area or point of interest (i.e., a feature). Includes Absolute
Location and Relative Location. As defined by OGC, Location is the extensible, abstract data type
for all expressions of location that can be used by geospatial applications and services to specify
the location of a target, asset, conveyance, person, etc. As used in LBS, a Location is the root of
a semantic tree that includes a Point, Position, Address, and Point of Interest as its subtypes, all
which must resolve to a unique point, so that it can be used in navigation applications. As used in
NIEM, a Location may also be an Area of Interest.

5.2.2     Use Case Vignettes

      1) An analyst sends the address of a suspected terrorist cell rendezvous point to local FBI
         field office for immediate perimeter emplacement and monitoring.
      2) An IA/ICE/CBP analyst sends the address of suspected terrorist safe house to U.S.
         intelligence community for immediate monitoring.
      3) FEMA sends locations for crisis counseling, housing and recovery operations centers to
         state disaster planning officials.
      4) Given a major flood, county EOC sends planned shelter locations to first responders who
         are coordinating evacuation efforts.
      5) ICE and CBP share locations of detention centers and impounds with SLT law
         enforcement officials.


Recommendation for Inclusion of Geospatial Types in NIEM                                         18
Version 0.2                                                                       January 11, 2005
      6) Local Health Departments send home and work addresses of influenza patients to State
          Health Departments and NBIS.
      7) CBP field agents submit GPS-based incident and arrest locations for pattern and trend
          analysis.
      8) FEMA requests locations of toxic chemical storage and handling facilities from local EOC
          after major flood event in urban area.
      9) DoD transmits to HSOC the estimated location of plane at instance when ordnance
          disengaged from wing mount.
      10) FBI asks IAIP to provide locations of landmark structures, National symbols, and tourist
          attractions within 50 km buffer of major metropolitan area following intel report of possible
          terrorist attack

5.3     Coverage

5.3.1     Description

Coverage: A two- (and sometimes three or higher) dimensional geographic representation of
earth phenomena. A subtype of Feature. Common examples include imagery and digital terrain
models.

5.3.2     Use Case Vignettes

      1) FBI requests best available digital orthoimagery and land use/cover data from federal
          officials for 5-km buffer surrounding small cabin in rural area.
      2) In evaluating tsunami threat to coastal communities, FEMA requests best-available
          elevation data for metropolitan areas through Federal government‘s Geospatial One-
          Stop, to be used for emergency operations response planning.
      3) County EOC requests recent high resolution orthoimagery as needed from a server at the
          state homeland security operations center that has state coverage, in order to conduct
          emergency operations planning and support to incident response.
      4) HSOC requests thermal and LIDAR coverages from NASA and DoD sources for damage
          assessment due to terrorist attack. HSOC also accesses high-res Quickbird satellite
          imagery from Digital Globe.
      5) FEMA requests color, high-resolution imagery flown by NASA from its servers for
          hurricane damage assessments.
      6) Secret Service requests DSM (elevation) data for 4 blocks of downtown metropolitan
          area for viewshed and line-of-sight analysis.
      7) FEMA request best available elevation data from county for vulnerability assessment of
          rural communities downstream of older dam strained after record rains.
      8) Based on plume modeling, IMAAC provides regional level-of-contamination surface
          following Anthrax release from top of radio tower.
      9) HSOC requests regional ash deposition scenarios in raster format from USGS for
          volcano in Washington State.
      10) NOAA sends snow depth surface (TIN) model output to Joint Operations Center (JOC)
          for regional resource planning for snow removal effort.

5.4     Observation

5.4.1     Description

Observation: Data derived from sensor measurement, human detection, and other sensing and
measurement techniques.




Recommendation for Inclusion of Geospatial Types in NIEM                                            19
Version 0.2                                                                          January 11, 2005
5.4.2     Use Case Vignettes

      1) Sentinel system transmits above-threshold measurement of CBRN constituent to
          National Biosurveillance Information System (NBIS) and Homeland Security Operations
          Center (HSOC).
      2) NOAA buoy transmits occurrence of anomalistic wave height to adjacent FEMA and
          applicable SLT EOC (emergency operations center).
      3) Sensors deployed at the U.S. border feed observations into Border Sector Offices.
      4) Customs officials use sensors deployed at port facilities to detect containers with
          potential CBRN content; observations are recorded and fed to the operations center for
          analysis.
      5) Weather sensors deployed throughout a county are accessed by the EOC for current
          weather conditions needed for response and recovery operations.
      6) Field Secret Service units transmit observations of potentially-suspicious activity to Ops
          Command.
      7) DoD CBRN mobile response team (e.g., Guardian Brigade element) reports radioactivity
          levels from predetermined locations in metropolitan area following dirty bomb detonation.
      8) FBI ask municipal officials to provide video clips of streetscape around subway entrances
          for two hours preceding explosion.
      9) EPA Radiological Emergency Response Team (RERT) sends radiological measurements
          and mass spec graphs from unkown substance to HSOC and NBIS, respectively, from
          field following sweep of suspected terrorist residences.
      10) CDC sends test results for presence of ricin and botulinum neurotoxins on clothing and
          carry-on baggage of suspected terrorists to NBIS.

5.5     Route

5.5.1     Description

Route: The representation of a route for navigation purposes. The route‘s overall characteristics,
such as its start point, waypoints, end point, transportation type, total distance, travel time and
bounding box. Route geometry is defined as a list of geographic positions along the route,
ordered in the sequence of planned travel, starting with the position of the route‘s origin and
ending with the position of the route‘s destination, including waypoints. Also, a list of travel
instructions consisting of turn-by-turn directions and advisories along the route, ordered in
sequence of their occurrence. Routes are derived from navigable transportation networks.

5.5.2     Use Case Vignettes

      1) After apprehension of a terrorist suspect attempting to board a plane in Athens, Greece,
         destined for NYC, the suspect‘s subsequent domestic flight itinerary is provided to CBP,
         TSA, and ICE.
      2) County EOC provides recommended driving directions and supporting navigation
         updates concerning road surface conditions and closures to en-route response teams.
      3) USCG officers request route plans to intercept an unknown ship that has entered U.S.
         waters.
      4) Due to an elevated threat advisory, TSA provides route plans for flights into and around
         the capital region to HSOC for threat and vulnerability assessment.
      5) Given a major CBRN incident, a county EOC sends planned evacuation routes to first
         responders involved in evacuation operations.
      6) Dignitaries plan tour of San Francisco Bay; Secret Service shares boat route with USCG.
      7) Analysts provide probable driving route of at-large terrorist suspect and vehicle
         description to state and local authorities.
      8) DOT provides tanker re-routing information to local port authorities and USCG after
         determining safety zone for diesel spill in the St. Lawrence Seaway.

Recommendation for Inclusion of Geospatial Types in NIEM                                        20
Version 0.2                                                                      January 11, 2005
      9) Analysts piece together probable driving route of man with smallpox; transmits to CDC,
          HSOC, and NBIS.
      10) EOC transmits GPS waypoints to next search area for use by boat teams brought in for
          mutual aid during rescue operation during major flood.

5.6     Map

5.6.1     Description

Map: Generally, an annotated, symbolized graphical representation of select geospatial-temporal
data for an intended purpose. Also, a map created by an orthorectified image. May contain
annotations and marginalia. May be in hardcopy or softcopy form. May reference a Report or
Plan. May be referenced by or embedded in a Report or Plan.

5.6.2     Use Case Vignette

      1) Prior to arrival at a terrorist bombing, a fire and rescue incident commander requests
          transmission of a detailed map displaying local critical infrastructure and jurisdictional
                                                                      9
          boundaries (i.e., ―governmental units‖, a framework layer ) from the local EOC.
      2) An ICE intelligence analyst prepares a map conveying recent spot observations involving
          foreign terrorist suspects, for daily briefings.
      3) CBP officials request detailed maps conveying border patrol sectors, CBP/ICE facilities,
          critical infrastructure, incidents and spot observations for border security operations.
      4) Analysts in a state homeland security operation center collaborate with analysts in the
          HSOC sharing maps conveying vulnerabilities to critical transportation facilities in the
          state capital.
      5) USCG officials share detailed maps of port facilities with Federal agents to plan a sting
          for a smuggling operation.
      6) Secret Service requests detailed map of streets within of 2500m of motorcade from local
          officials.
      7) Second responders bringing mutual aid to large terrorism incident, are provided incident
          orientation maps to be viewed en-route through on-board laptops.
      8) USDA provides map of foot and mouth disease quarantine zones for distribution to local
          NRCS field offices, county extension agents, and law enforcement community.
      9) Local DOT requests map of secure perimeter for commuter traffic reroute planning
          following subway explosion.
      10) USDA provides map of carcass disposal sites to county officials during bird flu epidemic.

5.7     Mobile Object

5.7.1     Description

Mobile Object: Any entity (object) of interest that is in motion, or is otherwise dynamic, and is
monitored and/or tracked, such as a person, good, conveyance, asset, or dynamic environmental
phenomena. Mobile objects have one or more sets of location-date-time, and optionally record
activity,   status,      speed    and      direction   of   motion.      Historical  records   of
location/time/activity/status/speed/direction may be recorded for tracking purposes.




9
 Framework layers include transportation, hydrography, elevation, cadastral, geodetic control,
orthoimagery, and governmental units.

Recommendation for Inclusion of Geospatial Types in NIEM                                          21
Version 0.2                                                                        January 11, 2005
5.7.2     Use Case Vignettes

      1) Following discrete spill of volatile and toxic material in a river, upstream of large
          municipality, FEMA sends a data package to HSOC that includes incident origin, time of
          incident, estimated river speed, and material type.
      2) USCG officers request current tracking information for unknown ship that has entered
          U.S. waters from U.S. Navy.
      3) USCG operations center tracks its own vessels and the unknown ship they are pursuing,
          sharing this information with the U.S. Navy.
      4) The incident commander for a major incident monitors the location and status of
          personnel and assets, including reserve elements, using a tracking system at the
          command post.
      5) CBP operations center at the sector office tracks its own vehicles on patrol at the U.S.
          Border.
      6) FBI requests all records of weight station stops from DOT for specific semi-trailer en-
          route from Toronto to Los Angeles.
      7) Citizen recognizes terrorist suspect on commuter train; calls 911, gives description; EOC
          transmits train position and estimated time at stops to all available field units.
      8) US Fish & Wildlife Service transmits probable present location, path, and estimated time
          of arrival at points along migration route of sandhill cranes known to be spreading bird flu.
      9) JOC receives tornado sighting reports and produces projected paths for distribution to
          EOCs, NWS, Emergency Broadcast SystemsEBS, R911, etc.
      10) HSOC sends out tracking status of hijacked semi-trailer carrying phosgene to EOC‘s
          along probable route and within driving range.

5.8     Alert

We understand that a NIEM alert type has already been developed. Our analysis will be limited
to seeing if the NIEM alert type meets the geospatial representation requirements of DHS.

5.8.1     Description

Alert: A communication message with geospatial and temporal context that is triggered by any
suspicious or threatening event. Can be determined by evaluating observed or calculated
conditions through a ―watch‖ function, an output from a modeling and simulation activity, by
correlating incidents, occurrences and/or intelligence and predicting a potential threat or threat
condition. Example: A sensor alert that results from one or more observations that meet
predefined ‗threat detection‘ conditions. Alerts may lead to false alarms or develop into Warnings
(as determined by a qualified party).

5.8.2     Use Case Vignettes

      1) Following a severe storm, National Weather Service (NWS) broadcasts flood alerts that
         are picked up by a county EOC for evacuation planning.
      2) City law enforcement officials receive terrorist alerts from HSOC regarding heightened
         threat warning to its subway system.
      3) Local law enforcement issues an Amber Alert to other local and state law enforcement
         organizations for a missing person.
      4) County EOC issues an emergency evacuation alert to local residents due to a chemical
         spill in the immediate vicinity.
      5) BP Sector offices transmit alerts detected by sensors deployed at the borders for officers
         to investigate.
      6) TSA transmits threat alert to local EOC after explosive residue confirmed at airport
         screening point.



Recommendation for Inclusion of Geospatial Types in NIEM                                            22
Version 0.2                                                                          January 11, 2005
      7) EOC transmits threat alert to TSA after report of hole cut in airport fence by local law
          officer.
      8) CDC sends alerts regarding two confirmed smallpox cases to NBIS, HSOC, and media.
      9) USDA sends alert regarding mad cow disease at regional feedlot to NBIS, HSOC, and
          others.
      10) State health agency sends NBIS alert regarding reports of suspected mustard gas
          exposure from hospital emergency rooms in three different metropolitan areas.

5.9     Structure

5.9.1     Description

Structure: The geospatial representation of a man-made structure, e.g., building or bridge.

5.9.2     Use Case Vignettes

      1) From hostage crisis scene at a state government facility, incident commander of field
          agent team requests floor plan from state EOC.
      2) County officials submit “as-built” drawings of new county justice building to state
          homeland security operations center for critical infrastructure protection.
      3) First responders arriving at the scene of a five alarm fire, request building drawings from
          the EOC for fire suppression operations.
      4) For the purpose of conducting vulnerability assessments, Federal and state officials
          request detailed facility plans for nuclear power plants from private utility firms.
      5) State, local and Federal security officials share airport facility plans for security planning
          and joint operations planning efforts.
      6) Secret Service requests detailed building plans for 4 blocks of downtown metropolitan
          area for viewshed and line-of-sight analysis.
      7) Terrorist suspect identified after takeoff; flight destination redirected away from Dulles;
          FAMS Mission Operations Center (MOC) transmits terminal layout schematics of new
          destination to on-board Air Marshall to identify optimal apprehension point.
      8) Incident Command Post (ICP) handling subway explosion response and recovery
          requests blueprints or CAD drawings of underground infrastructure from local Public
          Works department and Utilities.
      9) ICP requests Public Works to submit detailed sub-floor plans, superstructure schematics,
          and building age information for blocks adjacent to subway explosion.
      10) Response team requests sports arena schematics for managing staff and evacuees
          during relief effort following hurricane.


      6 Homeland Security Infrastructure Protection Information Exchange
        Package (HSIP IEP)

The "Guidelines for Homeland Security Infrastructure Protection Geospatial Data Content"
developed by the FGDC Homeland Security Working Group (chaired by DHS GMO) contains a
recommendation for the content of seventy-two feature types. All of these HSIP feature types
share a set of common attributes.

The HSIP IEP schema can be found in hsip.xsd, in the schema package attachment. These
schema utilize the Feature and Location core types. The attribute content is based on Federal
Geographic Data Committee, Homeland Security Working Group, "Guidelines for Homeland
Security Infrastructure Protection Geospatial Data Content, Version 1.0‖. The schema for the
common attributes and all 72 feature types) has been finalized.


Recommendation for Inclusion of Geospatial Types in NIEM                                            23
Version 0.2                                                                          January 11, 2005
The HSIP IEP instance document for six example feature types can be found in hsip.xml, also in
the schema package attachment.


Recommendations

Based upon the analysis and schema development work that has been conducted to date, the
following interim recommendations are made:
       Add standards-based geospatial type definitions to the NIEM core with separate target
        namespaces and prefixs from those that currently exist in NIEM.
       Avoid substituting NIEM definitions for the geospatial standard-based definitions; doing
        so breaks interoperability with existing standards-based geospatial COTS software, and
        will impede the use of information from existing or new distributed, standards-based
        geospatial resources. We feel that it is imperative to closely calibrate NIEM with proven
        industry standards and practices. To not do so will impair the successful uptake of NIEM
        by the marketplace, as well as have a negative impact on the cost of implementing NIEM
        across the HLS community.
       Add standards-based definitions from the provided geoSpatial4niem.xsd schema (see
        attachment) in one schema file, under one target namespace referenced by a shared
        target namespace prefix to the set of shared NIEM definitions from the core data types
        for use in all NIEM domain-specific IEPs.
       Add standards definitions from the provided profile schemas under the standard target
        namespaces and prefixes that they define to the set of shared NIEM definitions from the
        core data types for use in all NIEM domain-specific IEPs.
       Existing NIEM processes can continue to use existing NIEM definitions for geospatial
        components, such as location, but those definitions should be deprecated in favor of the
        standards-based, industry-compatible schemas described herein.
       Future NIEM processes should be designed and constructed to use the standards-based
        definitions for Geospatial Core Types.
The planned future work includes the following tasks:
       Develop guidelines for formulating IEPs – It is important to conduct further analysis in
        order to develop guidelines concerning how the Geospatial Core Types may best be
        used in formulating, well-defined, valid, interoperable IEPs. These guidelines will greatly
        facilitate the IEP development process and lead to far greater success in the uptake of
        the IEPs by the HLS community. As an example that illustrates why guidelines need to be
        developed, considering the Geospatial Core Type: Location. The use of the NIEM role
        mechanism to allow a Location to consist of geometries, features, and addresses, can be
        problematic, depending on the use case. For some use cases, such as assembling
        evidence about a Location in a criminal investigation, allowing one or many roles to co-
        exist for a single location, may be entirely necessary and appropriate. However, in other
        cases, such as the need to drive to the location (for which a location must resolve to a
        unique point), having a broad definition with many possible roles can pose unnecessary
        complexity and interoperability challenges. In these later cases, it would make sense to
        restrict the use of roles, depending upon intended applications. Therefore, this would be
        an important guideline in developing IEPs.
       Finalize HSIP IEP – This will be an exemplar of a complex feature data set that will be
        used by many.
       Further analysis and enhancement of schemas for Simple Feature, Location,
        Coverage, Route, Map, and Observation – Further analysis will be conducted on the

Recommendation for Inclusion of Geospatial Types in NIEM                                          24
Version 0.2                                                                      January 11, 2005
       basis of feedback received during the review process. This will result in enhancements to
       the schemas that have been defined thus far.
      Conduct analysis and develop schemas for Alert, Mobile Object, and Structure –
       The schema for the three remaining Geospatial Core Types will be defined, and example
       instances will be developed and vetted through the review process.




Recommendation for Inclusion of Geospatial Types in NIEM                                      25
Version 0.2                                                                    January 11, 2005

								
To top