Open Geospatial Consortium

Submission Date: 2022-01-23

Approval Date: 2023-05-10

Publication Date: 2023-05-11

External identifier of this OGC® document:

Internal reference number of this OGC® document: 05-020r29

Version: 29.0

Category: OGC® Policy

Editor: Scott Simmons

Technical Committee Policies and Procedures

Copyright notice

Copyright © 2023 Open Geospatial Consortium

To obtain additional rights of use, visit


This document is an OGC Policies and Procedures Document. The document is subject to change based on membership requirements and motions. Please note that the OGC “Technical Committee Policy Directives” should be also be read. []

Document type: OGC® Policy

Document subtype:

Document stage: Approved

Document language: English

Table of Contents

1. Introduction

1.1. About the OGC

The Open Geospatial Consortium (OGC) is an international consortium of organizations and individuals driven to make geospatial (location) information and services FAIR - Findable, Accessible, Interoperable, and Reusable. More information is available on the OGC website.

The OGC was formed to undertake a common objective that is beyond the resources or capabilities of any single organization, that is, to provide a collaborative, consensus forum for the discussion and resolution of interoperability issues in the geospatial domain. The work of the consortium is based on volunteerism.

1.2. This Policies and Procedures Document

The OGC provides a collaborative, consensus process for developing and approving open, international Standards and supporting content for the geospatial domain, collectively known as OGC Products. To guide the OGC Product development and approval process, a member-approved Policies and Procedures document for the Technical Committee (TC) is required.

This document describes the TC Policies and Procedures (TC PnP). The TC has been granted authority to operate by the OGC Bylaws. The TC is composed of individuals representing organizations that are duly recognized members in good standing of the OGC.

As the needs and purpose of the TC change, changes to these policies and procedures are approved by an electronic vote of the Voting Members of the OGC TC. These policies and procedures may be augmented or clarified by Policy Directives issued and approved by the TC or the Executive Planning Committee (EPC). Such directives are databased and hyperlinked to/from the appropriate portion of this document.

The OGC Principles of Conduct govern personal and public interactions in any TC activity.

2. Conventions and supporting resources

This document is organized to first describe the structure and policies for the TC and its subgroups, then to describe the specific process by which OGC Documents and Products are developed and approved per the policies. Because many processes are shared by subgroups and Product lifecycles, cross-references within this document are provided to minimize duplication of content.

The TC PnP is supported by additional resources to refine or implement policy.

2.1. Policy Directives

At times, the Technical or Planning Committees may identify new policies or changes to existing policies that should be made official on a more rapid basis than approval of a revision to a policy document. Such a new policy is known as a Policy Directive. Policy Directives are accessible from the OGC website Policy Directives database.

Policy Directives are sequentially ordered and more recent Directives may invalidate older Directives. Further, older Directives may now be incorporated into these Policies and Procedures.

2.2. Intellectual Property Rights Policy

OGC’s Intellectual Property Rights (IPR) policy helps minimize the possibility of inadvertent infringement of the IPR of Members and third parties using or implementing any OGC Standards. OGC’s IPR policies reflect the mainstream of current standard-setting best practices.

2.3. Compliance Program Policies and Procedures

The Compliance Program operates as part of the Standards development process to provide resources for the testing of implementations against OGC Standards. The Policies and Procedures for the Compliance Program describe the roles and responsibilities, compliance testing procedures, development of test packaging, and policies for developing and releasing the software used for testing.

2.4. Document templates

The preferred repository of OGC document templates is found in the templates GitHub repository. Templates in Microsoft Word format are also available on the OGC Portal. All templates are annotated to assist in document preparation.

2.5. Writing style guidance

OGC maintains a style guide in the templates repository. This guide is not a formal policy document, rather it is intended to assist authors and editors in developing content for OGC documents in a consistent manner. The style guide is periodically updated and expanded.

3. The Technical Committee

3.1. Purpose

The TC provides an open forum for professional discussion of issues and items related to the consensus development and/or evaluation and approval of candidate Standards and revisions to existing adopted OGC Standards that provide the ability to build and deploy interoperable geospatial solutions in the larger IT domain.

More specifically, the OGC Bylaws authorize the TC to perform the following functions:

  • development of Consortium Standards through a cooperative consensus process involving the Members;

  • creation of its own internal organization and process, subject to the review and approval of the EPC: such organization and process may involve the creation of such Working Groups, Subcommittees, or subgroups as the TC deems necessary;

  • development and approval of other document types as defined in the TC PnP;

  • coordination and convening of joint subcommittees, working groups, or other subgroups with external organizations; and

  • presentation of recommended Standards and any other related official documents to the EPC for approval.

3.2. Composition

The TC has the following composition:

  • representatives of all member organizations of the OGC;

  • the TC Chair; and

  • other individuals deemed appropriate by the OGC Board of Directors or EPC.

There is no limit to the number of TC representatives for any OGC Member organization.

3.3. Roles

The TC Members are organized into a number of roles. Members might have multiple roles. The following roles are formally part of the TC hierarchy.

3.3.1. TC Chair

The TC Chair is responsible for facilitating the progress and work of the TC. The TC Chair is a post held by appointment of the OGC President, to lead the activities of the TC. The TC Chair is an unbiased member of the TC, and therefore does not vote on Items and Issues except as noted below. The TC Chair shall ensure the following:

  • attendance is taken of TC Members, Voting TC Members, and their substitutes and proxies at each meeting;

  • minutes are kept of TC meetings, and distributed by OGC communication as soon as is practical after the meeting (NOTE: minutes may comprise notes and recorded actions in a slide set, text in a document, or issues lodged in OGC Collaboration environments);

  • TC meetings are announced with appropriate notice (no less than four months) and that a master schedule is initially published on the OGC website at least six weeks prior to each meeting;

  • TC meetings are facilitated in general;

  • a file of TC meeting minutes and all other distributed materials is kept;

  • all electronic mail discussions are kept on file;

  • the EPC and Board of Directors are kept appraised of the current business of the TC;

  • TC resolutions for recommendation to the EPC are brought to the attention of the EPC;

  • the various actions of the TC are issued and processed in a timely, orderly manner; and

  • in the event of a tie vote on any given Item or Issue for which a simple majority vote is required, the TC Chair has the right to cast the deciding vote.

3.3.2. TC Representative to the EPC

As stated in the Bylaws of the OGC, the OGC TC has the right to seat two representatives on the OGC EPC. Up to seven representatives may be available in a “pool” and the TC Chair will work with the representatives to choose the two to attend a specific EPC meeting.

The role of a TC Representative to the EPC is to bring issues of concern to the general TC membership to the attention of the EPC and to keep the TC apprised of the activity of the EPC, as follows:

  • accept documented issues from TC members and bring these forward at EPC meetings;

  • provide a report to the TC of the activities that take place at EPC meetings no later than two weeks following a EPC meeting;

  • be involved in discussions related to the ongoing work and issues in the TC; and

  • vote.

The election of these representatives will be held according to the following rules:

  • nominations will be made from the ranks of Voting TC Members (an individual or an individual representing an organization already holding a seat on the EPC cannot be nominated);

  • there must be at least one nominee for each vacancy;

  • the nomination must be accepted by the nominee;

  • each Voting TC Member may vote for one candidate per vacancy to be filled; and

  • the representatives will be selected in the order of most votes received to fill the available positions.

The term of office for TC representatives to the EPC shall be as recommended by the TC with a maximum term of two years. In the case of resignation, removal, death, or termination of TC Membership of a representative, the rules for election will be invoked to fill the vacancy. Also, the TC Chair may determine that a given TC representative to the EPC is not fulfilling their obligations, such as not attending EPC meetings on a regular basis. In such a case, the TC Chair may ask the TC representative to resign and the rules for election will be invoked to fill the vacancy.

3.3.3. Subgroup Chair

Each subgroup of the TC shall have at least one chair. More details on this role is in the Subgroups section.

3.4. Structure

The TC is the primary group where OGC Standards and many Products are developed, discussed, approved, and maintained. The TC members are responsible for the development and maintenance of all Standards and related technical documents and supporting deliverables. The TC membership includes Voting TC Members, non-voting TC Members, and Invited Guests, per the OGC Bylaws.

The TC contains a number of Subgroups.

3.5. Relationship with other groups

TC activities rely upon collaboration with other groups, inside and outside the OGC.

3.5.1. Executive Planning Committee

The Executive Planning Committee is a committee of the OGC per the OGC Bylaws and comprises representatives from OGC Strategic and Principal members. The EPC is focused on strategic oversight and leadership of standardization activities. All Standards, Best and Community Practices, and TC policies are recommended by the TC for approval by the EPC to become official positions of the OGC. EPC approval occurs via the EPC Policies and Procedures.

The EPC also may create Policy Directives that govern TC activities.

3.5.2. OGC Architecture Board (OAB)

The OGC Architecture Board (OAB) is a committee of the OGC per the OGC Bylaws and comprises representatives from OGC Membership who represent themselves, not their organizations. The OAB is tasked with maintaining consistency of the OGC Standards Baseline and evaluating candidate Standards for their compliance with the Modular Specification, among other tasks.

All candidate Standards must be reviewed by the OAB and approved for release for public comment by the OAB prior to starting the formal TC approval process.

3.5.3. Collaborative Solution and Innovation Program

The OGC Collaborative Solution and Innovation (COSI) Program is a forum for OGC members to solve difficult geospatial challenges via a collaborative and agile process. OGC members (sponsors and technology implementers) come together to solve problems, produce prototypes, develop demonstrations, provide best practices, and advance the future of standards through performance of COSI Initiatives.

Outcomes of COSI Initiatives may ultimately result in changes to or new OGC Standards. Initiative participants develop Engineering Reports for review and approval by the TC. These Engineering Reports may include draft specifications which can be used as contributed material for use by an existing or charter of a new SWG.

3.5.4. Authoritative Standards Development Organizations

An Authoritative Standards Development Organization (SDO) is an organization which operates on a consensus basis to develop Standards and which has been designated to be an Authoritative SDO by the EPC. An Authoritative SDO develops key foundational Standards which provide a basis for conceptual and implementation Standards created by the OGC. These foundational Standards may be approved to be part of the OGC Abstract Specification. A list of Authoritative SDOs shall be maintained by the TC Chair. ISO is already considered to be an Authoritative SDO.

The Authoritative SDO shall be notified if one of its Standards is proposed by the OGC to be a Topic of the Abstract Specification. The Authoritative SDO shall have the opportunity to reject the OGC proposal, in which case the Authoritative SDO Standard may still be used as a normative reference by other OGC standards, but will not be a part of the OGC Abstract Specification. There is no requirement that the Authoritative SDO provide its Standard to the OGC by any basis other than the normal distribution mechanism for the Authoritative SDO, although provision of the Standard for no fee is preferred.

3.5.5. Other Liaison Partner Organizations

OGC maintains liaison or partnership agreements with other organizations which can contribute to the mission of OGC. Such partnerships may include reciprocal membership in the respective organizations such that the organization is a member of the OGC and thus the TC.

Liaison representatives represent the partner organization in the TC and not the employer of that representative. For purposes of TC procedures, these partner organizations have the same rights as any other OGC member at the respective membership level.

3.6. Operational environment

3.6.1. Virtual organization

OGC is a virtual organization. All members operate from their own work environments and leverage OGC resources to accomplish the work of the Consortium. Formal OGC-organized meetings as well as member-organized meetings occur from time to time and these events may bring members together in a physical setting.

3.6.2. Portal

An electronic Portal is managed by OGC to provide a common platform for members and staff to execute the business of the consortium. This platform manages the following items:

  • files associated with OGC work (both Standards and COSI activities);

  • votes for the TC and subgroups;

  • member organization and representative information;

  • records of member participation and status in Working Groups and COSI Initiatives;

  • list and files associated with liaison organizations; and

  • links to external resources that support OGC work (such as file repositories, wikis, etc.).

Every OGC member organization has a portal account and manages the access of its specific representatives. Portal permissions are governed by the role of each account holder. The role is associated with the level of membership and agreement to abide by the Intellectual Property Rules of SWGs and COSI initiatives.

3.6.3. Email reflectors

The TC will have one or more email reflectors to communicate with or between TC members. The TC-Announce email reflector will be used for all official communication from the TC Chair to the TC.

3.6.4. Collaboration environments

In addition to the OGC Portal, OGC maintains collaboration environments for all types of OGC activities. Primarily, these environments are GitHub or GitLab instances. OGC Working Groups may choose to use one or more collaboration environments to perform their work. File storage, issue tracking, content version management, and supporting documentation are all permitted to be managed in these environments.

Any TC subgroup can request a dedicated collaboration environment for the purposes of advancing its work. These environments can be public or private. Environments managed by IPR-controlled subgroups (such as Standards Working Groups) must vote to approve making their environment public.

Every public collaboration environment shall include the following contribution statement on the landing page of the project environment (e.g., in the file for GitHub).

The contributor understands that any contributions, if accepted by the OGC Membership, shall be incorporated into OGC Standards or other documents and that all copyright and intellectual property shall be vested to the OGC.

3.7. Appeals Process

Appeals by any member to a decision made at the subgroup level can be brought to the TC Chair for consideration. Further appeal can then be made before the OAB. Each appeal or issue will be taken on a case-by-case basis, but rulings made by the OAB with approval of the Executive Planning Committee that affect the process will be reflected in these Policies and Procedures. If the member making the appeal is not satisfied by the decision made at the OAB level, the OGC Board of Directors may be presented with the case for final deliberation.

3.8. Privacy considerations

TC members have access to personal information about other members. This information is stored in the OGC Portal and all participants in the OGC agree to having this information available to other OGC members. However, in the course of conducting TC business, a TC member shall not share contact information or a record of that member’s activities in the OGC without the permission of that member.

Public meeting minutes shall not contain attribution of a specific TC member. For instance, the results of a subgroup vote can be circulated to the public, but the names of the member making and seconding the motion shall not be disclosed.

The TC agrees to abide by the privacy regulations in the jurisdiction in which a TC activity occurs.

4. Subgroups

The Technical Committee includes subgroups to:

  • evaluate and provide guidance on standardization and architecture issues;

  • carry out the development of new documents and related products;

  • evaluate OGC activities; and

  • provide a forum for the discussion and documentation of requirements for interoperability.

Subgroups will be formed, carry out their work, and when their work is completed, be inactivated or dissolved.

4.1. Membership in TC Subgroups

A subgroup is composed solely of representatives of current OGC members and (potentially) invited guests. The following rules apply to membership in subgroups of the TC.

  • Any OGC member organization may send representatives to attend any meeting of the TC or any subgroup of the TC. The exception is for SWGs. In order to attend a meeting of a SWG, the representative must have opted into the SWG in order to participate (Participating in a SWG (opting in and out)).

  • Invited guests may actively participate at the sole discretion of the subgroup’s chair. That is, in the interests of ensuring the efficient operation of any meeting, the chair may limit or eliminate the opportunity of any invited guest to participate in discussion at any meeting. Invited guests cannot vote.

4.2. Working Groups

There are two types of Working Groups in the TC: Domain Working Groups (DWGs) and Standards Working Groups (SWGs).

4.2.1. Domain Working Groups

A DWG is a group of individuals composed of members of the TC and invited guests with the specific intent of discussing and/or solving some particular problem or problems in a particular domain or technology arena for recommendation to the TC. Key functions of the DWG are to:

  • have a formal approved charter that defines the DWG’s scope of activities;

  • provide a forum for discussion and documentation of interoperability requirements for a given information or user community;

  • provide a forum to discuss and recommend document actions;

  • develop Change Request Proposals (CRPs) for existing OGC Standards;

  • develop documents with the intent seeking approval by the TC for release of these documents as OGC Technical Papers, Discussion Papers, or Best/Community Practices;

  • hold meetings with informational presentations and discussions about the market use of adopted OGC Standards; and

  • have missions and goals defined by the TC.

A DWG does not work on OGC Standards process submissions, candidate Standards, or revisions to existing OGC Standards. However, a DWG can develop change requests as documented interoperability requirements that can then be submitted as work items to a SWG. A DWG may initiate an activity that becomes realized as a new SWG.

By default, a DWG will allow public collaboration, such as in teleconference, email discussions, or in Collaboration environments. A DWG has the option to make a motion to the TC to remove public participation in the DWG.

4.2.2. Standards Working Groups

A SWG is a group of individuals composed of members of the TC and invited guests with the specific intent of Standards development or on making revisions to one or more existing OGC Standards.

Specific work items for a SWG include:

  • maintain and update a formal approved charter that defines the SWG’s Scope of Work and estimated timeline for completion of the work;

  • develop a new candidate Standard in preparation of that document as an OGC consensus Standards process submission;

  • move the candidate Standards through the approval process included in this TC PnP; and

  • consider official Change Request Proposals to an existing OGC Standard and make changes to the Standard as necessary.

Voting is limited to those Members who are either 1) Charter Members of the SWG or 2) have formally opted into the SWG and have waited the mandatory 30-day waiting period and requested to be voting members.

SWGs are persistent unless the SWG voting members decide otherwise and choose to inactivate the SWG once they have completed their work as described in their charter or choose to end the work.

4.3. Subcommittees

A subcommittee (SC) is a standing group of individuals composed of members of the TC and invited guests, with a mission to provide recommendations to the TC in some general area. A Subcommittee does not generate a Standard nor does it work on a Standard.

SCs are long-standing entities with general portfolios or missions. OGC staff can chair SCs. Any OGC member can attend a SC meeting and participate.

A SC may be proposed by any TC member and approved via charter.

There are two additional subcommittees with specialized purposes: the OGC Naming Authority and the Document Team.

4.3.1. OGC Naming Authority

The OGC Naming Authority (OGC-NA) controls the assignment of OGC Names to resources of interest in geographic information infrastructures. In the terminology defined in ISO 19135-1:2015, OGC-NA is the Control Body for the registry of OGC Names: the OGC Definitions Server. The registry consists of multiple registers, each focuses on a specific aspect of a domain. As many OGC Standards and other products include reference to or use of registered content, the OGC-NA works directly with the owning groups of those products in publication of resources. There are separate OGC-NA Policies and Procedures.

4.3.2. Document Team

The Document Team (DocTeam) works with OGC staff and OGC members to define, enforce, and educate OGC members on documentation guidelines (format, templates, style) within the OGC. The DocTeam also works with OGC staff and OGC members to manage the document publishing infrastructure used by OGC.

4.4. Regional Forums

A Regional Forum is a subgroup dedicated to advancing OGC topics in a particular region of the world. The Forum can cover international, national, or sub-national interests and one particular region may be part of multiple Regional Forums.

A Regional Forum may be proposed by any TC member and approved via charter.

4.5. Formation of a subgroup

At any time, a group of Members may determine that a new area of technology or domain exploration is required. This interest may lead to the formation of a new OGC subgroup.

4.5.1. Ad-hoc meeting(s)

Any group of OGC members can schedule and advertise an ad-hoc meeting. The interested members develop a basic agenda and draft scope for the work of the group and call for an ad-hoc meeting at a scheduled TC event or by teleconference/webinar. At this ad-hoc meeting, the participants continue to frame the mission and the scope for a proposed new subgroup. Participants determine whether there is adequate OGC member interest to actually form a new subgroup.

4.5.2. COSI initiatives

A COSI initiative may be structured to investigate or prototype a draft specification that could form that basis for an OGC candidate Standard. In such cases, the initiative leader(s) can notify the TC of the intent to develop a draft specification and begin work on a SWG charter. Such a notification allows OGC members to observe the initiative work and be more informed of the potential for standardization as an outcome of the work.

4.6. Charter process

All OGC subgroups must have a charter approved by the TC. The charter starts with the mission and scope of the subgroup as initially envisioned, but may be updated as the subgroup work continues.

4.6.1. Development of a proposed subgroup charter

The primary function of the ad-hoc meetings is to write a charter for the new subgroup. The charter documents the mission, scope, roles, and responsibilities of the proposed subgroup. Drafts of the charter can be shared with other members for review and comment. The templates for the DWG and SWG Charter documents can be found in the templates GitHub repository.

Charters can also be drafted during the execution of COSI initiative without the requirement of holding an ad-hoc meeting as the initiative meetings will serve the same purpose.

Subcommittees and Regional Forums use the DWG template with the language modified to fit the type of subgroup being chartered.

4.6.2. Approval of a subgroup charter

Once the charter is completed and agreed to by the members of the ad-hoc meeting or initiative participants, the following process is followed for approval of the Charter. NOTE: For a SWG charter, please review Policies related to SWGs for specific requirements related to the formation of a SWG.

  • The charter is reviewed by the TC Chair. The TC Chair shall provide edits and comments in a timely manner.

  • The charter submitters consider the TC Chair comments and edits the charter as necessary.

  • The charter is assigned an OGC document number and posted to Pending Documents.

  • The availability of the draft charter is announced to the TC and to the public and a three-week public review period begins. There is a formal press release with a general call for comments.

  • The draft charter is presented to the TC at a plenary or in a web meeting.

  • Comments received during the comment period are considered by the submitters and any necessary changes to the draft charter are completed.

  • The modified charter is posted to pending as an update with a new revision number. The TC Chair shall notify the membership that a revision of the charter has been posted.

  • A 45-day electronic vote followed by a EPC approval is held per the rules for a Required TC electronic vote.

4.6.3. Changes to a subgroup charter or recharter of a subgroup

The members of a subgroup may at anytime determine that a change to the charter is necessary. Such changes may be done at any time. The subgroup members need to approve the amended charter by a formally recorded vote. Once the subgroup members approve the amended charter, the Chair shall inform the TC Chair who will then assess if the changes are a natural progression of the work of the subgroup or a major shift in scope of the subgroup.

  • If the TC Chair judges the changes to reflect a natural progression of the subgroup work, then the TC Chair shall notify the full membership of the proposed changes. The amended charter shall be posted to pending documents for a 3-week member review and comment period. The review period is followed by an approval vote by the TC at a Closing Plenary or through an email vote.

  • If the TC Chair judges the changes to reflect a major shift in scope of the subgroup, then the revised charter shall proceed through the same approval process as a new subgroup charter in Approval of a subgroup charter.

  • When the recharter vote is requested to start by the TC Chair, the TC has the option to override the TC Chair vote type recommendation. For instance, if the TC Chair recommends a vote at the Closing Plenary, the TC can demand instead that a full 45-day electronic vote be held because the TC feels the scope of the revised charter is too different from the original charter.

4.6.4. Establishment of subgroup

Once the charter is approved, OGC staff will create a Subgroup work environment. The creation of the subgroup will be publicized to the TC and the general public with an invitation to participate.

4.7. Roles in a subgroup

Subgroups include special roles for administration of the subgroup as well as development of subgroup documents and products.

4.7.1. Chairs

Every subgroup must have at least one chair. If the subgroup has multiple chairs, which is recommended, each chair shares in the duties. The chairs may decide amongst themselves to have one person act as a primary chair, but all chairs are equally-designated. There is no limit to the number of chairs, but most subgroups work best with three or fewer chairs.

The chair of a subgroup is responsible for organizing the activities of that subgroup, including:

  • arranging meetings at times and places convenient for the subgroup membership;

  • announcing meeting arrangements to the entire OGC membership, including a preliminary agenda for the meeting, at least 2 weeks in advance of the meeting;

  • encouraging broad participation of the OGC membership;

  • ensuring that actions from the meeting are recorded (NOTE: this recording may comprise notes and recorded actions in a slide set, text in a document, or issues lodged in OGC Collaboration environments);

  • capture a list of persons attending the meeting whenever a vote or quorum-necessary decision is made (the attendance logging feature of the OGC Portal or the list of attendees from the virtual meeting tool is acceptable);

  • sending electronic reminders to action holder’s;

  • ensuring the smooth and orderly running of the meeting;

  • reporting on subgroup activities to the TC (and EPC if requested), including presenting subgroup recommendations (if any);

  • keeping the TC Chair apprised of the progress of the subgroup; and

  • recommending schedule and work plan and managing subgroup resources to accomplish the mission of the subgroup.

4.7.2. Editors

OGC document Products have one or more editors. Those editors are identified on the cover page of the document and in the document metadata. Editors have access to additional functions in OGC member resources, such as GitHub or GitLab repositories.

4.7.3. Member

Subgroups may have formal members. Those members are drawn from the TC. Not all subgroups require membership in that subgroup to participate in meetings or email discussions organized by the subgroup. Specific membership rules for SWGs are covered in Member types.

4.8. Election of subgroup chairs

The first order of business of a new subgroup is to elect one or more chairs. Chairs may also be elected over the course of the subgroup’s active operation. The chairs must be from different member organizations. Chairs are nominated and elected as follows:

  • the TC Chair or existing subgroup chair(s) call for nomination of chairs via the TC and subgroup email reflector (see Subgroup work environment) and, optionally, in a TC or subgroup meeting for an open period of 30 days (most candidate chairs are self-nominated); and

  • the TC Chair or subgroup chair(s) hold an election for the nominated chair(s) in a meeting or via the subgroup email reflector using a Unanimous consent vote.


    if more than four chairs are to be included in a vote, the TC Chair must be notified and in most cases, an election to select four chairs will be run by the TC Chair with each voter permitted to identify their top four nominees. Those four nominees with the most votes will be elected.

The election of the chair does not require TC approval. Once the election is complete, the new TC Chair shall notify the subgroup of the results of the election.

Chairs are elected to serve for a period of two years. At least one month before the expiration of the chair term, the subgroup must call for chairs via the TC email reflector and, optionally, in a subgroup meeting. Existing chairs may run for re-election. The subgroup then holds a vote to elect or confirm re-election of the chair(s) in a quorum-valid meeting or electronically.

4.9. Voting in subgroups (excluding SWGs)

Voting in subgroups (excluding SWGs, see SWG voting) is by simple majority of OGC Members present at the subgroup meeting, not just Voting TC Members, with the caveat that no OGC Member organization may cast more than one vote in a subgroup vote.

Subgroups should be able to use all of the expertise at hand in arriving at recommendations. All TC member organizations can be represented and vote at subgroup meetings in order to allow the expression of all members' opinions.

4.10. Subgroup work environment

Subgroups work in the TC Operational environment. Portal resources, email reflectors, and collaboration environments will be established for each subgroup as per the TC.

4.11. Subgroup internal organization

Subgroups may wish to develop their own smaller working entities (subgroups of the subgroup). Typically, these have been of shorter duration to deal with specific issues in DWGs or edit parts of a candidate Standard in SWGs. A subgroup may organize such entities at-will and request work environments for those entities. TC approval is not required for internal organization of a subgroup.

4.12. Inactivation of a subgroup

The TC Chair will provide a list to the TC at least once a year of those subgroups that have not met in the previous 18 months. The TC will then vote to determine if these groups should be continued, disbanded, or possibly combined with more active groups.

4.13. Policies related to SWGs

A SWG may be formed whenever:

  • three or more members (one member of whom must be a TC voting member) provide a submission for a candidate Standard;

  • one or more Change Request Proposals have been submitted to the public OGC Change Request repository that suggest the need for a new SWG;

  • three or more members (one member of whom must be a TC voting member) wish to define and document a new candidate OGC Standard that will be submitted using the OGC Consensus Standards process; and/or

  • three or more members (one member of whom must be a TC voting member) wish to bring an external document into the OGC process and wish to collaborate to prepare this document for submission using the OGC Consensus Standards process.

The formation and execution of the work of a SWG is closely tied to the OGC Intellectual Property Policies. Members are strongly encouraged to read this Policy prior to forming or joining a SWG.

The policies and procedures defined below are in addition to the requirements to form and operate a subgroup.

4.13.1. SWG Charter and Task approval process

Whenever a SWG needs to be formed, the first order of business is to inform the TC Chair. The TC Chair will discuss the process and next steps. The submission team then writes a SWG Charter following the subgroup Charter process and additional rules for a SWG, as below. The Charter documents the scope of work, references, business value, and projected timeline for the new SWG. SWG are chartered to create a primary delivery (a new Standard), maintain that Standard, and optionally update, extend, or profile that Standard through a SWG Task approval process. At a minimum, the scope of the primary delivery is provided in the SWG charter.

IPR rules for a new SWG

Each SWG to be formed must agree to develop Standards that are Reasonable And Non-Discriminatory (RAND) Royalty Free per the OGC Intellectual Property Rights (IPR) Policies.

Persistent SWGs

By default, OGC SWGs are persistent until the SWG elects to become inactive or disband. Persistence supports the ability to maintain the Standard products of the SWG, work on multiple revisions of an existing OGC Standard, or to ensure that long-term collaboration with other SWGs can be maintained. There may be reasons why a SWG is chartered not to be persistent and such reasons must be described in the charter.

After a SWG completes its primary delivery, each new proposed SWG deliverable under its in-force charter shall be approved via the SWG Task approval process.

SWG to DWG Relationship(s)

During the chartering of a new SWG, a "home" or "parent" DWG must be identified to:

  • be a forum for non-IPR-protected discussion of requirements that are relevant to the SWG’s work;

  • determine when an inactive SWG needs to reactivate to correct or revise a Standard created by the SWG; and

  • work with the TC Chair to address the situation where OGC members are unable or unwilling to reactivate the SWG.

The SWG charter submitters must seek approval from the proposed home DWG for that DWG to function as the home. The DWG may approve this request using the normal DWG voting process. The home DWG must approve the relationship and be identified in the proposed SWG charter prior to the approval of that charter.

In some cases, a SWG is proposed to be formed at the same time as its home DWG is proposed. Under such circumstances, the proposed home DWG is identified in the SWG charter and is effective only if both WGs are approved.

Should either or both the SWG and the DWG wish to change the parent relationship for a SWG, both WGs shall approve dissolution of the relationship through respective votes and the SWG shall identify and seek approval of a new home DWG.

SWG Charter Approval and Formation

The TC Chair will work with members to write the draft SWG Charter. Once a draft is completed, the charter review and approval process as defined in Approval of a subgroup charter shall be followed. For the purposes of charter development and approval, consider that the ad-hoc group and a submission team are equivalent in that a submission team is an ad-hoc group.

The SWG cannot begin business until the charter is approved.

SWG Task approval process

Any new work from a SWG after the primary deliverable must be approved by the TC as a new Task prior to start of that work. The new work can result in a new Standard or an update, extension, or profile of a Standard managed by the SWG.

The proposed Task must be presented to the TC at a plenary. Otherwise, a presentation will be developed and posted to the Portal. This presentation should cover the key aspects of the Task, especially the scope of work, the timeline, and the technical discussion related how the work relates to the Standard(s) developed by the SWG.

Once the proposed Task has been presented to the TC, the TC Chair will initiate a 21 day TC and public review of the proposed Task. If comments are received in the review period, the SWG shall consider the comments and reissue the proposed Task details, if necessary.

The proposed Task will be voted upon by TC Voting Members in a Closing Plenary or by a two-week email vote (see Voting forum and process). Once approved, the Task will be added to the SWG Charter and the updated Charter posted to the SWG Portal files. The SWG may now begin work on the Task.

4.13.2. Participating in a SWG (opting in and out)

Any OGC member representative can join a SWG at any time and participate in the work of the SWG. If a member wishes to participate, then the member representative must “opt-in” to the new SWG. Opting into a SWG is done via a registration page for that SWG. The registration page is available on the OGC Portal. The registration page will clearly state the IPR terms for the SWG as well as the Scope of Work.

If the member representative does elect to participate (opt-in), then there is a 30-day period during which the member representative can participate but cannot vote. During this 30-day period, the member representative can also elect to opt-out of the SWG and not be required to declare any IPR or essential claims.

Charter members of the SWG have opted-in to the SWG by agreeing to the SWG charter at the time of its publication.

Opting-out of a SWG: during the 30-day waiting period, any member representative may elect to opt-out of a SWG without having the Member having to declare any Necessary Claims. A member representative can opt-out by notifying the TC Chair.

4.13.3. Member types

The Roles in a subgroup apply to SWGs. However, SWG members can be further divided into three categories:

  • Charter member: a Charter member of a SWG supports the chartering of the SWG and agree to be a voting participant at the time of formation of the SWG;

  • Voting member: a Voting member has opted-in to the SWG (see Participating in a SWG (opting in and out)) and, at least 30 days after opting-in, informed the SWG chair that they wish to be a Voting member; Voting members must stay in good standing per the rules for SWG voting; and

  • Group Observer: a Group Observer is a non-voting member of the SWG, either because they have only recently opted-in or because they have not requested voting status; Group Observers cannot vote on any items in the SWG, but may express their opinions.

4.13.4. Responsibilities of the SWG Chair

In addition to the subgroup chair responsibilities as outlined for subgroup Chairs, the SWG Chair is responsible for organizing the activities of the SWG, including the following.

  • Maintaining SWG member status on the Portal.

  • Ensuring that issues are logged into the Subgroup work environment and these issues are prioritized and put into a roadmap for completion of a Standard. Further, that the chair ensures that the pertinent Standard roadmap is updated, agreed by consensus of the SWG members, and posted at least for each regularly scheduled TC meeting time.

  • Ensure that Submission of Change Request Proposals to OGC’s Public Change Request page are processed, including transferring the issues to the Subgroup work environment, if relevant.

Failure of the chair to provide these capabilities will result in the removal of the chair and the election of a new chair. If no suitable chair can be located, then the work of the SWG will be considered to be non-critical and the SWG will be inactivated.

4.13.5. SWG voting

SWGs operate under the same general rules as other subgroups of the TC, except that quorum is 1/2 of active voting members unless the SWG votes to have a larger fraction be quorum.

Caveat on Voting Rights – non-participation on a regular basis

Any member of a SWG who has voting privileges has a responsibility to participate in the meeting and email dialogues. Quorum for votes on any items or issues brought before a SWG is based on the number of voting members for that SWG. Ensuring quorum at SWG meetings is a vital aspect of the SWG being able to complete its work in a timely manner. Therefore, any SWG voting member who misses two consecutive SWG meetings (teleconference, face-to-face, or webinar) in which votes occur or misses two consecutive email or electronic votes shall lose their voting privileges and have their SWG member status changed from “Voting” to “Group Observer.”

The SWG Chair shall take roll call at the beginning of each meeting and determine quorum based on active voting members only. An inactive SWG voting member can become active again simply by attending the SWG meetings and participating. If regular attendance by a given voting member is an issue, that voting member may assign a temporary or permanent proxy to another SWG voting member or to the SWG Chair. The voting member may rescind that proxy at any time. A voting member can ask to change their status to "Observer" and still actively participate in the SWG.

4.13.6. Cross SWG communication

Many technical issues discussed in a SWG will require collaboration and communication with other SWGs. As long as the voting members agree to such cross SWG communication, then an open dialogue between two or more SWGs can occur on any specific technical issue.

4.13.7. SWG record-keeping

SWGs are expected to maintain their Portal records in a complete fashion, including presentations made at SWG meetings. Presentations in TC Meetings which the SWG permits to be viewed by general OGC membership should be stored in the TC Meeting folder for that SWG or in the SWG Portal project files with a symbolic link to the TC Meeting folder. All draft documents for SWG discussion should be in the SWG files until that point those documents are to be discussed in the TC. SWG documents for TC discussion or voting are to be uploaded to Pending Documents.

SWG use of collaboration environments

SWGs are free to use collaboration environments such as GitHub to store content of their candidate Standard, link that content to developing code, track issues, and manage the document development workflow and milestones. A SWG may also vote to allow non-OGC members to participate in the development of the Standard in the collaboration environment. Note that such a vote does not grant access to non-members to the OGC Portal nor does it give those non-members voting rights for SWG approval of any work.

The collaboration environment will be under ultimate control of the OGC. For example, OGC maintains organizational structures in GitHub and GitLab under which SWGs can create a project for their use. Non-OGC private repositories or projects may not be used for development of SWG deliverables.

The collaboration environment must clearly display a message on its home page (e.g., the README file in GitHub) that states the contributions to the work in the collaboration environment belong to OGC, as shown below.

The contributor understands that any contributions, if accepted by the OGC Membership, shall be incorporated into OGC Standards documents and that all copyright and intellectual property shall be vested to the OGC.

4.13.8. Public Release of SWG documents

At any time, the SWG voting members may agree to release any SWG in-progress technical document into a public forum or to another Standards organization for comment. Such an action requires a formal SWG motion and SWG vote as per SWG voting.

At any time, the SWG can vote to release an in-progress candidate Standard for public comment. Please remember that there is the official formal 30-day public comment period. However, a SWG is permitted to release an in-progress document early in the process in order to solicit input from the community. If a SWG votes to release a document for early public comment, it must coordinate with the TC Chair to generate a press release and properly create the Request For Comments (RFC) on the OGC website.

5. Meetings

This section describes the Policies and Procedures for meetings of the OGC Technical Committee and its subgroups.

5.1. Meetings of the TC

Technical Committee meetings shall be conducted under the general guidance of Robert’s Rules of Order. Meetings shall be facilitated by the TC Chair or other appointed representative(s) of the OGC. The TC currently holds three meetings per year. The number of meetings per year can be changed by a vote of the TC and the EPC or by direction of the Board of Directors.

TC meeting dates and locations will be announced as far in advance as possible but no less than three months in advance of the meeting. Announcements will be through formal OGC Communication. All recommendations, summary notes, presentations, and other meeting materials and records shall be posted to the OGC Member Portal.

5.2. Attendance at TC Meetings

Members of the OGC, Invited Guests, and non-OGC members are welcome to register for and attend TC meetings. TC Meetings may also include sessions that are open to the general public. Any TC member may send another representative of their organization as a substitute to a TC meeting and may assign Proxy for Voting.

5.3. Policy for Invited Guests

OGC staff or an OGC member may wish to invite one or more individuals from organizations who are not OGC members to attend an OGC TC meeting. Reasons for invitations may be to provide technical input, speak, or meet with OGC members and/or staff on items and issues germane to the work of the OGC.

Invited Guests (representatives of organizations that are not members of the TC) may actively participate in an OGC meeting at the sole discretion of the TC Chair. That is, in the interests of ensuring the efficient operation of any meeting, the TC Chair may limit or eliminate the opportunity of any invited guest to participate in discussion at any meeting.

All Invited Guest invitations and registration must be coordinated with the TC Chair and the OGC staff responsible for meeting logistics.

  • OGC staff or the subgroup chair provides a formal invitation to the individual with a copy to the TC Chair and the TC meeting support staff.

  • The TC Chair approves the invitation.

  • OGC provides the invited guest with a registration code.

  • The invited guest must register with the provided guest registration code.

  • Invited guests may or may not have to sign a non-disclosure agreement (NDA). For special meetings held in parallel with the OGC TC meetings, such as an OGC Interoperability Day, summits and workshops, or a Standards Coordination meeting, NDAs are not required.

The Invited Guest may or may not have to pay a meeting registration fee. OGC staff will work with the members to determine the fee structure for Invited Guests for any given TC meeting.

5.4. Policy for non-members

OGC meetings may be open to attendance of non-OGC members. Such attendance is at the discretion of OGC staff, the TC, and/or the EPC. Non-members can only attend DWGs, open sessions, or public sessions. Non-members who wish to attend a SWG must abide by the Policy for Invited Guests. OGC staff will work with the members to determine the fee structure for non-members for any given TC meeting.

5.5. Agenda and schedule of a TC Meeting

At least eight weeks before a TC meeting, a draft master schedule for that TC meeting will be posted to the public OGC web site. The agenda is managed by the TC Chair and OGC staff and will be modified prior to the meeting as appropriate. The TC Chair will maintain a master agenda that is available to members and which is generated from the agendas of each subgroup as they are populated.

The subgroup chairs shall work with the TC Chair to schedule sessions and set agendas. Subgroups cannot have alternative meetings that overlap temporally with the TC Meeting without approval of the TC Chair.

Each subgroup chair shall post an agenda to the meeting web site at least three weeks before the meeting. Subgroup chairs that fail to provide a proposed agenda by three weeks before the meeting may forfeit the right to meet during the course of regularly scheduled TC meeting times. Any subgroup can elect to have an ad-hoc meeting during the off-hours of a meeting (such as a breakfast or after-dinner session), but may not hold votes during those ad-hoc meetings.

Most TC and subgroup meetings include a virtual meeting option via online conference tools. These sessions are generally recorded for later use by OGC staff and OGC members. Guidance for such recording is as follows.

  • The members attending the meeting need to be notified that the meeting is being recorded. If there are objections, then the meeting shall not be recorded.

  • The recording shall remain members-only and shall not be available to the public. The exception is for open meetings in which the public is invited to attend.

  • All recordings shall be uploaded to the appropriate meeting folder on the OGC portal.

5.7. Subgroup Meetings

Subgroups may meet with any frequency that they feel is necessary to accomplish their work. These meetings may be virtual (online), teleconference, or in person. Meetings with anticipated votes must be announced at least two weeks in advance or scheduled to occur on a regular basis. All meetings must be reserved in the OGC Portal calendar.

5.8. Other Meetings

The TC or subgroups of the TC may organize other meetings on topics of interest to OGC’s mission, but which do not fulfill the purpose of regular TC or subgroup meetings. These meetings are organized on behalf of the TC or subgroup, may involve members and guests, and may have registration a fee terms on a basis that is best for the meeting.

6. Consensus and voting

OGC operates as a Voluntary Consensus Standards Organization. All actions that must be recorded as part of advancing work in OGC through its various review and approval stages require votes, either at the subgroup or TC level. Many of the actions that are performed to get to those vote stages, however, occur through "Rough Consensus" as described by the IETF.

Rough consensus is achieved when all issues are addressed, but not necessarily accommodated
— IETF RFC 7282

OGC subgroups and the TC work through technical issues by discussion: verbally, in email, tracked in GitHub issues, etc. Such discussions do not always have unanimous agreement, but when the chair or leaders of the discussion see general agreement, then the topic can be closed and the group can move ahead. There are no hard and fast rules to close a topic: the decision is left to the expertise of the chair or discussion leader. Ultimately, these discussions lead to a Standard or other work product which is voted upon by membership.

The table below summarizes the voting rules detailed in the remainder of this section.

Table 1. Vote types and allowed voters
Vote Type Who can Vote Forum Quorum Sufficiency Approval

Technical Committee

Approval of a Technical Paper, Discussion Paper, or Engineering Report

Any member




simple majority

Election of TC reps to the EPC

Any member




simple majority

Approval of a subgroup recharter

TC Voting Member




simple majority

Approval of a subgroup recharter

TC Voting Member




simple majority

Approval of a new SWG Task

TC Voting Member




simple majority

Approval of a new SWG Task

TC Voting Member




simple majority

Approval of early periodic review

Any member




simple majority

Approval of a periodic review action

TC Voting Member




simple majority

Approval of a periodic review action

TC Voting Member




simple majority

Approval of deprecation or retirement of Discussion Paper or Best Practice

Any member




simple majority

Approval to start electronic vote

TC Voting Member




simple majority

Recommendation for EPC approval

TC Voting Member




2X Yes:NO and 15% YES

Subgroup (other than SWG)

Election of chairs

Any member




simple majority

Recommendation to TC

Any member




simple majority


Election of chairs

Voting member




simple majority

Election of chairs

Voting member




simple majority

Recommendation to TC

SWG voting member




simple majority

Recommendation to TC

SWG voting member




simple majority

Release of document

SWG voting member




simple majority

Release of document

SWG voting member




simple majority

+For “Any Member” votes, only one member representative from a given Member Organization may vote.
++ "simple majority" includes no objections raised

6.1. Voting Thresholds

All thresholds for quorum, sufficiency, and voting are calculated to meet or exceed the fraction or number indicated. For example, a quorum of 1/3 of members means that exactly 1/3 or more members are required to meet quorum. 33.2% does not meet quorum, 33.3333 does.

6.2. Three Week Rule

For votes that require documentation, such as adoption of particular documents as Standards or documents to be released for public comment, documentation supporting the vote must be available to all members in the Pending Documents list on the Portal three weeks prior to the vote. The three-week rule clause ensures that Voting TC members have adequate time to read, distribute and gather comments on documents before voting on the document at the following TC meeting.

The TC may override the 3-week rule by a 2/3-majority vote of Voting TC members in attendance at a meeting.

6.3. Quorum

Quorum for meetings and electronic votes are specified for the TC and subgroups, below.

Quorum is always assumed for email votes as all eligible voters are subscribed to their respective group reflectors.

6.3.1. Technical Committee

The quorum for any meeting of the Technical Committee Members shall be 1/3 of the total Voting membership as comprised by the Strategic, Principal, and Voting members. If there is quorum, then a simple majority of the Voting TC Members present at a meeting shall constitute a positive vote for all TC Items and Issues. Electronic capture of attendance or a roll call will be held at the beginning of each Plenary where votes are to occur to ensure a quorum is present.

The only exception for this Quorum rule is for a vote to issue an electronic vote for adoption of a new or revised version of a candidate standard, creation of a Working Group, a Best Practice, or a policy document. In this case, a simple majority vote of those TC Voting members present constitutes a successful vote.

6.3.2. Subgroup

SWG quorum is ½ of SWG Voting members.

Quorum is assumed for all other subgroups (i.e., those present in a meeting comprise quorum).

6.4. Sufficiency

"Sufficiency" is the minimum number of votes cast to have a valid vote result. In most cases, sufficiency is equal to quorum, but for electronic votes, quorum is assumed and a sufficient number of voters need to participate.

6.4.1. Technical Committee

For a Hand vote or Electronic vote, sufficiency requires 1/3 of the Eligible voters to vote.

If during the vote there is a new TC Voting Member, that Member may vote but does not change the sufficiency rule.

6.4.2. Subgroup

Sufficiency is equal to quorum.

6.5. Approval

The criteria for approval of votes is generally Unanimous consent or a majority in favor, however an exception exists for the TC on a Required TC electronic vote.

6.5.1. Technical Committee

An OGC Position (Standard, Best or Community Practice, Policy) or creation of a subgroup is a Required TC electronic vote and requires that the number of YES votes be twice or more the number of NO votes. Further, 15% of the total number of Eligible voters must vote YES.

For all other votes, approval is by a simple majority.

6.5.2. Subgroup

All votes are approved by a simple majority.

6.6. Proxy for Voting

Any eligible voter in the TC or a subgroup can assign their proxy to another full-time employee of their organization, to another individual from another TC Member voting organization, or to the TC Chair or subgroup chair.

Proxies can be assigned electronically or in written form. A written proxy form is provided for each TC meeting and is posted to the TC meeting folder for which the proxy will be valid.

Proxy shall be communicated to the TC Chair in advance of the TC Closing Plenary. The TC Chair shall send reminders to the voting members prior to the meetings. Assignment of proxy to another full-time employee of the Voting member’s organization may be communicated verbally to the TC Chair in advance of or at the TC Closing Plenary.

Proxies are not transitive: that is, if Member A holds a proxy for Member B and Member B holds a proxy for Member C, Member A can only vote on behalf of Member B and CANNOT further vote on behalf of Member C by “proxy to a proxy.”

6.7. Form of a Document Motion

All subgroup document votes, except for Best Practices and Standards adoption votes, shall have the following language.

The <Name of the SC or WG> recommends that the TC approve the release of <OGC Document number and Name> as an OGC <Technical Paper, Discussion Paper, or Engineering Report>.

  • Pending any final edits and review by OGC staff.

Standards and Best/Community Practice adoption votes shall have the following language.

The <Name of the SC or WG> recommends that the TC approve an electronic vote to recommend <OGC Document number and Name> as an OGC <Standard, Draft Standard, Community Standard, Abstract Specification Topic, Best Practice, or Community Practice>.

  • Pending any final edits and review by OGC staff.

6.8. Voting methodology

OGC offers progressively more direct voting methods for actions of the TC or subgroups. Regardless of the method, only one vote is allowed per member organization.

6.8.1. Motion for a vote

  1. A motion is made for specific language describing the item to be voted upon.

  2. A motion may only be made by a member who can vote on the matter. For instance, any OGC member can make a motion in a DWG as all members in the DWG can vote; however, only a voting SWG Member can make a motion in a SWG. See Vote types and allowed voters for voting criteria.

  3. If the motion is made by the meeting chair, then the chair asks for a member to move the motion, otherwise, the member making the motion moves the motion.

  4. The chair asks for a second to the motion.

  5. The chair(s) ask if there is any discussion on the motion. Time is allocated for discussion, but if none occurs, then the motion continues. If discussion does occur, it must be captured with the motion. If the discussion changes the nature of the motion, the motion can be recast or include a friendly amendment with the approval of the moving member and the seconding member. The discussion cycle may continue.

  6. Once discussion ends and the motion is finalized, the chair initiates the vote. The normal course is to ask for any objection to Unanimous consent. The chair may choose to request a Hand vote.

In this vote, the chair asks if there is any objection to unanimous consent. If there is no objection, the motion vote passes. If there is objection, then the motion may move to a Hand vote.

6.8.3. Hand vote

A hand vote is one where the voters indicate YES, NO, or ABSTAIN by show of hands, verbally, or in writing.

6.8.4. Electronic vote

An electronic vote requires voting members to use the voting tool in the OGC Portal to cast their vote on a specific ballot. Only voting members of the TC or the subgroup (if applicable) can make or update their organization’s vote. An electronic vote can fulfill the same purpose as a Hand vote for the TC or a subgroup except in the special case of a Required TC electronic vote.

6.9. Voting forum and process

6.9.1. In a meeting

Votes occur in TC meetings (most frequently in the Closing Plenary) and in subgroup meetings. These votes directly follow the Voting methodology, except that there is no use of an Electronic vote.

6.9.2. Email vote

The procedures for holding email votes apply to any votes that the TC is eligible to hold in a Closing Plenary or any subgroup in a meeting. The email vote process follows the normal Voting methodology, with the following modifications.

  1. The motion is made in a meeting or via an email thread.

  2. The TC Chair or subgroup chair sends an email to the appropriate email reflector notifying the group of the start of an email vote. The message must specify the item(s) on which the group is voting, include relevant background information, provide the deadline for voting, and define the type of vote (Unanimous consent or Hand vote).

  3. Voters have until the deadline to cast (and possibly change) their votes, after which, the vote closes.

  4. For a Unanimous consent vote, no reply from the voters is equivalent to no objection.

6.9.3. Required TC electronic vote

The TC is required to use an electronic vote for the following actions:

  • recommend adoption of an OGC Standard;

  • recommend adoption option of an OGC Abstract Specification Topic;

  • recommend adoption of an OGC Community Standard;

  • recommend approval of an OGC Best Practice;

  • recommend approval of an OGC Community Practice;

  • recommend adoption of a Policies and Procedures document;

  • elect representatives to the OGC Architecture Board;

  • recommend approval of a subgroup charter;

  • recommend approval of a new Standard Work Item; and

  • recommend approval of a new Community Standard Work Item.

Each of these electronic votes is approved to start by motion of the TC in a Plenary or via email vote.

If the TC electronic vote for recommending an action passes, then the action proceeds to the EPC for an approval vote per the EPC Policies and Procedures.


Unless otherwise stated by the TC Chair, the normal deadline for response to a TC electronic vote shall be 45 days from the date of issuance of the electronic vote. There are no extensions for NO votes or insufficient votes (see Sufficiency). The start and end dates for any given vote are set by OGC staff and are posted with the ballot and announced.


Except for the following reasons, an electronic vote shall remain open for the duration as stated in Duration:

  • A SWG withdraws the motion to approve a candidate Standard (see Vote withdrawal); or

  • The TC Chair, the OAB, or the WG bringing the action identifies a procedural error and requests the vote be stopped.


All voting TC Members in good standing at any time during the electronic vote can participate in electronic voting, whether or not they have participated in any preceding TC meeting or electronic vote. All such members are referred to as "eligible voters." Each eligible voter shall have one vote.

Number of Eligible Voters

For each electronic vote, the number of eligible voters shall be determined as of the date of the start of the electronic vote. The number of eligible voters for a given vote shall be determined by OGC staff and shall be posted with the ballot and announced. This number shall not change for an active vote regardless of whether members gain or lose voting eligibility.

Allowable Votes

The voting member may vote Yes, No, or Abstain. Abstain counts toward sufficiency. Comments may be provided with any vote. Any eligible voter may change their vote during the voting period but not after the vote is closed.


Any eligible voter that votes may submit a written comment. If an eligible voter votes NO, then that voter shall also submit a written comment explaining their reason for voting NO.

For a Standard adoption vote, then the SWG shall respond in writing to all comments within 30 days of the completion of the vote. A TC vote that passes cannot proceed to the EPC for approval unless all NO votes are addressed.

For other votes, then the appropriate TC subgroup shall respond to the comments. The written response to comments shall be in an OGC document and made available to the OGC Membership. If a motion is withdrawn (See Vote withdrawal) then no response to comments is required.

6.10. Multi-part Documents

OGC Standards documents are often broken into parts along modular lines. Adoption votes for such multi-part documents must either be sequential and not overlapping in terms of start and stop dates or in parallel with the same start and stop dates for the vote.

If the votes are in parallel and if a part fails, then any part containing a module dependent upon a module in the failed part also fails. If the vote is sequential, any part containing a module dependent upon a module in a previously failed part cannot be voted until the failed part is re-voted and approved or the dependency is removed.

6.11. Vote withdrawal

A motion may only be withdrawn by the subgroup that made the original motion or by the TC Chair for procedural reasons. The subgroup shall have a formal documented vote to withdraw a motion. The reasons for withdrawing a motion are not constrained. The subgroup shall communicate to the TC Chair the request to withdraw a motion. The TC Chair shall then communicate the decision to withdraw a motion to the entire membership.

6.12. Vote restart or repeat

The following procedures shall be followed for those cases in which a revote is required.

  • If a subgroup withdrew a motion and there is no content change to the document, the subgroup can at any time request the TC Chair initiate new vote.

  • If a subgroup withdrew a motion and the content of the document is changed, then the subgroup needs to restart the approval process (in the case of a Standard: OAB review, public comment, TC approval to start the vote).

  • If the vote was stopped for procedural problem(s), fix the problem(s), and initiate a new vote.

6.13. Visibility

The following rules relate to transparency of the voting process.

  • During and after a vote, individual votes and comments are visible to any OGC member during and after the voting period.

  • After the vote is complete, the public only sees the vote result and does not see how an Eligible Voter voted or commented.

  • The WG can vote to make public the comments and WG responses to the comments - but shall not provide the name of the voter who made a given comment.

6.14. Vote failure or lack of sufficiency

If the vote did not pass, then the appropriate OGC subgroup needs to address all comments, revise the document and restart the approval process (for a Standard: OAB review, public comment, and a new adoption vote).

If the vote failed by not meeting Sufficiency criteria, a new request to start an electronic vote can be made to the TC and the vote can repeat, but only once. A subsequent lack of sufficiency is treated as the vote not passing.

7. OGC documents and other products

OGC publishes a number of different document types and supporting products to enable geospatial interoperability. Documents include Standards, Best Practices, Engineering Reports, etc. Products include registries, developer resources, sample code, etc.

The primary source of information that is versioned and has a formal approval process is a document. Any document may be accompanied by various products as supporting resources: those products may be published at the time of document publication, but have their own lifecycles and are managed by the TC, subgroups, or OGC staff as is deemed best to support the document.

7.1. Documents and their distribution

The numbered document (see Document numbers) as distributed to members is to be considered the official document of the TC. All documents must use the templates found in the templates GitHub repository or equivalent Microsoft Word templates found on the Portal; the latter are discouraged. Document development will result in periodic milestone releases which may be shared on the OGC Portal or in the applicable Collaboration environments. Official release of documents for OGC member or public review must be made available on the Portal. OGC Communication shall be used for announcing the availability of new official documents. Other electronic forms of documents can be made available at the written request of members.

OGC documents are authored and edited in AsciiDoc or Microsoft Word format. Publication of approved documents must be in HTML, but also includes PDF and Word formatted versions. The format for dissemination may change as distribution technology changes. Prior to mid-2014, all approved documents were only available in PDF and sometimes Microsoft Word format.

The TC Chair reserves the right to reject a document that is in a non-industry standard distribution format.

7.2. Standards

An OGC Standards document is the principal document type that captures the work and the consensus of the OGC membership. Standards documents must use the OGC Standards document template during development (with the exception of Community Standards). Standards may be published in multiple official views, as follows.

  • Normative view - the format that has been in use for all of OGC publication history (with some minor modifications) and that is similar to the format of ISO Standards. This format is considered the authoritative representation of the Standard.

  • Implementer views - one or more publication styles of the Standard content that is more accessible to software engineers or data professionals. The views may be published via developer frameworks, such as SwaggerHub or ReDoc.

OGC uses a multi-track Standards policy with three possible states: OGC Community Standard, OGC Draft Standard, and OGC Standard. These are described in The Two Track Standards process: characteristics.

Standards are further categorized as follows (see Annex A: Terms and Definitions for details): * Abstract Specification * Conceptual Model * Encoding * Implementation

Approval of an OGC Standard is described in Policies for the OGC Consensus Standards Process.

Each Standard distributed by the OGC shall include a cover page with the statement as specified in Policy Directive 4.

Standards documents have version numbers that shall start at 1.0 (see Versioning).

Standards may be accompanied by supporting normative content such as schemas and/or registries. This content is approved as part of the Standard and is managed in concert with the Standard lifecycle.

Informative products may also be developed along with the Standard, such as compliance tests, user guides, sample code, registered code lists, etc. This informative material may be created by a subgroup, members, or OGC staff and is managed by its originating party without formal obligation for maintenance.

7.2.1. Standard building blocks

Many OGC Standards are structured with modular sets of requirements (or requirement classes) that collectively function as a reusable building block. There is no firm definition for the content or scope of a building block, but the building block must fulfill a function that can operate in the larger context of an implementation, including combination with other OGC building blocks to create novel implementations.

Building blocks developed for one Standard can be reused in another Standard. To facilitate such reuse, a Standard constructed of building blocks shall identify each building block and publish a definition of the building block to OGC’s Registries and web resources. The definition will be in the form most suitable for the type of building block (e.g., Open API for a Standardized API), reference the owning Standard, and be adequately documented to be used in reference.

OGC Standards that reuse building blocks from other Standards must include in the Normative References a reference to the owning Standard of the building block(s) and a direct reference to the registered building block(s) content. In this fashion, implementers of the Standard reusing these building blocks need to only access specific parts (the building blocks) of the referenced Standard, not the entire document.

7.3. Registries

Registries are managed by the OGC-NA per the OGC-NA Policies and Procedures. Some registered content is normative content for a Standard, some supporting one or more Standards, and some enables geospatial interoperability for specific domains. Informative registry content is developed, approved, and maintained by the owning subgroup without further need for TC approval.

7.4. Best and Community Practices

OGC Members, TC subgroups, or COSI Initiatives may generate Best Practice (BP) and Community Practice (CP) documents for the community covering best practices related to the use of an OGC Standard or other technology relevant to one or more OGC Standards. These documents describe a technique or methodology that, through experience, implementation, and research, has proven to reliably lead to a desired result. In some cases, BPs or CPs may transition to full Standards through the OGC Consensus Standards process.

BP and CP documents have version numbers that shall start at 1.0 (see Versioning). BP and CP documents may also have corrigenda per the process defined in Corrigendum (errata) Changes to OGC Standards and Best and Community Practices.

Best Practice: a document describing the use of one or more OGC Standards, typically to address a domain-specific topic or provide a solution to an interoperability challenge. Best Practices may also describe implemented extensions to or profiles of OGC Standards.

Community Practice: a document describing implemented Standards, specifications, or technologies that originate outside of OGC, but which are relevant to address interoperability requirements in the geospatial and related communities.

7.4.1. Submission of documents to be considered as an OGC Best Practice or Community Practice

In order to be considered for approval as an OGC BP or CP, the document submitters shall provide the following.

  • An Abstract or Introduction in the document explaining why a submitted document is relevant to the OGC.

  • Evidence of implementation. Evidence of implementation shall include but not be limited to: implementation in commercial product, implementation in open source applications or software, and/or implementation in deployed applications. A single research related implementation is not proper evidence of implementation.

Approval of a BP or CP is as follows.

  • Submit for TC and Public Request for comment of 30 days.

  • Post the document to OGC Pending Documents on the OGC Members Portal for at least three weeks prior to the face-to-face or remote presentation.

  • Present the contents of the proposed document in a TC Meeting or webinar.

7.5. Engineering Reports

Any OGC COSI Initiative will have Engineering Reports (ER) as a deliverable. These ERs are posted to pending documents and presented and discussed in a WG meeting. The WG may recommend to the TC that the ER be publicly released. If approved by the TC, these documents shall be released as “Public Engineering Reports.”

While these ERs shall be distributed by the OGC, and might in fact lead to adopted Standards later, they do not represent the official position of the OGC TC or the OGC.

Motions to approve release of a document as an Engineering Report may originate from a WG with TC approval, from a motion at a TC Plenary, or from a motion by the TC Chair.

Each Public Engineering Report distributed by the OGC shall include a cover page with the statement as specified in Policy Directive 6.

Engineering Reports do not have a version number.

7.6. Discussion Papers

A subgroup can generate Discussion Papers for the community covering a specific technology area germane to the subgroup’s interest area.

While these Discussion Papers shall be distributed by the OGC, and might in fact lead to adopted Standards later, they do not represent an official position of the OGC TC or the OGC itself.

Motions to approve release of a document as a Discussion Paper may originate from a subgroup with TC approval, from a motion at a TC Plenary, or from a motion by the TC Chair.

Each Discussion Paper distributed by the OGC shall include a cover page with the statement as specified in Policy Directive 5.

Discussion Papers do not have a version number.

7.7. Technical Papers

Technical Papers are OGC member-approved publications released to the public that present a position on one or more technical considerations or other subjects that are germane to the work of the OGC. Technical Papers often include a high-level explanation of a Standards-based architecture or framework of a solution. Technical Papers may explain the results or conclusions of research or workshops.

Technical Papers do not represent an official position of the OGC TC or the OGC itself.

Motions to approve release of a document as a Technical Paper may originate from a subgroup with TC approval, from a motion at a TC Plenary, or from a motion by the TC Chair.

Each Technical Paper distributed by the OGC shall include a cover page with the statement as specified in Policy Directive 5 where the word "Discussion" is replaced with the word "Technical" in the statement.

Technical Papers do not have a version number.

7.8. Policy documents (including this one)

A policy is a principle, rule, or process that guides decisions to achieve rational outcome(s). The work of the OGC is guided by a number of member-approved policies and processes. These policies and processes are documented in various OGC Policies and Procedures documents. These shall be known as “Policy” documents. This TC PnP is a policy document. Policy documents are either maintained by the members or by OGC staff. In all cases, new policy documents or revisions to existing policy documents applicable to the TC or its subgroups shall be reviewed and approved by both the Technical and Planning Committees. Approval of a policy document shall follow the rules as defined for a Required TC electronic vote. If the TC approves the Policy document, then a simple majority of the EPC Voting Members must approve the TC recommendation.

Policy documents have version numbers that shall start at 1.0 (see Versioning).

7.9. Guidance documents (lighter than a policy)

A Guidance document is developed by a subgroup, the TC, or OGC staff to provide informative guidance on the development of OGC documents and products. This guidance is intended to provide consistency in approach and common properties for OGC deliverables. Guidance documents are not official policy, but the guidance may be required for use by SWGs per one or more Policy Directives.

7.10. Document numbers

All member-submitted documents shall be assigned a document number. Members can obtain document numbers using the Portal, Pending Documents page.

Instructions are available for obtaining a Pending Document number and posting the document.

8. Standards development

This section covers procedures for adoption, revision, and maintenance of OGC Standards.

8.1. Standards proposed for adoption – caveats

All adoption votes to approve a document as an OGC Standard shall be electronic. Only Voting TC members may vote on an adoption vote. However, any OGC member, regardless of membership level, can 1) be part of a team submitting a candidate document and 2) join a SWG and work on a candidate Standard.

8.2. The Two Track Standards process: characteristics

There are two possible tracks for proposing and approving candidate Standards or proposing and approving revisions to an existing adopted Standard: The OGC Community Standard and the OGC Full Standard tracks. These two tracks are described below. Regardless of the submission track, the OGC Consensus Standards Process shall be used. There are key differences in the OGC Consensus Standards process depending on whether the Community or the Full Standards track is being used. The following table summarizes the key aspects and steps in the OGC Consensus Standards process for the two tracks.


Evidence of Implementation

Modular Spec

Compliance Test

OGC Template

Public Comment

OAB Review


Member Vote

Community Standard

Not required


Not required


Not required



Shared or retained by submitter


Full Standards Track

Draft Standard




Not required










Not required






Community Standard: This is a document, developed by communities external to the OGC, that OGC members wish to bring into the OGC process. The key consideration for a Community Standard submission is that there is very strong evidence of implementation. At the same time, the community owning the Standard may not want to allow normative changes (except for errors) to the document, may not wish to follow the OGC Modular Specification Policy, nor do they wish to develop CITE tests. Annex C: Community Standard adoption checklist summarizes the steps in the Community Standard submission, review, and approval process.

The Full Standards track consists of two possible target levels of a Standard.

Draft Standard: This is a document developed by the OGC membership for which there is no evidence of implementation or CITE tests. However, the members wish to approve the document as an official OGC document in order to have developers and organizations implement the Draft Standard and provide feedback. A Draft Standard is uplifted to a Standard once evidence for implementation is provided. Annex B: OGC Consensus Standards adoption checklist summarizes the steps in the Draft Standard submission, review, and approval process.

Standard: This is a mature OGC Standard for which there is evidence of implementation This is the final stage in the Full Standards track.

8.2.1. Two Track Standards process criteria

Evidence of implementation: The TC will judge whether the evidence of implementation for a particular Standard is sufficient to warrant approval of that Standard. Strong evidence of implementation as required for the Community Standard is generally defined to be implementation in multiple products or environments OR widespread use of the Standard in a community, even if in only one or a limited number of products or environments. Evidence of implementation for a Standard in the Full Standards track is defined as three or more documented implementations that meet the Nature of implementation criteria, below. The TC may choose to override the minimum number of implementations for a specific candidate Standard by specifying a lesser number in the electronic adoption vote.

Nature of implementation: Implementation Standards shall have as evidence of implementation running services which deliver content to another machine (including client software). Encoding Standards shall have as evidence of implementation data sets containing content representative of the Standard, but not necessarily containing an example of every element in the Standard.

Conceptual model evidence of implementation: a Standard that is conceptual in nature (e.g., cannot be implemented directly) and not being advanced as an Abstract Specification Topic shall only be advanced from a Draft to a final stage once at least one implementation Standard based on the conceptual model is approved at the Draft stage.

Abstract Specification Topics: these Standards do not require evidence of implementation due to their foundational nature. Abstract Specification Topics are approved as Standards without a Draft stage.

Modular Specification: compliance with the Modular Specification is evidenced by inclusion of clearly defined Requirements and an Abstract Test Suite in the Standard document. The OAB will evaluate a Standard against this criterion.

IPR: Community Standard may contain IPR that is jointly held by the OGC and the submitting organization. The Full Standards track requires that OGC hold the IPR.

8.2.2. Status of Standards initiated before the Two Track Standards process

OGC Standards initiated prior to the effective date of Revision 24 of these Policies and Procedures (05-020r24), 25 May 2016, will automatically be classified as “Standards” under the Full Standards track.

8.3. Adoption and/or Revision to a Standard - General

The OGC Consensus Standards Process (Policies for the OGC Consensus Standards Process) is the only way for a candidate Standard to move through the review and approval process. This is the approach for proposing a new candidate Standard, submitting an externally developed community specification into the OGC process, extensions to an existing Standard, profiles of an existing Standard, or an application schema for consideration by the membership. For the Full Standards track, a SWG manages the OGC Consensus Standards process.


A new Standards activity can also be initiated when there are outstanding Change Request Proposals (CRPs) (Change Request Proposals (CRP) to an OGC Standard), which provide details for revisions to existing Standards. A CRP describes proposed changes or enhancements to an existing Standard. A CRP may be submitted by one or more OGC member organizations. One or more CRPs against an existing OGC Standard is evidence that a revision process for that Standard should be initiated. In this case, the TC Chair may request members consider a Standards activity.

8.4. Policies for the OGC Consensus Standards Process

The following sections details the requirements, policies, and procedures for adoption of a candidate Standard using the OGC Consensus Standards process. Each section specifies whether that step or requirement in the process is for All submissions, Community Standard only, or Full Standard track only.

8.4.1. Conditions for Submission of a Candidate Standard (All)

Any OGC Technical Committee Voting Member may make an unsolicited submission of a candidate Standard or a proposal for the development of a new candidate Standard using the OGC Consensus Standards process given that for the submission, the following conditions are met.

  • Three different Member organizations endorse the submission and communicate to the TC Chair an intent to start work on a new Standard or revision to a Standard.

  • At least one voting member is part of the submission team.

  • For a candidate Community Standard, there is evidence of implementation and evidence of a continued commitment to commercialize and/or support the implementation.

8.4.2. Terms and Conditions for OGC Candidate Standard process submissions (All)

In the OGC Consensus Standards process, the submitters agree to the following set of terms and conditions.

  • For a Community Standard, work with OGC Staff to develop and submit a Work Item justification for submitting a candidate Community Standard.

  • For a Full Standards track submission, work with OGC staff to develop a new SWG Charter or to revise the Charter of an existing SWG.

  • All OGC Consensus Standards process submissions originating from work done external to the OGC consensus process and then submitted into the OGC for consideration as an OGC Standard may require a signed original of the OGC Submission of Technology (SoT) Form. Work with OGC staff to determine if a SoT form is required. This form shall be provided to the OGC prior to the adoption vote.

  • The Submission team agrees to comply with the current Policy Regarding Intellectual Property Rights of OGC.

  • Proprietary and confidential material is not included in any submission to the OGC.

  • OGC Candidate Standard submitters agree to grant OGC a non-exclusive, royalty-free, paid-up, worldwide license to copy and distribute their submission to the OGC membership, and, if adopted by OGC, the right to modify, enhance, and make derivative works from the Standard and to copy and distribute the Standard, modifications, enhancements, and derivative works both inside and outside of the OGC membership.

  • The Submitters agree that OGC will own the copyright in the resulting Standard or amendment and all rights therein, including the rights of distribution. This agreement shall not in any way deprive the submitter of any patent or other IPR relating to the technology to which its submission relates.

  • OGC Standards may reference other OGC Standards or Standards from other Standards organizations. Incorporating Standards by reference requires that the Standard clearly designate what portions of the other Standard are referenced, the version of the other Standard, a complete reference to the other Standard, and complete information on how to obtain the other Standard. Whenever possible, submitting organizations are asked to make available to OGC the referenced Standard.

8.4.3. Specific process requirements for the submission of a Community Standard (Community Standard)

Notify TC Chair

The submission team shall notify the Technical Committee Chair of the intent to submit a Community Standard. This notification may be done using email. The notification shall include the organization names of the submission team. The notification shall also include agreement to the following statement:

<list of companies/organizations> have granted the Open Geospatial Consortium (OGC) a nonexclusive, royalty free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version.

Submission justification document process

The submission team shall provide a written justification as to why the Community Standard process can be used. This justification shall also include the reasons why the candidate Standard may not need to be aligned with the OGC Abstract Specification and Standards Baseline. There is a template for this justification document.

Once the submission team completes a draft of the justification document, they shall provide the TC Chair the draft. The TC Chair shall review the draft and provide comments and guidance back to the submission team. The submission team reviews the TC Chair comments, modifies the justification as required, and posts the justification to Pending Documents when complete.

Submission justification document: Member review process

Once the justification document is posted to pending, the TC Chair shall organize member and public review of the work item, as follows.

  • Announce a three week OGC Member review period. Comments may be provided.

  • Coordinate a broad community announcement that the OGC is considering accepting a Community Standard into the OGC Standards process.

  • Have the proposed Community Standard submitters present the justification to the TC at a Plenary or via a virtual meeting and ask the full TC if there are any objections to starting an electronic vote on the proposed candidate Community Standard as an official OGC work item. If there are objections, comments shall be provided.

Approval of the proposed Community Standard work item

Upon completion of the review and comment process, the TC Chair shall initiate a Required TC electronic vote to approve (or not) the proposed work item for processing a Community Standard. If the approval motion fails, the submission shall be withdrawn and the submission team may resubmit the candidate community Standard after addressing member concerns. A Community Standard work item is valid for six months: within this time period the draft Community Standard must be scheduled for OAB review or else the work item must be renewed through a new submission.

Processing Comments received during the Community Standard work item approval vote

If comments are received as part of the approval vote for using the Community Standard process, the submission team shall follow the process as defined in Review of the received comments (All).

8.4.4. Main Steps in the OGC Consensus Standards Process

The steps in the OGC Consensus Standards Process are as follows.

OGC Technology Submission Form (Full Standard: externally-developed submissions only)

This clause applies to candidate Standards origintating in content developed external to the OGC and then submitted by the members for consideration as an OGC Standard under the Full Standard track.

Assurances are required at the time of submission that the IPR inherent in the submissions will, if the submission is approved as an OGC Standard, be made available under license to all implementers, members and non-members alike.

The organization(s) proposing the external work to enter the OGC process may be required to complete, sign, and deliver a Submission of Technology Form (SoT). Please contact OGC staff to discuss whether a SoT is required. If required, the signed SoT shall be provided prior to the adoption vote.

Formation of a new SWG to work on the OGC Consensus Standards process submission (Full Standard)

See SWG Charter and Task approval process on the Policies specific to the formation of a new SWG and SWG processes.

Release of candidate Standard for internal review and Public Comment (All)

At any time in the OGC Consensus Standards process, the SWG may vote to release a candidate Standard for public comment. These interim public comment periods do not require OAB or OGC Naming Authority review. However, there shall be, at a minimum, one official 30 day public comment period.

Full Standard: Once the SWG determines that the candidate Standard is ready for OAB and OGC-NA review and public comment, the SWG shall have a vote to release the document for public review. Upon a simple majority vote by the voting members of the SWG, the candidate Standard will be released for OAB and OGC-NA review in advance of public request for comment.

Community Standard: The community Standard submission team and the TC Chair must agree that the candidate Standard is ready for review and the TC Chair will submit the candidate Standard for review by the OAB and OGC-NA in advance of public request for comment.

Review by the OGC Architecture Board (All)

Once the SWG or Community Standard submission team approves the candidate Standard for public comment, the candidate Standard is reviewed by the OAB. The OAB has the responsibility to ensure that the OGC candidate Standard submission is relevant with respect to current adoption plans of the OGC (and/or the current Abstract Specification), how the proposal is consistent with the current OGC Standards baseline, and, for Full Standards, compliance with the Modular Specification Policy The Specification Model - A Standard for Modular specifications (08-131r3).

The candidate Standard cannot be released for public comment until it is approved for release by the OAB. The OAB may request changes to be made to the candidate Standard and have that document returned to the OAB for further review prior to release for comment.

Review of OGC Identifiers (http URIs, etc.) by the OGC Naming Authority (All)

Concurrent with the OAB review, the SWG shall request that the OGC Naming Authority review all new OGC identifiers specified in the candidate Standard.

The candidate Standard document/repository will also be provided to the OGC-NA to ensure that document tags and formatting are consistent with the OGC Standard template and suitable for ingestion into the OGC Knowledge Management database.

In order to facilitate the review and to be in compliance with the OGC URN policy, the editor shall submit the candidate Standard’s list of Namespace URIs for OGC-NA review as a spreadsheet or as a Persistent Uniform Resource Locators (PURL).

Request for Public Comment Period (All)

The candidate Standard is released for a 30-day public comment period, unless the SWG or submitters determine that a longer comment period is required. During the comment period, any party (including all classes of OGC members, as well as any non-member of OGC) may send comments via the means announced with the request for comment issuance. OGC staff will manage collection of the comments.

Review of the received comments (All)

Once the request for comment period closes, the SWG or submission team reviews the comments and determines how each comment will be addressed. The team may decide to:

  • accept the comment as-is and edits the candidate Standard accordingly;

  • accept the comment with modification and edits the candidate Standard accordingly;

  • accept the comment as a future work item; or

  • reject the comment with an associated reason.

the team cannot accept a comment that makes a normative change to a Community Standard unless the comment identifies an error. A Community Standard is normatively-frozen once it enters the approval process.

In all cases, the team shall document their decision in a comment response document or via issues in the SWG collaboration environment. Further, the team shall notify each individual who submitted a comment as to the disposition of the comment.

If the comments result in a significant change to the candidate Standard, then the TC Chair may request that the revised candidate Standard be reviewed by the OAB once more prior to the TC adoption vote.

The SWG or submitters may decide that comments received are sufficient to halt the advancement of the candidate Standard.

Member briefing for candidate Standard (All)

Once the final document has been posted to Pending Documents, the submission team shall brief the TC on the contents of candidate Standard. This briefing shall occur prior to a final adoption vote. This briefing may be at a TC Meeting or webinar. The briefing shall be announced via formal OGC communications at a minimum of two weeks prior to the briefing.

Vote to approve candidate Standard (All)

After the candidate Standard has been briefed to the TC, the TC Chair will request that the TC approve the start of a Required TC electronic vote to recommend approval of the candidate Standard by the EPC. This vote request can occur via the Voting forum and process.

Upon approval of the TC to start an electronic vote, the TC Chair will initiate a 45-day electronic vote to recommend approval of the candidate Standard by the EPC.

Approval by the TC to recommend approval by the EPC will initiate a EPC vote, further described in the EPC Policies and Procedures.

8.4.5. Specific policies regarding approval of uplift of a Draft Standard to a Standard

A Draft Standard proposed to be approved as a Standard must be submitted by the SWG to the TC Chair with written documentation that the Standard meets the criteria for evidence of implementation per the Two Track Standards process criteria. The candidate Standard must then proceed with the RFC (Request for Public Comment Period (All)) through voting (Vote to approve candidate Standard (All)) steps.

8.5. Specific Policies Regarding Abstract Specification Topics

The OGC Abstract Specification development, revision, and approval process is the same as for any OGC Standard except for documents that originated in Authoritative Standards Development Organizations or are joint Standards activities between OGC and an Authoritative SDO.

Abstract Specification Topics may be initiated by a SWG or directly by the TC. When an Abstract Specification Topic is developed directly under the TC, the Topic shall be briefed to the TC and any relevant Working Groups prior to OAB Review in advance of public comment. Any comments received as a result of the briefing(s) shall be considered and accepted by the TC Chair before the document is presented to the OAB.

8.5.1. Scope and Content

The Abstract Specification forms a foundation (generally of conceptual models) upon which OGC Standards can be constructed. The Abstract Specification comprises a series of Topics, each approved as a Standard.

The detail of the Abstract Specification shall be sufficient to provide normative references, including models, and technical guidelines as a foundation for Standards. Each Topic, to the extent possible, provides unambiguous normative and informative information that allows for implementation of Standards in software.

The level of detail of the Abstract Specification is at the discretion of the TC as reflected by the actual content that is approved for inclusion in the document itself.

The TC can add, deprecate, or retire Topics just as for Standards. The OAB manages Topic 0, which summarizes all Topics and provides reference to their relationships.

8.5.2. Authoritative SDO Documents as OGC Abstract Specification Topics

A new Abstract Specification Topic or a revision to an existing Abstract Specification Topic may be proposed by the OGC members for the case in which the document was created in an Authoritative SDO activity or a joint OGC and Authoritative SDO-developed activity.

Solely Authoritative SDO Standard as an OGC Abstract Specification Topic

For this case, the Authoritative SDO Standard has been developed and approved solely in the Authoritative SDO.

for this case, the TC Chair will need to ensure that a copy of the Authoritative SDO Standard is freely available to the OGC members for review. The document shall then be posted to pending documents and the availability of the document announced to the membership. Once approved, the Topic may no longer be free to the public or OGC members.
Joint OGC-Authoritative SDO Standard as an OGC Abstract Specification Topic

For this case, the OGC and the Authoritative SDO have agreed to have a joint Standards development activity. The OGC shall be open to participation by both OGC and the Authoritative SDO members in the work on the Topic. Both OGC and the Authoritative SDO will coordinate on timelines and process for all stages of review and approval in the respective organizations.

8.5.3. Approval of an Abstract Specification Topic

The TC, OAB, or a subgroup can recommend the Topic for inclusion in the Abstract Specification. In some cases, a SWG is established for the maintenance of the Topic, but this is optional. Review and approval of the Topic is the same as for an OGC Standard, starting with Review by the OGC Architecture Board (All).

8.6. Submission of an OGC Standard for consideration by another SDO

OGC membership may choose to submit an approved OGC Standard to another SDO for adoption of the Standard by that SDO. A number of OGC Standards have been submitted to ISO / TC 211 and are now also approved as ISO Standards. Such a submission will follow the steps below.

  • The body or persons controlling the relationship with the other SDO shall approve the submittal and any documentation required for submission; and

  • the TC will vote on the submission via the Voting forum and process.

8.7. Change Request Proposals (CRP) to an OGC Standard

At any time, any OGC member or non-member can submit a CRP. A CRP allows for the formal documentation of a proposed change to an existing, adopted OGC Standard or Abstract Specification Topic. The change could be an identified error (see Corrigendum (errata) Changes to OGC Standards and Best and Community Practices), an inconsistency, a requested enhancement, or a major proposed enhancement.

CRPs are used as the basis for new SWG work items. The SWG must consider proposed changes and enhancements.

8.7.1. Submission of Change Request Proposals

A CRP shall be submitted to the OGC by posting to the Public Change Request page or to the Issue tracker for the Standard in question.

8.7.2. Evaluation of a Change Request Proposal

A CRP is processed by appropriate SWG. The SWG shall discuss the proposed CRP and then vote on how the CRP should be processed:

  • reject the CRP with a written reason;

  • accept the CRP but request additional clarification; or

  • accept the CRP with documentation as submitted.

If a CRP is accepted, the SWG will incorporate the contents of the CRP into the designated Standard, either as a revision or a corrigendum. If the CRP is rejected, then the SWG must write a formal response to the CRP submitter(s), or log the response in the Issue tracker, explaining the rationale for rejection and then allow the submitter(s) the opportunity to respond and/or resubmit their CRP with modifications.

8.7.3. Completion of a Change Request Proposal

When a SWG has processed a CRP, the status of the CRP will be updated in the tracker used. The status and disposition will be modified based on the SWG decisions. The CRP will remain available for future reference.

8.8. The Standard Editor

In addition to the formation of a SWG, there is a requirement for an editor or editors who will maintain the content of the candidate Standard based on member input and the decisions of the SWG. One or more members can fill the editor position. The editor has the responsibility for managing the text and related resources of the Standard document. The editor is not necessarily the author nor the owner of the document. By way of guidance, the editor is responsible for:

  • the editorial quality of the document - clear language, well written, self-consistent, and proper format;

  • ensuring that the consensus of the SWG and the TC is captured in the content of the document;

  • keeping modification of the document on schedule - knowing the content and history of the document well enough to prevent it from and endless round of modification; and

  • maintaining revision notes that document what changes were made and in response to which comments or CRPs. These notes will be used as the basis for creating the revision notes document for a given revision/version of a Standard.

8.9. Compliance tests

Many OGC Standards have an associated compliance test suite of software that enables qualification or certification of software that accurately implements the Standard. These tests are managed under the Compliance Program Policies and Procedures.

Each Compliance Test is approved via the Voting forum and process.

9. Lifecycle management of OGC Standards and other documents and products

All OGC Standards are managed in a lifecycle of development-publication-revision and perhaps eventual retirement. The governing principles of lifecycle management for Standards are:

  • ensuring relevance of the active Standards;

  • practical and logical maintenance of previous editions of Standards, where appropriate; and

  • sound business decisions for deprecation or retirement of Standards.

No two Standards are ever likely to follow identical timelines for their lifecycles. Some very fundamental Standards have exceptionally long lifecycles, while those Standards addressing emerging IT trends may revise frequently. The TC will manage the lifecycle of Standards in accordance with the following policies and procedures.

9.1. Versioning

OGC Standards (and Best and Community Practices) are versioned according to Policy Directive 18, which follows the Semantic Versioning Specification (SemVer). The guidelines for version/revision numbers for documents are as follows.

  • Only approved OGC Standards have document numbers 1.0.0 or greater. The first approved version of an OGC Standard shall be version 1.0.0.

  • Corrigendum releases shall NOT result in any change to the major/minor number. If the Standard being revised has schema, then the schema shall use the version attribute to document the revision number at the third level.

  • Revisions to an adopted Standard typically result in a change to the minor number. For example, the first revision to an adopted 1.0 Standard would be 1.1.0. Minor revision releases should be 100% backwards compatible with the previous version.

  • Changes to the major version number are reserved for when there are significant changes to the adopted Standard or when backwards compatibility cannot be maintained with the previous version.

Building blocks may undergo their own lifecycle of development. A change to a building block results in a revision (and thus new version) of its owning Standard. Each building block is individually versioned, but cannot be versioned higher than the owning Standard.

9.2. Periodic review

All OGC Standards will undergo periodic review to ensure that the Standards are meeting community needs. Periodic review will occur at a maximum interval of every four years. However, the TC or a subgroup can request an earlier review based on observations of poor adoption, lack of market relevance, or significant errors in the Standard. The TC Chair will put requests for earlier review to a TC vote (all members) via the Voting forum and process.

The process for periodic review is as follows.

  • Not more than twice per year, the TC Chair shall gather a list of all Standards which have a four-year anniversary date in the interval since the last review notice AND all Standards requested by the TC or a subgroup to be reviewed.

  • The list of Standards will be released for 30-day TC and public review. The review request will include download statistics for each document to be reviewed.

  • Those who choose to submit a response to the review shall indicate their suggestion on a fate for the Standard (no change, revise, deprecate, legacy, retire; see Policy for Retiring, Deprecating, or Rescinding OGC Documents) and provide a rationale for their suggestion.

  • The TC Chair will collate all responses and work with the owning SWG to determine a course of action. The SWG must vote per SWG voting to suggest the course of action.

  • The SWG will recommend to the TC approval of their action, to be voted via the Voting forum and process.

  • Should the TC agree to the SWG action, the TC will recommend approval of the action to the EPC for EPC vote.

  • The SWG will proceed with the action. The action may result in further work (as detailed below) which will entail its own approval process.

In some cases, the owning SWG for the Standard under review is no longer active. In this case, the TC will vote on a course of action via the Voting forum and process without input from a SWG.
The periodic review process above applies to all OGC Standards except the Abstract Specification. The Abstract Specification lifecyle is managed by the OAB, with consultation or advice from the TC.

9.3. The Standard Revision Process (Full Standard)

A SWG manages the revision of a Standard based on either a) comments received as part of the OGC Consensus Standards process or b) the contents of one or more official OGC Change Request Proposal(s) (CRPs), which can include Issues logged in the SWG collaboration environment such as GitHub or GitLab or Change Requests logged in the OGC central Standards Tracker.

All voting in a SWG for revisions to an existing Standard will follow the rules as defined for SWG voting.

9.3.1. The Revision Process

The SWG reviews requests for revisions and corrections to a Standard. The SWG may discuss issues that have not been submitted as CRPs and may vote to direct one or more of its members to create official CRPs to document an agreement reached as the result of those discussions.

A major or minor version revision of a Standard follows the process of the Full Standard track with the initial revision approved as a Draft Standard. A Corrigendum to a Standard does not require new evidence of implementation and the Corrigendum is approved at the final stage of a Standard.

Internal Review and Public Comment

When the SWG work items are complete and with the approval of the voting members of the SWG, the candidate revised Standard may be submitted to the OAB and OGC-NA for a review and subsequent release for the 30-day public comment period.

For Standards defining APIs where one or more API elements are proposed for removal in the revision, the API element deprecation process (Deprecating API elements in OGC Standards) will also need to be followed to completion.

From this point on, the processing of the revision to the Standard is the same as defined in Review of the received comments (All) and subsequent sections.

Cut-off date for accepting new Change Request Proposals

CRPs to approved Standard documents or documents currently in revision can be submitted at any time, and then must be considered by the appropriate SWG. A SWG can set and publicize a cut-off date beyond which it will not consider additional CRPs. CRPs submitted after such a cut-off date must be considered as part of future revision activities.

9.3.2. Additional Guidance and Responsibilities of a SWG during the revision process

The SWG shall perform the following tasks.

  • Work to ensure that revisions to the Standard are consistent and harmonized with other related OGC Standards.

  • Work to ensure that the new revision is – as best as can be accomplished – backwards compatible with the previous revision.

  • Provide a revision notes document using the Standard revisions template that documents the revisions to the Standard resulting from either public comments or CRPs. The revision notes include lists of deprecated capabilities, changes to capabilities, and new capabilities that are added over time.

9.4. The Standard Revision Process (Community Standard)

Revision of a Community Standard is treated similar to a new Community Standard submission and all processes for approval of a Community Standard from approval of a Work Item to vote for final approval are required. The only difference in the process is the TC vote to recommend the Work Item for revision to a Community Standard for EPC approval can occur at a Plenary or via a two-week e-mail vote, i.e., the vote is not a 45 day electronic vote. The revision process is effectively identical to the addition of a Task to a SWG Charter for a Full OGC Standard.

9.5. Corrigendum (errata) Changes to OGC Standards and Best and Community Practices

Errors may be discovered in a published and approved OGC Standard, Best Practice, or Community Practice. Under the corrigendum process, an error (or errors) in a published document discovered after adoption and publication is shown with its correction(s) in a document that is clearly identified as a corrigendum.

This process to create and approve a corrigendum is as follows.

  1. An identified error is documented and submitted to the OGC via a change request or logged issue. The SWG, Community Standard submitter, or owning subgroup assesses the error and if it fits the criteria for a corrigendum, notifies the TC Chair with a proposed corrigendum document or a plan to create such a document.

  2. The TC Chair evaluates the candidate corrigendum to verify that a specific error is being documented and corrected. The TC Chair assesses if the correction is suitable as a corrigendum (error correction) or if it should create a minor or major revision to the document.

  3. If the TC Chair agrees with the subgroup that a corrigendum is needed, then a request for comment is made to the TC. The reason for the TC broadcast is that there may be many implementations of a Standard for which an error has been documented.

  4. The Membership votes to release (or not) the corrigendum. A Corrigendum vote will occur via the Voting forum and process and there is no IPR review requirement.

  5. The corrigendum is published with text indicating what error(s) have been corrected. Associated documents and products may also require update.

Minor editorial corrections or improvements to published OGC documents, including Standards, may be approved by the TC Chair to be made directly to the published document if those changes are so minor as to not require further TC consideration. Such changes may include typos, formatting, broken links, or unclear grammar.

9.6. Backwards Compatibility (Full Standard)

In all cases of adopted Standards in a revision process, the members will work to insure the highest level of achievable backwards compatibility to the previous release. In those cases in which backwards compatibility cannot be achieved, the Standard will have a major revision and the SWG will provide Release Notes that document all enhancements, changes, and compatibility issues resulting from the revision of the Standard. Both the TC and the EPC reserve the right to review the issues related to backwards compatibility for a given revision of a Standard. If the backwards compatibility issues are deemed too onerous, the TC and/or the EPC may elect to reject the proposed revision.

9.6.1. Policy for Retiring, Deprecating, or Rescinding OGC Documents

This section provides the policy and procedure for retiring, deprecating, or rescinding OGC documents. Note that retiring, deprecating, or rescinding an OGC Standard results in the same fate for all OGC-published extensions to and profiles of the exact version of that Standard.

Standards are retired or deprecated by a Required TC electronic vote of the TC. Retirement or deprecation must be preceded by a 60-day public comment period informing the community that the Standard is proposed for retirement or deprecation and requesting evidence to support or reject the change in status. Any comments received during the public comment period must be presented to the TC during the request to retire or deprecate the Standard.

Retiring OGC Standards

Retirement criteria can be based on one or more of the following:

  • no one is implementing the Standard;

  • a Standard is no longer technically up to date;

  • a Standard is not actively downloaded from the OGC website;

  • a Standard is no longer considered to be of interest by the Membership; or

  • the Standard is no longer valid due to new OGC documents being published.

Retired Standards are published in a "Retired" archive available to the public. Each Retired Standard shall have “Retired” watermarked on the cover page. If there are schemas associated with a retired OGC Standard, the schemas remain in the OGC schema repository. If there are compliance tests for the retired Standard, the compliance tests are automatically retired but also remain available on the OGC web site.

Deprecating OGC Standards

The TC may choose to deprecate a Standard when it has been replaced by new version of that Standard. A deprecated Standard is no longer supported, but is made available to the public on the OGC website and other resources and clearly labeled as "Deprecated."

The deprecation vote may be part of the adoption vote for the new version of the Standard. In this case, when the motion is made to the TC at a meeting or email vote to approve the start of an electronic vote for a Standard, that motion shall include a request to deprecate the previous version.

The deprecation public comment period can start at any point prior to requesting approval of the revision to the Standard. Such a review of the impact of deprecation should begin as soon as a SWG considers a revision that is intended to result in a deprecation of a Standard.
Deprecating API elements in OGC Standards

Standards for APIs (Application Programming Interfaces) are specifically designed to be implemented as a series of API elements. These elements may be described in a format more suitable for direct use by software developers (such as OpenAPI content delivered in YAML). Elements with the API description correspond to one or more requirements defined in the Standard document. Elements may correspond to building blocks, but not necessarily.

When an API element is removed during the The Standard Revision Process (Full Standard), the impact on implementations of that Standard should be minimized. Therefore, the implementing community will be given sufficient notice and provided with options for commenting on the changes to the Standard through a formal API element deprecation process.

The API element deprecation process is as follows.

  1. A candidate revision to the Standard and any supporting API definition resources is provided to the TC Chair with all proposed deprecated elements clearly identified. The rationale for deprecating the elements is provided as a separate document. Optionally included with the rationale can be work-arounds or other documentation to describe how implementers might address the changes to the Standard.

  2. The candidate revision is released for a 60-day public comment period informing the community that the Standard is proposed for revision with deprecation of some API elements. The call for comments will request the community to provide evidence to support or indicate the consequences of deprecating the API elements.

  3. The SWG will consider all comments received per the process for Review of the received comments (All). Based on the comments, the SWG will decide whether to proceed with the revision.

  4. The candidate Standard with all deprecated API elements clearly identified as deprecated continues the Standard approval process.

  5. Once approved, the Standard retains the deprecated API elements, each clearly identified as deprecated, in the publication for a period of two years. After two years, the deprecated API elements may be removed from the published document. If there is another revision to the Standard before the two-year period ends, the deprecations will still be identified in the revision until the original two-year period ends.

Legacy OGC Standards

If an existing Standard is replaced in part or whole by one or more new Standards, then a special case of deprecation may occur resulting in the original Standard being labeled a "Legacy Standard." As with deprecated Standards, Legacy Standards are no longer supported, but they remain on the OGC website with a notification that the capabilities of the Standard have been replaced in whole or part by new Standard(s). The notification will clearly indicate that the Legacy Standard is not invalid, but that new implementations of the capabilities of the Standard are better served by the identified new Standard(s).

The approval process for deprecating a Standard to a Legacy Standard status is the same as Deprecating OGC Standards, but the process clearly states that the deprecation will result in a Legacy Standard.

Legacy Standards will undergo Periodic review every two years.

Rescinding OGC Standards

OGC Standards may be rescinded for three reasons:

  1. the Standard includes intellectual property that was unintentionally or illegally provided as part of the Standard;

  2. a Community Standard is abandoned by its originating/maintaining party and the OGC membership does not take over maintenance of that Community Standard; or

  3. a Community Standard is judged by OGC membership to no longer be applicable to the OGC Mission.

A Standard is rescinded by electronic vote of the TC as described for Retiring OGC Standards.

Rescinded Standards are not published on any public OGC resources. Should the Standard be rescinded for legal reasons, all supporting information for that Standard may be removed from the OGC Portal.

9.7. Lifecycle management of other OGC documents and products

Other OGC documents and products also have a managed lifecycle. The process for each type is generally as described for Standards, with the following specific policies.

  • Best and Community Practice: these documents follow the rules for Lifecycle management of OGC Standards and other documents and products, except that the owning subgroup is not necessarily a SWG.

  • Engineering Reports, Discussion Papers, and Technical Papers: these documents are not revised. Each will have a Periodic review on a frequency not to exceed two years with the only consideration to retain or retire the document. The Periodic review process is restricted to TC review for comment on retention or retirement of the document. The TC Chair along with OGC staff will propose an action based on the TC review for vote in a meeting or via email.

  • Registry content: registered content is managed by the OGC-NA and its lifecycle is handled by OGC-NA policy.

  • Other supporting documentation or products: other documents or products which support a Standard are tied to that Standard in its lifecycle and follow the same fate as the Standard.

10. Overriding or enhancing specific policies or procedures

The TC PnP may not be updated quickly enough to address emerging policy decisions by the TC or EPC. Thus, a means to override or extend policies is provided.

10.1. Temporary override

The Technical Committee may temporarily override specific procedures set forth in this document by a motion to override the normal TC Policies and Procedures. Approval of such an override motion shall require a two-thirds majority vote of non-abstaining Voting TC Members, present at a quorate TC meeting or by electronic TC vote.

10.2. Policy Directives

The TC may choose to generate a Policy Directive to create a specific rule for use in the TC business. The Policy Directive is approved per the rules for Voting forum and process in a meeting. TC-generated Policy Directives are not approved via email or electronic votes in the TC. The EPC may also recommend a Policy Directive for TC and such a directive can be approved by email vote of the TC.

Annex A: Terms and Definitions

AP (Application Profile) - Set of one or more base standards and - where applicable - the identification of chosen clauses, classes, subsets, options and parameters of those base standards that are necessary for accomplishing a particular function [ISO 19101, ISO 19106]

Application Schema: [ISO 19109] An application schema utilizes an Implementation Standard and adds application specific entities, e.g., feature types. An example of an application schema is IndoorGML or CityGML.

AS (Abstract Specification): The Abstract Specification forms a foundation (generally of conceptual models) upon which OGC Standards can be constructed The Abstract Specification comprises a series of Topics, each approved as a Standard.

Board of Directors: Defined by the bylaws of the OGC.

BP (Best Practice Document): A document containing discussion of best practices related to the use and/or implementation of an adopted OGC document or related technology and for release to the public. Best Practices Papers are the official position of the OGC and thus represent an endorsement of the content of the paper.

Candidate Standard: An engineering document that describes an existing, operational Standard that one or more OGC Voting TC Members wish to sponsor as an RFC submission under the Bylaws of the OGC.

Concept: an abstract or generic idea generalized from particular instances [Merriam-Webster].

Conceptual model: a description of common concepts and their relationships, particularly in order to facilitate exchange of information between parties within a specific domain [CEN ENV 1613:1994]. A conceptual model is explicitly chosen to be may be informed by, but independent of design or implementation concern.

COSI (Collaborative Solutions and Innovation) Program: A global, collaborative, hands-on engineering and testing program designed to deliver proven candidate standards into the OGC Standards Program and to exercise and test existing OGC Standards in domain specific situations. More information about COSI can be found at

Draft Standard: A Standard which has been approved by OGC membership, but which lacks evidence of implementation.

Deprecated Document: An official Standard of the OGC but no longer maintained. An OGC document shall be deprecated by a vote of the OGC Voting Members.

Encoding Standard: a Standard that describes the rules and format for encoding data to satisfy a specific interoperability concern. Encoding Standards may be general for all types of geospatial use or domain-specific.

ER (Engineering Report): An ER Report is a document that reports on some technical activity in an Interoperability Program Initiative. An ER Report may also be a candidate Standard or a formal change request proposal for an approved Standard. An ER Report documents are submitted to the OGC TC for review and comment. An ER Report is not a publicly available document unless approved for release by the OGC membership. An ER Report does not represent the official position of the OGC nor of the OGC Technical Committee.

EPC (Executive Planning Committee) − The OGC Executive Planning Committee is granted authority to operate by the OGC Bylaws. Principal Membership is available for organizations that wish to participate in the planning and management of the Consortium’s technology development process.

Extension: An extension is a set of one or more conformance clauses that defines new options for an existing Standard. Extensions are generally designed to add additional capabilities that are not part of the core Standard. An example is OGC GeoPackage Extension for Tiled Gridded Coverage Data.

Implementation Standard: a Standard that describes how software may be designed to perform one or more operations.

Invited Guest: A liaison representative appointed by an external organization which has reciprocal liaison status with the OGC, or an individual who has received an invitation to attend meetings of the TC. The OGC staff or Voting TC Members may issue invitations. It is the policy of the OGC to freely allow guests and observers, so long as they provide a request to attend to the OGC staff and pay the appropriate meeting fees.

IPR (Intellectual Property Rights): An umbrella term used to refer to the object of a variety of laws, including patent law, copyright law, trademark law, trade secret law, industrial design law, and potentially others.

Issues: Issues are questions (other than standard adoption questions) that come before the Technical Committee for discussion, resolution and, potentially, final recommendation to the EPC.

Items: Items are proposed standard adoption questions that come before the committee for discussion, resolution and, potentially, final recommendation to the EPC. Items come about through TC voting membership motions and seconds, typically in response to RFCs, EPC directives, and WG recommendations, or the normal course of TC business.

Necessary Claims: Those claims of a patent or patent application, throughout the world, excluding design patents and design registrations, owned by a Member or its Related Parties now or at any future time and which would be Necessarily Infringed by implementation of a standard. Notwithstanding the foregoing, Licensed Claims shall not include any claims (i) relating to any enabling technologies that may be necessary to make or use any implementation of a standard but are not themselves expressly set forth in the standard (e.g., semiconductor manufacturing technology, compiler technology, object oriented technology, basic operating system technology, and the like); or (iii) necessary for the implementation of other published standards developed elsewhere and merely referred to in the body of the standard. For purposes of this definition, a standard shall be deemed to include only architectural and interconnection requirements essential for interoperability and shall not include any implementation examples unless such implementation examples are expressly identified as being required for compliance with the standard.

Official Position - A consensus document approved by OGC membership or the OGC Board of Directors that defines a standard, practice, or policy which is judged by OGC to be authoritative within the context or applicability of that document.

OGC − Open Geospatial Consortium Founded in 1994, the OGC is a voluntary consensus standards organization.

OAB (OGC Architecture Board) - The OGC Architecture Board works with the TC and the EPC to insure architecture consistency of the Baseline and provide guidance to the OGC membership to insure strong life cycle management of the OGC Standards baseline. The OAB performs review of every Standard proposed for adoption by the OGC. The OAB is an entity organized under the Consortium.

OGC Communication: A communication by any means, including posting on the WWW Site (, electronic mail, facsimile transmission, or by regular post. The primary forms of communication will be either via email or using the OGC Members Only Portal. Any member desiring delivery by other than electronic means (WWW site or electronic mail) must state so in written form to OGC staff.

OGC Standard: A document containing an OGC consensus computing technology dependent Standard for application programming interfaces and related Standards based on the Abstract Specification or domain-specific extensions to the Abstract Specification provided by domain experts. OGC Standards generally have evidence of implementation.

OGC Member, or Member: Any member in good standing.

OGC Member Portal: A members’ only accessible component of the OGC web site. The Portal provides a location for storing and accessing all in progress OGC TC and EPC documents, all WG agendas, working documents, and presentations, and to perform project management functions, such as tasks, tracking actions, and calendars.

OGC Standards Program: Provides an industry consensus process to plan, review and officially adopt OGC Standards for interfaces and protocols that enable interoperable geoprocessing services, data, and applications. The OGC bodies involved in the Standard Program are the Technical Committee, Executive Planning Committee, and Strategic Member Advisory Committee.

Profile: [ISO 19106:2004, Type 1 Profile] A profile is a pure subset of an existing Standard including restrictions on or deletions of conformance clauses related to the subsetting. An example of a profile is the GML Simple Feature Profile.

Profile with Extension: A profile with extension is a set of one or more conformance clauses from a base Standard that includes at least one new conformance clause (extension). An example is OpenGIS® Web Map Services - Profile for EO Products.

RAND: Reasonable and Non-discriminatory.

Request for Comment (RFC): An explicit request to the industry for comments concerning a particular candidate Standard that OGC membership is considering for adoption as a Standard satisfying a portion of the Abstract Specification.

Retired Document: An OGC document that, by Member approval, is no longer an official or supported document of the OGC. As such, retired documents should not be referenced in any procurement, policy statement, or other OGC document. Retired documents are made available on the OGC website for historical purposes.

SMAC (Strategic Member Advisory Committee): The SMAC is granted authority to operate by the OGC by-laws. The SMAC has as a primary responsibility to recommend areas of strategic opportunity for Consortium operations and recommending resource strategies in support of Consortium programs to the Board of Directors, Consortium staff and the Membership.

Standards Development Process: The operational details of the discussing and evaluating technologies relevant to the OGC Standards baseline, Standard revision, and the RFC processes to propose, review, recommend modifications to, and recommend adoption of candidate Standards.

Standards Baseline: The complete set of member approved abstract specifications, Standards (including profiles and extensions), and Community Standards.

TC (Technical Committee) See Section 5: The OGC TC has been granted authority to operate by the OGC Bylaws. The OGC Technical Committee is composed of individuals representing organizations that are duly recognized members in good standing of the OGC.

TC Member: Any member in good standing of the TC.

Technical Paper: An OGC member approved publication released by the OGC to the Public that states a position on one or more technical or other subject that is germane to the work of the OGC, often including a high-level explanation of a standards-based architecture or framework of a solution. A Technical Paper often explains the results or conclusions of research. A Technical Paper is not an official position of the OGC.

Voting TC Member: Any member of the TC who may vote on TC Items and Issues. Voting TC Members are the Technical Representatives of OGC Technical Committee Members, Principal Members, and Strategic Members. Only the designated Technical Representative from a given member organization may be a Voting TC Member.

Annex B: OGC Consensus Standards adoption checklist

Action Responsible Party

Contact Technical Committee chair about intent to submit or start


Identify submission team (3 or more Members, one is TC Voting Member)


Signed Submission of Technology form (optional)

TC Chair and convener

Submission Team writes draft SWG Charter

Submission Team

When draft ready, the team sends the draft to the TC Chair


TC Chair reviews draft and provides comments back to the submission team

TC Chair

Submission Team reviews TC Chair comments and modifies charter as required

Submission Team

When ready, convener posts draft charter to pending documents


After posting, the TC Chair shall notify the membership of the draft

TC Chair

30 day public comment and review period

TC Chair

Present SWG charter to TC

Submission Team

45 day TC recommendation vote


EPC approval vote (meeting or 14 days by email)

TC Chair

OGC Portal Update


Press release to announce formation of new SWG

Staff and Submission team

TC Chair does a call for participation and chairs

TC Chair

SWG officially starts: first order of business is to elect chair etc


Work on candidate Standard happens


For a revision to an existing Standard, collate all CRs/Issues and prepare summary


For a revision to an existing Standard, process all CRs/Issues


Editor(s) edit the document based on change requests


SWG approves release for public comment


Notify TC Chair of intent for release for public comment

SWG Chair and TC Chair

OGC Architecture Board Review


OGC Naming Authority Review


Post to Portal project as a public read access document

SWG Chair and editor

30 day public comment period


The SWG compiles a list of the comments into a document


SWG Processes the public comments


Editor(s) edit the document based on comments


For a revision, write release notes


SWG Votes to release candidate Standard for adoption vote


TC Chair reviews candidate Standard and makes suggestions

TC Chair

SWG Posts candidate Standard to pending documents.

SWG Chair

SWG Briefs TC Membership on contents of candidate Standard

SWG Chair or designee

45 day TC recommendation vote

Voting Members

SWG process any comments received during the adoption vote


EPC approval vote (meeting or 14 days by email)

TC Chair

TC Chair does final review of adopted Standard

TC Chair

Schema processing

SWG and OGC staff

Schemas validated and errors corrected

SWG and OGC staff

Standard published

OGC staff

Create Press release to announce new Standard

SWG and OGC staff

Annex C: Community Standard adoption checklist

C.1 Qualification Checklist – Community Standards

The following is a list of questions that the submission team needs to answer in the affirmative prior to submitting community specification into the OGC.

  1. Can the original specification be licensed for free, public distribution per OGC policy?

  2. Is there sufficient evidence of broad implementation?

  3. Is the candidate Standard unencumbered by any 3rd party intellectual property?

  4. Is there method to determine compliance with the Community Standard? This could be an abstract test suite, a compliance test framework, clearly defined requirements, or other text in the document that describes compliance.

C.2 Community Standard Process Checklist

Action Responsible Party

Contact TC Chair about intent to submit or start a Community Standard process


Identify submission team (3 or more Members, one is TC Voting Member)


Submission team creates work item justification

Submission Team

TC Chair reviews justification and provides comments back to the submission team

TC Chair

Submission Team reviews TC Chair comments and modifies justification as required

Submission team

Justification document posted to pending documents

Submission team

After posting, the TC Chair shall notify the membership of the draft

TC Chair

30 day public comment and review period

TC Chair

Present justification to TC

Submission Team

45 day TC recommendation vote


EPC approval vote (meeting or 14 days by email)

TC Chair

Submission team edits candidate Community Standard happen based on public comment and TC/EPC votes: normative content may not change

Submission team

Notify TC Chair of intent for release for public comment

Submission team

OGC Architecture Board Review


OGC Naming Authority Review


Post to Portal project as a public read access document

Submission team

30 day public comment period


Submission Team reviews comments and modifies document as required


Post candidate Community Standard to pending documents

Submission team

Submission team briefs TC Membership on contents of candidate Community Standard

Submission team

45 day TC recommendation vote

Voting Members

Submission team process any comments received during the adoption vote

Submission team

EPC approval vote (meeting or 14 days by email)

TC Chair

TC Chair does final review of adopted Standard

TC Chair

Standard published

OGC staff

Create Press release to announce new Standard

Team and OGC staff