Figure 29 Using Z39.50 with the Geodata Discovery Service
The CGDI Metadata for GeoData specification defines the content standards for which peer registries are considered to be compatible with CGDI registries for the purpose of holding descriptions of geodata resources. Currently, the CGDI has adopted the U.S. Federal Geographic Data Committee's Content Standard for Digital Geospatial Metadata (FGDC CSDGM) for the Metadata for Geodata (see A2.3.3.1, The Federal Geographic Data Committee Content Standard for Digital Geospatial Metadata). It is anticipated that the CGDI will also adopt ISO 19115 as a Metadata for Geodata format (please see A2.3.3.2, ISO TC 211 Metadata Standard 19115).
The Geodata Discovery Service is a CGDI specification to search Geodata Resource Registries and to retrieve metadata about geospatial data.
There are two profiles of the Geodata Discovery Service: stateful and stateless.
The stateful specification of the Geodata Discovery Service is based on the Z39.50 search and retrieval protocol. Z39.50 is ratified by the United States' national standards body, ANSI, but it is widely used in many application areas around the world.
Z39.50 is a search and retrieval protocol: it enables clients to search catalogues of information through the Internet, and to retrieve details about the catalogue records that match the search criteria. While HTTP is an Internet protocol for hypertext transfer based on URL-encoded requests for information, Z39.50 is an Internet protocol for metadata retrieval based on a set of detailed search specifications in the request. Just as an HTTP-based application may have its own specification for URL parameters to request and retrieve services though HTTP, there are many "profiles" for information search and retrieval through Z39.50.
The advantages that Z39.50 has over HTTP include the fact that these search profiles may be very specific to application communities. For example, the BIB-1 profile was created for the library community to search through distributed library catalogues and retrieve the catalogue information for the records that match the search. There is also a GEO profile that facilitates spatial, temporal and textual searching for geodata, and for the retrieval of the catalogue information (metadata) for the resulting records.
Another advantage is that Z30.50 is stateful. This is unlike HTTP, where a client sends a request to a server, the server processes the request, returns the result to the client, then goes back to its initial state. In Z39.50, a client can send a search query to the server, and then terminate the connection. The Z39.50 server continues to process the request, and the client may connect back to the same session to check the status of the request, or to do a secondary query within the result set that was returned from the initial search.
In addition, the client does not have to request that all results are returned to it in the same connection to the server. For example, it can ask for the first 50 results, then go off and do its own processing or interactions with the user, then go back to the Z39.50 server and ask for the next 50 results. Alternatively, the client may send several different searches, but may refer back to the results of any one of the searches at any time. This is called persistent result set management. The whole advantage of the stateful model is that it allows the client software component to interact with the user, without having to go back and redo the search if more information is required from the results of the previous search. It also permits the client to resume its own services while it is waiting for the server to complete the search.
The GEO profile of Z39.50 is widely used in geospatial applications for searching many inventory catalogues distributed throughout the Internet at the same time. It is a means of searching for geospatial content, using a single set of search criteria, which are held at the source of the data (i.e. at the supplier's site) and are described by metadata inside the supplier's databases. The GEO search profile is based on the FGDC CSDGM attribute set. It can be considered to be equivalent to a filter encoding specification for inventory metadata though the Z39.50 protocol.
Figure 29 shows how Z39.50 can be used by a consumer who connects to a Geodata Discovery Service, which then cascades simultaneously to several suppliers' inventory catalogues to search for individual data products.
Figure 29 Using Z39.50 with the Geodata Discovery Service
See 6.2, CGDI Search Protocols, for the three basic Z39.50 operations.
The stateless specification is intended to serve the same goals as Z39.50, to search geospatial inventory catalogues through the Internet, but without the requirement to deploy specialized Z39.50 components on the client and the server.
This specification is currently under development. The draft documented specification is available from the GeoConnections GeoData Discovery Service description page at: http://www.geoconnections.org/en/communities/developers/standards/fa=technical.geodata_discovery_service.
The specification should align with OGC's Stateless Catalogue Interface Implementation specification. Interfaces in this specification are aligned with OpenGIS®-style interfaces, which consist of the following operations:
GetCapabilities
As with most OpenGIS®-specified services, the server must respond to a GetCapabilities request with an XML document that conforms to the schema defined by the specification. The capabilities statement must respond with a list of operations that are supported by the server, the supported query languages, the type of geodata schema used with the results (e.g. FGDC-CSDGM or ISO 19115) and other specific information regarding the functionality of the query service.
DescribeCollectionSchema
When an entry identifier is specified with this request (where the entry identifier comes from the same GeoData Discovery Service), the server must respond with the XML schema for the record in which that entry is encoded. If identifier 0 is provided, the server must respond with the schema for the metadata directory.
GetRecords
This operation is used to retrieve the actual metadata in XML for the requested entry. The XML must conform to the schema for the metadata content standard (or geodata type) in which the record is stored.
To find geographic content on the Internet, users must be able to issue an Internet-wide search. There must be a common means for those searches to be specified so that servers will understand them. OGC is developing specifications that define services that must be supported by geographic search servers. This will enable users to find geographic objects that have similar properties.
The Filter Encoding specification is a means of defining what those properties are; it is used to filter the objects out of geospatial servers. In technical terms, it is an XML encoding of OGC's Common Query Language, or simply put, an XML schema for specifying a geographic query.
Although filter encoding is not yet a CGDI-endorsed specification, it will be in the near future.
The Filter Encoding specification is an XML notation for specifying queries for spatial objects. There is no requirement in this specification on the formulation or contents of the response.
Search servers may describe geographic objects using a set of attributes (or descriptors). The filter will constrain those attributes using the following query properties:
Web Coverage Service (WCS) is an emerging specification from OGC; it is not yet ratified as a specification, nor is it publicly available. The service interfaces are based on the definition of a coverage in OGC's Abstract Specification (see http://www.opengis.org/docs/03-065r6.pdf). Consequently, Web Coverage Service is not yet a CGDI-endorsed specification.
A coverage is a special type of a feature. It is essentially an irregular multi-dimensional grid that describes many types of Earth phenomena at every point in the grid. The advantage of coverages is that relationships between different geographic entities can be represented and derived. Spatial and/or temporal relationships may be modeled between different entity types. Many different types of phenomena may be represented by coverages, including lines, images, surfaces, geometries, vectors and points.
Interoperable implementations will eventually provide for powerful applications that can perform GIS-like analyses through the Internet.
Web Coverage Service (WCS) servers support the following operations:
GetCapabilities
A WCS server must respond to a capabilities request with an XML document that conforms to the capabilities XMS schema defined by the WCS interface specification. The capabilities must indicate which WCS operations the server supports, which vendor-specific operations are supported, details of the data types supported by the services (including interface specifications), and server access constraints. Finally, the server must return links to external catalogues that contain and describe metadata for coverages used by the service.
DescribeCoverage
This operation will retrieve a full description of one or more coverages available through the WCS server. The response must be an XML document conforming to the XML schema defined in the specification. This is a way for the client to find out which coverages are available on the server, and for each coverage, to retrieve the spatial extent, coordinate reference system, supported formats, and types of information contained in the coverage.
GetCoverage
A client may retrieve a full coverage, a coverage constrained by geographical area and/or a temporal range, or a subset of the coverage types. This can be considered analogous to a "data download" capability, where the user gets the data (GeoTIFF, Shapefile, etc.) instead of GML or an image.
Simple Features is not yet a CGDI-endorsed specification.
Simple features are specified by OGC's Abstract Specifications (see http://www.opengis.org/docs/99-049.pdf, http://www.opengis.org/docs/99-050.pdf, http://www.opengis.org/docs/99-054.pdf), but they are basically two-dimensional features in which the vertices are connected by straight lines. This specification has interfaces for representing and manipulating points, lines, polygons, curves, surfaces, geometries etc.
Recognizing that different communication and database architectures require different implementation architectures, the OGC publishes specifications for the storage and retrieval of simple features using various platform specifications. These implementation architectures are developed for:
For example, the SQL specification provides SQL schema for the management of simple features via an ODBC (object database connectivity interface). ODBC is a platform-independent interface to enable an application (in this case a web service) to interact with any type of relational database, using SQL.
Figure 30, SQL, CORBA and OLE Architectures, shows the nature of these architectures for the purpose of supporting OGC-type services as platform-independent system architectures.
Figure 30 SQL, CORBA® and OLE Architectures
Coordinate Transformation Services is not yet a CGDI-endorsed specification.
Coordinate Transformation Services can be considered to be a superset of the Simple Features services. The specification has separate sets of interfaces for positioning, for coordinate systems, and for coordinate transformations. It has interfaces for creating, managing, transforming and describing multi-dimensional coordinate systems. The profile can handle all coordinate systems from the European Petroleum Survey Group (EPSG), plus it can handle multi-dimensional and coordinate systems that are not georeferenced. This specification has profiles for COM, CORBA® and Java.