13.3 GIDB Web Map Service Implementation

  Previous section   Next section

In this section, we will look at the OpenGIS Consortium's (OGC) Web Map Service (WMS) Interface Specification and how it is utilized within the GIDB System. This specification is a set of open protocols that allow Web map servers to provide uniform services to HTML clients. By definition of the specification, a Web map server has three basic responsibilities:

  1. Publish a list of maps it can provide, together with the query abilities of each.

  2. Reply to queries concerning map content.

  3. Generate a map.

Actual map data can be provided in a number of formats, including pictures or images, basic graphical elements (vector), or sets of geographic feature data. The standardization of map requests can allow users, via HTML clients, to create custom layered maps with information from possibly different Web map servers.

Requests are submitted through Web browsers in the form of uniform resource locators (URLs). The URL parameters indicate relevant request information, such as the portion of the earth to be mapped, coordinate system, output format, map and location to be queried, or the holdings of a particular server. A map server provides three interfaces: Capabilities, Map, and FeatureInfo. The Capabilities and Map interfaces are required for conformance to the WMS specification, while the implementation of a FeatureInfo interface is optional. The Capabilities interface provides clients with machine-parseable lists of supported interfaces, map layers, and formats. Capabilities must be provided in an XML format to be considered conformant. The Map interface provides the actual maps to clients. To do this, the interface may possibly access multiple map servers. If the request cannot be satisfied, the server must throw an exception according to instructions received in the request. The FeatureInfo interface provides clients with additional information about points in maps that were previously returned as a result of a Map request. The map server developer is free to determine the information to be returned in response to a FeatureInfo request (detailed information for developers can be found in the OpenGIS Web Map Server Interface Implementation Specification at http://www.opengis.org/).

A GIDB portal driver was written to allow the GIDB mapping application to connect to and retrieve data from WMS-compliant map servers. Currently, the GIDB portal driver for WMS servers only implements the required request interfaces: Capabilities and Map. The FeatureInfo request interface is not implemented since it is optional, and at the time of initial development, no WMS servers could be found that provided this interface.

It is possible to connect to many WMS-compliant servers at the same time. To accomplish this, a driver instance is registered with the GIDB portal by submitting a URL request for the Capabilities interface. The WMS server should respond with a Capabilities XML document that complies with the WMS Capabilities DTD (http://www.digitalearth.gov/wmt/xml/capabilities_1_1_1.dtd). The driver software then parses the Capabilities XML document using the Apache Xerces XML parser. The Capabilities XML document contains information about the layers of mapping data available, the coordinate reference systems used, the geographic bounds the data covers, and how the data can be retrieved. As the GIDB portal driver parses the document, it translates the information into a structure that facilitates rapid understanding of available data and quick retrieval by the GIDB mapping application.

The driver instance maintains an array of geographical layer objects as a result of parsing the Capabilities XML document. A geographical layer object is defined to have a unique name, descriptive title, output map format, data location URL, and minimum geographic bounding rectangle. Listing 13.3 is an example of a layer in a Capabilities XML document.

Listing 13.3 Example of a Geographical Layer
[View full width]
<Layer>
  <Title>The GLOBE Program Visualization Server</Title>
  <SRS>EPSG:4326 AUTO:42003 AUTO:42005</SRS>
  <LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
  <Layer>
    <Title>Physiography</Title>
    <Layer queryable="0">
      <Name>RTOPO</Name>
      <Title>Topography and Bathymetry</Title>
      <Abstract>Topography and Bathymetry. Availability: special,19941231.  Units: m.</
graphics/ccc.gifAbstract>
    </Layer>
  </Layer>
</Layer>

In Listing 13.3, the Topography and Bathymetry layer inherits its bounding box from its parent layer. The resulting geographical layer object that is created and maintained in the driver instance is defined in Listing 13.4.

Listing 13.4 Resulting Geographical Layer in the Driver Instance
Name: RTOPO
Title: Topography and Bathymetry
Map Format: PNG: Topography and Bathymetry
Data URL: http://viz.globe.gov/viz-bin/wmt.cgi?
Bounding Box: -180, -90, 180, 90

The GIDB portal uses the array of geographical layers to determine which map data, if any, exists in the user's area of interest. Since the GIDB WMS implementation does not include FeatureInfo requests, the only types of maps returned by WMS-compliant servers will be image or raster maps such as JPEG, GIF, TIFF, and PNG image formats. These map images can then be displayed in the GIDB mapping application and overlaid with data from other sources.

To utilize the GIDB WMS portal driver, the GIDB mapping application will first ask the WMS driver instance for a list of its available map formats. This list is obtained from the output map formats in the geographical layer object array. Examples of map formats include topographic map layer, elevation data layer, aerial photography layer, and water bodies layer. When a user of the GIDB mapping application selects a particular map format for display, the request is sent to the WMS driver instance. The driver instance will then structure the WMS URL request based on the selected geographical layer object and the user's area of interest. A sample URL request is shown in Listing 13.5.

Listing 13.5 Example URL Request
http://viz.globe.gov/viz-
bin/wmt.cgi?&request=map&wmtver=1.0&SRS=EPSG:4326&LAYERS=RTOPO&BBOX=-
134.08163,15.81284,-
57.857143,54.901443&WIDTH=1024&HEIGHT=641&STYLES=default&FORMAT=-
PNG&TRANSPARENT=TRUE

Given this request, the WMS-compliant server will return a PNG image, which can then be displayed in the GIDB mapping application, as shown in Figure 13.8.

Figure 13.8. The Display within the GIDB Mapping Application of a PNG Image that Was Returned from a WMS-Compliant ServerRequest

graphics/13fig08.gif

A summary of the GIDB WMS architecture is shown in Figure 13.9. Note its similarity to the Metcast architecture shown earlier in Figure 13.3.

Figure 13.9. GIDB WMS Architecture

graphics/13fig09.gif

The WMS specification provides a standard mechanism for map data interchange over the Internet. This technology uses XML, coupled with URL requests, to provide georeferenced map images. The implementation of a WMS driver for the GIDB portal has demonstrated that this XML-enabled technology can be used to successfully integrate mapping data from many distinct and disparate databases over the Internet into a single application for display and analysis.


Top

[http://safari.oreilly.com/0201844524/ch13lev1sec3]

 


Part IV: Applications of XML