OGC Requests

OpenGIS® Sensor Model Language (SensorML): Request for Public Comments

Status: 
Please note: This Request is closed. The documents listed below have been adopted by the OGC Technical and Planning Committee. These specifications are under control of the specification Revision Working Group and will be released after the edits and revisions. For the most current version please check our Standards Page.
Description: 

The Open Geospatial Consortium (OGC) is contemplating adoption of a technology called OpenGIS® Sensor Model Language (SensorML). OGC invites public comment on a candidate specification that will soon be presented for approval by OGC members as an OpenGIS(R) Implementation Specification. The purpose of this Request for Public Comment (RFPC) is to obtain comments on the proposal for technologies and needed encodings required for OpenGIS® Sensor Model Language (SensorML). Documentation of this draft specification can be downloaded here:

Candidate Submission: Wed, 2006-02-01 16:00
Close request period: Fri, 2006-03-10 16:00
TC and PC vote to issue request: Wed, 2006-04-05 16:00
Begin request period: Fri, 2006-05-05 16:00
 

Downloads: 

This document specifies models and XML encoding for the core SensorML. SensorML provides a common framework for any process and process chain. Within SensorML, sensors and transducer components (detectors, transmitters, actuators, and filters) are all modelled as processes that can be connected and participate equally within a process chain, and which utilize the same process model frame as any other process.
Comment: 
Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template.
Subscribe: 
You may wish to be added to the distribution list to receive comments as they are submitted:
Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.
OGC Requests: 

OGC Calls for Comment on revision to OGC Web Services Common Standard

Status: 
Please note: This Request is scheduled to closed on 20 May 2009.
Description: 
The members of the Open Geospatial Consortium, Inc. (OGC®) request comments to a revision to the OpenGIS® Web Services Common Standard. This document specifies many of the aspects that are common to multiple OGC Web Service (OWS) interface Implementation Standards. These common aspects are primarily parameters and data structures used in operation requests and responses. Examples of common usage are how to handle bounding boxes, exception processing, URL requests, URN expressions, key value encoding, and so forth.

The primary use of OWS Common is as a normative reference for other OWS standards. Those standards currently include the OpenGIS Web Map Service (WMS), Web Feature Service (WFS), and Web Coverage Service (WCS) Standards. Rather than continuing to repeat this material in each Implementation Standard, each standard normatively references each relevant part of OWS Common.

The 30 day public comment period begins April 20, 2009 and closes on May 20, 2009. Comments will be reviewed and processed by the OGC Membership. The intent is to edit the OWS Common standard and move the revised document to be an approved OGC standard. The OpenGIS® Web Services Common Standard Request for Comment document can be downloaded below.

Comment: 
Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template.
Subscribe: 
You may wish to be added to the distribution list to receive comments as they are submitted:
Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.
OGC Requests: 

OGC Seeks Comments on NetCDF Enhanced Data Model Extension Standard

Status: 
Please note: This Request is closed. The documents listed below have been adopted by the OGC Technical and Planning Committee. These specifications are under control of the Standards Working Group and will be released after the edits and revisions. For the most current version please check our Standards Page.
Description: 

The Open Geospatial Consortium (OGC®) membership seeks comments on an OGC candidate standard, the Network Common Data Form (NetCDF) NetCDF Enhanced Data Model Extension Encoding Standard. This document specifies an extension to the existing OGC Network Common Data Form (NetCDF) Core Encoding Standard version 1.0.

The OGC netCDF encoding supports electronic encoding of geospatial data, specifically digital geospatial information representing space- and time-varying phenomena. NetCDF (network Common Data Form) is widely used internationally to communicate and store many kinds of multidimensional data, although it was originally developed for the Earth science community. The netCDF data model is particularly well suited to providing data in forms familiar to atmospheric and oceanic scientists: namely, as sets of related arrays. NetCDF was developed and is maintained and actively supported by the Unidata Program Center (http://www.unidata.ucar.edu) of the University Corporation for Atmospheric Research (UCAR).
 
The netCDF classic data model has previously been established as the core OGC CF-netCDF standard. With this extension to the core standard for the enhanced data model, complex data structures can be represented very easily, allowing for more efficient programming. In performance-critical applications, the enhanced model provides significant benefits. Moreover, if existing HDF5 (Hierarchical Data Format, release 5) applications that depend on groups, user-defined types, unsigned types, or strings produce or use these data, the netCDF enhanced data model is required. The recently introduced candidate NetCDF Enhanced Data Model Extension Encoding Standard is the latest step in a longer-term plan for establishing CF-netCDF as an OGC standard for binary encoding, which will enable standard delivery of data in binary form via several OGC service interface standards, including the OGC Web Coverage Service (WCS), Web Feature Service (WFS), and Sensor Observation Service (SOS) Interface Standards.
 
The candidate OGC Network Common Data Form (NetCDF) NetCDF Enhanced Data Model Extension Encoding Standard and information about submitting comments on this document are available below. The public comment period closes on July 1, 2012.
Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

 You may wish to be added to the distribution list to receive comments as they are submitted:


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 

OGC Web Services, Phase 6 (OWS-6) Request For Quotation and Call For Participation

Status: 
Please note:  As of October 31, this Request is CLOSED to further proposals.
Description: 
RFQ Issuance Date: 21 July 2008
OWS-6 Bidder's Conference: 8 August 2008
Proposal Due Date: 5 September 2008

 


Overview

OWS testbeds are part of OGC's Interoperability Program, a global, hands-on and collaborative prototyping program designed to rapidly develop, test and deliver proven candidate specifications into OGC's Specification Program, where they are formalized for public release. In OGC's Interoperability Initiatives, international teams of technology providers work together to solve specific geoprocessing interoperability problems posed by the Initiative's sponsoring organizations. OGC Interoperability Initiatives include test beds, pilot projects, interoperability experiments and interoperability support services - all designed to encourage rapid development, testing, validation and adoption of OGC standards.

The OWS-6 sponsors are organizations seeking open standards for their interoperability requirements. After analyzing their requirements, the OGC Interoperability Team recommended to the sponsors that the content of the OWS-6 initiative be organized around the following threads:

  1. Sensor Web Enablement (SWE)
  2. Geo Processing Workflow (GPW)
  3. Aeronautical Information Management (AIM)
  4. Decision Support Services (DSS)
  5. Compliance Testing (CITE)

OWS-6 Sponsors

  • U.S. National Geospatial-Intelligence Agency (NGA)
  • Joint Program Executive Office for Chemical and Biological Defense (JPEO-CBD)
  • GeoConnections - Natural Resources Canada
  • U.S. Federal Aviation Agency (FAA)
  • EUROCONTROL
  • EADS Defence and Communications Systems
  • US Geological Survey
  • Lockheed Martin
  • BAE Systems
  • ERDAS, Inc.

OWS-6 Threads

1) Sensor Web Enablement (SWE)

The OGC Sensor Web Enablement framework has achieved a degree of maturity through previous OWS interoperability initiatives and deployments worldwide. OWS-6 will focus on integrating the SWE interfaces and encodings into cross-thread scenarios and workflows to demonstrate the ability of SWE specifications to support operational needs. Emphasis for SWE during this phase of the OWS test-bed will be on:

  • CCSI-Enabled CBRN Sensors into the SWE Environment
  • Build on Georeferenceable imagery accomplishments of OWS-5
  • Harmonize SWE-related information models: SensorML, GML, UncertML, MathML
  • Apply GeoRM, Trusted Services, and security models in SWE environment
  • Events-based architecture including WNS

2) Geo Processing Workflow (GPW)

This GPW thread aims to build on the progress of previous testbeds with a focus on maturing the interoperability and capabilities of OGC web services in a service-oriented architecture with particular emphasis to address OGC web service security issues. To satisfy mission-critical goals, the architecture must not only provide for integration of a wide variety of service capabilities and resources, it must do so and ensure authenticity, integrity, quality and confidentiality of services and information. To meet these goals, the following task areas have been identified:

  • Asynchronous Workflow and Web Services Security
  • Data Security for OGC web services
  • Data Accessibility
  • WPS Profiles - Conflation; and Grid processing
  • GML Application Schema Development & ShapeChange Enhancements

3) Aeronautical Information Management (AIM)

The Aviation Information Management (AIM) subtask is a new thread within OWS to develop and demonstrate the use of the Aeronautical Information Exchange Model (AIXM) in an OGC Web Services environment. The AIM subtask shall focus on evaluating and advancing various AIXM features in a realistic trans-Atlantic aviation scenario setting by devising and prototyping a Web Services Architecture for providing valuable aeronautical information directly to flight decks, Electronic Flight Bags (EFB) and hand-held devices (such as PDAs and Blackberries) while the airplane is at the gate or en-route to its destination (for the purposes of OWS-6, the aeronautical information in the latter case does not depend on the knowledge of the airplane's location).

AIXM was developed by the Federal Aviation Administration (FAA) and Eurocontrol as a global standard for the representation and exchange of aeronautical information. It was designed as a basis for digital aeronautical information exchange and for enabling the transition to a net-centric, global aeronautical management capability. AIXM has been developed using the ISO 19100 modeling framework and has two major components: a conceptual model presented in the form of an UML class model and a data encoding specification which was developed using the OGC Geography Markup Language (GML). Both have been tailored to the specific requirements for the representation of aeronautical objects, especially the temporality feature that allows for time-dependent changes affecting AIXM features. More information about AIXM is available on www.aixm.aero. In support of the above objectives, the OWS-6 AIM thread shall perform tasks in the following areas while ensuring that the integrity of data is preserved throughout all data exchange operations:

  • Use and enhancement of Web Feature Service and Filter Encoding specifications in support of AIXM features and 4-dimensional flight trajectory queries,
  • Prototype of Aviation client for retrieval and seamless visualization of AIXM, Weather and other aviation-related data, emphasizing time and spatial filtering in order to present just the right information into a given user context anytime, anywhere,
  • Architecture of standards-based mechanism to notify users of changes to user-selected aeronautical information.

4) Decision Support Services (DSS)

Decision Support Services having an emphasis on applications of geospatial and temporal information has been a recurring thread in previous OWS testbeds. This thread focuses on presenting and interacting with data obtained from the sensor web and geoprocessing workflows in the most effective ways to support analysis and decision making. The focus for DSS in OWS-6 builds on portrayal, WMS Tiling, and integrated client work from OWS-4, with additional work on 3D visualization and integration of the built environment and landscape. This thread will encompass these capabilities and task areas:

  • ISO 19117 and OGC SLD Portrayal
  • 3D Portrayal of GML with Fly-through
  • Hosting CityGML data with WFS
  • Outdoor and indoor 3D route and tracking services
  • WMS performance (tiling)
  • Integrated Client for multiple OWS services

5) Compliance Testing (CITE)

Validating compliance with an OGC specification means verifying that a software product has implemented the specification correctly by testing the software interface for response and behavior that is outlined in the specification. Verifying compliance to the standard is necessary in order to achieve interoperability. As a result, geospatial application vendors desire to provide their potential costumers a means to verify adherence to OGC standards as a measurable discriminator for the interoperability of software products. Similarly, users desire assurance that acquired software components will interoperate with their existing investments in OGC-compliant technology. The Conformance and Interoperability Test and Evaluation (CITE) thread is intended to provide the geospatial industry (consumers and vendors) a methodology and tools that will test compliance with OGC web services.

The OGC Interoperability Program and the OGC Specification Program have achieved a great deal of momentum as a result of the multiple OGC web service specifications that have recently been published. Key consumers in the geospatial industry are modernizing their enterprises based on the applicability and interoperability of OGC web services. The major geospatial industry consumers require verifiable proof of compliance with OGC specifications in order to reach the desirable outcome of interoperability. Furthermore, as the OGC technology stack has matured, a group of interfaces has emerged that represents a baseline of technology needed to implement a fully interoperable, end-to-end spatial data infrastructure. The CITE threads in previous OWS projects have made significant progress towards having a complete suite of compliance tests for this baseline of interfaces.

A major focus of OWS-5 was on achieving consensus on the format and content of an Abstract Test Suite (ATS). The OWS-5 CITE participants agreed to follow the ISO guidance for writing Abstract Test Suites. The ATS are used to develop Executable Test Suites which are the scripts that the TEAM Engine runs to conduct an automated compliance test. A major focus of OWS-6 CITE will be in clearly documenting the approach to defining Abstract Test Suites. This will be a great benefit to the OGC community as the OGC Architecture Board (OAB) requires that new specifications be published with an accompanying ATS. In addition, a focus of OWS-6 CITE will be to expand the usability of the existing OGC compliance tests by "tailoring" these tests for specific schema profiles and/or data.

Downloads: 

Proposals for cost reimbursement are due by September 5, 2008.

Click a link to download the .zip archive:
DOWNLOAD COMPLETE PACKAGE
Complete OGC Web Services, Phase 6 (OWS-6) RFQ (zip format)

OGC Web Services, Phase 6 (OWS-6) Bidder's Conference Information


A Bidder's Conference is currently scheduled for 8 Aug 2008, 10am-noon US Eastern time.
Time: 14:00 UTC, 4:00 PM CEST, 10:00 AM EDT, 9:00AM CDT, 7:00 AM PDT
Phone line: +1 512-225-3050 passcode:36429#.
WebEx will also be used; connection instructions to be sent out before the meeting.

Clarifications to OWS-6 RFQ/CFP

The following clarifications apply to the Request for Quotation/Call for Participation in OGC Web Services, Phase 6 (OWS-6) as issued on 21 July 2008. This list will be updated as additional clarifications are needed. The most current list will always be posted here:

Clarifications have been posted .

 


OGC Requests: 

OGC seeks comment on candidate Earth Observation profile of coverage standard

Status: 
Please note: This Request is closed. The documents listed below have been adopted by the OGC Technical and Planning Committee. These specifications are under control of the Standards Working Group and will be released after the edits and revisions. For the most current version please check our Standards Page.
Closing Date: 
Tue, 11/01/2011 - 04:00
Description: 

The Open Geospatial Consortium (OGC®) seeks public comment on the candidate Earth Observation profile for the OGC Web Coverage Service (WCS) 2.0 standard. This profile will facilitate on-line data access to Earth Observation data products.

The OGC WCS 2.0 standard defines a general interface and operations that enable interoperable access to geospatial coverages, such as sensor data, satellite imagery, digital elevation models, and climate/ocean data. The candidate OGC Web Coverage Service Application Profile for Earth Observation products (EO-WCS) defines an interface for interoperable access to Earth Observation data.

The rapid increase of computer power and network accessibility, along with implementations of the OGC WCS standard, make it possible for applications to deliver user selected sensor, image, and statistics data, including human modifications of the Earth's surface and atmosphere. As use of the standard increases, an increasingly wide variety of data will conveniently be brought together in applications such as environment, natural resources, planning, disaster management and public security.

The candidate Earth Observation profile for the OGC Web Coverage Service (WCS) 2.0 standard documents are available for review and comment below.

Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

 You may wish to be added to the distribution list to receive comments as they are submitted:


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 

The OGC Seeks Comments on Candidate GeoPackage Encoding Standard

Status: 
Please note: This call is now closed.
Closing Date: 
Fri, 11/08/2013 - 05:00
Description: 

The Open Geospatial Consortium (OGC®) seeks final “last-call” public comments on the current draft of the candidate OGC GeoPackage (GPKG) Encoding Standard. The GPKG Standards Working Group (SWG) will consider all submitted comments for minor and editorial changes when they prepare a final draft of the GeoPackage Standard.

The candidate OGC GeoPackage Encoding Standard provides an open, non-proprietary, platform-independent SQLite container for distribution and direct use of all kinds of geospatial data, including vector features and tile matrix sets.  GeoPackage can be used by mobile device users who require geospatial application services and associated data in disconnected or limited network connectivity environments where open, sharable geospatial data to support their applications is frequently unavailable. GeoPackage supports applications that involve creation of geospatial data products in enterprise computing environments, data product distribution to other computing environments, mobile workforce data capture and updates, and volunteered geographic information.

The GeoPackage and the related GPKG SQLite Configuration and GPKG SQLite Extension API will increase the cross-platform interoperability of geospatial applications and web services in the mobile world.  Standard configuration and APIs for access and management of GeoPackage data will provide consistent query and update results across such applications and services. 

All OGC standards are free and publicly available. The candidate OGC GeoPackage Encoding Standard can be downloaded below.

OGC will also release the candidate OGC GeoPackage (GPKG) Encoding Standard on GitHub, a web-based hosting service for software development projects, on 1 November 2013.  See http://opengis.github.io/geopackage/.

The GeoPackage SWG will consider change requests for the candidate GeoPackage Standard that have been posted through 8 November 2013. 

Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

 You may wish to be added to the distribution list to receive comments as they are submitted:


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 

Request for Comment on Image Geopositioning Service (IGS)

Status: 
Please note: This Request is closed. The documents listed below have been adopted by the OGC Technical and Planning Committee. These specifications are under control of the specification Revision Working Group and will be released after the edits and revisions. For the most current version please check our Standards Page.
Description: 

The Open Geospatial Consortium (OGC) is contemplating adoption of a technology called OpenGIS Image Geopositioning Service (IGS). OGC invites public comment on a candidate specification that will soon be presented for approval by OGC members as an OpenGIS(R) Implementation Specification.

The OpenGIS Image Geopositioning Service (IGS) Draft Implementation Specification defines an Image Geopositioning Service (IGS) interface to services that perform triangulation. (NOTE: The name of this service has not yet been formally agreed upon.) Accompanying this 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 purpose of this Request for Public Comment (RFPC) is to obtain comments on the proposal for technologies and needed interfaces required for the IGS. Documentation of this draft specification can be downloaded below:

Candidate Submission: Thur, 2007-03-22
TC and PC vote to issue request: Fri, 2007-04-20
Begin request period: Tue, 2007-05-15
Close request period: Thu, 2007-06-14

Comment: 
Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template.
Subscribe: 
You may wish to be added to the distribution list to receive comments as they are submitted:
Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.
OGC Requests: 

OGC Web Services, Phase 8 (OWS-8) Request For Quotation and Call For Participation

Status: 
Please note: This Request closed on 14 January 2011.

 

Description: 

 

RFQ Issuance Date: 22 November 2010

OWS-8 Bidder's Conference: 6 December 2010, 10:00-11:30am US EST
Proposal Due Date:
14 January 2011, 5:00 p.m. EST.

Go Directly to the Request for Quotation Document
Go Directly to the Bidder's Conference Information Overview
Go Directly to the Request for Quotation Clarifications

OGC members who wish to observe OWS-8 may do so upon submission of the OGC Observer Agreement: 
http://bit.ly/aTGi8T

Overview

OWS testbeds are part of OGC's Interoperability Program, a global, hands-on and collaborative prototyping program designed to rapidly develop, test and deliver proven candidate specifications into OGC's Specification Program, where they are formalized for public release. In OGC's Interoperability Initiatives, international teams of technology providers work together to solve specific geoprocessing interoperability problems posed by the Initiative's sponsoring organizations. OGC Interoperability Initiatives include test beds, pilot projects, interoperability experiments and interoperability support services - all designed to encourage rapid development, testing, validation and adoption of OGC standards.

 

The OWS-8 sponsors are organizations seeking open standards for their interoperability requirements. After analyzing their requirements, the OGC Interoperability Team recommend to the sponsors that the content of the OWS-8 initiative be organized around the following threads:

  • Observation Fusion
  • Geosynchronization (Gsync)
  • Cross-Community Interoperability (CCI)
  • Aviation

OWS-8 Sponsors

  • U.S. National Geospatial-Intelligence Agency (NGA)
  • U.S. Geological Survey (USGS)
  • U.S. Army Geospatial Center (AGC)
  • U.S. Federal Aviation Administration (FAA)
  • EUROCONTROL
  • U.S. National Oceanic and Atmospheric Administration (NOAA)
  • U.S. National Aeronautics and Space Administration (NASA)
  • European Space Agency (ESA)
  • U.K. Defence, Science and Technology Laboratary (DSTL)
  • Lockheed Martin Corporation

OWS-8 Threads

In July 2010, the OGC issued a call for sponsors for the OWS-8 interoperability initiative to advance OGC's open framework for interoperability in the geospatial industry.  Two meetings were conducted with potential OWS-8 sponsors to review the OGC technical baseline, discuss OWS-7 results, and identify new requirements to be addressed in OWS-8.  The following organization and scope of activity threads resulted from consolidation of all sponsors’ requirements:

  • Observation Fusion
    • WCS 2.0 Earth Observation Application Profile, WCPS, Compliance Test Scripts
    • Detection, tracking, and bookmarking of moving objects in video, implemented using SWE and other OGC encodings and interfaces.
  • Geosynchronization
    • Geodata Bulk Transfer: The ability to distribute individual data sets and/or collections of data sets in a consistent manner offline and over networks.
    • Geosynchronization: Web services and client components to support synchronization and updates of geospatial data across a hierarchical Spatial Data Infrastructure (SDI).
  • Cross-Community Interoperability (CCI)
    • Advancement of semantic mediation approaches to query and use data based on different heterogeneous data models, which are available via OGC WFS.
    • Advancement of the use of style registries and styling services.
    • Advancement of the use of KML.
    • Advancement of the use of UML/OCL for Schema Automation on Domain Models.
  • Aviation
    • AIXM: Maturing the delivery, filtering and update of AIXM 5.1 using WFS-T/FE 2.0; continuing the development of reusable tools, benchmarking of compression techniques for enhanced performance, advancing styling and portrayal support, and validating the emerging metadata and GML profiles.
    • Event Notification Architecture: including Digital NOTAM Events.
    • WXXM and weather information: using coverages for encoding representative weather forecast and radar datasets, supporting on-demand Coordinate Reference System (CRS) specifications/transformations, exploring alternative distributed architectures for managing Units of Measure (UoM), demonstrating the applications of probabilistic Terminal Aerodrome Forecasts (TAF) decision making applications, and reviewing/validating the WXXM schemas.

Schedule of Events and Milestones

  • Request for Quotation / Call for Participation (RFQ/CFP): 22 November 2010
  • Bidders Conference (Q&A with WebEx): 6 December 2010. Go to the WebEx calendar here: http://opengeospatial.webex.com/ and look for the OWS8 Bidders event.
  • Last date for submitting questions or changes to the RFQ: 15 December 2010
  • Proposals due: 14 January 2011
  • Participant selections completed: 28 January 2011
  • OWS-8 Kickoff (3-day workshop in DC area, attendance required): 9-11 March 2011
  • OWS-8 Completion (final reports due): 30 September 2011

Live demonstrations of OWS-8 results will be conducted at the September 2011 OGC Technical Committee meeting in Boulder, Colorado USA 

Demonstration videos of the testbed results will be posted for public viewing within 30 days of testbed completion. 

Downloads: 
Proposals for cost reimbursement are due by 14 January 2011, 17:00 p.m. EST.
 
For those who have done this before: Please do not reuse old templates, but use our new ones. Thanks!

Click a link to download the .zip archive:
DOWNLOAD COMPLETE PACKAGE


Complete OGC Web Services, Phase 8 (OWS-8) RFQ (pdf  zip format)
Complete OGC Web Services, Phase 8 (OWS-8) RFQ (doc  zip format)

OR INDIVIDUAL FILES

OGC Web Services, Phase 8 (OWS-8) RFQ Main Body (pdf)
OGC Web Services, Phase 8 (OWS-8) RFQ Main Body (doc)

OGC Web Services, Phase 8 (OWS-8) RFQ Annex A (pdf)
OGC Web Services, Phase 8 (OWS-8) RFQ Annex A (doc)

OGC Web Services, Phase 8 (OWS-8) RFQ Annex B (pdf)
OGC Web Services, Phase 8 (OWS-8) RFQ Annex B (doc)

OGC Web Services, Phase 8 (OWS-8) RFQ Annex C (pdf)
OGC Web Services, Phase 8 (OWS-8) RFQ Annex C (doc)

OGC Web Services, Phase 8 (OWS-8) RFQ Annex D (pdf)
OGC Web Services, Phase 8 (OWS-8) RFQ Annex D (doc)

 OGC Web Services, Phase 8 (OWS-8) RFQ Template - Funding (xls)
OGC Web Services, Phase 8 (OWS-8) RFQ Template - Proposal (doc)
 

Questions: Bidder's Conference

 A Bidder's Conference (webinar) was held Monday 6 December 201010:00-11:30am US EST to discuss all communications received since the RFQ release. You can download and view the “OWS8 Bidders Conference” video.

 

 

 

Clarifications Document

All Q&A, updates, and other information about OWS-8 from the Bidder’s Conference and other communications will be collected into a Clarifications document, and posted here for public access. Subsequent questions may be directed by email to techdesk [at] opengeospatial.org (techdesk [at] opengeospatial.org) until 15 December 2010. After this date, no further questions or clarifications will be posted. The Clarifications Document is here:

Clarifications - pdf
Clarifications - doc

OGC Requests: 

The OGC requests comment on the Scaling Extension to the OGC Web Coverage Service Interface Standard

Status: 
Please note: This call is now closed.
Closing Date: 
Thu, 09/19/2013 - 04:00
Description: 

The Open Geospatial Consortium (OGC®) is seeking comments on the candidate OGC Web Coverage Service (WCS) Interface Standard Scaling Extension. 

The OGC Web Coverage Service (WCS) Interface Standard defines an open standard interface to access multi-dimensional spatio-temporal coverages, such as satellite imagery, image time series, point clouds, and meshes. The candidate WCS Scaling Extension document specifies parameters to the WCS GetCoverage request that provide control over scaling of a coverage during its server-side processing. Scaling refers to retrieving gridded coverages in reduced resolution, such as for thumbnails or lower-resolution overview pictures.

All OGC standards are free and publicly available. Download the candidate OGC WCS Scaling Extension Standard below.  Comments are due by 19 September 2013.

Comment: 

Comments can be submitted to a dedicated email reflector for a thirty day period ending on the "Close request date" listed above, Comments received will be consolidated and reviewed by OGC members for incorporation into the document. Please submit your comments using the following link: requests [at] lists.opengeospatial.org (Click here to submit comments) The link provided above should include a standard template in the message body. If the preloaded message body does not work properly using your mail client, please refer to the following template for the message body: Comments Template

Subscribe: 

 You may wish to be added to the distribution list to receive comments as they are submitted:


Subscribing to the the list will also allow you to view comments already received, which can be found in the List Archives.

OGC Requests: 

OGC Request for Information on "Contextual State Description" Services

Status: 
Please note: This Request is closed.
Description: 

Introduction

With this Request for Information (RFI), The Open Geospatial Consortium Inc. (OGC) is soliciting input on technologies related to Contextual State Descriptions (CSD).  A CSD describes the "environment" or context in which a service chain executes. The objective of this request is to identify existing capabilities that can provide a robust metadata foundation for supporting agile, adaptive, autonomous processes capable of producing repeatable, predictable results with no intervention.

In August, 2004, the Open Geospatial Consortium Inc. (OGC) issued a call for sponsors for an OGC Web Services 3 (OWS-3) interoperability initiative, a multi-threaded test bed activity to advance OGC's open framework for interoperability in the geospatial industry.  Key Components of OWS-3 will Sensor Web Enablement (SWE) and Service Chaining.  Each of these components are described below followed by some potential uses for CSD in OWS-3.

Organizations with relevant technology regarding CSD are urged to respond to this RFI. Information on how to respond are at the end of this RFI.  The contents of the OWS-3 request for quotations (RFQ) will be based in part on the RFI response to the CSD RFI.

 

Sensor Web Enablement and OpenGIS SensorWeb™

A key component of OWS-3 will be Sensor Web Enablement (SWE), in which OGC members are developing standard interfaces and encodings that will enable real time integration of heterogeneous sensor webs into the information infrastructure. Developers will use these specifications in creating applications, platforms, and products involving web-connected devices such as flood gauges, air pollution monitors, stress gauges on bridges, mobile heart monitors, Webcams, and robots as well as space and airborne earth imaging devices. Several elements of SWE have already been developed and are being finalized before they are submitted to the OGC membership for adoption. CSD is a potential new element of SWE.

OWS-3 will combine the previous work on SensorWeb with the OWS-2 Image Handling and Decision support results to provide automated workflow management to produce value-added products. SensorWeb is the source of tremendous amounts of geospatial data, e.g.,  in-situ, imagery and simulation data.  The Decision Support component of OWS-3 will continue the work of OWS-2 Service Chaining to produce value-added information products derived from SensorWeb data.

 

Using CSD for Service Chaining

A major thrust of OWS-2 was Image Handling for Decision Support. The Image Handling component of OWS-2 increased the ability to access and process geographic imagery into value-added products using open web services.  The Decision Support component of OWS-2 demonstrated automated service chaining of imager processing services.  This automation was achieved with an emerging open specification of workflow management: BPEL.

This RFI seeks input on the technology related to Contextual State Descriptions (CSD).  A CSD could describe the "environment" or context in which a service chain "executes". A well-characterized service chain or workflow derives a repeatable result given equivalent sources, methods, and processing state or context.  A workflow script defines the order of service invocation in a service chain but the details of the services are hidden behind the web service interface. A CSD provides information about the distributed processing environment and resources that are hidden behind the interfaces.  A CSD is specifically designed to address environmental state descriptions, in such a manner that an equivalent state can be recreated at some future point to provide identical, repeatable results from a specified process, assuming identical sources, services and scripting are utilized.

When workflows are manually executed and interpreted, complexity can be addressed through human intuition and experience.  However, in an autonomous environment, complexity must be distilled into codified states, before business logic can be characterized to facilitate autonomous processing with any level of confidence.  Thus, a CSD is specifically designed to facilitate the autonomous processing of complex workflows in a predictable, repeatable fashion.

The promise of complex autonomous processing is the increased productivity of end user "analysts" that presently focus an inordinate amount of their time preparing data instead of analyzing it.  Thus, the transition of data into information into knowledge into some form of decision or course of action is largely still a manual process that cannot be reliably repeated.  True autonomous processing will not determine the ultimate course of action from a workflow, but can relieve the analyst from having to manually shepherd data through this workflow process, freeing them to focus on interpreting the derived knowledge into alternative courses of action in less time than the current process requires to develop a single course of action manually.

CSD does not describe the workflow business logic, but the contextual state that the workflow executes within.  Thus, the CSD would describe the systems configuration, the hardware configuration, the firmware used by each device, the operating system, including patches, the software configuration, including external dependencies (shared libraries), and any data.  All of this information characterizes the operational state or context of the system. Any change in this contextual state may result in discrepancies when the workflow is re-executed.

 

Potential use for CSD in OWS3

OWS-3 will apply service chaining to enable use of SensorWeb technologies for decision support.  This technology will allow sensor measurements and modeling predictions to be processed into higher-value information specific to a given decision making context.  CSD may be used to capture the state of the service chain including the SensorWeb components and the geo-processing services and the workflow management components.  Capturing this information in a CSD will allow for post-processing analysis of the decision support information.

For instance, this initiative could describe each of the sensor components of the current SensorWeb, as well as a corresponding set of metadata to describe the processing chain.  Quality metrics embedded within the data stream can describe the resultant accuracies associated with any point in the stream.  However, when a degraded signal is recorded within the sensor stream, there is no context to interpret the cause and effort on the resulting value-added information.  The CSD associated with this process could describe the environmental context or state that the SensorWeb was operating within to illustrate the reason for the degraded decision support information.

Due to the potential iterative nature of CSDs, a normalizing relationship structure must be provided to "relate" voluminous descriptive metadata references, without requiring these references to be redundantly embedded within a single CSD.  Several compelling technologies and standards currently exist to address these specific issues.  The net result of an CSD-enabled workflow would be a greater understanding of the situational context present when the SensorWeb was captured.  These concepts are not new and have often been referred to as "fusion", multi-INT/multi-Source, and/or horizontal integration.

CSD could be applied to the OWS-2 Image Handling results including automated image orthorectification.  In OWS-2, the orthorectification was accessible by a single web service request without exposing the underlying processing hardware.  While retaining this simple web service interface, CSD could be used to capture a description of the underlying processing environment.  For example, orthorectification may be performed by a cluster-based computing task with the processing load distributed across all available nodes in the cluster.  Depending upon the load on the system, the number of nodes available during processing time, the system resources allocated to each node and the system, the methods and availability of source materials (raw imagery and control information), and the business logic applied to the process (tiling inputs, parallel vs. serial processing, types of control applied), the resultant orthorectified images will be created with varying degrees of accuracies and latencies.  Once sufficiently populated, these accuracies and latencies (CSDs) can be mined to support the development of an adaptive system, whereby an orthorectification request can be fulfilled based on the degrees of freedom provided by varying the accuracies or latency in the fulfillment of this request.

 

Objective Requirements

The objective of this RFI is to identify existing capabilities that can provide a robust metadata foundation for supporting agile, adaptive, autonomous processes capable of producing repeatable, predictable results with no intervention.  These objectives are purposely abstracted to describe a wide variety of processes or workflows, beyond just computer system processes.

A CSD shall describe the contextual state of a process or workflow. The structure of a CSD shall be such that a subsequent re-execution of a specified process will generate equivalent results, assuming the state from which the original process executed can be faithfully replicated.  A CSD shall be capable of relating or referencing other external processes, services, or data as part of a contextual state.  External references embedded within a CSD should not require the inclusion of the full reference, but rather a form of relation that will support normalized, iterative references.  CSD shall not be explicitly tied to computer system processes or workflows, but must support a much broader, abstracted description of a process and/or workflow.

CSD is information, i.e., metadata, about the processing environment. OGC has adopted and implemented ISO 19115:2003, Geographic Information - Metadata in OGC Abstract Specification, Topic 11 - Metadata. While ISO 19115 is primarily for the description of datasets, it includes metadata to describe the processing history of a dataset.  While the objectives of CSD exceed the elements in ISO 19115, CSD implementations must utilize elements of ISO 19115 when appropriate in lieu of defining new terms for the same concept.

Methodologies need to be developed to couple CSDs with processes and workflows as logical metadata structures.  Methodologies need to be provided to extract the contextual state from a system, process or workflow and codify that state within a specified CSD. Additional methodologies need to be provided to extract a contextual state from a CSD to reconfigure (to the extent physically possible) a described system capable of re-executing the process or workflow associated with the CSD.  Methods need to be developed that can identify and codify the differences between two CSDs, forming the basis for determining whether two CSDs are essentially equivalent.  A CSD shall be capable of being described in a service context that will facilitate autonomous processing of CSD attributed processes and workflows.

 

Responding to this Request

Organizations responding to this request should send a short document to:

George Percivall
Executive Director, Interoperability Architecture
Open Geospatial Consortium

percivall [at] opengeospatial.org

A response to this RFI must contain the following information:

  • A description of the technology relevant to CSD
  • Descriptions of example implementations of the relevant technology
  • Applicability of the technology to OWS3, e.g., SWE and Service Chaining.

Documents in pdf format are preferred.

Submission of proprietary information is discouraged. Any response containing proprietary information must place that information in a separate file.  Do not send proprietary information unless your organization has previously executed a Non-Disclosure Agreement with OGC.

Any organization with relevant technology can respond to this RFI.  You need not be a member of OGC to respond.  There is no reimbursement for responding to this RFI. By accepting an RFI response, OGC implies no endorsement of the technology and there is no implied agreement that the contents of an RFI response will be reflected in the OWS-3 RFQ.

For more information about CSD Services, contact:

Brent Bursey
President, Great-Circle Technologies, Inc.,
703 764-9140,

BBursey [at] Great-CircleTech.com

The OGC is an international industry consortium of more than 250 companies, government agencies and universities participating in a consensus process to develop publicly available interface specifications. OpenGIS(R) 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. Visit the OGC website at http://www.opengeospatial.org.

Candidate Submission: Tue, 2004-08-10 17:00
Close request period: Thu, 2006-08-10 17:00
TC and PC vote to issue request: Thu, 2006-08-10 17:00
Begin request period: Thu, 2006-08-10 17:00
 

OGC Requests: 

Pages