A government/industry team integrated and deployed a system that successfully demonstrated interoperability (using standards from the OpenGIS Consortium ) between diverse ArcIMS, CubeWerx, and Intergraph Web Mapping System servers. The system allowed browser-based clients to search all servers’ metadata via a single query, to display maps whose features reside on all servers and to display attributes of features. Interoperability works because the servers’ Web Map Services are able to respond to standard HTTP requests and any server responding to these requests can register its metadata. The Corps and Louisiana State University served Mississippi River, Corps, and Louisiana data; other servers provided USGS, NASA, and NIMA data.
This paper describes a multi-vendor web mapping system build for the U.S. Army Corps of Engineers (USACE). This system was possible because the vendors used common standards. The Developing the Technology section (below) describes how these standards were developed.
But first, a story. An organization builds a server based on a single vendor (Acme ). The system is robust; Acme made sure that all the components could be integrated easily. It’s easy to install and maintain. The problem is people that won't use Acme. Some engineers have used Brand X for years and will resist switching because of the cost of retraining and because Brand X supports some functions that Acme does not.
Non-Acme components are Standards-based Commercial-Off-The-Shelf (SCOTS). For example, the web server may be IIS, Netscape or Apache. The user doesn’t care, because all three support standards like HTTP and JPEG. The system looks like this, with Acme components in white.
The goal was to get geospatial software vendors to make only SCOTS components .
Now we can build a system incorporating legacy servers put up by different agencies. This paper describes such a system. The Developing the Technology Section (below) describes how we developed the technology to build it, and The Solution Section (below) describes how we built it.
This project aimed to solve a
number of problems (1) .
Topic: USACE geospatial data and systems management: administration and
personnel issues.
Problem: Data discovery
Problem: Time and money
Problem: Understanding the power of Geographic Information Systems (GIS)
Problem: Communication and coordination
Topic: Data Sharing
Problem: Technical hurdles
Problem: Cultural hurdles
Problem: Version control
Topic: USACE geospatial data systems and management
Problem: Interoperability of hardware, software and networking
Problem: Interoperability of GIS data formats
Additionally, the Corps realized that in order to stay competitive and serve
its customer (the U.S. public), it needs to function in a more “business-like”
manner. No longer can the Corps allow its districts to function in a
vacuum. The Corps has to approach an enterprise GIS solution and present
a “One Corps” to the world.
Web mapping capabilities were inadequate when we started in 1999, and to some extent still are.
Additionally, the Corps realized that in order to stay competitive and serve
its customer (the U.S. public), it needs to function in a more “business-like”
manner. No longer can the Corps allow its districts to function in a
vacuum. The Corps has to approach an enterprise GIS solution and present
a “One Corps” to the world.
There are many GIS systems in place, and users tend to be
loyal to their system. This immediately creates conflict with a single
vendor solution. Even if everyone was forced to accept a single vendor’s
software, who pays for it? Districts would have to buy new software
licenses, and in some cases, new hardware. There would be costs
associated with data conversion. Users would have to be trained and work
would backlog during the ramp-up period. During these times of limited
budgets, a single vendor solution is not practical.
A solution does exist. Starting in 1998, one of the Corps’ labs, the The Topographic Engineering Center (TEC) , an Engineering Research and Development Center ( ERDC) lab, began working with OpenGIS Consortium (OGC) , with other user organizations (mostly federal agencies), and with vendors , to promote interoperable web-based GIS. The OGC is a group of government, industry and non-profit organizations with an interest in geospatial software interoperability. Members include Esri, Oracle and NIMA . We hoped to provide a method to access various GIS systems through the Internet, and be able to combine data, regardless of software used and data format. The system should be easy to implement and relatively inexpensive. It should allow users to maintain their current GIS. Additionally, this system should be easy to use, requiring the user to have only a thin-client, such as a web browser. The key to accomplishing this is interoperable standards.
Our group of users and vendors participated in a series of efforts to develop interoperable software prototypes that solved our problems .
At first, users were skeptical. Why would any vendor promote an interoperable solution and potentially give away their business? The first Web Mapping Pilot Project demonstrating interoperability in response to a hurricane, used almost exclusively smaller vendors who were willing to use their research and development dollars in order to promote their software. By the time the second pilot was completed, open web mapping had caught the attention of larger firms who saw that interoperable data sharing was the future of GIS, and not some passing fad.
The resulting prototypes interoperate by using common HTTP interfaces. For example web map clients ask for a map using a standard HTTP request. The response is either data or an XML document. After all the vendors and the OGC membership agree on the interface specification, OGC releases the specification, and vendors are free to commercialize their prototypes. Many have done so. For example, any application compliant with the OGC Web Map Server specification (3) can get metadata, maps and attributes of displayed features from a web map server, such as ArcIMS. The metadata ArcIMS provides is sufficient to use the server with no prior knowledge of the server other than that it is OGC-compliant.
In the fall of 2000, the Corps’ Headquarters asked TEC to apply the technology developed over the past two years in a real world demonstration project, allowing data sharing (at least) between a district and a division. The project became the Civil Technology Insertion (CTI) (2), which we will discuss in the Solution section.
The above efforts succeeded. OGC interfaces allow a user, who in most
cases has only a browser, to exploit data that is distributed on servers made
by various vendors. Format, coordinate system and datum are hidden from the
user. In most cases the user has only a browser, but is able to search
for and find data, display the data, access the data and edit the data.
OGC provides a listing of commercial components conforming to OGC specifications . The most widely used components areWeb Map Servers. In addition, there are servers that provide vector and raster data. The Architecture section (below) contains more information about components. Here is a description of the most important.
Web Map Servers perform these services.
o format, coordinate system and scale
o geographic extent
o rules for symbolizing
features based on attributes
Most OGC-compliant web map clients have functionality similar to conventional web map clients like the ArcIMS HTML client. The functionality providing metadata allows a compliant catalog (such as ArcCatalog) to harvest metadata from compliant servers (such as the ArcIMS metadata server). This metadata conforms to the ISO (4) and FGDC (5) content standards, but it also contains metadata describing the server. By using this metadata to form a query, the client can use a server it has no prior knowledge of.
These software producers create products conforming to the Web Map Server Specification.
Immediately upon notification of the project, TEC began talking with potential candidates. The Mississippi Valley Division (MVD) was selected because of its commitment to an enterprise GIS. Out of MVD, TEC selected the New Orleans District (MVN) because of its expertise with GIS. In addition, MVN provided a unique opportunity. They were already sharing a data set with Louisiana. The state kept the data online at the Louisiana State University (LSU). By making LSU interoperable as well, MVN could use the data without needing to duplicate and maintain the database locally.
TEC provided the management oversight and the OGC provided the technical expertise. Two OGC members, Cubewerx and Compusult provided a cascading map server, catalog, and discovery services (see below.)
MVD uses Esri’s ArcIMS as their web mapping server. MVN and LSU use
Intergraph’s GeoMedia Webmap as their servers. This would truly be a
multi-vendor, interoperable solution.
Below is the general architecture.
The architecture for the CTI is simple. Data providers register their servers with a Service Registry. This registry contains metadata about the servers: their URL, type of data on the server, file names, projections, etc. A user, using his web browser (5) issues an http request. This request goes to the Cascading Map Server (CMS). The CMS (2), through the registry (3), knows what data exists on what servers (1). Because the data providers serve the layers using interoperable standards, the CMS can request the needed layers, reproject them into a common datum, combine the layers into a “picture” and send the picture down to the user’s desktop. If a user is unsure as to what data are available, he can search for data through the catalog (4) that works in conjunction with the service registry. This architecture works if every one abides by the interoperable standards developed and promoted by the OGC.
The figure below shows how we applied it to the Civil Technology Insertion
effort.
Work started in earnest on the CTI in April 2001. By August, there was a fully interoperable, integrated system able to share data between district, division, university and other federal agencies.
The figure below shows the true interoperability of the CTI.
Layers from several servers are pulled on to a desktop through a web browser. The data were not preprocessed; it came directly from the servers on which it resides. These layers include:
roads (red ) from the U.S. Geological Survey using ArcIMS
current project sites ( yellow dots) from MVD using ArcIMS
levees (purple ) from MVN using GeoMedia Webmap
railroads (orange ) from LSU using GeoMedia Webmap
base data - water (blue ) and urban areas (red) from Compusult using their software
photo mosaic from the National Aeronautic and Space Administration – Jet Propulsion Lab using Arc IMS
Government-industry collaboration has made it possible to build a system incorporating legacy software from multiple vendors.
CTI successfully met its goals, addressing many of the questions the Corps
faces as it looks toward creating an enterprise GIS. Along the way, the
project allowed participants to develop new interfaces for web mapping, and to
exercise and refine the interoperable standards. Additionally, though not
required, this project helped evolve stylized layer descriptors, a tool
allowing users to further refine the data display.
1. U.S. Army Corps of Engineers Geospatial Data and Systems Management Report (draft), May 2000
2. U.S. Army Corps of Engineers, U.S. Army Corps of Engineers Geospatial Data and Systems Management Report, (draft), May 2000
3. OpenGISŪ Web Map Server Interfaces Implementation Specification 1.1.1
4. ISO/DIS 19115 Geographic information - Metadata
5. Content Standard for Digital Geospatial Metadata (version 2.0), FGDC-STD-001-1998
Dan Specht
Physical Scientist
US Army Engineer Research and Development Center, Topographic Engineering
Center
7701 Telegraph Road
Alexandria, VA 22315
(703) 428-6761
(703) 428-8176 (fax)
specht@tec.army.mil
William Ryder
Physical Scientist
US Army Engineer Research and Development Center, Topographic Engineering
Center
7701 Telegraph Road
Alexandria, VA 223155
(703) 428-8106
(703) 428-8176 (fax)
William.H.Ryder@erdc.usace.army.mil