OGC Requests

OGC Calls for Participation in Geo4NIEM Initiative to enhance geospatial capabilities for the the US National Information Exchange Model (NIEM)

Status: 
Please note: This Request is closed as of 4 March 2013. 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: 
Mon, 03/04/2013 - 05:00
Description: 

RFQ Issued Date: 14 February 2013
RFQ Written Comments due
: 5pm EST on 21 February 2013
Proposals Due Date
: 5pm EST on 4 March 2013

Go Directly to the Request for Quotation Document
Go Directly to the Request for Quotation Clarifications

 

Overview

The Open Geospatial Consortium (OGC®) has issued a Request for Quotations/Call for Participation (RFQ/CFP) to solicit proposals in response to requirements for the OGC Geo4NIEM Project. The Geo4NIEM Initiative will result in recommendations to enhance the geospatial capabilities within the National Information Exchange Model (NIEM). Sponsors have identified specific Information Exchange Packages (IEPs) from Department of Homeland Security (DHS), Justice/Law Enforcement domain, and the Maritime domain as representative examples for investigation in this initiative.

The RFQ/CFP is available below. Deadline for submitting questions on the RFQ/CFP is 5pm EST on 21 February 2013. Responses are due by 5 pm EST on 4 March 2013.

The Point of Contact is Lew Leinenweber: techdesk [at] opengeospatial.org (techdesk [at] opengeospatial.org).

Geo4NIEM Initiative sponsors are:

  • Program Manager – Information Sharing Environment (PM-ISE)
  • National Information Exchange Model – Program Management Office (NIEM PMO)

The focus of Geo4NIEM project will be to address requirements in the context of the following information exchange domain areas:

Justice/Law Enforcement. The Justice/Law Enforcement domain in NIEM is defined by the Global Justice XML Data Model (Global JXDM). The Global Justice XML Data Model (Global JXDM) is an XML-based framework that enables the US justice and public safety communities to effectively share information at all levels.

Maritime Domain Awareness. The Maritime domain supports the effective understanding of anything associated with global maritime that could impact the United States' security, safety, economy, or environment. NIEM facilitates this understanding through effective, timely sharing of vital, secure information among many key partners by representing vessels, people, cargo, and maritime locations and activities.

The Geo4NIEM Project has been organized to address specific functional requirements to meet the following objectives:

  • Develop recommendations for the inclusion and standard use of embedded GML with NIEM IEP documents (IEPDs).
  • Develop recommendations for the standardized use of Naming and Design Rules and the use of adaptors (e.g. NIEM wrapper for GML).
  • Test and demonstrate use of a standardized embedded GML and adaptors within NIEM IEPDs.
  • Develop Architecture documentation and a fact sheet for the use of embedded GML and adaptors for use with NIEM IEPDs.
  • Develop Recommendations for the inclusion of a Geospatial Domain within NIEM.

 

    Click a link below to download individual files or a complete package for the RFQ/CFP.

    DOWNLOAD RFP/CFP PACKAGE (as .zip archive)

    Complete Geo4NIEM RFQ/CFP (pdf zip format)
    Complete Geo4NIEM RFQ/CFP (doc zip format)

    INDIVIDUAL FILES

    Geo4NIEM RFQ Main Body (pdf)
    Geo4NIEM RFQ Main Body (doc)
    Geo4NIEM RFQ Annex A (pdf)
    Geo4NIEM RFQ Annex A (doc)
    Geo4NIEM RFQ Annex B (pdf)
    Geo4NIEM RFQ Annex B (doc)

    RFQ/CFP RESPONSE TEMPLATES (not included in above package)

    Geo4NIEM RFQCFP Template Proposal (doc)
    Geo4NIEM Template Spreadsheet (xls)

    QUESTIONS:

    Prospective bidders are invited to submit written questions by email regarding the RFQ to the OGC Technical Desk email address here: techdesk [at] opengeospatial [dot] org.

     

    CLARIFICATIONS

    Response to questions and any other clarifications are posted here:

    OGC Requests: 

    OGC Calls for Participation in Major Interoperability Testbed - OWS-10

    Status: 
    Please note: This call is now closed.

     

    Go Directly to Clarifications

    Closing Date: 
    Mon, 08/26/2013 - 04:00
    Description: 

    The Open Geospatial Consortium (OGC®) has issued a Request for Quotations/Call for Participation (RFQ/CFP) to solicit proposals in response to requirements for the OGC Testbed 10.

    The RFQ/CFP is available at http://www.opengeospatial.org/pub/www/ows10/rfq/index.html.

    Organizations who haven't previously been engaged in OGC Testbeds are encouraged to check out the quickstart guide for help on navigating the RFQ.

    Responses are due by 5 pm EST on 26 August 2013.

    An IP Program and Testbed 10 Q&A Webinar will be held on 6 August 2013 at 10 am EDT (Check your local time http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130806T14). Register here https://portal.opengeospatial.org/public_ogc/register/130806ows10.php. For the most efficient use of this webinar, please send your questions in advance to techdesk [at] opengeospatial.org.

    You are also invited to follow us on twitter, Linkedin or Facebook to stay updated on the Q&A Webinar, clarifications to requirements, kickoff details, etc.

    The OGC Testbed 10 Kickoff event for the CCI and Open Mobility threads (see below) will be held 7-9 October 2013 in Washington, DC. The Aviation thread kickoff will be held 27 September in Frascati, Italy during the week of the OGC Technical Committee Meeting in Frascati.

    The Point of Contact is Nadine Alameh: techdesk [at] opengeospatial.org.

    The OGC Testbed 10 sponsors are:

    • AGC (Army Geospatial Center, US Army Corps of Engineers)
    • ESA (European Space Agency)
    • EUROCONTROL
    • FAA (US Federal Aviation Administration)
    • GeoConnections - Natural Resources Canada
    • Harris Corporation
    • Lockheed Martin Corporation
    • NGA (US National Geospatial-Intelligence Agency)
    • NOAA National Weather Service
    • USGS (US Geological Survey)
    • UK DSTL (UK MoD Defence Science and Technology Laboratory)

    OGC Testbed 10 builds on the outcomes of prior OGC initiatives (http://www.opengeospatial.org/resource/demos) and is organized around the following threads:

    -   Cross-Community Interoperability (CCI): Increase Geospatial community interoperability by building on CCI OWS-9 work in semantic mediation, volunteer geographic information (VGI), provenance and data quality, and Global Gazetteer. Explore the potential of interoperability in the hydrology domain and utilizing ontologies to more easily share and visualize geospatial data.

    -   Open Mobility: Explore the geospatial standards requirements needed to support the growing emerging mobile environment where client applications are mobile, information services are mobile, and increasingly distributed across cloud infrastructures. The Open Mobility thread will address these requirements while leveraging on the work achieved in the OWS-9 Testbed in the areas of Geopackages and Geopackaging services and new OWS Context encodings.

    -   Aviation: Develop and demonstrate the use of the Aeronautical Information Exchange Model (AIXM) and the Flight Information Exchange Model (FIXM), building on the work accomplished in prior testbeds to advance the applications of OGC Web Services standards in next generation air traffic management systems to support European and US aviation modernization programs.

    The RFQ/CFP includes details of these threads as well as details on participation eligibility, selection process and kickoff workshop information.

    OGC testbeds, pilot projects and interoperability experiments are part of the OGC Interoperability Program, a global, hands-on collaborative agile prototyping program designed to rapidly develop, test and deliver proven candidate standards into the OGC Standards Program, where they are formalized for public release.

    Downloads: 

    Click a link below to download individual files or a complete package for the RFQ/CFP.

    DOWNLOAD RFP/CFP PACKAGE (as .zip archive)

    Complete OWS10 RFQ/CFP (pdf zip format) *UPDATED 22 July 2013*

    INDIVIDUAL FILES

    OWS10 RFQ Main Body (pdf)
    OWS10 RFQ Main Body (doc)
    OWS10 RFQ Annex A (pdf) *UPDATED 22 July 2013*
    OWS10 RFQ Annex A (doc) *UPDATED 22 July 2013*
    OWS10 RFQ Annex B (pdf)
    OWS10 RFQ Annex B (doc)
    OWS10 RFQ Annex C (pdf)
    OWS10 RFQ Annex C (doc)
    OWS10 RFQ Annex D (pdf)
    OWS10 RFQ Annex D (doc)

    RFQ/CFP RESPONSE TEMPLATES (also included in above zip)

    OWS10 RFQCFP Template Proposal (doc)
    OWS10 Template Spreadsheet (xls)

     

    CLARIFICATIONS

    Response to questions and any other clarifications are posted here:

    Clarifications

    OGC Requests: 

    OGC Empire Challenge 2009 Pilot: SAS Solicitation

    Status: 
    Please note: This Request scheduled is closed.
    Description: 
    Due to the short turn around and limited scope of the request many of the work items that are normally included in a Statement of Work for an OGC pilot will not be performed. Nor will it be necessary for a responder to provide the detailed information outlined in the original EC'09 CFP/ RFQ. This SAS Solicitation document describes the work to be performed, the schedule required, the reports and attendance requirements for responding. Please submit using the ‘Submission Documentation' directions below - DO NOT use the detailed template listed in the orginal CFP/RFQ.

    Initiative Conduct

    Meetings and Teleconferences

    Selected responders will participate in the Kickoff Teleconference and weekly progress teleconferences.

    Each shall render a verbal report weekly during this teleconference. (In lieu of written reports)

    Coordination and Integration Activities

    Selected responders will work directly with the sponsor to select test networks, functions and schedules.

    Deliverables

    1. Online Sensor Alert Service (SAS) using XMPP and KML on at least one of the three networks.
    2. SAS Best Practice specification to be used: http://portal.opengeospatial.org/files/?artifact_id=15588
    3. Company personnel at designated site (see Demonstration Deployment below) during EC09 Demonstration.

    Accreditation

    Selected responders shall work directly with the sponsor to coordinate accreditation of the computers and software that they will use to provide the SAS.

    Test and Integration

    Selected responders shall work directly with the sponsors to conduct Technology Integration Experiments (TIEs).

    Demonstration Deployment

    Selected responders shall provide an SAS server for deployment at a location identified in negotiations with OGC and sponsor approval.

    Submission Documentation (Not to exceed 2 pages)

    Company Information

    Respondents shall provide an indication of their qualifications to participate.

    Financial Information

    Respondents shall provide a single $US figure for their reimbursement. WBS breakouts are not required.

    Personnel

    Respondents shall identify personnel who will work the program and provide a brief summary of their qualifications.

    Schedule

    17 April RFP/RFQ Reopened - SAS Solicitation announced
    27 April 0900, EDT Responses Due to techdesk [at] opengeospatial.org
    29 April Selected respondents notified and contract work begins

    4 May Kickoff (Teleconference or in person at OGC Office, Herndon, VA)
    6 May Security Accreditation Documentation input sent to Sponsor
    20 May First Technology Integration Experiment (TIE) conducted

    26 June Open Internet TIEs concluded

    10 July Demonstration Hardware and software installed at location TBD.
    31 July EC09 Field Portion concludes

    14 August Final Report information provided to sponsor

    Inquiries and Questions

    All questions are to be sent to techdesk [at] opengeospatial.org. They will be answered daily as Clarifications and posted to this webpage.


    Comment: 
     
    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: 

    OGC Request for Quotation for Empire Challenge 08 Pilot

    Status: 

     

    Slides for the Bidders Conference on 16 January are now available.

    Description: 

    The Open Geospatial Consortium, Inc. (OGC) has issued a Request For Quotations and Call for Participation (RFQ/CFP) to solicit proposals in response to requirements for the Empire Challenge 08 Pilot (EC08 OGC Pilot).

    The EC08 OGC Pilot is sponsored by a US agency which will provide cost-sharing funds to offset expenses associated with the initiative. The sponsor and the OGC intend to involve as many participants in the initiative as possible and thus are soliciting proposals that will enhance and/or make use of the initiative outcomes. This RFQ/CFP is soliciting partners to provide and deploy hardware / software and to collaborate on the final technology design for the pilot network. Personnel without clearances will be able to install and maintain software on the network. Responses are due by January 24, 2008 and the Pilot Kickoff Meeting will be held the week of February 26-28, 2008, in the Washington, DC area. Technology deployments will be complete by June 27, 2008, followed by a four-week demonstration phase in July.

    The EC08 OGC Pilot will examine the suitability and performance of OGC Sensor Web Enablement (SWE) and OGC Web Services (OWS) standards for providing open management of and access to sensors of varied types and Web service access by analysts to the resulting data and products. Several use cases and supporting workflows are provided to enable understanding of the design of the pilot. The use cases involve both sensor management and exploitation by a targeting analyst.

    Downloads: 
    You may download a complete package of the RFQ and all the annexes and templates:
    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: techdesk [at] opengeospatial.org (Click here to submit comments).
    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: 

    OGC Seeks Comment on candidate GeoSPARQL 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 specification 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®) seeks public comment on the candidate OGC “GeoSPARQL: A Geographic Query Language for RDF Data” Standard. The candidate OGC GeoSPARQL standard defines spatial extensions to the W3C's SPARQL protocol and RDF query language. 

    SPARQL is a protocol and query language for the Semantic Web. SPARQL is defined in terms of the W3C's RDF data model and will work for any data source that can be mapped into RDF, which potentially includes sources of geospatial data. The OGC GeoSPARQL standard supports representing and querying geospatial data on the Semantic Web. GeoSPARQL provides the foundational geospatial vocabulary for linked data involving location and defines extensions to SPARQL for processing geospatial data. This standard serves as a common target for vendors to implement and provides rich functionality for building geospatial applications.

    GeoSPARQL follows a modular design. A core component defines top-level RDFS/OWL classes for spatial objects. A geometry component defines RDFS data types for serializing geometry data, RDFS/OWL classes for geometry object types, geometry-related RDF properties, and non-topological spatial query functions for geometry objects. A geometry topology component defines topological query functions. A topological vocabulary component defines RDF properties for asserting topological relations between spatial objects, and a query rewrite component defines rules for transforming a simple triple pattern that tests a topological relation between two features into an equivalent query involving concrete geometries and topological query functions.

    The candidate OGC GeoSPARQL 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: 

    OGC Seeks Comment on Geography Markup Language 3.3 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®) seeks public comment on the candidate version 3.3 of the OGC Geography Markup Language (GML). GML 3.3 builds on GML 3.2.1, published by ISO as ISO 19136:2007, and extends GML with additional schema components based on requirements requested by various domains of interest. For example, the 3d modeling community suggest the addition of triangular meshes (TINs) to GML. GML 3.3 is fully backwards compatible with GML 3.2.

    GML defines an XML data encoding for geographic data and a grammar to express models of such data using XML Schema. GML has come into wide use since it was first adopted as an OGC standard in 2001 (http://www.ogcnetwork.net/gmlprofiles for examples). GML is the standard that enables information communities and other standards organizations such as the Internet Engineering Task Force (IETF) and OASIS to insert geospatial elements into their standards and be confident that their standards will be compatible with mainstream information infrastructure methods of conveying spatial/temporal information.

    Some of the changes between the previous version 3.2.1 and 3.3 are:

    • Support for additional date representations based on ISO 8601 (Representation of dates and times)
    • Support for an additional, compact encoding of commonly used geometry types
    • Support for a new encoding of Triangulated Irregular Networks (TINs)
    • Support for Linear Referencing
    • Extensions to the XML encoding rule
    • Support for grids used by the meteorological and ocean observation communities

    All extensions are made in separate XML namespaces to support a modular use of components from the GML schema.

    Information on the change requests addressed in GML v3.3 can be found athttp://external.opengeospatial.org/twiki_public/GML/ChangeRequests. The candidate OGC GML v3.3 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: 

    OGC Seeks Comments on "NIL Extension" to Geography Markup Language (GML)

    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: 
    Fri, 11/23/2012 - 05:00
    Description: 

    The Open Geospatial Consortium (OGC®) seeks public comment on the candidate "GML-NIL profile" of the OGC Geography Markup Language (GML) Encoding standard. GML is a widely used XML grammar for encoding information about geographical features. The GML-NIL profile provides a way to allow data providers to make a best effort to supply data according to an application schema, even if they do not have values for all feature properties. This is achieved by marking the application schema as a whole as ‘nillable=true’ and using OGC ‘nil’ URIs in links for missing data. This reverses the usual pattern which has a default value of nillable=false.   

     

    The GML-NIL pattern of use has been used informally for several years in Earth and environmental science applications, and this candidate standard merely aims to formalize and document the practice. It is expected to be useful in many applications where a heterogeneous community wishes to enable participation by a wide variety of members with different capabilities and data sources. The submission team is composed of members of the GeoSciML project.

     

    The candidate OGC GML-NIL standard documents are available for review and comment below.

    Downloads: 


     Nillable GML (12-110)   

     



    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 Seeks Comments on Candidate GeoAPI 3.0 Interface Standard

    Status: 
    Please note: This Request is scheduled to close on 1 May 2010.
    Description: 

    The Open Geospatial Consortium, Inc. (OGC®) seeks public comment on the candidate OGC GeoAPI 3.0 Application Programming Interface.

    The GeoAPI standard provides a set of Java language interfaces based on the ISO 19100 series of geospatial abstract models for metadata and feature geometry as well as two OGC Abstract Specifications for metadata and coordinate reference systems. In addition to producing this set of Java language interfaces, the OGC GeoAPI 3.0 Standards Working Group is producing a test suite through which developers implementing the Java interfaces can test their implementations.

    The GeoAPI project emerges from the earlier OGC Geographic Objects effort and is the result of the collaboration of participants from various institutions and software communities. The GeoAPI project's goal is to provide a set of interfaces in the Java language to help software projects produce high quality geospatial software. This work is not expected to cover all OGC standards.

    The candidate OGC GeoAPI 3.0 Interface Standard and information on submitting comments on this document are available below. The public comment period closes on 1 May 2010.

     

    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: 

    Pages