SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
|
| News: Cover Stories |  |  |
| OGC Public Review for GeoXACML and OpenGIS Image Geopositioning Service (IGS). |
Contents
The Open Geospatial Consortium announced a call for public comment on two draft OpenGIS Implementation Specifications: GeoXACML and OpenGIS Image Geopositioning Service (IGS).
OGC Implementation Specifications are different from the OGC Abstract Specification, consisting of a core collection of documents that provide a reference model for the development of OpenGIS Implementation Specifications. The Implementation Specifications "are written for a technical audience, and detail the interface structure between software components. An interface specification is considered to be at the implementation level of detail if, when implemented by two different software engineers in ignorance of each other, the resulting components plug and play with each other at that interface. The Abstract Specification provides the conceptual foundation for most OGC specification development activities. Open interfaces and protocols are built and referenced against the Abstract Specification, thus enabling interoperability between different brands and different kinds of spatial processing systems.
Geospatial Extensible Access Control Markup Language (GeoXACML)
The draft Geospatial Extensible Access Control Markup Language (GeoXACML) Implementation Specification defines a geo-specific extension to the Extensible Access Control Markup Language (XACML) OASIS Standard. XACML "defines a core schema and corresponding namespace for the expression of authorization policies in XML against objects that are themselves identified in XML. There are many proprietary or application-specific access control policy languages, but this means policies cannot be shared across different applications, and provides little incentive to develop good policy composition tools. Many of the existing languages do not support distributed policies, are not extensible, or are not expressive enough to meet new requirements. XACML enables the use of arbitrary attributes in policies, role-based access control, security labels, time/date-based policies, indexable policies, 'deny' policies, and dynamic policies — all without requiring changes to the applications that use XACML."
The Extensible Access Control Markup Language (XACML), as defined in the OASIS standard, allows establishing an Access Control System which can be used to manage access for Service Oriented Architectures. In that sense, it can be used with limitations to protect geographic information by the declaration of rights through the specified Policy Language. The limitations are based on the fact, that XACML does not have the capabilities to express geo-specific constraints on access rights, as it is relevant for managing access to geographic information.
The OGC GeoXACML draft clarifies that access control systems enable management of access to information only until it is obtained by the user and stored locally, as opposed to rights management systems that remain in force regardless of where the content of the original resource is located or reproduced. Attention is therefore drawn to the point that the document defines a Policy Language in the context of access control, and not a Rights Expression Language, typically used to enforce usage rights in the context of Digital Rights Management.
The GeoXACML specification is thus not meant to be an implementation specification in regard to the Geospatial Digital Rights Management Reference Model (GeoDRM RM). GeoDRM RM is an abstract specification for the management of digital rights in the area of geospatial data and services, being Topic 18 of the OpenGIS Abstract Specification. The GeoDRM RM "defines the framework for web service mechanisms and rights languages to articulate, manage and protect the rights of all participants in the geographic information marketplace, including the owners of intellectual property and the users who wish to use it. A key aspect of the GeoDRM RM is that it is abstract, or general, rather than specifying implementation details about types of agreements. Such agreements might range from an open content sharing model to a cost-recovery program of a public or government organization or a full commercial vendor license model."
The GeoXACML geospatial extension to the XACML Policy Language is based on the extensibility points; it defines geometry Attribute Values, testing functions for topological relationship between geometries, and OpenGIS Web Service and CRS-specific specific Resource Attribute Designators. Modifications of the XACML schemas are not required. GeoXACML uses the same Policy Language as XACML does. However, a GeoXACML Policy may include specific Attribute Value Elements and Condition Functions, which are defined in GeoXACML only. Therefore a PDP, supporting GeoXACML Policies is capable to also perform authorization decisions on XACML policies; the opposite is not true.
OpenGIS Image Geopositioning Service (IGS)
The second OGC draft released for public comment is the OpenGIS Image Geopositioning Service (IGS) Draft Implementation Specification. This document defines an Image Geopositioning Service (IGS) interface to services that perform triangulation. This service is a specific Sensor geometry model adjustment service, as listed in Subclause 8.3.5.2 of ISO 19119 and OGC Abstract Specification Topic 12. This service might alternately be named Image Triangulation Service, Image Registration Service, or Image Adjustment Service; suggested additions, changes, and comments on this draft are welcome and encouraged.
Accompanying the IGS draft specification is a separate OpenGIS Image Geopositioning Metadata Geography Markup Language (GML) Draft Application Schema, which is structured to provide consistency between the IGS and other OGC Web Services (OWS) specifications.
The Image Geopositioning Service (IGS) is an OGC Web Service (OWS). Four phases of Web Service interoperability testing have been conducted. The most recent was OGC Web Services, Phase 4. The OGC Web Services, Phase 4 (OWS-4) Testbed was an initiative of OGC's Interoperability Program to collaboratively extend and demonstrate OGC's baseline for geospatial interoperability. The main development of OWS-4 was conducted from June to December 2006 with a number of important outcomes. Some fifty-nine (59) components were implemented and deployed in interoperability testing. Components were developed in 7 threads: Sensor Web Enablement (SWE); Geo Processing Workflow (GPW); Geo-Decision Support (GeoDSS); Geo-Digital Rights Management (GeoDRM); CAD / GIS / BIM (CGB); OGC Location Services (OpenLS); Compliance Testing (CITE). Each of these threads of activity extended or refined a portion of the OGC Standards Baseline. OWS-4 Participants conducted Technology Integration Experiments (TIEs) of the components, where each TIE involved components developed independently by at least two organizations. Thirty-six (36) Interoperability Program Reports (IPRs) were written. The OWS-4 IPRs were either technical specifications or reports regarding testing and analysis.Most of these will result in documents that will be posted for public review prior to the formal adoption of some of them as OGC standards.
The OGC 2007 follow-on activity to OWS-4 is OWS-5; OGC has issued a Request for Quotes/Call for Participation (RFQ/CFP) for the OGC Web Services, Phase 5 (OWS-5) Interoperability Initiative, a testbed to advance OGC's open geospatial interoperability framework. Based on sponsor requirements, the OWS-5 initiative is organized as six threads over two initiative phases: (1) Sensor Web Enablement (SWE), (2) Geo Processing Workflow (GPW), (3) Information Communities' Semantics (ICS), (4) Agile Geography, (5) Compliance Testing (CITE), (6) CAD/GIS/BIM. Significant work items include geospatial Web service chaining and workflow, enhancements to the XML-based KML language, practical application of the Sensor Web, and application of GML to real-world scenarios.
The OpenGIS Image Geopositioning Service (IGS) Draft Implementation Specification defines the interface to an Image Geopositioning Service that adjusts the georeferencing coordinate transformations of multiple images. This Image Geopositioning Service interface specifies two operations that can be requested by clients. The GetCapabilities operation allows a client to get server metadata. The Triangulate operation performs a triangulation, adjusting the parameter values of one or more image georeferencing coordinate transformations that are input with associated error statistics.
The associated OpenGIS Image Geopositioning Metadata GML 3.2 Application Schema for image geopositioning metadata "is an Application Schema of ISO 19139. This image geopositioning metadata is designed for use by a separately specified Image Geopositioning Service (IGS) that adjusts the georeferencing coordinate transformations of images. This schema can also be used by other future OGC Web Services. The XML schema encodes image georeferencing coordinate transformations with associated parameter error statistics. These georeferencing coordinate transformations can use many possible image geometry (or sensor) models that can be encoded using extensions of this Application Schema."
Geospatial Extensible Access Control Markup Language (GeoXACML)
Geospatial eXtensible Access Control Markup Language (GeoXACML). Edited by Andreas Matheus. Open Geospatial Consortium Inc. Date: 2007-03-22. Version: 0.3.0. OGC Project Document Reference Number: OGC 07-026. Category: OGC Implementation Specification. Document type: OGC Publicly Available Standard. 39 pages. Copyright © 2007 Open Geospatial Consortium, Inc. See also the .DOC format. OGC source.
Submitting organizations: The following organizations submitted this Implementation Specification to the Open Geospatial Consortium Inc. as a Request for Comment (RFC). [1] Universität der Bundeswehr München (Andreas Matheus, Werner-Heisenberg-Weg 39, D-85579 Neubiberg, Germany); [2] Galdos Systems Inc. (Ron Lake, 1300-409 Granville St, Vancouver V6C 1T2 Canada).
Draft Status: "This document is not an OGC Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation."
OpenGIS Image Geopositioning Service (IGS)
OpenGIS Image Geopositioning Service (IGS). Edited by Arliss Whiteside. Open Geospatial Consortium Inc. Date: 2007-05-10. Version: 0.0.3. OGC Project Document Reference Number: OGC 07-030r1. Category: OpenGIS Implementation Specification. Document subtype: OGC Web Service RFC. 50 pages. Copyright © 2007 Open Geospatial Consortium, Inc. See the ZIP file and file listing.
OpenGIS Image Geopositioning Metadata GML 3.2 Application Schema. Edited by Arliss Whiteside. Open Geospatial Consortium Inc. Date: 2007-05-10. Version: 0.0.3. OGC Project Document Reference Number: OGC 07-031r1. Category: OpenGIS Implementation Specification. Document subtype: GML Application Schema RFC. 79 pages. Copyright © 2007 Open Geospatial Consortium, Inc. See the ZIP file and file listing.
"The Policy Language introduced in this document defines a geo-specific extension to the XACML Policy Language, as defined by the OASIS standard Extensible Access Control Markup Language (XACML), Version 2.0. This document is not comprehensive by itself, because it defines an extension to an existing OASIS standard, as defined in Extensible Access Control Markup Language (XACML). It is therefore mandatory to use this document ONLY together with the OASIS XACML Standard...
Even though geographic information is often available for free, it might not always be unprotected. Requirements might come from the law, which requires a managed access to geographic information, independent from commercial aspects. However, commercial aspects might bring relevant requirements for protection as well.
In contrast to a persistent protection mechanism as it is defined by GeoDRM-RM to be a mechanism that remains in force regardless of where the content of the original resource is located or reproduced, an Access Control System allows to manage access to information, until it is obtained by the user and stored locally on her computer. Thinking of a service oriented Spatial Data Infrastructure, a GeoDRM System would manage the access at (i) the time the user accesses the geographic information on the service and (ii) the time afterwards, when the geographic information is stored somewhere else.
The limitations of an Access Control System are such that access can only is controlled at the time the user initiates a request to the service. After the (geographic) information has left the service, it is out of control and can not be managed any longer. However there is this distinctive difference between a (Geo)DRM and an Access Control System, requirements exist where the establishment of an Access Control System is sufficient.
The Extensible Access Control Markup Language (XACML) as defined in the OASIS standard allows establishing an Access Control System which can be used to manage access for Service Oriented Architectures. In that sense, it can be used with limitations to protect geographic information by the declaration of rights through the specified Policy Language. The limitations are based on the fact, that XACML does not have the capabilities to express geo-specific constraints on access rights, as it is relevant for managing access to geographic information....
The OpenGIS Abstract Specification does not require changes to accommodate this [GeoXACML] standard. Even though this document does not require the change of OGC specifications, it has influence to the OpenGIS Web Service Common Implementation Specification, because GeoXACML can be used to establish an Access Control Mechanism to protect the access to OpenGIS Web Services. In that sense, a OWS can reply with exceptions, currently not defined in the Common Implementation Specification.
The XACML standard can be separated into two main sections: (i) Policy Language and Authorization Model and (ii) Information Flow Model. The XACML Policy Language Model defines an XML encoding for expressing general purpose access restrictions and extension points to define your own Attribute Values, Functions, etc. The entire set of access restrictions defines an XACML Policy... The XACML Information Flow Model defines the architecture of a modular and distributed access control system. In addition, it defines the exchange of messages between the components and the structure of the messages...
The XACML Specification defines the non-normative extensibility points. For this specification, it is important to note that the 'DataType', 'FunctionId', and 'AttributeId' can be extended...
GeoXACML uses the same Policy Language as XACML does. However, a GeoXACML Policy may include specific Attribute Value Elements and Condition Functions, which are defined in GeoXACML only. Therefore a PDP, supporting GeoXACML Policies is capable to also perform authorization decisions on XACML policies; the opposite is not true...
OpenGIS Web Services specific ResourceAttributeDesignator: In order to protect access to OpenGIS Web Services, it is practicable to allow unique definition of the service and its operation that is to be protected. For this purpose this specification defines two optional ResourceAttributeDesignator elements: Service-Id and Operation-Id. The Service-Id <ResourceAttributeDesignator> is of type URI and can keep the URL of the service. The Operation-Id <ResourceAttributeDesignator> is of type URI and defines the operation of the service...
CRS-specific ResourceAttributeDesignator: In order to allow sufficient structuring of access rights, applicable to a specific Coordinate Reference Systems, GeoXACML defines an optional CRS Resource Attribute Descignator. This allows the policy administrator to maintain the same access rights for a OpenGIS Web Service that supports different CRSs by defining an early matching in the <Target> element vs. a late matching by a complex <Condition>...
OpenGIS Image Geopositioning Service (IGS): "For most applications of object (or ground) positions extracted from images, it is highly desirable to maximize the accuracy of those positions, by using georeferencing coordinate transformations that are as accurate as possible. In many cases, high relative accuracy is needed, with respect to positions previously or subsequently measured, in other images or by surveying (including by GPS). For many of those positions, it is also highly desirable to produce explicit estimates of the position absolute and relative accuracy, where those accuracy estimates are as accurate as possible. One such application is producing large scale maps.
This document specifies the interface to an Image Geopositioning Service that adjusts the georeferencing coordinate transformations of multiple images. This adjustment is normally done using a photogrammetric triangulation process, although other methods could be used. Such triangulation adjusts the parameter values of the image georeferencing coordinate transformations, using a least-squares fitting process to measured image positions with known error statistics. Such adjustment is often required to obtain georeferencing coordinate transformations with sufficient accuracy to support image exploitation.
In addition to using existing approximate image georeferencing coordinate transformations, such triangulation uses the measured image positions of multiple object (or ground) points. Control points and tie points can be used. A control point has a measured position with position error statistics in one or more images, and a known position with error statistics in some object or 'ground' Coordinate Reference System (CRS), assumed to be a GeodeticCRS. A tie point has a measured position with error statistics in two or more images, but not a known position in any object CRS.
This Image Geopositioning Service interface specifies two operations that can be requested by clients. The GetCapabilities operation allows a client to get server metadata. The Triangulate operation performs a triangulation, adjusting the parameter values of one or more image georeferencing coordinate transformations that are input with associated error statistics. The Triangulate operation inputs also include measured image positions and known object point positions, all with associated error statistics..."
OpenGIS Image Geopositioning Metadata GML 3.2 Application Schema: "This document specifies a GML 3.2 Application Schema for image geopositioning metadata, which is also an Application Schema of ISO 19139. This image geopositioning metadata schema is used by the separately specified Image Geopositioning Service (IGS) interface that adjusts the georeferencing coordinate transformations of images. This schema can also be used by other future OGC Web Services.
This XML schema encodes image georeferencing coordinate transformations with associated parameter error statistics. These georeferencing coordinate transformations can use many possible image geometry (or sensor) models that can be encoded using extensions of this Application Schema.
This Application Schema also encodes point positions measured in one of more images and optional object coordinates, with associated position error statistics. These object points can be tie points, control points, or check points. A control or check point has a measured position with position error statistics in one or more images, and a known position with error statistics in some geodetic Coordinate Reference System (CRS). A tie point has a measured position with error statistics in two or more images, but not a known position in any geodetic CRS.
Error statistics are represented as variance-covariance matrices, representing both absolute and relative accuracies. These covariance matrices are used to represent correlations between the accuracies of different parameters, coordinates, and positions.
The Image geopositioning metadata GML Application Schema is specified in six parts, corresponding to six UML packages with six corresponding XML Schema Documents.
The GML 3.2 Application Schema for geopositioning metadata is also an Application Schema of ISO 19139. This Application Schema uses small profiles (or subsets) of GML 3.2 (ISO 19136) and ISO 19139, although those profiles are not yet formally specified. For GML, the profile used is essentially a subset of the GML 3.1.1 grid CRSs and simple features profiles. For ISO 19139, the profile is a subset of the ISO 19139 profile that is used by GML 3.2 (ISO 19136).
Also recently published:
KML 2.1 Reference — An OGC Best Practice. Edited by Carl Reed on behalf of Google Earth Staff. Open Geospatial Consortium Inc. Date: 2007-05-02. Version: 0.0.9. OGC Project Document Reference Number: OGC 07-039r1. Category: OGC Best Practices. [source]
"KML is a file format used to display geographic data in an Earth browser, such as Google Earth, Google Maps, and Google Maps for Mobile. KML uses a tag-based structure with nested elements and attributes and is based on the XML standard.
Google submitted KML (formerly Keyhole Markup Language) to the Open Geospatial Consortium (OGC) to be evolved within the OGC consensus process with the following goal: KML Version 3.0 will be an adopted OpenGIS implementation specification that will have been harmonized with relevant OpenGIS specifications that comprise the OGC standards baseline. There are four objectives for this standards work:
- That there be one international standard language for expressing geographic annotation and visualization on existing or future web-based online maps (2d) and earth browsers (3d).
- That KML be aligned with international best practices and standards, thereby enabling greater uptake and interoperability of earth browser implementations.
- That the OGC and Google will work collaboratively to insure that the KML implementer community is properly engaged in the process and that the KML community is kept informed of progress and issues.
- That the OGC process will be used to insure proper life-cycle management of the KML candidate specification, including such issues as backwards compatibility.
The OGC has developed a broad Standards Baseline. Google and the OGC believe that having KML fit within that family will encourage broader implementation and greater interoperability and sharing of earth browser content and context.
What information sharing space is KML targeted at? KML is an XML language focused on geographic visualization, including annotation of maps and images. 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.
From this perspective, KML is complementary to most of the existing OGC specifications including key standards such as GML (Geography Markup Language), WFS (Web Feature Service) and WMS (Web Map Service). Currently, KML (v2.1) utilizes certain geometry elements derived from GML (version 2.1.2). These elements include point, line-string, linear-ring, and polygon.
The OGC and Google have agreed that there can be additional harmonization of KML with GML (e.g. to use the same geometry representation) in the future. The Mass Market Geo Working Group in the OGC will define additional harmonization activities. Other OGC specifications such as Context and SLD will be considered.
Google submitted the KML Reference Manual to the OGC. OGC staff put the reference document into the OGC Document Template. During the April Technical Committee meetings, the OGC membership approved release of the document as an OGC Best Practices Paper. This document is based entirely on the current KML 2.1 reference documentation from Google. This OGC Best Practices document is provided to the community to initiate the process of KML standardization within the OGC consensus process..."
Extensible Access Control Markup Language (XACML) is an OASIS Standard produced by members of the OASIS XACML TC; the Version 2.0 standard is now widely implemented.
According to the TC's Brief Introduction to XACML,
XACML is an OASIS standard that describes both a policy language and an access control decision request/response language (both written in XML). The policy language is used to describe general access control requirements, and has standard extension points for defining new functions, data types, combining logic, etc. The request/response language lets you form a query to ask whether or not a given action should be allowed, and interpret the result. The response always includes an answer about whether the request should be allowed using one of four values: Permit, Deny, Indeterminate (an error occurred or some required value was missing, so a decision cannot be made) or Not Applicable (the request can't be answered by this service).
The typical setup is that someone wants to take some action on a resource. They will make a request to whatever actually protects that resource (like a filesystem or a web server), which is called a Policy Enforcement Point (PEP). The PEP will form a request based on the requester's attributes, the resource in question, the action, and other information pertaining to the request. The PEP will then send this request to a Policy Decision Point (PDP), which will look at the request and some policy that applies to the request, and come up with an answer about whether access should be granted. That answer is returned to the PEP, which can then allow or deny access to the requester. Note that the PEP and PDP might both be contained within a single application, or might be distributed across several servers. In addition to providing request/response and policy languages, XACML also provides the other pieces of this relationship, namely finding a policy that applies to a given request and evaluating the request against that policy to come up with a yes or no answer..."
An Interoperability Event for XACML is being planned for the Burton Catalyst Conference in San Francisco, 28-June-2007.
"The Open Geospatial Consortium (OGC) is a non-profit, international, voluntary consensus standards organization that is leading the development of standards for geospatial and location based services. OGC follows an open standards consensus process that supports transparent access to heterogeneous geodata and geoprocessing resources in a networked environment. The goal of OGC is to provide a comprehensive suite of open interface specifications that enable developers to write interoperating components that provide these capabilities...
The Open Geospatial Consortium (OGC) Interoperability Program (IP) is a global, hands-on and collaborative prototyping program for rapid development of proven candidate specifications for consideration for consensus adoption and public release by the OGC Specification Program. The Interoperability Program is an essential part of OGC's fast, effective, inclusive user-driven process to develop, test, demonstrate, and promote the use of OpenGIS Specifications. The functions of the Interoperability Program complement those of the Specification Program.
OGC provides resources for both members and non-members to understand, research, develop and implement OpenGIS Specifications. A Compliance Testing Program permits 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. The listing of Registered Products indicates significant deployments.
OGC Standards are developed within the OGC Specification Program. Here the OGC Technical Committee and OGC Planning Committee work in a formal consensus process to arrive at approved (or 'adopted') OpenGIS Specifications or standards. The OGC Specification Program sometimes issues public requests for comments, proposals, information or technologies, for the purpose of ensuring the best possible technical foundation for an OpenGIS Specification.
To obtain broad input and support from geoprocessing technology users and providers, OGC issues formal public requests related to its Specification Program. These documents provide detailed information about the specific interoperability requirements to be addressed in an initiative, and they outline the steps that will be followed in planning and executing the initiative.
OGC Best Practices documents contain discussion of best practices related to the use and/or implementation of an adopted OGC document and for release to the public. Best Practices Documents are an official position of the OGC and thus represent an endorsement of the content of the paper.
The Open Geospatial Consortium, Inc (OGC) is an international industry consortium of 341 companies, government agencies and universities participating in a consensus process to develop publicly available interface specifications. OpenGIS Specifications support interoperable solutions that "geo-enable" the Web, wireless and location-based services, and mainstream IT. The specifications empower technology developers to make complex spatial information and services accessible and useful with all kinds of applications..."
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
