Source: http://rap.opengeospatial.org/orm.php
Timestamp: 2016-12-04 14:12:57
Document Index: 407805811

Matched Legal Cases: ['art 1', 'art 1', 'art 2', 'art 3', 'art 6', 'art 1', 'art 2', 'art 1']

OGC 08-062r7
Document Type: Informative/Educational
Reference number: OGC 08-062r7
External Reference Identifier: http://www.opengis.net/doc/orm/2.1
Copyright © 2011 Open Geospatial Consortium To obtain additional rights of use, visit http://www.opengeospatial.org/legal/.
This document is not an OGC Standard. This document is provided as an educational description of the standards work of the OGC. This document is subject to change without notice and may not be referred to as an OGC Standard. Please do not specify this document as mandatory or normative in procurements or policy. This is an informative document.
Permission is hereby granted by the Open Geospatial Consortium, Inc. (“Licensor”), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
The OGC Reference Model (ORM) describes the OGC Standards Baseline focusing on relationships between the baseline documents. The OGC Standards Baseline (SB) consists of the approved OGC Abstract and Implementation Standards (Interface, Encoding, Profile, and Application Schema – normative documents) and OGC Best Practice documents (informative documents).
What is the purpose of the ORM?
To provide an overview of OGC Standards Baseline;
To provide insight into the current state of the work of the OGC;
As a basis for coordination and understanding of the documents in the OGC SB;
To provide a useful resource for defining architectures for specific applications.
To better understand the OGC Standards Baseline;
To better understand the ongoing work of the OGC;
To gain an understanding necessary to make contributions to the OGC process;
To aid in implementing one or more of the OpenGIS Standards.
Interested in an overview of the consortium? – See Section 1.
Interested in the geospatial information standards? – See Section 2.
Interested in geospatial service standards? – See Section 3.
Interested in OGC-based development patterns? – See Section 4.
Interested in implementations of OGC-based systems? – See Section 5.
The ORM contains numerous links to OGC resources. For more detail on any topic be sure to select the link and access the detailed information. For example, definitions of terms used in the ORM are available in the on-line OGC Glossary
The ORM provides just an overview of the results of extensive development by hundreds of OGC Member Organizations and tens of thousands of individuals who have contributed to the development of the OGC Standards Baseline. A revision history of the ORM is provided at the end for the document.
1.2 An Example: Web Map Service
1.4 The OGC Programs
1.5 OGC Standards and Other Documents
2.1 Geospatial Information Is Fundamental or Everything is somewhere
2.2 Information Specifications
2.4 Maps, KML, and PDFs
2.7.1 The GML Standard
2.7.2 Profiles of GML
2.7.3 GML Application Schemas
2.7.4 CityGML
2.7.5 Binary encoding of XML
2.8 Sensor Web Enablement Information 2.8.1 OGC SWE Standards
2.8.2 Observations and Measurements
2.8.3 SensorML
2.8.4 SWE Common Data Model
2.9 NetCDF
2.10 Units of Measure
2.11 Geographic Metadata
2.12 GeoDRM
2.13 GeoXACML
2.14 OGC Schema Repositories
2.15 OGC Naming Authority
3.2 OGC Web Services 3.3 OWS Web Mapping Services
3.4 OWS Data Access services
3.4.1 Web Feature Service
3.4.2 Web Coverage Service
3.4.3 Web Coverage Processing Service
3.4.4 Filter Encoding 3.4.5 Table Joining Service
3.4.6 GeoRSS
3.5 Catalogue Service for the Web
3.6 Processing Services and Service Chaining
3.7 Sensor Web Enablement (SWE) Services
3.8 Location-Based Mobile Services
3.8.1 Open GeoSMS
3.8.2 OpenLS
3.9 Fine-Grained Services
4.6 Earth Observation
4.7 Geoprocessing Workflows
4.8 Data Fusion
4.9 Building Information Modeling and Services
4.10 Events Architecture: publish/subscribe
4.11 Securing OGC Web Services
5.3 OGC Network, Cookbooks and Demos
5.4 Strategic implementations of OGC Standards
5.4.1 GEOINT Standards managed by NGA
5.4.2 FGDC/USGS
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 TypesOGC Document TypeDescriptionOpenGIS Implementation StandardA document containing an OGC consensus, technology dependent standard for application programming interfaces and related standards based on the Abstract Specification or domain-specific extensions to the Abstract Specification. There are five subtypes: Interface, Encoding, Profile, Application Profile, and Application Schema.Abstract SpecificationA document (or set of documents) containing an OGC consensus, technology-independent standard for application programming interfaces and related standards based on object-oriented or other IT accepted concepts. It describes and/or models an application environment for interoperable geoprocessing and geospatial data and services products.Best PracticesA document containing discussion related to the use and/or implementation of an adopted OGC document. Best Practices Documents are an official position of the OGC and thus represent an endorsement of the content of the paper.Engineering ReportsDocuments that are a primary output of OGC Interoperability Program Initiatives (testbeds, pilot projects and interoperability experiments). ERs represent consensus positions of the initiative participants and sponsors only. ERs become a publicly available document by consensus motion of the Standards Program. An ER does not represent the official position of the OGC nor of the OGC Technical Committee.Discussion PapersA document containing discussion of some technology or standard area for release to the public. Discussion Papers are not the official position of the OGC and contain a statement to that effect.White PapersA publication released by the OGC to the Public that states a position on a social, political, technical or other subject, often including a high-level explanation of an architecture or framework of a solution.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 Geospatial Information
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:Civic locations using geographic terms or identifiers;Coordinates as numeric values in a coordinate reference system.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 Section 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 existing 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 Section 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 Section 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
The OpenGIS® Geography Markup Language (GML) Encoding Implementation Standard is an XML grammar to express geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet. The GML information model is based on the ISO 19100 series of International Standards and the OGC Abstract Specification. In addition, GML provides XML encodings for additional concepts not yet modeled in the ISO 19100 series of International Standards or the OpenGIS Abstract Specification, for example, dynamic features, simple observations or value objects.GML defines the XML Schema syntax, mechanisms and conventions that:Provide an open, vendor-neutral framework for description of geospatial application schemas for the transport and storage of geographic information in XML;Allow profiles that support proper subsets of GML framework descriptive capabilities;Support the description of geospatial application schemas for specialized domains and information communities;Enable the creation and maintenance of linked geographic application schemas and datasets;Support the storage and transport of geospatial application schemas and datasets;Increase the ability of organizations to share geographic application schemas and the information they describe.Implementers may decide to store geographic application schemas and information in GML, or they may decide to convert from some other storage format on demand and use GML only for schema and data transport.The requirements of an application schema determine the XML Schema components from the GML schema to be included in a GML profile. GML defines a variety of conformance classes that apply depending upon the content of a specific profile. Examples of GML Conformance Classes for GML Profiles are shown in Table 2. See the GML standard for the full list.Table 2  Examples of Conformance Classes for GML ProfilesGeometric primitives: 0, 1, 2 or 3 dimensionsCoordinate reference systemsTopologic complexes: 0, 1, 2 or 3 dimensionsCoordinate operationsTemporal geometry  0 or 1 dimensionsTemporal reference systemsTemporal topologyDictionariesDynamic featuresUnits dictionariesObservationsAbstract coverageDiscrete point coverageDiscrete curve coverageDiscrete surface coverageDiscrete solid coverageGrid coverageContinuous coverage 2.7.2 Profiles of GML
To promote broad use of GML, the OGC has defined several profiles of GML. In the OGC, a GML profile is a restricted subset of the full GML standard.GML ProfileDocument TypeGML Simple Features profileStandardGML Common CRSs profileStandardGML CRS support profileStandardGML Grid CRSs profileStandardGML Simple dictionary profileStandard 2.7.3 GML Application Schemas
Designers of GML application schemas may extend or restrict the types defined in the GML schema to define appropriate types for an application domain. GML application schemas use applicable GML schema components, either directly or by specialization, and are valid in accordance with the rules for XML Schema. The OGC membership has approved a number of GML Application Schema as Standards and Best Practices:GML Application SchemaDocument TypeCityGMLStandardGML Application Schema - Coverages (1.0)StandardMoving Object Snapshot (adoption pending)StandardGML Application schema for Earth Observation productsStandardGML PIDF-LO Geometry Shape Application Schema for use in the IETFBest PracticeGML Encoding of Discrete Coverages (interleaved pattern)Best PracticeOGC maintains an informal list of all known GML Application Schemas. These schemas are not necessarily approved or endorsed by the OGC. 2.7.4 CityGML
The OpenGIS City Geography Markup Language (CityGML) Encoding Standard provides for the representation, storage and exchange of virtual 3D city and landscape models. CityGML models both complex and georeferenced 3D vector data along with the semantics associated with the data. In contrast to other 3D vector formats, CityGML is based on a rich, general-purpose information model in addition to geometry and appearance information. For specific domain areas, CityGML also provides an extension mechanism to enrich the data with identifiable features under preservation of semantic interoperability.Targeted application areas explicitly include urban and landscape planning; architectural design; tourist and leisure activities; 3D cadastres; environmental simulations; mobile telecommunications; disaster management; homeland security; vehicle and pedestrian navigation; training simulators and mobile robotics. 2.7.5 Binary encoding of XML
The Binary Extensible Markup Language (BXML) Encoding Specification Best Practice specifies a binary encoding format for the efficient representation of XML data, especially scientific data that is characterized by arrays of numbers. This encoding format is applicable to any application that uses XML format. 2.8 Sensor Web Enablement Information 2.8.1 OGC SWE Standards
With sensors of all types becoming part of the global information infrastructure, the OGC has approved Standards and Best Practices designed to enable sensors to better interoperate with the Web and other information technology assets. The OGC Sensor Web Enablement (SWE) is a set of interfaces and protocols that enable a Sensor Web through which applications and services will be able to access sensors of all types over the Web. Foundational components for Sensor Web Enablement have defined, prototyped and tested:Observations & Measurements (O&M) StandardSensor Model Language (SensorML) StandardSWE Common Data Model StandardSensor Observation Service (SOS) StandardSensor Planning Service (SPS) StandardSensor Alert Service (SAS) Best PracticeWeb Notification Service (WNS) Best PracticeThe first three standards are described immediately following. The SWE service standards are described in Section 3.7. 2.8.2 Observations and Measurements
The OGC Observations & Measurements(O&M) standard, also published as ISO 19156, defines a conceptual schema for observations, and for features involved in sampling when making observations. An observation is an act at a discrete instant or period, through which a number or term is assigned to a phenomenon using a procedure, such as a sensor, instrument, or algorithm. Observations commonly involve sampling of an ultimate feature of interest. The O&M Standard defines a set of sampling feature types classified primarily by topological dimension.OGC Observations and Measurements - XML Implementation provides an XML implementation for the OGC Observations and Measurements (O&M) conceptual model including a schema for Sampling Features. This encoding is an essential dependency for the OGC Sensor Observation Service (SOS) Interface Standard. More specifically, this standard defines XML schemas for observations, and for features involved in sampling when making observations. These provide document models for the exchange of information describing observation acts and their results, both within and between different scientific and technical communities. 2.8.3 SensorML
The OGC Sensor Model Language (SensorML) Implementation Standard provides a framework within which the geometric, dynamic, and observational characteristics of sensors and sensor systems can be defined. SensorML enables robust definitions of sensor models for providing geolocation of observations from remote sensors. Different mathematical models can be designed to define a sample location within a variety of coordinate systems, including the local sensor frame, the local frame for the associated platform, or a geographic coordinate reference frame. These can all be supported through the definition of atomic process models and process chains. Within SensorML, all processes and components are encoded as application schema of the Feature model in the Geographic Markup Language (GML) Version 3.1.1. 2.8.4 SWE Common Data Model
The OGC SWE Common Data Model Encoding Standard defines low-level data models for exchanging sensor related data between nodes of the SWE framework. These models allow applications and/or servers to structure, encode and transmit sensor datasets in a self-describing and semantically enabled way. The SWE Common Data Model is intended for describing static data (files) as well as dynamically generated datasets. All categories of sensor observations are in scope ranging from simple in-situ temperature data to satellite imagery and full motion video streamed out of an aircraft. 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 WMSRepository 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 Geospatial Services
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:WMS ProfilesDocument TypeStyled Layer Descriptor Profile of WMSStandardWeb Map Service - Application Profile for EO ProductsBest PracticeDGIWG WMS 1.3 Profile and systems requirements for interoperability for use within a military environmentBest PracticeThe 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 Section 2.4) 3.4 OWS Data Access services
The OpenGIS Web Feature Service (WFS) Implementation Specification, also published as ISO 19142, allows a client to retrieve and update geospatial data encoded in Geography Markup Language (GML) from multiple Web Feature Services. The specification defines interfaces for data access and manipulation operations on geographic features. Via these interfaces, a Web user or service can combine, use and manage geodata from different sources. A Transactional WFS (WFS-T) includes an optional Transaction operation to insert, update, or delete a feature.The OGC Gazetteer Service Best Practices Document defines an Application Profile of the WFS Implementation Standard by specifying a minimum set of Feature Types and operations required to support an instance of a gazetteer service. The information model of the standard is a GML application schema that defines a general feature type to be served by a Gazetteer Service. 3.4.2 Web Coverage Service
The OpenGIS Web Coverage Service (WCS) Implementation Specification supports electronic retrieval of geospatial data as coverages  that is, digital geospatial information representing space/time-varying phenomena. WCS provides access to coverage data in forms that are useful for client-side rendering, as input into scientific models, and for other clients.Similar to WMS and WFS, WCS allows clients to choose portions of a servers information holdings based on spatial constraints and other query criteria. Unlike WMS, WCS defines a rich syntax for requests against Coverages; and returns data with its original semantics (instead of pictures) that may be interpreted, extrapolated, etc., and not just portrayed. Unlike WFS, WCS focuses on coverages as a specialized class of features with correspondingly streamlined functionality.As described in the WCS 2.0: Core and Extensions Best Practice, WCS 2.0 consists of a set of normative specifications, collectively referred to as the WCS suite:WCS 2.0 Interface Standard - CoreGML 3.2 Application Schema for WCSA set of extensions to the WCS Core: KVP Protocol Binding Extension XML/SOAP Protocol Binding Extension XML/POST Protocol Binding Extension 3.4.3 Web Coverage Processing Service
The OpenGIS Web Coverage Processing Service (WCPS) defines a language for retrieval and processing of multi-dimensional geospatial coverages representing sensor, image, or statistics data. The WCPS language is independent from any particular service. In a separate document, WCPS has been defined as an extension of the WCS adding a ProcessCoverages operation to form requests of arbitrary complexity allowing, e.g., multi-valued coverage results. 3.4.4 Filter Encoding The OpenGIS Filter Encoding (FE)Implementation Standard, also published as ISO 19143, describes an XML and KVP encoding of a system neutral syntax for expressing projections, selection and sorting clauses collectively called a query expression. FE can be used with a number of OGC web services. For example, WFS may use FE in a GetFeature operation. 3.4.5 Table Joining Service
The OpenGIS Georeferenced Table Joining Service (TJS) Implementation Standard offers a way to expose data that contains geographic identifiers but does not contain geographic referencing by coordinates. The geographic identifiers are defined in a spatial framework that partitions the surface of the earth into a set of management units, e.g., postal codes. TJS allows the data to be accessed and merged with spatial coordinates from the framework, in order to enable mapping or geospatial analysis. 3.4.6 GeoRSS
GeoRSS (Geographically Encoded Objects for RSS feeds) is a proposal for geo-enabling, or tagging, really simple syndication (RSS) feeds with location information. There are two GeoRSS serializations: GeoRSS GML and GeoRSS Simple. GeoRSS GML is a formal GML Profile, and supports a greater range of features than GeoRSS Simple, notably coordinate reference systems other than WGS84 latitude/longitude. Additional information can be found in the OGC White Paper: An Introduction to GeoRSS. 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.CSW ProfileDocument TypeCatalogue Services Specification 2.0.2 - ISO Metadata Application ProfileStandardCSW-ebRIM Registry Service - Part 1: ebRIM profile of CSWStandardCSW-ebRIM Registry Service  Part 2: Basic extension packageStandardCSW-ebRIM Registry Service  Part 3: Abstract Test SuiteStandardCatalogue Services Standard 2.0 Extension Package for ebRIM Application Profile: Earth Observation ProductsStandardFGDC CSDGM Application Profile for CSW 2.0 Best PracticeThe 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
The OpenGIS Open GeoSMS standard defines an encoding for location enabling the Short Message Service. SMS is a communication service for phone, web or mobile communication systems that provides exchange of short text messages between fixed line or mobile phone devices. The OGC Open GeoSMS encoding standard facilitates communication of location content using the extended SMS devices or applications for achieving interoperable communications while still maintaining human readability of the content. 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: 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. 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. 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. Presentation Service. Creates maps and other graphic depictions of selected geospatial data, with a set of ADTs as logical layers. 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 Reusable Patterns for Deployment
Previous sections defined the information and services standards that serve as building blocks for deployments. To support reusable deployments several patterns are defined that use the OGC standards in ways that accomplish many typical tasks. 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 PatternIn 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. Figure7  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 NetworksThe 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 ProductsStandardGML 3.1.1 Application Schema for EO products Best PracticeWeb Map Services - Application Profile for EO Products Best PracticeOrdering Services for Earth Observation Products Best PracticeUser Management for Earth Observation Services Best PracticeSensor 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 Implementations of OGC Standards
OGC standards have been implemented through several activities as described below. 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
The US National System for Geospatial Intelligence (NSG) is the combination of technologies, policies, capabilities, doctrine, activities, people, data and communities needed to produce geospatial intelligence (GEOINT) in an integrated, multi-intelligence, multidomain environment. GEOINT is defined as the exploitation and analysis of imagery and geospatial information to describe, assess, and visually depict physical features and geographically referenced activities on the Earth. GEOINT consists of imagery, imagery intelligence, and geospatial information.The GEOINT Standards Working Group (GWG) provides the forum for the coordination of GEOINT standard activities. The GWG is led by the National Geospatial-Intelligence Agencys (NGA) National Center for Geospatial Intelligence Standards (NCGIS). Through the GWG, NGA has collaboratively defined a common baseline of standards including many OGC as described in Enabling a Common Vision.The GWG manages GEOINT standards lifecycle recommendations for developing and promoting standards interoperability in support of net-centricity. NGA and the geospatial community are well positioned to achieve coordinated implementation of these standards  the result will not only be enhanced interoperability, but also the ability to, at the lowest tactical level, return value-added content from the warriors on the front lines for re-use by others. 5.4.2 FGDC/USGS
The US Federal Geographic Data Committee (FGDC) is an interagency committee that promotes the coordinated development, use, sharing, and dissemination of geospatial data on a national basis. FGDC activities are administered through the FGDC Secretariat, hosted by the U.S. Geological Survey (USGS).The partner agencies of FGDC are developing the Geospatial Platform to more effectively provide place-based products and services to the American public. Through the FGDC, the Geospatial Platform will adopt and enforce open and interoperable standards to leverage the work already accomplished by national and international standards organizations including OGC Web Services (features, map, processing, coverage, etc.), Location Services, Metadata, Registries, Data Quality and other applicable standards specifically dealing with geospatial data. 5.4.3 NASA
The US National Aeronautics and Space Agencys Earth Science Technology Office (ESTO) demonstrates and provides technologies that can be reliably and confidently applied to a broad range of science measurements and missions as well as facilitate practical applications that benefit society at large. ESTO developments in advanced information systems are used to process, archive, access, visualize, and communicate science data. ESTO has sponsored several implementations of OGC standards including the following.The NASA SensorWeb is an interoperable environment for a diverse set of satellite sensors via the use of software and the Internet. This capability can be used to better understand physical phenomena, such as volcanic eruptions, fires and floods. Furthermore, it facilitates science investigation since it becomes much easier to enlist existing satellite, airborne and ground sensors for required observations. The NASA SensorWeb Architecture implements multiple OGC Standards. Revision history
Initial version of ORM. Doc OGC - George Percivall, Sam Bacharach, Carl Reed, Cliff Kottman, Chuck Heazel, John Davidson, Yaser Bisher, Harry Niedzwiadek, John Evans, Jeffrey Simon
Approved and published in public OGC baseline
Unpublished HTML version: http://ormdev.opengeospatial.org/ Contributors: Chuck Heazel, Carl Reed, Ron Fresne, Phillip Dibner, Josh Lieberman, John Davidson, Lew Leinenweber, Raj Singh
08-062r4
Approved by OAB and published in public OGC baseline - Contributors: Carl Reed, Lew Leinenweber, Chris Tucker, Tina Cary
2.1 (draft)
08-062r5
Final draft of version 2.1 including all changes to the OGC Baseline since version 2.0.
08-062r7
Implemented comments by the OGC Architecture Board (OAB) members including: F. Houbie, M. Botts, A. Matheus, J. Herring. - Approved by OAB for release.
“We are so bound together that no man can labor for himself alone. Each blow he strikes in his own behalf helps to mold the Universe.”Jerome K Jerome, 1886
“Wisdom is knowing what to leave out”William James, 1890