The Canadian Geospatial Data Infrastructure was envisaged to help organizations enjoy the benefits of having easy access to the geospatial information they need, in a format they can easily integrate into any application they would like to develop. The CGDI can offer this ease of access because it relies on a set of common standards. This chapter:
The CGDI has enormous potential to help a wide range of organizations use and access geospatial information in their daily operations. For a company that runs a fleet of delivery trucks, for instance, the CGDI could provide Internet-based maps of the country's road network, the location of road construction, and predicted areas of snowfall. The delivery company could then develop applications to display all this information, and to plan the best route to all its pick-up and drop-off delivery points.
Furthermore, using the CGDI, this company could also integrate traffic congestion information, ferry routes and schedules, road conditions, and accident reports. The company could then offer a service to its customers to submit requests for pick-up and delivery. This service could allocate the delivery to the most appropriate truck (based on its current location and route), develop a plan of how to alter its route to fulfill the request, estimate pick-up and delivery times based on traffic congestion, road construction and conditions, etc., and respond to customers with a detailed schedule.
For the CGDI to reach its full potential, participants must make two commitments:
When you use services based on CGDI-endorsed standards for data delivery, you can integrate data from multiple sources. You can then develop a whole range of applications that have been, until now, cost-prohibitive. Indeed, the CGDI is fostering the development of tools (some open-source) that can efficiently deliver and manipulate data accessible through these standard services.
The need for standards for geospatial data is well known, which is why committees such as the Open Geospatial Consortium, Inc. (OGC) and the ISO Technical Committee 211 on Geographic Information and Geomatics are developing them. Geospatial data infrastructures such as the CGDI, however, require broader standards, since they encompass protocols and web services, e.g. HTTP, Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), Electronic Business using Extensible Markup Language (ebXML); information technology committees such as the World Wide Web Consortium (W3C) and Oasis are addressing these comprehensive standards.
For its part, OGC is helping GeoConnections implement standards and specifications in order that the CGDI remain an operational and sustainable spatial data infrastructure. Indeed, OGC describes its role in the geospatial domain as follows:
Because there are so many incompatible standards in the geo-information technology area, geospatial information and geo-processing are not part of most information systems, and sharing geodata between geo-processing systems and between user communities requires considerable time and expertise.
Most of the standards attempt to normalize one of the following: 1) the encoding of information in software systems (data format standards and data transfer standards), or 2) the naming of features and feature relationships (data dictionaries), or 3) schemas for descriptions of datasets (metadata).
Uniquely, OGC addresses the Babel-like profusion of data format and data transfer standards by creating open, common interfaces between software system components, and letting those systems use any data format internally. These OpenGIS® Interfaces provide access to both information and functionality. OGC also works to develop open software approaches that address inconsistent data dictionaries and metadata schemas (http://opengis.org/).
The Canadian Geospatial Data Infrastructure shares OGC's vision of interoperability. As a sponsor of OGC, GeoConnections is developing a set of standard interfaces and services through which geospatial data can be accessed within the CGDI. These services do not dictate how organizations store their data: rather, each organization can choose what best fits its needs. They do, however, define a standard external interface with which organizations must comply in order to openly share data and services.
OGC describes the advantages of standard external interfaces in this way:
The interface approach has the great advantage of providing "transparent access" between systems. That is, it becomes possible for the data on another system to be as readily available to you as the data on your own system. The OpenGIS Specification for geo-processing interfaces largely eliminates the need for data format standards and costly batch data conversion. A query returns not a whole data file, but only the "result," or the answer to the query, and thus the network model eliminates the need for users to keep (usually outdated) copies of whole datasets.
An even greater advantage is that the interface approach enables geo-processing to become an integral part of the new Internet and web-based distributed computing paradigm in which applets, middleware, components, e-commerce tools, online data servers, and object request brokers give any networked computing device real-time access to a huge universe of data and processing resources. Any Internet-linked device, even cell phones, will be able to access countless data servers and powerful application servers as if all those terabytes of geodata and sophisticated software were on their own local storage media. Remote servers will upload little GIS applets and geo-enabled software components and will enable ordinary users to make use of smart digital maps in all kinds of desktop documents. Conventional RDBMSs (through advances not related to the OpenGIS Specification) will soon store complex spatial data and serve it (through OpenGIS® conformant interfaces) to a wide variety of GIS and non-GIS applications (http://opengis.org/).
With geospatial data available from multiple sources through standard interfaces, organizations like yours can now cost-effectively develop applications that integrate data from these sources. This will lead to a host of new applications (such as the one described above for the fictitious delivery company) that have until now been cost-prohibitive.
OpenGIS is a registered trademark and OpenLS and OGCNetwork are trademarks of the Open Geospatial Consortium, Inc. in the United States and other countries.
For a full description of CGDI-endorsed standards, please refer to Appendix A, CGDI-Endorsed Specifications.
The Canadian Geospatial Data Infrastructure has endorsed various standards and specifications and provides several resources for anyone developing applications. Of course, for these resources to help you, your application must have some geospatial association. While this might at first glance rule out many applications, most applications could in fact be improved by becoming more "geographically aware". Any application that is intended to convey information (e.g. municipal tax information or weather information) or deliver a product to the user (i.e. by shipping purchased items) is likely to use geographic information in some way.
The CGDI can help you by providing the following resources:
Framework data is geographic data that provides context and reference information for Canada. You can incorporate framework data into your application to provide context to other information. For example, to show your business location on a map, framework data will provide the surrounding roads; all you need to do is provide the location of your business and the framework data provides the geographic context or background information.
Web services include web map services, web feature services and web coverage services. These are described in Chapter 11, Implementing CGDI Web Services.
The CGDI Web Map Service Client Component (CWC2) is an open-source, downloadable web map client development toolkit developed for the CGDI, which consumes OGC web map services. It provides complete programmer configuration capabilities (i.e. template-driven) over the viewer client and WMS interfaces.
With this tool, you or your developer can embed a web map viewer into your web application. You control the access to one or more layers to (a) web map server(s) (either directly or via the use of context documents), and also control the presentation of the map and associated control widgets.
For further documentation and to download see:
CWC2 is an instance of Chameleon from http://www.maptools.org/chameleon/
The GeoConnections Discovery Portal's Application Program Interfaces (APIs) are the subject of Appendix C, Using GeoConnections Discovery Portal APIs.
The CGDI resources described in the pages that follow are currently available. However, the CGDI is quickly evolving and additional resources will likely be available by the time you read this manual. For the latest information, please refer to the GeoConnections web site at: http://www.geoconnections.org/.
You can incorporate dynamic framework data into your application by retrieving it when you need it, using one of the CGDI-endorsed service interfaces. In this way, you avoid having to maintain the data, and your application always uses the latest version of the data.
Alternatively, you can download framework data into your own GIS or database, for subsequent use in your applications. In this way, your application does not rely on a service provided by another organization. However, it is your responsibility to periodically retrieve the latest version of the framework data.
As discussed in 4.5, Common Framework Data, framework data takes three principal forms:
Each portion of the framework has a specified resolution (normally the resolution at which it was acquired) and a range of scales to which it is suited. Although eventually it might be possible to maintain just a single representation of any particular feature, for ease of use the CGDI framework data is currently stored and maintained at two separate resolutions, as shown in Table 1, Resolutions for Framework Data.
| Resolution | Accuracy | Large Scale | Small Scale |
|---|---|---|---|
| National | 1 km | 750,000 | 7,500,000 |
| Regional | 250 m and better | 10,000 | 750,000 |
These two resolutions have the following characteristics:
National Resolution
As of July 2003, the current framework data at a national resolution includes railroads, hydrography, provinces, municipalities and ecological units. The standard reference layers chosen at this resolution are integrated with the 1:1 million hydro/coastline framework maintained by the Atlas of Canada. The nominal scale of this data is 1:1,000,000 and the accuracy is approximately 1 km.
These national resolution frameworks feature correct relative positioning, and a consistent national resolution and methodology through partnerships with federal source agencies. Additional linkages (e.g. common feature identifiers) will be developed with the regional-scale frameworks to enhance cross-scale visualization and updates.
Regional Resolution
As of November 2003, the current framework data at a regional resolution became available through the GeoBase Portal (http://www.geobase.ca/). This regional data includes National Road Network, Canadian Digital Elevation Data, Geographical Names of Canada data (toponymy), Canadian Geopolitical Administrative Boundaries, Canadian Geodetic Network and Landsat-7 Ortho-image data.
Framework data at a regional resolution consists of data produced by a wide variety of organizations from federal, provincial, and in some cases, municipal levels. These datasets are maintained at a variety of accuracies, typically ranging from 250 m to 1 m. Normally the resolution used as the standard is the most detailed resolution of mapping available for that area. Horizontal integration is required between adjacent regional datasets.
As with other aspects of the CGDI, additional data is always being made available, so visit the site often.
A key attribute of the CGDI is its set of standards-based services that enable access to geospatially-referenced data. The CGDI has endorsed these standards, and encourages all organizations working with geospatial information to adopt them. These standards are introduced in this section, and are discussed in more detail in Appendix 1, CGDI-Endorsed Specifications. Details on the specifications may also be found on the OGC web site under OpenGIS® Implementation Specifications: http://www.opengis.org/specs/?page=abstract. These CGDI-endorsed standards include:
Web Map Services (WMS) Specification defines a service to retrieve a map (or image) of geo-referenced data. It has three operations:
Web Feature Services (WFS) Specification defines a set of operations that retrieve and manipulate geographic features. The specification allows for two levels of functionality. A Basic (read-only) WFS supports feature retrieval only, while a Transaction WFS additionally supports feature manipulation (creation, modification and deletion).
The operations supported by a Basic WFS are:
Web Coverage Services (WCS), to provide delivery of data coverage such as digital elevation data and other fixed or variable sized matrix data (http://www.opengis.org/docs/03-065r6.pdf); and
Map styling services, and services to access map symbol libraries, to support styling of geographic features in an encoding form passable by a web map service.
The Styled Layer Descriptor (SLD) standard defines a language that specifies how features are to be portrayed. It is currently most widely used as an additional parameter in the WMS GetMap operation, allowing the person making the request to define, in detail, how features are to be portrayed in the resulting map (http://www.opengis.org/docs/02-070.pdf).
The Web Map Context Specification defines an XML document that contains map metadata and enough information to retrieve a particular map from WMS servers. It can be thought of as a bookmark to a specific map (http://www.opengis.org/docs/03-036r2.pdf).
An optional component of the GetFeature, Transaction, and LockFeature requests is a "filter" that selects the features to operate on. The Filter Encoding Specification defines the format of this filter (http://www.opengis.org/docs/02-059.pdf).
The WFS specification specifies that features are to be exchanged using Geography Markup Language (GML). GML is a standard system for encoding spatial data in XML. It provides a grammar for encoding the geospatial content (feature properties, location, extent, feature relationships) of features. GML is based on XML Schema (Schema Definition Language-XSD) and can be thought of as a schema-writing language for spatial information that provides a set of standard XML tags or elements for spatial features and geometry types (http://www.opengis.org/docs/02-023r4.pdf).