1.1.  Interoperability Is Essential

Standards are the basis for the success of the Internet and the World Wide Web. The Net has reshaped how we view and share information. Standards are a fundamental enabling technology of the Net. Standards allow thousands of applications, vendor solutions, and technologies to be interoperable. The Net, via standards, is vendor and content-neutral. A standard describes requirements and recommendations that have been agreed to in a consensus forum, such as the Internet Engineering Task Force (IETF), the International Organization for Standardization (ISO), or the OGC. To be useful, standards should represent the “best engineering practices” providing technical value, both in enhancement of individual products, and the multiplicative factor of providing inter-application operability, communication and cooperation.

As described in The Importance of Going Open White Paper, non-interoperability impedes the sharing of data and the sharing of computing resources, causing organizations to spend much more than necessary on geospatial information technology development. At its best, the Web works in a near frictionless environment, allowing data and processes to flow and interact with a minimal number of barriers. Standards tear down barriers and obstacles to the flow of information and services – they make the Web as we know it possible. OGC plays the particular role of making spatial information open and seamless on the Web.

The Havoc of Non-Interoperability White Paper identifies risks associated with non-interoperability. Today, lives and property depend on digital information flowing smoothly from one information system to another. Public safety, disaster management, and military applications increasingly depend on communication between dissimilar systems. No single organization produces all the data (so it’s inconsistent) and no single vendor provides all the systems (so the systems use different system architectures, which are usually based on different proprietary interfaces).

Organizations like the OGC, the IETF, the World Wide Web Consortium (W3C) and others are open organizations in the sense that any individual or organization can participate, the topics of debate are largely public, decisions are democratic (usually by consensus), and specifications are free and readily available. An “open” process is necessary to arrive at an “open” standard. The openness that OGC promotes is part of this general progress.

Often the terms “open standards” and “open source” are confused or incorrectly taken to mean the same thing. The OGC standards are specifications developed in an open process. Open source is software made freely available under a license that allows the program to run for any purpose, to study how the program works, to adapt it, and to redistribute copies, including modifications. As a matter of policy, the OGC Board of Directors and staff don’t favor either proprietary software or open source software. From the OGC perspective, any developer who implements OGC standards in software or online services is doing the right thing. OGC cares about interoperability – the ability to share geospatial information.

1.2.  An Example: Web Map Service

OGC’s Web Map Service standard is an example of interoperability achieved through open standards. It is of particular importance since the “map” is a potent user interface tool for conveying spatial information in a compact, useful and meaningful form. The Web Map Service standard began as discussion in the OGC Specification Program that became the first OGC Interoperability Program initiative, the Web Mapping Testbed, in 1998. The WMS candidate interface standard that was developed in the WMS Testbed was adopted as an OpenGIS Implementation Specification in 2000 (WMS version 1.0). Since then, WMS has progressed in maturity with implementations numbering in the thousands. WMS is now also published as ISO 19128.

WMS provides a simple example of how topics are discussed in this reference model:

• Section 2.3 Spatial Referencing describes coordinate reference systems (CRSs) used in WMS. CRSs are vital to geospatial interoperability;

• Section 3.2 OGC Web Services describes several OGC geospatial web services, including WMS, as a coordinated service architecture implemented with common elements across services;

• Section 4.4 Spatial Data Infrastructures describes the use of WMS and other OGC Web Services in a reusable pattern for deployment for worldwide SDIs.

• Section 5.1 OGC Compliance Test Program describes the automated testing resources available for all approved OGC services; these resources allow implementers to determine compliance with the OGC specifications.

WMS has dramatically increased the use of on-line mapping. One issue of OGC User describes the use of the WMS standard in helping with disaster response to hurricane Katrina, soils data distribution in Europe, a statewide data center, and access via mobile phones. In another OGC User article, the number of WMS servers on the Internet is seen to rise each week as more organizations realize the power of using open standards. At the same time, the number of WMS clients – designed for use in a browser, or on the desktop or on a mobile device – is growing.

1.3.  Business Processes Benefit from Geospatial Standards

Integrating Geospatial Standards and Standards Strategies into Business Process – an OGC White Paper – identified many business processes that could benefit from the integration of geospatial information and services currently do not. This is because geospatial information has been locked in non-standard systems using different information models and storage structures – often referred to as “stove pipes.” A commitment to interoperability and to implementing open standards unlocks this foundational information type…​

For over a decade, the OGC has been promoting the benefits of open geoprocessing specifications. In the last several years, we have seen an increase in the number of policy statements regarding the use of OGC standards. The federal and national agencies involved are endorsing OGC standards. OGC members and users of OGC standards offer testimonials in an endorsements section of OGC website.

Several studies document the benefits of developing and implementing standards. Examples of such studies include: “The Economic Benefits of Standardization,” published by the DIN German Institute for Standardization, e. V. Beuth Verlag, in April, 2000; “The Value of Standards: A Delphi Study” published in June, 2003; “Geospatial Interoperability Return on Investment Study,” prepared by Booz Allen Hamilton, Inc. for the National Aeronautics and Space Administration (NASA) in April 2005; and the Socio-Economic Impact of the Spatial Data Infrastructure of Catalonia by the European Commission in 2008. These reports document in ROI terms the value that accrues for users, technology providers, and society when open standards are used. The enterprise “return on investment” in open interfaces is unquestionable today.

1.4.  The OGC Programs

The OGC is an international industry consortium of companies, government agencies and universities participating in a consensus process to develop publicly available interface standards. The OGC is organized into four operational business areas.

• In the OGC Standards Program, the OGC Technical Committee and OGC Planning Committee work in a formal consensus process to create and revise member-adopted OpenGIS Standards.

• The OGC Interoperability Program is a series of engineering initiatives to accelerate the development and acceptance of OGC Standards and that OGC technology meets user environments and needs.

• The OGC Marketing and Communication Program leads outreach and education efforts; nurtures strategic partnerships and alliances; and develops and supports regional and sector programs.

• The OGC Compliance Program provides a process whereby compliance can be tested and certified — indicating that compliance with OGC Implementation Specifications has been achieved.

Policies and Procedures guide the work of the OGC programs. These policies assure the openness of the OGC process, outlining how change requests and dissents are to be treated and adjudicated so the all technically legitimate issues are treated fairly, without prejudice and in a timely manner. OGC Policies also standardized quality control mechanisms to assure structure and relevance of OGC standards to their avowed purpose.

1.5.  OGC Standards and Other Documents

The OGC technical documents have been developed by the membership to address specific interoperability challenges and opportunities. OGC documents are available to everyone at no cost.

OGC publishes several different types of documents (Table 1). Sections 2 and 3 of the ORM contain exclusively Standards, Abstract Specifications and to a lesser extent Best Practices. Other ORM sections may include other OGC Document Types.

Table 1 — OGC Document Types

OGC develops information models, usually in the form of XML Schema documents. The general process for disseminating a model is to publish a specification (or standard) document, and publish the XML schema to a schema repository. Based upon the status of the specification or documentation, the schemas will be posted to one of several OGC Schema repositories.

2.1.  Geospatial Information Is Fundamental or “Everything is somewhere”

Geospatial information is a ubiquitous element of almost all data. Whether represented as a map or an image, encoded as an address, zip code, or phone number, described in a text passage as a landmark or event, or any of the many other ways of representing Earth features and their properties; geography is pervasive.

Geospatial location and time are integral to all aspects of the work in the OGC and OGC standards. Geography is a foundational property for modeling the world in a coherent, intuitive way. Location and time can be exploited as a unifying theme to better understand the context of most real and abstract phenomena.

2.2.  Information Specifications

The OGC Standards Development Process creates Abstract and Implementation specifications. The purpose of the Abstract Specification is to create and document a conceptual model to support the creation of Implementation Specifications. Implementation Specifications are unambiguous technology platform specifications for implementation of industry-standard, software application programming interfaces. Geospatial domain semantics defined in the Abstract Specifications are to be consistent across multiple technology platforms as defined in Implementation Specifications.

The Information Viewpoint section of the ORM describes both Abstract and Implementation specifications for geospatial information. For example, the key concepts used by Geography Markup Language (GML) to model the world are drawn from the OpenGIS Abstract Specification and the ISO 19100 series of International Standards.

OGC Information Specifications are used in conjunction with other information technology standards. The OGC Abstract Specifications are used to bring geospatial semantics to more general IT specifications, for example using the OGC Coverage specification with grid encoding formats. Elements of the OGC GML Implementation Specification are embedded in other specifications.

2.3.  Spatial Referencing

Location is contextually simple and intuitive to most people. For example, people can relate to where they are on a map, follow directions to a place, readily grasping the spatial context of their local environment, and so forth. For computers to exchange geospatial data, clear definition of the location and the spatial referencing system is required.

Locations can be described by using different types of spatial referencing systems:

1. Civic locations using geographic terms or identifiers;

2. Coordinates as numeric values in a coordinate reference system.

3. Linear referencing for linearly located events and linear segments.

Civic locations may be unique identifiers or place names. Spatial referencing with identifiers occurs when the identifier uniquely indicates a location, such as a postal code. Place names may be ambiguous, such as “Springfield”, requiring additional information so that this place name can be resolved into a specific location identified by coordinates. Gazetteers and geocoding are geospatial operations or processes used to convert a place name into a geographic coordinate. The OGC Gazetteer Service Best Practice utilizes a gazetteer data model defined in ISO 19112: “Spatial referencing by geographic identifiers.” Turn to Clause 3.2 for more about the OGC Gazetteer Service.

Coordinates are a sequence of N numbers designating the position of a point in N-dimensional space. Coordinates are always expressed using some coordinate reference system (CRS). A coordinate reference system is a coordinate system that has a reference to the Earth. CRSs are defined in the OGC Abstract Specification: Topic 2 — Spatial Referencing by Coordinates, also published as ISO 19111. This document also describes coordinate transformations and coordinate conversions between two different coordinate reference systems. With such information, geographic data referred to different coordinate reference systems can be merged together for integrated manipulation. A map projection is a coordinate conversion from a geodetic coordinate system to a planar surface, converting geodetic latitude and longitude to plane (map) coordinates. The result is a two-dimensional coordinate system called a projected coordinate reference system.

OGC has defined several methods for encoding Coordinate Reference Systems:

• The OpenGIS® Implementation Specification for Geographic Information — Simple feature access — Part 1: Common architecture, also published as ISO 19125-1, defines “Well-known Text Representation of Spatial Reference Systems.” The specification provides a non-exhaustive list of Geodetic Codes and Parameters for defining the objects in the Well-Known Text Representation.

• The OGC Best Practices Paper for Definition identifier URNs in OGC namespace specifies Universal Resource Names (URNs) in the OGC URN namespace to be used for identifying definitions, including definitions of Coordinate Reference Systems (CRSs) and related objects, as specified in OGC Abstract Specification Topic 2: Spatial referencing by coordinates. This document specifies the formats used by these URNs, including formats that can reference definitions recorded in the EPSG database and by other authorities.

There are a variety of practices, specifications, and standards for how spatial geometry coordinates (axes) are ordered. Geodesy, computational geometry, graphics processing, and computer-aided design – all have different rules for specifying or encoding axis order. The OGC developed an Axis Order Policy and Recommendations summarized as “in all cases, honesty is the key”. In other words, any documentation, encoding, payload, or service interface must state how the coordinate axis order is actually encoded in the coordinate strings.

The OGC Abstract Specification: Topic — Linear Referencing System (to be published) defines a conceptual schema for locations relative to a one-dimensional object as measurement along (and optionally offset from) that object. It defines a description of the data and operations needed to use and support linear referencing.

2.4.  Maps, KML, and PDFs

A map is a visualization of geographic information. Figure 1 shows how maps differ from other types of geospatial information. A map may be a digital image file suitable for display on a computer screen; a map is not the data itself. Examples of map encodings include jpg, gif and other file types.

The OGC KML Standard is an XML grammar to encode and transport representations of geographic data for display in an earth browser, such as a 3D virtual globe, 2D web browser application, or 2D mobile application. Put simply: KML encodes what to show in an earth browser, and how to show it. Geographic visualization includes not only the presentation of graphical data on the globe, but also the control of the user’s navigation in the sense of where to go and where to look. The OGC KML Standard Development Best Practice provides guidelines for developing the OGC KML standard.

The OGC PDF Georegistration Encoding Best Practice describes an extension to the Adobe® Portable Document Format (PDF) for creating PDF objects that identify a region of the PDF page as a map and describe the map’s coordinate systems. The intent of this specification is to codify xisting practice. The intent is not to make this specification an OGC standard. An OGC Best Practice should not be referred to as a standard.

Figure 1 — Maps, Display, Features and Data (Source: WMS 1.0, OGC document 00-028)

2.5.  Geographic Features

A feature is an abstraction of a real world phenomenon. A geographic feature is a feature associated with a location relative to the Earth. A digital representation of the real world can be thought of as a set of features.

The OGC approach to feature modeling follows the principles specified in ISO 19109:2005, “Geographic information — Rules for application schema.” As shown in Figure 2, Conceptual schemas define abstract feature types and provide the process for domain experts to develop application schemas that are used to encode content describing feature instances. The developer of an application schema may use feature definitions from feature catalogues that already exist. The process for defining an application schema is described in Clause 2.7.3.

Figure 2 — Modeling Geographic Information (Source: ISO 19109:2005)

Any feature may have a number of properties. These properties may be operations, attributes or associations. Any feature may also have a number of attributes: Spatial, Temporal, Quality, Location, Metadata, Thematic. A feature collection is a feature that represents a collection of features that have common metadata and formal relationships. Collections possess all the characteristics of a feature.

Geographic phenomena fall into two broad categories, discrete and continuous. Discrete phenomena are recognizable objects that have relatively well-defined boundaries or spatial extent. Examples include buildings, streams, and measurement stations. Continuous phenomena vary over space and have no specific extent. Examples include temperature, soil composition, and elevation. A value or description of a continuous phenomenon is only meaningful at a particular position in space (and possibly time). Temperature, for example, takes on specific values only at defined locations, whether measured or interpolated from other locations. These concepts are not mutually exclusive. In fact, many components of the landscape may be viewed alternatively as discrete or continuous. Historically, geographic information has been treated in terms of two fundamental types called vector data and raster data.

“Vector data” typically deals with discrete phenomena, each of which is conceived of as a feature. “Raster data,” on the other hand, deals with real world phenomena that vary continuously over space. Raster is included in the OGC the “coverage” concept. A coverage defines a data model that associates spatio-temporal positions to data values. The data attributes of a coverage vary across its spatio-temporal extent.

2.6.  Geometry and Topology

Geometry provides the means for quantitative description of the spatial characteristics of features, including dimension, position, size, shape, and orientation. Topology is useful for characterizing relationships between geometric objects without concern for the size or exact shape of the objects.

The conceptual model for geometry and topology is contained in OGC Abstract Specification Topic 1 — Feature Geometry, also published as ISO 19107:2003 Geographic information — Spatial schema. OGC has implemented the conceptual model of ISO 19107 in the OGC Geography Markup Language as described in Clause 2.7.

A geometric object is a combination of a coordinate geometry and a coordinate reference system. In general a geometric object is a set of geometric points, represented by direct positions. A direct position holds the coordinates for a position within some coordinate reference system. Typical geometric objects are points, lines, and polygons.

Geometric calculations such as containment (point-in-polygon), adjacency, boundary, and network tracking can be computationally intensive. A productive use of topology is to accelerate computational geometry. Another purpose is, within the geographic information domain, to relate feature instances independently of their geometry.

Spatial query operators are a mechanism for characterizing topological relations between different features. The operators are meant mainly for query evaluation and are defined in such a manner as to allow a variety of implementations to be assured of equivalent results against datasets with equivalent information content. The Simple Features Access and the OGC Filter Encoding Implementation standards provide typical names for spatial query operators (See Figure 3). OGC Abstract Specification Topic 1 – Geometry provides a more exhaustive standardization of spatial operators.

Figure 3 — Spatial query operator examples

2.7.  Geography Markup Language

2.8.  Sensor Web Enablement Information

2.9.  NetCDF

The OGC Network Common Data Form (NetCDF) Core Encoding Standard defines an encoding for geospatial data, specifically digital geospatial information representing space and time-varying phenomena. NetCDF is a data model for array-oriented scientific data. The CF-netCDF Core and Extensions Primer provides an overview of the OGC CF-netCDF standards suite by describing the CF-netCDF core and extensions. The NetCDF Binary Encoding Extension Standard: NetCDF Classic and 64-bit Offset Format defines binary representations of space-time varying geo-referenced data. Specifically, this standard specifies the netCDF classic and 64-bit offset file binary encoding formats.

2.10.  Units of Measure

The Units of Measure Recommendation Best Practice provides recommendations for use and definition of the units of measure used for numerical quantities. These recommendations are more widespread than OGC only, and are being proposed at other organizations, including POSC, W3C, CSIRO, PIDX, and OASIS.

The recommendations are stated for a single, measure value. However, many of the same structures apply to arrays and tuples of values. XML Schema and documents that capture arrays of values, and tuples of values, should consider the patterns of these recommendations, and follow them where appropriate.

Many of these recommendations are stated using XML and XML Schema. These recommendations should be followed even when XML is not being used.

2.11.  Geographic Metadata

OGC adopted ISO 19115 as the OGC Abstract Specification – Topic 11: Metadata. ISO 19115:2003, Geographic information – Metadata defines the schema for the identification, extent, quality, spatial and temporal schema, spatial reference, and distribution of digital geographic data. These schemas are useful for the cataloguing of datasets, clearinghouse activities, and the full description of datasets; geographic datasets, dataset series, and individual geographic features and feature properties.

The OGC Abstract Specification Topic 12 — The OpenGIS Service Architecture, also published as ISO 19119:2005, defines a service metadata schema for use in a catalogue service as is done for dataset metadata.

2.12.  GeoDRM

The OGC Geospatial Digital Rights Management Reference Model (GeoDRM RM) defines a conceptual model for digital rights management of geospatial resources. The GeoDRM RM provides a metadata model for the expression of rights that associate users to the acts that they can perform against a particular geospatial resource, and associated information used in the enforcement and granting of those rights, such as owner metadata, available rights and issuer of those rights. The GeoDRM RM also defines requirements that are placed on rights management systems for the enforcement of those rights. Finally the GeoDRM RM defines how this is to work conceptually in the larger DRM context to assure the ubiquity of geospatial resources in the general services market.

2.13.  GeoXACML

OGC GeoXACML is a policy language that defines a geo-specific extension to the OASIS standard eXtensible Access Control Markup Language (XACML). GeoXACML defines an extension to XACML for spatial data types and spatial authorization decision functions. Those data types and functions can be used to define additional spatial constraints for XACML-based policies. GML encodings for geometric data types are defined in GeoXACML extensions. By using the GeoXACML Policy Language, an interoperable access control system for geospatial applications, such as Spatial Data Infrastructures, can be implemented. It is important to highlight that GeoXACML is not designed to be a Rights Expression Language.

2.14.  OGC Schema Repositories

Many OGC specifications include XML Schemas. The schemas appear in the specification document and are published in the OGC schema repository. Based upon the status of the specification or documentation, the schema will be posted to one of several repositories.

• OGC XML schema repository for Adopted Technology, i.e., Implementation Standards, such as OGC’s GML, SensorML, or WMS

• Repository for XML schema documents related to OGC Best Practice documents.

• Repository for XML schema documents related to OGC Discussion Papers documents. Discussion Papers are not intended to be targets of acquisition descriptions. These papers do not represent the official position of the Open Geospatial Consortium nor of the OGC Technical Committee.

• Repository for experimental XML instance and schema documents. Documents posted here do not represent an official position of the OGC. This repository is for the convenience of developers in the OGC community, and is not necessarily on track for adoption as a standard.

2.15.  OGC Naming Authority

The OGC Naming Authority (OGC-NA) controls the assignment of OGC Names to resources of interest in geographic information infrastructures. The scope of the resources that may be identified with OGC Names is indicated by the set of items in the register http://www.opengis.net/register/ogc-na/type. A URN namespace for the Open Geospatial Consortium (OGC) Best Practice describes a URN (Uniform Resource Name) namespace for naming persistent resources published by the OGC. In June 2010, an OGC policy was approved that http URIs be used to persistently identify OGC resources instead of URNs.

3.1.  Services Architecture

The widespread application of computers and use of information systems have led to the increased analysis of geospatial data within multiple disciplines. Geospatial datasets are increasingly being shared, exchanged, and used for purposes other than their producers’ intended ones. Geographic information systems, sensors systems, automated mapping, facilities management, traffic analysis, geopositioning systems, and other technologies for geospatial information are entering a period of radical integration.

The OGC Abstract Specification Topic 12 — The OpenGIS Service Architecture provides a framework for developers to create software that enables users to access and process geospatial data from a variety of sources across generic computing interfaces within an open information technology environment.

• “a framework for developers” means that the OGC Standards are based on a comprehensive, common (i.e., formed by consensus for general use) plan for interoperable geoprocessing.

• “access and process” means that geodata users can query remote databases and control remote processing resources, for example in information systems using service oriented architecture.

• “from a variety of sources” means that users will have access to data acquired in a variety of ways and stored in a wide variety databases and knowledge bases.

• “across generic computing interfaces” means that OGC services enable reliable communication between otherwise disparate software resources that are equipped to use these interfaces.

• “within an open information technology environment” means that this OGC standard enables geoprocessing to take place outside of the closed environment of monolithic GIS, remote sensing, and automated systems that constrain access based on proprietary interfaces.

There are multiple choices of information technology for defining, developing and deploying service networks, i.e., distributed computing platforms. OGC standards are defined for multiple distributed computing platforms while maintaining common geospatial semantics across the underlying technology. OGC defines one conceptual specification as the basis for multiple platform-specific implementation specifications.

Development of standards may proceed from conceptual to implementation or from implementation to conceptual. In either case, a specification is not considered complete until it has a conceptual model and at least one implementation.

OGC services are defined using fundamental principles of service-oriented architecture:

• A Service is a distinct part of the functionality that is provided by an entity through interfaces,

• An Interface is a named set of operations that characterize the behavior of an entity,

• An Operation is a specification of a transformation or query that an object may be called to execute. Each operation has a name and a list of parameters.

Application and extension of the OGC Service Architecture is described in The Reference Model for the ORCHESTRA Architecture available as an OGC Best Practice.

3.2.  OGC Web Services

OGC Web Services (OWS) are defined using open non-proprietary Internet standards; in particular the World Wide Web (WWW) standards of HTTP, Uniform Resource Locators (URLs), Multipurpose Internet Mail Extensions (MIME) types and the Extensible Markup Language (XML).

The OGC Web Services Architecture Description Best Practice Document summarizes significant aspects of the OGC web services architecture. This architecture is a service-oriented architecture, with all components providing one or more services to other services or to clients.

The OpenGIS Web Service Common Implementation Standard provides specifics that are common to OWS interface Implementation Standards. These common aspects are primarily some of the parameters and data structures used in operation requests and responses. Each Implementation Standard details additional aspects of that interface, including specifying all additional parameters and data structures needed in all operation requests and responses.

OGC recognizes the need to accommodate multiple architecture styles and patterns, e.g., SOAP and REST. By a motion in the TC meeting of December 2008, the OGC promoted “development of service oriented architecture standards using platform-independent abstract specifications and platform-dependent implementation specifications for all OGC service standards that support both procedure-oriented and resource-oriented service styles or patterns.” It was recognized that this requirement could be dropped for service standards for which multiple bindings or patterns are not appropriate. While OGC standards have been developed and adopted with bindings of several styles, development of bindings to new architectural patterns continues.

3.3.  OWS Web Mapping Services

The OpenGIS Web Map Service (WMS) Implementation Specification, also published as ISO 19128, provides three operations (GetCapabilities, GetMap, and GetFeatureInfo) in support of the creation and display of registered and superimposed map-like views of information that come simultaneously from multiple remote and heterogeneous sources.

The OpenGIS Web Map Tile Service (WMTS) provides for serving spatially referenced data using tile images with predefined content, extent, and resolution. WMTS trades the flexibility of custom map rendering – as provided by WMS – for the scalability possible by serving a fixed set of tiles. The fixed set of tiles also enables the use of standard network mechanisms for scalability such as distributed cache systems. WMTS includes both resource (REST) and procedure oriented architectural styles (KVP and SOAP).

The OGC has defined profiles of WMS:

The OpenGIS Styled Layer Descriptor (SLD) Profile of WMS, explains how WMS can be extended to allow user-defined symbolization of feature and coverage data. This profile defines how the Symbology Encoding standard can be used with WMS. SLD is used in combination with SE Standard. SLD allows for user-defined layers and named or user-defined styling in WMS. If a WMS is to symbolize features using a user-defined symbolization, the source of the feature data must be identified. The features may be in a remote WFS or WCS, or from a specific default feature/coverage store. WMS servers using remote feature data are also called Feature Portrayal Services (FPS), while those using remote coverage data are Coverage Portrayal Services (CPS).

The OpenGIS Symbology Encoding (SE) Implementation Standard specifies the format of a map-styling language for producing georeferenced maps with user-defined styling. SE is an XML language for styling information used to portray Feature and Coverage data. SE may be used together with SLD. As SE is a grammar for styling map data independent of any service interface specification it can be used flexibly by a number of services that style georeferenced information or store styling information that can be used by other services.

The OpenGIS Web Map Context Documents Implementation Standard defines how a specific grouping of one or more maps from one or more WMS servers can be described in a portable, platform-independent format for storage in a repository or for transmission between clients. A Context Document contains sufficient information for Client software to reproduce the map, and ancillary metadata used to annotate or describe the maps and their provenance for the benefit of human viewers. (Based on the success of the Web Map Context, an OGC Standards Working Group is currently developing an OGC OWS Context Document standard.)

The OGC KML Standard defines an XML grammar used to encode and transport representations of geographic data for display in an earth browser. Put simply: KML encodes what to show in an earth browser, and how to show it. (See also Clause 2.4)

3.4.  OWS Data Access services

3.5.  Catalogue Service for the Web

The Catalogue Service for the Web (CSW) is one binding defined in the OpenGIS Catalogue Services Implementation Standard (CAT). The Catalog standard defines common interfaces to discover, browse, and query metadata about data, services, and other potential resources for several bindings: Z39.50, CORBA, and HTTP.

OGC has defined several profiles of CSW with some common elements required. All CSW implementations must support the CAT core queryables and returnable properties. The common CSW record syntax is an XML-based encoding of Dublin Core metadata terms.

The OpenGIS Catalogue Services Specification 2.0.2 — ISO Metadata Application Profile specifies interfaces, bindings, and encodings required to publish and access digital catalogues of metadata for geospatial data, services, and applications that comply with a profile for ISO19115 metadata for geodata/geospatial applications and ISO19119-based metadata for tightly and loosely-coupled geospatial services.

The several parts of the CSW-ebRIM Registry Service apply CSW to the OASIS ebXML registry information model (ebRIM 3.0) providing a general and flexible web-based registry service (WRS). WRS enables users—human or software agents—to locate, access, and make use of resources in an open, distributed system. WRS provides facilities for retrieving, storing, and managing many kinds of resource descriptions. An extension mechanism (called Extension Packages) permits registry content to be tailored for more specialized application domains.

The Catalogue Services Standard 2.0 Extension Package for ebRIM Application Profile: Earth Observation Products standard specifies an Extension Package for ebRIM Application Profile of CSW 2.0. This application profile enables CSW-ebRIM catalogues to handle a variety of metadata pertaining to earth observation, like EO Products defined in the OGC GML Application Schema for EO Products.

3.6.  Processing Services and Service Chaining

The OpenGIS Web Processing Service (WPS) Implementation Standard defines an interface that facilitates the publishing of geospatial processes, and the discovery of and binding to those processes by clients. Processes include any algorithm, calculation or model that operates on spatially referenced data. A WPS may offer calculations as simple as subtracting one set of spatially referenced numbers from another (e.g., determining the difference in influenza cases between two different seasons), or as complicated as a global climate change model. The data required by the WPS can be delivered across a network using OGC Web Services.

A WPS process may be an atomic function that performs a specific geospatial calculation. Chaining of WPS processes facilitates the creation of repeatable workflows. WPS processes can be incorporated into service chains in a number of ways:

• A BPEL engine can be used to orchestrate a service chain that includes one or more WPS processes. Business Processing Execution Language is a standard issued by OASIS.

• A WPS process can be designed to call a sequence of web services including other WPS processes, thus acting as the service-chaining engine.

• Simple service chains can be encoded as part of the execute query. Such cascading service chains can be executed via the GET interface.

OGC Abstract Specification Topic 12: OpenGIS Service Architecture defines service chaining as the combination of services in a dependent series to achieve larger tasks. Topic 12 addresses the syntactic concepts of service chaining, e.g., data structure of a chain, and the semantic concepts, e.g., does a specific chain produce a valid result? Service chaining enables users to combine data and services in ways that are not pre-defined by the data or service providers.

3.7.  Sensor Web Enablement (SWE) Services

The goal of OGC’s Sensor Web Enablement (SWE) is to enable all types of Web and/or Internet-accessible sensors, instruments, and imaging devices to be accessible and, where applicable, controllable via the Web. The vision is to define and approve the standards foundation for “plug-and-play” Web-based sensor networks.

OGC had established Web Service standards for geospatial data:

• The OpenGIS Sensor Observation Service (SOS) Implementation Standard defines a web service interface for requesting, filtering, and retrieving observations and sensor system information. Observations may be from in-situ sensors (e.g., water monitoring devices) or dynamic sensors (e.g., imagers on Earth-observation satellites).

• The OpenGIS Sensor Planning Service (SPS) Implementation Standard defines an interface to task sensors or models. Using SPS, sensors can be reprogrammed or calibrated, sensor missions can be started or changed, simulation models executed and controlled. The feasibility of a tasking request can be checked and alternatives may be provided. The OGC SPS Earth Observation Satellite Tasking Extension supports the programming process of Earth Observation (EO) sensor systems used by many satellite data providers.

• The OGC Sensor Alert Service (SAS) Best Practice Document defines a web service interface for publishing and subscribing to alerts from sensors. Sensor nodes advertise with an SAS. If an event occurs the node will send it to the SAS via the publish operation. A consumer (interested party) may subscribe to events disseminated by the SAS. If an event occurs the SAS will alert all clients subscribed to this event type.

• The OpenGIS SWE Service Model Implementation Standard provides data types and mechanisms reused by other SWE standards.

3.8.  Location-Based Mobile Services

3.8.2.  OpenLS

The OpenGIS Location Services (OpenLS) standards define an open platform for position access and location-based applications targeting Mobile Terminals. The OpenLS Core Services exchange content in the form of Abstract Data Types shown in Figure 4. The five Core OpenLS services are defined in a single document, the OpenGIS Location Services (OpenLS): Core Services Implementation Standard:

1. Directory Service. Provides access to an online directory (e.g. Yellow Pages) enabling an application to find the location of a specific or nearest place, product, or service.

2. Gateway Service. Retrieves the position of a known Mobile Terminal from the network. This interface is modelled after the LIF/OMA Mobile Location Protocol (MLP), Standard Location Immediate Service, specified in Open Mobile Alliance MLP.

3. Location Utility Service (Geocoder/Reverse Geocoder) Geocoding converts a text description of a location, such as a place name, street address, or postal code to a position structured as Point geometry. Reverse Geocoding converts a position into a feature (Address with Point), where the address may be a street address, intersection address, place name, or postal code.

4. Presentation Service. Creates maps and other graphic depictions of selected geospatial data, with a set of ADTs as logical layers.

5. Route Service. Determines travel routes and navigation information between two or more points.

The OpenLS: Part 6-Navigation Service Implementation Standard is an enhanced version of the Route Service that determines travel routes and navigation information between two or more points.

The OpenLS Tracking Service Interface Standard supports a very simple functionality allowing a collection of movable objects to be tracked as they move and change orientation.

Figure 4 — OpenLS Information Model

3.9.  Fine-Grained Services

OGC specifications apply to environments as diverse as the Internet and to workgroup clusters. For web services, the client and server have very little knowledge of one another. Specifications designed for this environment are classified as coarse-grained profiles. At the other extreme, the interface between a client and server is fine-grained exposing greater detail on the server’s holdings. OGC has standardized several fine-grained specifications:

• The OpenGIS® Implementation Specification for Geographic information — Simple feature access — Part 1: Common architecture, also published as ISO 19125-1, describes the common architecture for simple feature geometry. The simple feature geometry object model is Distributed-Computing-Platform neutral and uses Unified Modeling Language (UML) notation. The base Geometry class has subclasses for point, curve, surface and geometry collection. Each geometric object is associated with a coordinate reference system, which describes the coordinate space in which the geometric object is defined.

• The OpenGIS Implementation Specification for Geographic information — Simple feature access — Part 2: SQL option, also published as ISO 19125-2, defines a Structured Query Language (SQL) schema that supports storage, retrieval, query and update of features. This standard is dependent on components defined in Part 1 of this standard. In an SQL-implementation, a collection of features of a single type is stored as a “feature table” usually with some geometric-valued attributes (columns). Each feature is primarily represented as a row in this feature table.

• The OpenGIS Coordinate Transformation Service Implementation Specification defines interfaces for general positioning, coordinate systems, and coordinate transformations. The specification provides an abstract model in UML along with profiles for Java and Interface Description Language (IDL).

• The OGC GeoAPI Implementation Standard defines, through the GeoAPI library, a Java language API including a set of types and methods that can be used for the manipulation of geographic information structured following OGC specifications. This standard standardizes the informatics contract between the client code which manipulates normalized data structures of geographic information based on the published API and the library code able both to instantiate and operate on these data structures according to the rules required by the published API and by OGC standards.

4.1.  Publish, Find and Bind Pattern

OGC web services utilize the popular publish/find/bind pattern shown in Figure 5 for dynamic binding between service providers and in a distributed environment.

Figure 5 — Publish/Find/Bind Pattern

In Figure 5, there are three essential roles:

• Service: publishes services to a broker (registry) and delivers services to service requestors.

• Service Consumer: performs service discovery operations on the service broker to find the service providers it needs and then accesses service providers for provision of the desired service.

• Service Directory: helps service providers and service requestors to find each other by acting as a registry or clearinghouse of services.

As shown, there are three essential kinds of operations performed by services:

• Publish: used to register data and services to a directory (such as registry, catalog or clearinghouse). A service provider contacts the service directory to publish (or unpublish) a service. A service provider typically publishes service metadata describing its capabilities and network address.

• Find: used by service consumers to discover specific service types or instances. Service consumers describe the kinds of services they’re looking for to the directory and the directory responds by delivering the results that match the request. Service consumers typically use metadata published to find services of interest.

• Bind: used when a service consumer invokes a services. A service consumer typically uses service metadata provided by the registry to bind to a service provider. The service consumers can either use a proxy generator to generate the code that can bind to the service, or can use the service description to implement the binding before accessing that service.

OGC has developed a framework for defining specialized catalogues that support registration processes such as those described in ISO 19135: establishing, maintaining, and publishing registers of identifiers and meanings that are assigned to items of geographic information. The Catalog Service for the Web (CSW) – as defined in the OGC Catalogue Specification (CAT) – has been augmented by an ebRIM Information Model to establish an OGC framework for registration of geospatial information.

4.2.  Geospatial Portal and Clients

For users to achieve the value of geospatial data and services, user interfaces must exist that allow access. Portals have become a regular and familiar user interface to web-based users. Client applications hosted on user hardware continue to serve a large portion of the user community. Portal and application clients are discussed in this section.

The OGC Geospatial Portal Reference Architecture Discussion Paper was developed to assist the global geospatial technology community in implementing standards-based geospatial portal solutions. The document is a resource for rapid development and informed acquisition of portals and portal-exploiting applications that can plug and play with geospatial data and services in your organization and other organizations in your community and around the world.

A Web portal is a single point of access to information, which is linked from various logically related Internet-based applications and is of interest to various types of users. Portals present information from diverse sources in a unified way; they provide a consistent look and feel with access control and procedures for multiple applications, which otherwise would have been different entities altogether. Since all the applications share information through portals, there is better communication between various types of users. Another advantage of portals is that they can make event-driven campaigns.

The OWS Integrated Client Discussion Paper describes the core concept of providing a unified environment that allows a user to visualize, analyze, and/or edit data from numerous OGC Web Services simultaneously. An Integrated Client unifies common service discovery, feature production, imagery exploitation, portrayal management, processing, and sensor web enablement functionalities, and provides an environment for visualizing, analyzing and/or editing data from these sources/services.

Portals and application clients represent just the tip of geospatial Decision Support Services (DSS) which aim to provide interoperable access to distributed geospatial web services to aid decision makers in forming, analyzing, and selecting alternatives, see Figure 7. GeoDSS includes workflow management to produce context-specific results from information and knowledge from multiple communities. One objective of geospatial web services is to allow decision makers to access and use information that may have been collected for other purposes.

Figure 6 — GeoDSS Integrated OWS Client

4.3.  Multi-Tier Architectures

Services and data are packaged as components to define a deployment architecture. As an aid to managing the deployment, components can be classified into client, business process and access tiers (See Figure 7). Client tier components provide the user interface of the system. Business process tier components provide the mediation and processing functionality of the system. Access tier components offer persistent storage of data along with data acquisition and dissemination services. Figure 7 is an example of tiered architecture from the OGC Best Practice GIGAS Methodology for comparative analysis of information and data management systems.

Figure 7 — Service tiers in OWS architecture

4.4.  Spatial Data Infrastructures

OGC standards are key elements of the interoperability strategy of several Spatial Data Infrastructures (SDIs).

The SDI Cookbook, published by the GSDI, remarks that “SDI” is often used to denote the relevant base collection of technologies, policies and institutional arrangements that facilitate the availability of and access to spatial data. An SDI must be more than a single data set or database: an SDI hosts geographic data and attributes; sufficient documentation (metadata); a means to discover, visualize, and evaluate the data (catalogues and Web mapping); and some method to provide access to the geographic data.

The OGC Web Services Architectural Profile for the NSG describes how the various OGC specifications relate to the web service architecture implementation at the US National Geospatial-Intelligence Agency and the National System for Geospatial-Intelligence (NSG). The document enables organizations that interface with the NSG to understand how to produce and consume data and services in an interoperable environment.

GeoConnections helps decision-makers “use online location-based (or “geospatial”) information, such as maps and satellite images, to tackle some of Canada’s most pressing challenges.” GeoConnections strongly advocates the use of standards endorsed for the Canadian Geospatial Data Infrastructure (CGDI) to achieve interoperability for richer and more useful information than a single data set can provide. GeoConnections was an early supporter of WMS development and was an early adopter of the WMS standard. Recently the OGC Canadian Geospatial Data Infrastructure WFS and GML gives guidelines and recommendations for administrators, users and implementers of WFS serving GML-encoded response documents. This OGC document is applicable to the design, implementation and operation of Web Feature Service networks.

The Directive of the European Parliament and Council establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) directs Member States to establish and operate a network of services for discovery, viewing, and transformation. The services are to be easy to use, available to the public and accessible via the Internet. Implementation of the directives by the European Commission is proceeding with significant uptake of OGC standards envisioned.

The GEOSS 10 Year Plan, published by the Group on Earth Observations, states that to enable implementation of the GEOSS architecture, GEOSS will draw on existing Spatial Data Infrastructure (SDI) components as institutional and technical precedents in areas such as geodetic reference frames, common geographic data, and standard protocols. The GEO Architecture Implementation Pilot is defining and deploying the GEOSS Core Architecture for exchange and dissemination of observations including considerable uptake of OGC web services.

The OGC Federated Earth Observation Missions (FedEO) Pilot Discussion Paper describes the application of OGC services to Earth Observation. The FedEO Pilot was conducted in conjunction with and in support of the GEOSS Architecture Implementation Pilot. The FedEO pilot used and extended the GEOSS Architecture with additional services, e.g., Product Programming, Service Orchestration, Processing Services, Orthorectification and Reprojection Services and Order Service.

4.5.  Sensor Webs

The OGC Sensor Web Enablement Architecture Best Practice provides a description of the general architecture that applies to SWE. The Sensor Web is a revolutionary concept towards achieving a collaborative, coherent, consistent, and consolidated sensor data collection, fusion and distribution system. It can be viewed as a new breed of Internet for monitoring spatio-temporal phenomena appearing in the physical environment in real time.

The Sensor Web represents a meta-platform that integrates arbitrary sensors and sensor networks; each maintained and operated by individual institutions (Figure 8). The architectural design of the Sensor Web allows the integration of individual sensors as much as the integration of complete sensor systems without the need of fundamental changes to the legacy systems.

Figure 8 — Sensor Web: Aggregation of Sensor Networks

The retrieval and processing of sensor data, but also the management of sensor devices (i.e. tasking), is often carried out by means of distributed software entities that interoperate via the Internet. At its stage of completion, billions of sensors will be connected and produce georeferenced observation data. Every single sensor provides a small mosaic stone that helps us to generate a consolidated view of the world, to get a better understanding of the past, present, and future situation of our planet as well as active processes and correlations.

The Specification of the Sensor Service Architecture (SensorSA) – OGC Discussion Paper – presents specifies the SWE-based architecture used in the Sensors Anywhere (SANY) Project. The document describes a generic service-oriented architecture integrating the access to, the management and the processing of sensor-related information based on OGC standards and resulting from the requirements analysis of diverse application domains such as maritime risk management, observation of geo-hazards and monitoring of air quality.

4.6.  Earth Observation

Profiles of multiple OGC standards have been developed to support Earth Observations:

• Catalogue Services 2.0 EP for ebRIM Application Profile: EO Products Standard

• GML 3.1.1 Application Schema for EO products Best Practice

• Web Map Services — Application Profile for EO Products Best Practice

• Ordering Services for Earth Observation Products Best Practice

• User Management for Earth Observation Services Best Practice

• Sensor Planning Service Application Profile for EO Sensors Best Practice

• (WCS Earth Observations Profile – currently under development)

Several of these documents were developed within ESA’s Heterogeneous Mission Accessibility (HMA) project. For more information see for example, the OGC Federated Earth Observations (FedEO) Pilot Engineering Report.

4.7.  Geoprocessing Workflows

OGC has implemented workflow and service chaining beginning with the first OGC Web Services Testbed. The OWS-6 Geoprocessing Workflow Architecture Engineering Report provides a summary of past Geoprocessing Workflow implementations and methods in SOA environments from OWS testbeds and other implementations. The ER also summarizes the key developed concepts for deploying Geoprocessing Workflows using OGC and other standards.

Geoprocessing Workflows integrate data and services in an interoperable way, where each part of the workflow is responsible for only a specific task, without being aware of the general purpose of the workflow. Due to the distributed nature of geographic data, geoprocessing workflows provide flexible means of processing highly distributed and complex data for a wide variety of uses. Figure 9 shows the process of creating and executing a workflow composition. Several technologies, e.g., BPEL, are available for the composition and execution of workflows. OGC services are used in workflows. WPS can be used to encapsulate a workflow hiding the details.

Figure 9 — Composition and Execution of a Workflow

4.8.  Data Fusion

Making new connections in existing data is a powerful method to gain understanding of the world. Data fusion in distributed information environments with interoperability based on open standards is radically changing the classical domains of data fusion while inventing entirely new ways to discern relationships in data with little structure. The OGC Fusion Standards Study, Phase 2 Engineering Report summarizes two phases of the OGC Fusion Standards study and of fusion prototypes developed during the OWS-7 and OWS-8 Testbeds.

Three categories were used to organize the OGC Data Fusion study: Observation (sensor) fusion, Object/Feature fusion, and Decision fusion. The study considered classical fusion as exemplified by the JDL and OODA models as well as how fusion is achieved by new technology such as web-based mash-ups and mobile Internet. The study considers both OGC standards, e.g., WPS, as well open standards from other standards organizations.

The SANY Fusion and Modelling Architecture – an OGC Discussion Paper – reports the SANY project’s best practice for using OGC standards to provide generic fusion processing services. Concrete case studies are documented and a detailed appendix is provided with example of XML request and responses.

4.9.  Building Information Modeling and Services

The Architecture, Engineering, Construction, Owner, Operator, Phase 1 (AECOO-1) Testbed developed and implemented methods to streamline communications between parties in the conceptual design phase to get an early understanding of the tradeoffs between construction cost and energy efficiency. To that end, the project developed the interoperability components required for these analyses in collaborative team settings. These were Information Delivery Manuals (IDMs) for quantity takeoffs and energy analysis business processes, and used these to define Model View Definitions (MVDs)—standards-based subsets of Industry Foundation Classes (IFCs). AECOO-1 was conducted in response the felt need that overall productivity loss and fragmentation in the capital facilities development industries is no longer tolerable. All stakeholders need to practice the best way they know, and practice profitably; software interoperability problems must not hold them back. Non-interoperable software and data is cause for loss of competition across the market. For more information see: Summary of the Architecture, Engineering, Construction, Owner, Operator Phase 1 (AECOO-1) Joint Testbed

4.10.  Events Architecture: publish/subscribe

The OWS-7 Event Architecture Engineering Report addresses realization of an Event-Driven Spatial Data Infrastructure (ED-SDI). An ED-SDI is a traditional SDI where services and clients also communicate by means of events. This leads to improved activity of the whole infrastructure which is important if timely communication of information is critical – which is the case for example in aviation and emergency response scenarios. A major part of this report is concerned with a common approach on publish/subscribe for OGC Web Services. [Note: a Pub/Sub Standards Working Group is currently in process in OGC based on this ER and other activities.] The ER provides an abstract model for pubsub in OWS. Then functional requirements are developed based upon the model. Finally, a mapping is performed for a given publish / subscribe technology which shows how well the technology supports the requirements.

4.11.  Securing OGC Web Services

OGC Web Services can be secured with information technology standards developed by other standards organizations. The following reports describe several implementations.

The OWS-4 Trusted Geo Services Interoperability Program Report describes the exchange of trusted messages between OGC Web Services and clients for these services. The document addresses the service protocol, service request, chaining with other services and service response required to form a complete trusted services chain.

The OWS-6 Security Engineering Report describes work accomplished during the OWS-6 Testbed to investigate and implement security measures for OGC web services. The document offers insight into ways to apply existing security standards from W3C, OASIS, and others with the architecture of OGC web services and standards.

The OWS-6 Secure Sensor Web Engineering Report applies standards-based security solutions for making the OGC SWE services ready for handling of sensors in the intelligence domain. This brings in the requirement for handling sensors that eventually produce classified information and the main objective of accreditation.

The OGC Authentication Interoperability Engineering Report presents results as guidance to both implementers and organizations deploying solutions that involve basic authentication. The OGC Authentication Interoperability Experiment (Auth IE) tested and documented ways of transferring basic authentication information between OGC clients and OGC services.

The OWS-7 Towards secure interconnection of OGC Web Services with SWIM Engineering Report provides guidance to properly enable security in the near future such that a seamless, interoperable but secure interconnection between OGC Web Services and FUSE ESB technology stack as selected by use in the System Wide Information Management (SWIM) System of the US Federal Aviation Administration (FAA) can be achieved.

5.1.  OGC Compliance Test Program

The purpose of the OGC Compliance Testing Program is to permit vendors and users to take advantage of the standards that OGC has created. The program provides a process for testing compliance of products to OpenGIS® Implementation Specifications.

When a vendor has completed compliance testing and OGC has confirmed its successful completion, vendors who agree to the terms of the OGC Trademark License Agreement that accompanies this program, and who have paid their trademark license fees, may use OGC’s marks (trademarks or certification marks) to indicate to their customers that they have achieved compliance with OpenGIS Implementation Specifications.

The OGC Compliance Testing Portal is the home of the OGC’s on-line compliance testing resources. The portal provides test scripts in an automated test environment for the adopted OGC Standards for OGC web services. In addition, the OGC provides a tool to validate Geography Markup Language (GML). If you want to try out compliant software, take a look at the Reference Implementations as open-source applications.

The Compliance Test engine is an open-source application allowing integrators and software developers to host the compliance test tools in their own development laboratories. Although only tests performed at the OGC compliance site can be used as the basis for certification, organizations find it valuable to perform the same tests in their labs to support development and integration. Compliance Test Language (CTL) Best Practice is an XML grammar for documenting and scripting suites of tests for verifying that an implementation of a specification complies with the specification.

Previously developed off-line Compliance Test Suites for download include: Catalog Service Interface 1.0, Coordinate Transformation 1.0, Gridded Coverages 1.0, Simple Features SQL 1.1, Simple Features COM 1.1, Simple Features CORBA 1.0. Those suites are hosted on the OGC site.

In addition, OGC provides on-line tools for GeoRSS, Geography Markup Language (GML) 2.1.2, and Web Map Context (WMC) 1.1.0 validation. These validation tools are not associated with official OGC Compliance Certification and are simply provided as a community resource.

5.2.  Registered Implementations

Implementations of OGC Specifications can be registered on the OGC website including those that have been certified OGC Compliant. The lists of Compliant and Implementing Products identify publicly available products and services that either implement or have been tested Compliant to OpenGIS Specifications. You may also Register Your Products at this site.

5.3.  OGC Network, Cookbooks and Demos

The OGC Network™ is a window onto the dynamic, constantly changing geospatial web. Here you will find the latest information on OGC-compatible software, services, and information models (e.g. GML profiles, SLD examples, etc.). From this site you can quickly locate OGC-compatible geospatial web services, the latest XML schema documents, discussion forums, conformance testing resources, and GML profile working areas. OGC Cookbooks are free, online, easy-to-use technical documents for developers. On-line demonstrations of OGC specifications and interoperable software are available from previous OGC Interoperability Program initiatives.

5.4.  Strategic implementations of OGC Standards