CHAPTER 10

Implementing CGDI Web Services

You can use web map services from the Canadian Geospatial Data Infrastructure for your own application. These services include gazetteers, geospatial-content servers, geospatial-content clients and standards-based inventories.

This chapter documents the architectures, descriptions, parameter specifications and web service interfaces of these web map services.

10.1 Web Service Architectures

Web service architectures arose from the need for computer-to-computer communication among distributed organizations. While the Internet has vastly increased person-to-person communication, it has also fuelled the demand for computer-to-computer communication. However, progress in this area has lagged due to the lack of a widespread communication mechanism. The mechanism must accommodate all who wish to participate, no matter what computer platform they use. The barriers to participation must be low.

These needs are paramount for business-to-business (B2B) e-commerce to succeed, and it is this B2B market that is spearheading the development of web service architectures. The same needs are also imperative to establish distributed infrastructures such as the Canadian Geospatial Data Infrastructure. The purpose of the CGDI is to increase the online availability of geospatial data and services, and foster new geomatics applications. Access to distributed data and other geomatics services is crucial to meet this goal.

Web service architectures provide a distributed environment in which you can deploy and invoke services using standard Internet protocols. In this context, a service is a collection of operations, accessible through one or more interfaces, that allows you to evoke a behaviour of value to you.

10.1.1 Benefits of Web Service Architectures

Web service architectures leverage the pervasive Web, providing a universal distributed computing platform. Applying distributed computing no longer means a heavy financial and training investment in technologies. Many methods exist to publish legacy applications to the Web. A service can be made web-accessible no matter how it is implemented, or what platform it executes on. Applications can be easily built from services running on heterogeneous platforms in any location.

These benefits are vital for large organizations (corporations or governments) whose distributed divisions, running different computing platforms, need to interoperate. Inter-organizational infrastructures, such as the CGDI, and B2B infrastructures can function thanks in part to web service architectures.

Applying web service architectural principles to development yields applications composed of loosely coupled, distributed (or distributable), and reusable services. Complex applications are broken down into simpler entities that can be independently developed. The development adds to the pool of services that become available for use in new, even more sophisticated applications. The cost of application development is reduced, making sophisticated application development more cost effective.

10.1.2 How to Use Web Service Architectures

The following example demonstrates how you can build an application using a web service architecture. This case study develops a web application that accepts place names, and returns a map showing a road route between the two places. This application might be implemented as shown in Figure 10, Traditional Application Design.

Figure 10 Traditional Application Design

The user invokes the application through a web browser, and then enters the place names. The web server invokes an application, which performs the necessary processing i.e. accessing a database of place names, a road route database, and a database of other map features. The web server then returns a map to the browser as a Graphics Interchange Format (GIF) image. The important aspect of this process is the way in which the application is structured, particularly the partitioning of the software into components and the interfaces between the components.

Traditional design techniques structure the software into logical units with well-defined interfaces, but deploy the application as a uniform entity, not suitable for distribution.

When you apply web-service based techniques to this application, they break down the application into a number of web service components, which are deployed as stand-alone servers with an HTTP interface. The result of this structure is shown in Figure 11, Application Design Using a Web Service Architecture. (Since the user's access to the web browser, and the browser to web server interaction, are unchanged, they are not shown.) The application has been constructed to make use of the services provided by distinct servers:

• A gazetteer server provides services to convert a place name into a geographic location;
  
  
• A route server provides services to get the road route between two geographic locations;
  
  
• A map server provides services to get a base map on which the route is displayed;
  
  
• An overlay server provides a service to overlay the route on the map; and
  
  
• A display route server makes use of the services above to convert a road route request into a map displaying the route.
  
  

The services are deployed in the web service platform and hence can potentially be located anywhere on the Internet, even though they might all reside on a single host computer for the initial deployment.

Figure 11 Application Design using a Web Service Architecture

The benefits of this architecture are not necessarily apparent when this application is considered in isolation. However, when the application is considered as part of a distributed infrastructure such as the CGDI, the benefits of a web service architecture are immediately apparent:

• The development of this application has resulted in the deployment of a number of reusable services that can initiate the development of other applications;
  
  
• The architecture is scalable: even if all services were initially deployed on a single computer, if the server is swamped by heavy use, services can easily be migrated to different computers; and
  
  
• The most suitable participant can provide the back-end services (e.g. the Atlas of Canada can provide the server that provides the base map).
  
  

Additional benefits are realized when the service interfaces become "standards" (formal or de facto), and when there are multiple deployments of the same services. The design allows the application to make use of new and better implementation of the services as they emerge.

10.1.3 Best Practices and Case Studies

One of the focal points of the Canadian Geospatial Data Infrastructure is to implement a distributed set of OpenGIS® web services that were developed to support user communities of practice.

Existing web services now available from the CGDI include:

• National-provincial mapping services such as the Centre for Topographic Information Map Server of Natural Resources Canada;
  
  
• Provincial topographic web map servers from British Columbia, Ontario, and Newfoundland and Labrador;
  
  
• National and provincial gazetteers;
  
  
• Catalogue servers; and
  
  
• Application development tools.
  
  

All of these services are based on OGC's implementation specifications, namely: Catalog Services, Web Map Server Interfaces, Geography Markup Language (GML), Web Feature Service (WFS) and Web Map Service (WMS).

Table 2, Web Services Best Practices, and the following case study, provide examples of "best practices" of organizations that have implemented web services.

The National Forest Information System (NFIS) (http://www.nfis.org/) provides a good example of how an organization can meet its internal needs while at the same time contributing to and using the Canadian Geospatial Data Infrastructure.

The National Forest Information System aims to be the key thematic component of the CGDI for forest resources information. The NFIS is actively contributing to the direction of the evolving CGDI architecture framework, through its representation on the GeoConnections Technology Advisory Panel (TAP) and Access Program and through participation on the CGDI Architecture Working Group. Wherever possible, NFIS developments are contributed to the pool of CGDI assets maintained under GeoGratis.

The NFIS is being built on the principles that this section has been advocating, namely:

1. Use of Standards

   The NFIS will adopt and promote the use of international and other appropriate standards as these standards evolve through the work of bodies such as ISO, W3C and OGC, and as these standards become accepted within the CGDI community. Standards are fundamental in achieving interoperability of information services relating to metadata, web content delivery (both spatial and thematic) and for generic IT services such as user authentication, e-commerce, etc.

2. Web Services Architecture

   The NFIS architecture will consist of a network of content servers working within a common information and services framework. OGC web map technologies (http://www.opengis.org/index.htm) will form the basis for vendor-neutral information interoperability in the NFIS network. The common information and services framework will allow NFIS member organizations to attach attributes to the shared representations of the landscape and to carry out independent, off-line analyses and compilations for subsequent web delivery through the common framework.

   This distributed architecture will allow responsibility for the management of information and implementation of services to reside with the custodian, closest to the data source. This approach ensures that the data are authoritative and current while providing the custodial agency with full control of the data.

10.2 Using CGDI Web Map Services

The advantage of using CGDI web service interfaces is that you receive standards-compliant results from the web services. You can easily integrate these results along with other standards-based mapping components, into your own applications to create more powerful services for your users.

In most cases, the standards are based on definitions ratified by the Open Geospatial Consortium, Inc. and documented at http://www.opengis.org.

Some services have two interfaces: a web service that returns XML and an embedded HTML service in which you can insert the component into a web page.

Figure 12 depicts the process involved when someone uses a web map service from the CGDI.

Figure 12 Using a CGDI Web Map Service

10.3 Gazetteers

Gazetteers are CGDI services that look up geographic regions based on secondary reference systems. These secondary reference systems are a means of geo-coding a point or a region by some arrangement, such as postal code, CGDI place name, the Canadian Geographic Name Service, or the National Topographic System.

10.3.1 Postal Code Lookup Service

The Postal Code Lookup service finds geographic regions based on Canadian postal codes. This gazetteer uses the "Forward Sorting Area" (FSA) portion of Canadian postal codes for input; the Forward Sorting Area is the first three characters of the full Canadian postal code. It then returns a point location that contains the latitude-longitude coordinates of the central postal station of the FSA.

Note that at some time in the future, this service may be upgraded to use the full six-character postal code. Watch for notices of changes in the online documentation.

Service Type
Gazetteer

Output Format
XML/GML with place name, latitude-longitude point location.

Output Encoding
OGC GML 3.0.0

Further Documentation
http://geoservices.cgdi.ca/postalcode/postalcode_1_0_0-en.doc

Sample Interface
http://geoservices.cgdi.ca/postalcode/sample.html

Capabilities Document
http://geoservices.cgdi.ca/ cgi-bin/postalcode/postalcode.cgi?version=1.0.0&request=GetCapabilities

Base URL
http://geoservices.cgdi.ca/cgi-bin/postalcode/postalcode.cgi?

HTML Encoding
An alternate embedded HTML version of this service is available at: http://geodiscover.cgdi.ca/gdp/about/en/6.2.html

10.3.1.1 Parameter Specification

Table 3 provides a snapshot of the parameter specifications for the Postal Code Lookup service. Please refer to the online documentation under "Further Documentation" for the latest parameter specifications.

For an example of the results of a Postal Code Lookup service, please see:

10.3.2 CGDI Place Name Lookup Service

The CGDI Place Name Lookup service finds all places in Canada that match the place name specification in the input string. A repeatable set of the feature description and GML latitude-longitude coordinates is returned within a web feature service (WFS) XML description. The complexity of the geometry that is returned can vary from simple points to complex geometries; this is determined by one of the parameters in the input request.

The place name data used for the CGDI Place Name Lookup service is from the Canadian Geographic Names Service (CGNS). For more details, please see 9.3.3, Canadian Geographic Name Service Place Name Gazetteer, and 9.3.4, Canadian Geographic Name Service Server.

Service Type
Gazetteer

Output Format
An XML/GML containing one or more features. There may be several features provided in the output if the search criteria match several geographic places.

Output Encoding
OGC GML 2.1.2

Further Documentation
http://cgdi-dev.geoconnections.org/prototypes/cgdigaz/

http://geodiscover.cgdi.ca/gdp/search?action=entrySummary&entryType= webService&entryId=1825&entryLang=en

Sample Interface
http://cgdi-dev.geoconnections.org/prototypes/cgdigaz/sample.htm

Capabilities Document
http://cgdi-dev.geoconnections.org/cgi-bin/prototypes/cgdigaz/cgdigaz.cgi?version=1.0&request=GetCapabilities

Base URL
http://cgdi-dev.geoconnections.org/cgi-bin/prototypes/cgdigaz/cgdigaz.cgi?

Note that the URLs for the CGDI Place Name Lookup service will change once it is up and running. It is not expected that the parameter specification will change. For the latest description on the deployment of this service, please see:

10.3.2.1 Parameter Specification

Table 4 provides a snapshot of the parameter specifications for the CGDI Place Name Lookup service. Please refer to the online documentation for the latest parameter specifications at: http://cgdi-dev.geoconnections.org/prototypes/cgdigaz/.

For an example of a CGDI Place Name Lookup service, please see:

Please refer to the online documentation for more examples.

10.3.3 Canadian Geographic Name Service Place Name Gazetteer

The Canadian Geographic Name Service (CGNS) Place Name gazetteer returns feature information for specific geographic locations.

Service Type
Gazetteer

Output Format
HTML, XML or CSV

Further Documentation (including parameters, codes and Refer functionality)
http://gnss.nrcan.gc.ca/gnss-srt/help_api.jsp#api

Sample Interface
http://gnss.nrcan.gc.ca/gnss-srt/api?regionCode=24&geoname=Montreal

10.3.4 Canadian Geographic Name Service Server

The Canadian Geographic Name Service (CGNS) is a web feature service (WFS), with all input requests and output conforming to the WFS specifications. The WFS includes the place name data, which is used to drive some of the CGDI gazetteer services, such as the Canadian Geographic Name Service Place Name Gazetteer.

Service Type
WFS Gazetteer, Web Map Server

Output Encoding
OGC WFS or WMS

Capabilities Document
http://cgns.nrcan.gc.ca/wfs/cubeserv.cgi?datastore=cgns&version=1.0.0&service=wfs&request=GetCapabilities

Base URL
http://cgns.nrcan.gc.ca/wfs/cubeserv.cgi?datastore=cgns

There is also a web map service (WMS) instance of the place name service, with scale-dependent location names available as layers. The capabilities document for this service is available at:
http://cgns.nrcan.gc.ca/wms/cubeserv.cgi?version=1.1.1&service=wms&request=GetCapabilities

The base URL is: http://cgns.nrcan.gc.ca/wms/cubeserv.cgi

10.3.5 Other Place Name Gazetteer Services

The CGDI offers two other place name gazetteer services: the World Place Name gazetteer, and the HTML-encoded gazetteer.

10.3.5.1 World Place Name Gazetteer

Service Type
Gazetteer

Further Documentation
http://ogc.compusult.nf.ca/OGC/gaz_get_search.html

Capabilities Document
http://ogc.compusult.nf.ca/cgi-bin/OGC/gazetteers/wfs?request=getCapabilities

Base URL
http://ogc.compusult.nf.ca/cgi-bin/OGC/gazetteers/wfs

10.3.5.2 HTML-Encoded Gazetteer Client

Service Type
An embedded HTML gazetteer client (based on the CGDI gazetteer for Canadian place lookups and the World gazetteer for non-Canadian place lookups).

Further Documentation
http://geodiscover.cgdi.ca/gdp/about/en/6.2.html

10.3.6 National Topographic System Lookup Service

The National Topographic System (NTS) returns geometries for known NTS map sheet identifiers, or it returns NTS map sheet identifiers for given geometries.

Service Type
Gazetteer

Output Format
XML with two regions encoded in GML with latitude-longitude coordinates. One location is the neat line of the map sheet, the other location is the quadrangle of the map sheet. Alternatively, it can return the National Topographic System map sheet number for a given location and scale.

Output Encoding
OGC GML 3.0.0

Further Documentation
http://geoservices.cgdi.ca/NTS/index.jsp

Sample Interface
http://geoservices.cgdi.ca/NTS/NTSLookup?request=GetMapsheet&version=1.1.0&mapsheet=31g5

Capabilities Document
http://geoservices.cgdi.ca/NTS/NTSLookup?request=GetCapabilities&version=1.1.0

Base URL
http://geoservices.cgdi.ca/NTS/NTSLookup?-

10.3.6.1 Parameter Specification

Table 5 provides a snapshot of the parameter specifications for the National Topographic Systems lookup service. Please refer to the online documentation under "Further Documentation" for the latest parameter specifications.

For an example of a National Topographic Systems lookup service, please see:

Please refer to the online documentation for more examples.

10.4 Other CGDI Mapping Services

The Canadian Geospatial Data Infrastructure has web mapping services of many varieties registered as web services in the GeoConnections Discovery Portal. These include web map servers, web map clients, web feature services, web coverage services, web registry services, and gazetteer clients. With time, the number and breadth of services registered in this directory will grow. Descriptions of the services in this directory include links to capabilities documents for the services and URLs for further descriptions about the services.

You can access the list of CGDI web services from the CGDI web services form of the GeoConnections Discovery Portal at http://geodiscover.cgdi.ca.

The direct link for the list of CGDI web services is:

You can use the GeoConnections Discovery Portal XML API (described in Appendix C, Using GeoConnections Discovery Portal APIs) to get an XML list of all CGDI web services. The API service for this list is found at:

Each service in the XML response has an entryId. For more information about each entryId using the getEntry interface, please see Appendix 3, Using GeoConnections Discovery Portal APIs.

10.5 Web Map Services Repository Interfaces

The CGDI also offers a web map service repository. This repository stores service information (such as web map server instances) and capabilities documents. It enables clients to discover web services such as map servers and layers, at:
http://geodiscover.cgdi.ca/gdp/search?action=executeSearch& entryType=webService& sortOrder=alphabetic& serviceType=CgdiAllServicesAndClients

10.5.1 Service Manager

The Service Manager is a repository of OGC-compliant services, implemented using OGC's Catalogue Interface Implementation Specification. Queries conforming to this specification may be used to retrieve CGDI services that conform to OGC's specifications.

Further Documentation
http://ceomap2.ccrs.nrcan.gc.ca/cslt/wes/SM_ref_guide010825.pdf

Base URL
http://ceomap2.ccrs.nrcan.gc.ca/cgi-bin/cslt/wes/service_manager/catquery
Note: You must make a valid request to it for it to work.