Published

OGC Policy

Technical Committee Policies and Procedures
Scott Simmons Editor
Version: 27.0
OGC Policy

Published

Document number:05-020r27
Document type:OGC Policy
Document subtype:
Document stage:Published
Document language:English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, (“Licensor”), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.



I.  Abstract

The OGC provides a collaborative, consensus process for developing and approving open, international standards for the geospatial domain. “International standards”1 are those adopted by an international standardizing/standards organization and made available to the public. Specifically, an OGC standard is:

A document, established by consensus and approved by the OGC Membership, that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context.

To guide an open standards development and approval process, a member approved Policies and Procedures is required.

This document describes the OGC Technical Committee (TC) policies and procedures (P&P). 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. The Technical Committee Chair (TCC — see Clause 2.2) facilitates the TC process.

The TC P&P:

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

The OGC Technical Committee provides an open, collaborative forum for professional discussion related to the consensus development and/or evaluation, approval, and revision of OGC international standards. The primary use of approved OGC standards is to provide the ability to build and deploy interoperable geospatial solutions in the larger Information Technology (IT) domain.

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

II.  Security considerations

No security considerations have been made for this document.

Technical Committee Policies and Procedures

1.  What is a Consortium?

A broad definition of a consortium is: a combination or group of organizations formed to undertake a common objective that is beyond the resources or capabilities of any single organization. The OGC was formed 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.

More specifically in the standards area, a consortium has the following characteristics:

The OGC is defined as a Voluntary Consensus Standards Organization2.

2.  Purpose and Composition of the Technical Committee

The OGC Corporate bylaws state that the OGC Technical Committee (TC) shall be responsible for developing standards3 through a cooperative consensus process involving the Members. The bylaws provide authority to:

Above all, 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. The OGC Principles of Conduct4 govern personal and public interactions in any TC activity.

2.1.  Composition of the TC

The OGC Bylaws provide the enabling authority for the OGC TC. The TC has the following composition:

  • The Technical Committee Chair (appointed by the OGC President and approved by the OGC Board of Directors (BOD));

  • Representatives of all member organizations of the OGC; and

  • Other individuals deemed appropriate by the BOD or Planning Committee.

2.2.  Role of the Technical Committee Chair (TCC)

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

  • Note 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;

  • 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 8 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 PC and BOD are kept appraised of the current business of the TC;

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

  • 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 TCC has the right to cast the deciding vote.

2.3.  Clarifications with respect to the composition of the TC

Although one or more individuals may represent each member organization of the OGC at TC meetings, only OGC Member organizations with TC voting rights (Strategic, Principal, and Technical Committee Members) can vote on any items or issues related to the adoption of an OGC standard, approval of membership of the OGC Architecture Board (OAB), the TC Policies and Procedures, or the Standards Baseline. For these votes, only one individual may vote on behalf of each such Member organization. There is no limit to the number of TC members that may represent each OGC member organization at TC meetings. However, the TCC may limit the number of attendees (on a maximum-per-organization basis) for reasons of meeting space or other operational considerations.

The TCC shall have the authority to nominate and recommend non-OGC organizations to the BOD members for consideration as voting members of the TC for appointment by the BOD.

3.  Structure of the Technical Committee

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

The Technical Committee is comprised of three primary subgroups: the OGC Naming Authority, Working Groups (WG), and Subcommittees (SC) to:

WGs will be formed, carry out their work, and when their work is completed, be dissolved. Working Group Policies and Procedures are defined in Clause 6.

3.1.  OGC Naming Authority (OGC-NA)

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 register of OGC Names: this document describes the framework of documents, registers and other resources required for OGC-NA to execute that role. There are separate OGC-NA Policies and Procedures.

3.2.  Subcommittee (SC) of the TC

A standing group (organizationally, a subgroup of the TC) 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 have Voting TC Member-only voting. As with all OGC groups, each Voting TC Member has only one vote per SC. SCs are long-standing entities with general portfolios or mission. OGC staff can chair TC SCs. Any OGC member can attend a SC meeting and participate.

A SC may be proposed by any TC member. The TCC shall determine whether the SC should be established and whether a charter is necessary.

3.3.  Working Groups (WGs)

A group (organizationally, a subgroup of the TC) of individuals composed of members of the TC and invited guests, with the specific intent of solving some particular interoperability problem or problems in a particular technology domain for recommendation to the TC. A Group is not a subcommittee as outlined by the Bylaws of the OGC.

There are two types of Working Groups in the TC: Domain Working Groups (DWGs) and Standards Working Groups (SWGs). The reason that there are two different type of Working Groups is due to the OGC Intellectual Property Policy. The OGC IP Policy can be downloaded from http://www.opengeospatial.org/ogc/policies.

3.3.1.  Domain Working Group

A group (organizationally, a subgroup of the TC — Clause 6.6) 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 Domain Working Group (DWG) are to:

  • Have a formal approved charter that defines the DWGs Scope of Work and estimated timeline for completion of the work (if applicable);

  • 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 related to Interoperability Program Reports;

  • Develop Change Request Proposals (CRPs) for existing OGC standards;

  • Develop Engineering Reports with the intent seeking approval by the TC for release of these documents as OGC White Papers, Discussion Papers or Best Practices Papers;

  • Informational presentations and discussions about the market use of adopted OGC standards.;

  • Have all-member voting policies (unless otherwise stated); and

  • Have missions and goals defined by the TC.

A DWG Does Not work on OGC Consensus Standards process submissions, candidate standards, or revisions to existing OGC standards. However, a DWG can develop change requests as document interoperability requirements that can then be submitted as work items to a SWG.

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

3.3.2.  Standards Working Group (SWG)

A group (organizationally, a subgroup of the TC) of individuals composed of members of the TC and invited guests with the specific intent of working on a candidate standard prior to approval as an OGC standard or on making revisions to an existing OGC standard. Please see Clause 6.7 for details on the policies and procedures for SWGs. The following is a general overview.

Specific work items for a SWG could be:

  • Have a formal approved charter that defines the SWGs 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.

  • Process a new OGC Consensus Standards process submission once approved by the OAB;

  • Consider official Change Request Proposals to an existing OGC standard and make changes to the standard as necessary: from this perspective, a SWG does all the work that was formerly performed by a Revision Working Group;

  • Approve a candidate standard for public comment;

  • To vote on any changes to a candidate standard or to an existing OGC standard; and/or

  • Make recommendations to the entire TC once a document is ready for a formal adoption vote;

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 dissolve the SWG once they have completed their work as described in their charter or choose to end the work.

4.  Meetings of the Technical Committee

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

4.1.  Meetings of the TC

Technical Committee meetings shall be conducted under the general guidance of Robert’s Rules of Order6 (RONR). Meetings shall be facilitated by the TCC or other appointed representative(s) of the OGC. The planning goal is to have four meetings per year. The number of meetings per year can be changed by a vote of the TC and the PC 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 four months in advance of the meeting. Announcements will be through formal OGC Communication. All recommendations, summary notes, presentations, and so forth shall be posted to the OGC Member Portal.

4.2.  Attendance at TC Meetings

Only members of the OGC, Invited Speakers, and Invited Guests are welcome at TC meetings. Any TC member may send another representative of his or her organization as a substitute to a TC meeting (please note Clause 5.3.4). Subgroups may only meet by being formally scheduled by the TCC or designee during the course of regularly scheduled TC meetings (subgroups cannot have alternative meetings that overlap temporally with the TC Meeting without approval of the TCC or PC).

4.3.  Policy for Invited Guests

From time to time, 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 (see Policy for Invited Speakers below), 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 TCC. That is, in the interests of ensuring the efficient operation of any meeting, the TCC 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 TCC and the OGC staff responsible for meeting logistics. The steps are very similar to those for Invited Speakers.

  • OGC staff or the DWG/SWG Chair provides a formal invitation to the individual with a cc to the TCC and the TC meeting support staff.

  • The TCC 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.

4.4.  Policy for Invited Speakers

From time to time, OGC staff or Members wish to invite an individual from a non-Member organization to speak at an OGC Working Group meeting or Plenary session. Any invited speaker may attend the TC meetings for the day on which they are speaking without having to pay the TC meeting fee. The process is as follows.

  • The DWG/SWG Chair provides a formal invitation to the individual with a cc to the TCC and the TC meeting support staff. The formal invitation may be via email.

  • The TCC approves the invitation.

  • The OGC provides the invited speaker with a speaker registration code.

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

If the invited speaker wishes to spend more time at the TC meetings beyond the day on which they are speaking, they will need to pay the required TC meeting fee, unless waived. For the day the invited speaker is attending, they are free to partake of any refreshments but will need to pay for their own lunch or any related OGC social event they wish to attend on that day. Finally, the speaker may need to sign the standard OGC Non-Disclosure Agreement (NDA).

4.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 solely by the TCC or designee and will be modified prior to the meeting as appropriate. The TCC will maintain a master agenda that is available to members and which is generated from the agendas of each WG as they are populated.

The WG Chairs shall provide the TCC or designee meeting date and time requests at least 4 weeks before the actual TC meeting. The earlier the better!

Each WG Chair shall email an agenda to OGC members at least three weeks before the meeting. Due to schedule conflicts, WG 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. However, the Chairs of a WG that do not provide an agenda can elect to have an ad-hoc meeting during the off-hours (such as a breakfast or after dinner session).

5.  Voting During and Between TC Meetings

The following policies address voting during and between TC meetings. One of the primary functions of the TC is to vote on a variety of actions, items, and issues. Votes can be for any purpose pertaining to the format and content of the Abstract Specification, Candidate standards, OGC standards, Discussion Papers, approval of the slate of nominations for the OGC Architecture Board, Best Practices Documents, Policies and Procedures of the TC, and for other purposes consistent with the purpose of the TC as described in these Policies and Procedures. The TC will make recommendations to the PC concerning adoption of a candidate standard, changes to a standard, creation of a Working Group, a Best Practice, or a policy document and these recommendations require further approval by the PC.

5.1.  Quorum for a TC Meeting

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, Technical, and Technical Aggregate 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. 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.

5.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, one third of the Voting TC members in attendance may invoke the requirement that documentation supporting the vote must be available three weeks prior to the vote. The TC may override the 3-week rule by a 2/3-majority vote of Voting TC members in attendance at a meeting.

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.

5.3.  Voting at TC Meetings

Many votes happen during a face-to-face TC Meeting. Votes can occur in a TC Plenary or in any sub-group meeting. Votes may be related to document actions, recommendations for staff action, formation of new sub-groups, approval of WG charters, and so forth. This section provides guidance on the policies and procedures related to votes at TC meetings.

5.3.1.  Votes that can occur at a TC DWG Face to Face Meeting

Any number of votes can occur at a TC DWG meeting. No prior notice is required to have a vote at a DWG meeting during a TC. Any member representative attending a DWG may vote. However, only one member representative from a member organization may vote in a DWG. Any member representative attending a DWG can frame a motion.

The votes that may occur at a DWG are:

  • Move to release an Engineering Report as a Discussion Paper;

  • Move to initiate an electronic vote to release an Engineering Report or other OGC document as a Best Practices document;

  • Move to elevate a Discussion Paper to a Best Practices document;

  • Move to recommend to the TC a change in policy or procedure;

  • Move to accept or revise a DWG charter;

  • Move to dissolve a DWG; and

  • Move to modify the charter of a DWG.

All of these motions of the DWG are recommendations to the full TC.

5.3.2.  Votes that can occur in a TC Plenary

Many votes usually occur in the Opening or Closing TC Plenary. The following is a matrix of possible votes and who can vote.

Table 1 — Vote types and allowed voters

Vote TypeWho can Vote
Approval of a White Paper, Discussion Paper, or Engineering ReportAny member
Election of TC reps to the PCAny member
Approval of a DWG CharterAny member
Approval of deprecation or retirement of Discussion Paper or Best PracticeAny member
Approval to start electronic vote for an OGC Best Practices DocumentTC Voting Member
Approval to start electronic vote for adoption of an OGC standardTC Voting Member
Approval to start electronic vote for a revision of an OGC standardTC Voting Member
Approval to start electronic vote for a new TC P&P or other policy documentTC Voting Member
Approval to start electronic vote for a new SWG or Community standard work activityTC Voting Member
Approval of a new SWG TaskTC Voting Member

+For "Any Member" votes, only one member representative from a given Member Organization may vote.

5.3.3.  Form of a Document Motion in a SC or WG

All SC or WG 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 <White, Discussion, or Engineering> Document.

Often the following clause is added:

“Pending any final edits to the document.”

Best Practice and standards 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 a <OGC Best Practice or Adopted Standard>.

5.3.4.  Proxy for Voting

Not every OGC TC Voting member can attend every TC Closing Plenary. Therefore, the OGC maintains a proxy process. The official TC Voting representative for an organization can assign their proxy to another full-time employee of their organization, to another individual from another TC Member voting organization, or to the TCC.

Proxies can be assigned electronically or in written form. The written proxy form is provided for each meeting and are sent to the Voting members via email as well as being posted to the TC meeting folder for which the proxy will be valid. Assignment of proxy to another full-time employee of the Voting member’s organization may be communicated verbally to the TCC in advance of or at the TC Closing Plenary.

Proxy shall be communicated to the TCC in advance of the TC Closing Plenary. The TCC shall send reminders to the Voting Members prior to the meetings.

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.”

5.4.  TC Electronic Voting

At any time, the TCC, the TC, or a subgroup of the TC may recommend starting an electronic vote. Initiation of electronic votes may be brought by motion and second at a TC plenary meeting, a WG meeting, or by direct action of the TCC. Please refer to Table 1 for what membership level is allowed to vote for any particular vote. The following rules are for official OGC votes related to:

  • Adoption of an OGC Abstract and Implementation standards;

  • Adoption of a revision to an existing OGC Abstract or Implementation standard;

  • Adoption of a OGC Policies and Procedures;

  • Approval of an OGC Best Practice;

  • Election of representatives to the OGC Architecture Board; and

  • Approval of a Standards Working Group Charter or a new Community standard work activity.

5.4.1.  Duration

Unless otherwise stated by the TCC or designee, the normal deadline for response to an 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 Clause 5.4.6). The start and end dates for any given vote are set by OGC staff and are posted with the ballot and announced.

5.4.2.  Continuity

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

  • A WG withdraws the motion to approve a candidate standard (see Clause 5.4.9); or

  • The TCC, the OAB, or the WG identifies a procedural error and requests the vote be stopped.

5.4.3.  Eligibility

All Voting TC Members7 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.

5.4.4.  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.

5.4.5.  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.

5.4.6.  Sufficiency

For all votes on any OGC document or OGC policy, sufficiency requires 1/3 of the Eligible voters to vote. Further, 15% of the total number of Eligible voters must vote YES.

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

5.4.7.  Approval8

In addition to Sufficiency thresholds, for documents that are official OGC positions, such as a standard, creation of a new WG, an OGC Best Practice, or an OGC policy, a motion passes (is approved) if the number of YES votes is twice or more the number of NO votes. All other documents pass with a simple majority

5.4.8.  Comments

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. For other votes, then the appropriate TC sub-group 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 Clause 5.4.9) then no response to comments is required.

5.4.9.  Withdrawal

A motion may only be withdrawn by the Working Group9 that made the original motion or by the TCC for procedural reasons. The WG shall have a formal documented vote to withdraw a motion. The reasons for withdrawing a motion are not constrained. The WG shall communicate to the TCC the request to withdraw a motion. The TCC shall then communicate the decision to withdraw a motion to the entire Membership.

5.4.10.  Restarting a vote

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

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

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

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

  • If failure to approve the motion (See Approval and Sufficiency), then the appropriate OGC group needs to address all comments, revise the document and restart the standard approval process with an OAB review, public comment, final edits to the document and a new adoption vote.

5.4.11.  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.

5.4.12.  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.

5.4.13.  Assuming Successful TC vote, what next?

Once the electronic vote completes and assuming a successful TC vote, the following must occur.

  • The TCC shall announce the results of the vote.

  • If there are any comments, the submission team or SWG shall respond to all comments submitted during the voting period. The responses to the comments shall be documented in an OGC document that is then posted to pending.

  • The TCC shall make a recommendation to the Planning Committee requesting approval of the motion from the Technical Committee. The PC shall have two weeks to consider the motion, ask questions, and approve or reject the motion. Approval in the PC is a simple majority of the PC members.

5.5.  Subgroups of the TC Electronic Voting

The procedures for holding electronic votes (e-votes) presented in this section apply to any subgroup of the TC that:

  • Has an email reflector on the OGC Portal on which all voting members are subscribed; and

  • Has a quorum rule on votes, or a rule that requires a notice to the TC at large of the type of vote being contemplated.

In the event that a motion is made either on the email reflector of a subgroup or in some other scheduled meeting of the subgroup (that lacks quorum and thus cannot act directly), then the chair (or presiding officer of the meeting if the elected chair is not present) may call for a Portal vote as a “measures to obtain a quorum” (RONR, 11th Edition, §40, pages 347-348). The procedure will be as follows.

  1. A motion is made and seconded on the subgroup’s email reflector or during a meeting (such as a teleconference) that may not have a quorum.[multiblock footnote omitted]

  2. The chair (or the presiding person at the meeting where the motion was made in conjunction with one of the subgroup’s elected chairs) announces that a Portal e-vote will be taken and summarizes the procedure to be used. This summary includes an opening date (usually immediately or within one week after the motion is made) and a closing date at least one full week after the opening, making the vote last at least 8 calendar days (such as a Monday to Monday schedule).

  3. All requirements for previous announcements as delineated in the TC policy and procedures must be met before the email or Portal vote start date. These requirements may include posting of the associated supporting documents in advance of the vote and/or an official notice to the TC of a pending vote within the subgroup.

  4. Votes must be cast before the end of the closing day at midnight in the time zone of the voter (as recorded by the email send protocol). This mail announcing the vote shall include a formal name for the vote in the subject field.

  5. Any valid voting member of the subgroup may visit the Portal page for the e-vote and cast their vote. The member may change their vote at any time. The last vote cast by the member before the closing date and time is his official vote. Portal votes do not stop until their end date is reached or the vote organizer chooses to withdraw the vote.

  6. Only one vote is allowed per OGC Member organization.

  7. Protests on the procedures involving the vote will be addressed to the subgroup chair, with a final appeal to the TCC and the membership of the TC.

  8. If at least a quorum (1/2) of the subgroup votes (YES, NO or ABSTAIN) then the vote is valid. The original motion passes under the same rules as would have been required in an official meeting.

For most votes that require a simple majority at a quorum-valid meeting, the motion passes only if a quorum is obtained, and the number of YES votes is greater than the number of NO votes.

This procedure shall not be used to suspend the rules or to amend any motion made at a quorum-valid meeting of the subgroup.

5.6.  TC or Subgroups of the TC Email Voting

The procedures for holding email votes presented in this section apply to any votes that the TC is eligible to hold in a Closing Plenary or any subgroup of the TC that meets the criteria for holding electronic votes as defined in Clause 5.6 Note that use of the Portal electronic voting function is preferred over the use of email voting procedures.

Email votes follow the same process as laid out for TC votes in the TC Meeting (see Clause 5.4) or for subgroups of the TC electronic voting (see Clause 5.6), with the following additional procedures.

  1. The TCC or subgroup chair sends an email to the appropriate 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 (“Hand” or “No Objection”).

  2. “Hand” vote: voting members email the reflector (from the email address listed for the corresponding Portal user) with the vote clearly mentioned in the first few lines of the mail, and optionally in the subject line. Allowed votes are YES, NO, or ABSTAIN. The subject line should include the formal name of the subject of the vote used by the chair in the announcement. A member may change their vote by emailing again at any time before the close of the vote. The last vote cast by the member before the closing date and time is that member’s official vote.

  3. “No Objection” vote: an email vote may consist of a request to the group members for any objection to unanimous consent. Voters with no objection to the ballot do not need to email the chair or reply to the vote announcement. Should there be an objection, the vote will be paused and the objection discussed in the reflector or in a meeting. If the objection is addressed to the satisfaction of the objecting party, the vote will continue for the number of days remaining in the vote from the date at which the vote was paused. If the objection is not removed, then the vote will restart as either a “Hand” vote (see 2 above) or a Portal e-vote.

6.  Policies and Procedures for Subgroups of the TC

This section describes the Policies and Procedures for Sub-groups of the TC. This includes Domain Working Groups (DWGs) and Standards Working Groups (SWGs).

6.1.  Membership in TC Subgroups

A subgroup is composed solely of representatives of current OGC members and (potentially) Invited Guests. Each type of group is chartered by simple majority vote of the TC in the course of normal business and ratified by the PC.

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 (Clause 6.7.3).

  • 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.

6.2.  Role of Subgroup 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 minutes of meetings are taken, and made available electronically to the entire OGC membership within two weeks of the meeting: minutes must include:

  1. A list of persons attending the meeting;

  2. A list of motions, seconds, and outcomes; and

  3. A section that details specific actions taken by members of the subgroup;

  • Sending electronic reminders to action holder’s one week before the action is due for completion;

  • Ensuring the smooth and orderly running of the meeting;

  • Reporting on subgroup activities to the parent body, and PC if requested, including presenting subgroup recommendations (if any);

  • Keeping the Chair of the parent body apprised of the progress of the subgroup; and

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

6.3.  Inactive Subgroups

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

6.4.  Subgroup Meetings

Subgroups except as noted above may set their own meeting schedules. In particular, they do not have to meet every time their parent body meets, nor are they prevented from organizing meetings not co-located with those of the parent body, provided that in every case the relevant meeting notice and reporting criteria are met (see Clause 4.1).

6.5.  Formation of a Sub-Group/Working Group

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 Working Group. The following are the usual steps related to the formation of a new WG. Typically, the first step is to call an ad-hoc meeting at a face-to-face TC meeting. An ad-hoc meeting is to 1.) judge interest in forming the new sub-group and 2.) define the scope of work for the proposed new sub-group.

6.5.1.  Ad-hoc Meeting(s)

Any group of OGC members can schedule an ad-hoc meeting. The interested members develop a basic agenda and draft mission statement for the work of the group and call for an ad-hoc meeting at a scheduled TC event or by teleconference/webinar. Like any sub-group, they shall schedule a meeting time and post the meeting time information on the OGC Portal Calendar. Also, like any other sub-group meeting of the TC, they shall announce the meeting to the broader TC and communicate an agenda. At this Ad-hoc meeting, the participants continue to frame the mission and the scope for a proposed new WG or other OGC activity. They must also determine whether there is adequate Member interest to actually form a new WG.

6.5.2.  Development of a proposed Sub-Group Charter

The primary function of the Ad-hoc meetings is to write a Charter for the new sub-group/Working Group. The Charter documents the mission, scope, roles, and responsibilities of the proposed WG. Drafts of the Charter can be shared with other members for review and comment. The templates for the Domain and Standards WG Charter documents can be found here:

https://portal.opengeospatial.org/?m=public=templates=1

6.5.3.  Approval of a Sub-Group Charter

Once the Charter is completed and agreed to by the members of the Ad-hoc11, the following process if followed for approval of the Charter.

NOTE  For a SWG Charter, please review Clause 6.7 for specific requirements related to the formation of a Standards Working Group (SWG).

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

  • The ad-hoc considers the TCC 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.

  • If possible, the draft charter is presented to the TC at a plenary. Otherwise, a PowerPoint or video presentation will be developed and posted to the Portal. NOTE: For a SWG, this presentation should cover the key aspects of the charter, especially the scope of work, the timeline, and the technical discussion related how the standards work aligns with the current OGC standards baseline.

  • Comments received during the comment period are considered by the ad-hoc members 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 TCC shall notify the membership that a revision of the charter has been posted.

6.5.3.1.  Votes to approve the charter and formation of a sub-group

This section describes the voting associated with the approval of specific types of sub-groups: Committees and Working Group. In all cases, the TCC makes the motion to approve the charter for the new sub-group of the TC.

  • Committees: Charters for and formation of subcommittees and committees may be approved by a simple majority vote of the membership. These votes happen at the Closing Plenary during a Face-to-Face TC meeting or by email vote per Clause 5.6.

  • WG: This is a TC Voting Member vote. Approval of the charter is a simple majority. The TCC initiates a vote to approve the Charter and the formation of the WG. This is an electronic vote under the e-vote rules as stated in Clause 5.4. The TCC shall also send an informational email to the full TC membership asking if there are any final comments or objections to the formation of the new WG.

If the TC approves formation of the new group, then the TC makes a recommendation to the Planning Committee (PC) to approve formation of the new sub-group. These votes may happen at face-to-face meetings or by email votes or by a PC e-vote.

Upon approval of the TC and the PC, the new group will become an official subgroup of the TC.

6.5.4.  Changes to a WG Charter or Recharter of a WG

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

  • If the TCC judges the changes to reflect a natural progression of the WG work, then the TCC 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 TCC judges the changes to reflect a major shift in scope of the WG, then the revised charter shall proceed through the same approval process as a new WG charter in Clause 6.5.3.

  • When the recharter vote is requested to start to the TC, the TC has the option to override the TCC vote type recommendation. For instance, if the TCC 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.

6.6.  Policies Specific to a Domain Working Group

This section describes the formation, role, and responsibilities of a Domain Working Group (DWG).

6.6.1.  Voting in a DWG

Voting in DWGs is by simple majority of OGC Members present at the DWG meeting, not just Voting TC Members, with the caveat that no OGC Member organization may cast more than one vote in a WG vote.12

6.7.  Policies Specific to a Standards Working Group (SWG)

A SWG may be formed whenever:

  • Three or more members provide a submission for a candidate standard;

  • One or more Change Request Proposals for a given adopted OGC standard have been submitted to the public Change Request repository on the OGC web site;

  • Three or more members wish to define and document a new candidate OGC standard that will be submitted using the OGC OGC Consensus Standards process; The new candidate standard could be an interface, encoding, profile, application schema, or extension package; and/or

  • Three or more members 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 and Procedures. Members are strongly encouraged to read this Policy prior to forming or joining a SWG.

Whenever a SWG needs to be formed, the first order of business is to inform the TCC The TCC will discuss the process and next steps. The TCC shall announce to the full Membership via OGC communications that there is an intent to start a new SWG (standards) activity.

The submission team then writes a SWG Charter. Please review the OGC ad-hoc meeting and charter creation and approval process as outlined above in Clause 6.5.3. The policies and procedures defined below are in addition to the requirements to form an OGC Domain WG.

6.7.1.  The SWG Charter

The Charter documents the scope of work, references, business value, and projected timeline for the new SWG. There is a formal OGC template for a SWG charter. This template may be downloaded from:

https://portal.opengeospatial.org/?m=public=templates=1

SWG are chartered to create a primary delivery (a new standard), maintain that standard, and optionally update, extend, or profile that standard through a Clause 6.7.13. At a minimum, the scope of the primary delivery is provided in the SWG charter.

6.7.1.1.  IPR rules for a new SWG

The charter of each SWG shall also specify whether the SWG to be formed is a RAND13-Royalty Free SWG or a RAND- for Fee SWG. For a complete discussion of the OGC Intellectual Property Rights (IPR) policies, please refer to:

http://www.opengeospatial.org/about/ipr

The OGC IPR policy is similar to those of other voluntary standards organizations.

6.7.1.2.  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 insure 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. The Charter template has a section that specifies whether a SWG is persistent or not.

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

6.7.1.3.  SWG Charter Approval and Formation

The TCC will work with either the candidate standard submission team or an interested group of members that wish to craft a new OGC standard to write the draft SWG Charter. Once a draft is completed, the charter review and approval process as defined in Clause 6.5.3 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.

Once the charter is approved by the TC and the PC, OGC staff will create a new Portal project for the new SWG. Formation of the new SWG will be announced to the membership.

Finally, the TCC shall make a general call for participation in the new SWG. The call for participation will be made public.

6.7.2.  “Charter” members of the SWG

The charter members for a SWG will be:

  • Any members that are part of a candidate standard submission team;

  • Any member who asks to join the SWG during the three-week SWG Charter review period; and

  • Any members who participate in the development of the Charter for a new SWG.

Charter members have agreed to the IPR terms of the SWG. Charter members are immediately vested in the work of the SWG and can vote on any items or issues during the first meeting of the SWG.

6.7.3.  Participating in a SWG — Opting In

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(s) need(s) to “opt-in” to the new SWG in order to participate. Opting into a SWG is done via a registration page for that SWG. The registration page will be available on the OGC Portal. The registration page will clearly state the IPR terms for the SWG as well as the Scope of Work.

Any member representative opting into a SWG and making a Contribution to any SWG (regardless of its licensing designation) must commit at the time of making such Contribution that if the Proposed standard in connection with which the Contribution is made is finally approved by OGC, the Contributor will provide a License to all patent claim(s) Owned by it that become Necessary Claim(s) by reason of its making a Contribution, without compensation and otherwise on a RAND basis, to all Implementers. Such commitment shall be made be made pursuant to a written declaration in the form of Appendix A to this IPR Policy.

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.

6.7.4.  SWG voting members

All of the SWG charter members can vote at the first meeting of the new SWG and are therefore deemed “voting members” of the SWG.

After the 30-day waiting period, any member representative who is not a charter member may request that the SWG chair change their status to a voting member of the SWG. Once the Chair approves the request, the member can then vote on any item or issue brought before the SWG. Any member who has been participating in a SWG for 30 days but does not wish to be a voting member can remain of group member and participate.

6.7.5.  Opting out of a SWG

If 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 TCC and/or designee representative.

6.7.6.  Election of SWG Chair and Co-Chair

The first order of business of a new SWG is to elect a Chair and Co-chair. The Chair and Co-chair must be from different Member organizations. When there are adequate nominations or volunteers for the Chair/Co-chair, the SWG Convener will call for a vote of members who have opted in to participate in the SWG. In the case where there is only one nomination for Chair and one for co-chair, the SWG Convener will ask the SWG members whether there is any objection to unanimous consent. The election of a Chair or Co-Chair can happen at either a TC Meeting or via email. The election of the Chair and Co-Chair does not require TC or PC approval. Once the election is complete, the new Chair shall notify the TCC of the results of the Chair and Co-chair election.

6.7.7.  Responsibilities of the SWG Chair and Co-Chair

In addition to the sub-group Chair and Co-chair responsibilities as outlined in Clause 6.2, the SWG Chair is responsible for organizing the activities of the SWG, including the following.

  • Ensuring that minutes of meetings are taken, and once approved by the SWG voting members and made available electronically to the SWG membership within two weeks of the meeting. Minutes must include:

  • A list of persons attending the meeting and determining if there is quorum;

  • A list of motions, seconds, and outcomes; and

  • A section that details specific actions taken by members of the subgroup.

  • Reporting on subgroup activities to the TC and if the SWG meetings during a TC meeting, presenting at the closing TC Plenary, including presenting subgroup recommendations (if any). Any reports to the TC SHALL be approved for release by the SWG voting members.

  • Maintaining SWG member status on the Portal (voting, observer, etc).

  • Ensuring that issues are logged into the Portal and these issues are prioritized and put into a roadmap for completion of a revision (or a future revision). 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.

  • Ensuring that issues worked result in official change proposals and that only these official change proposals shall be considered by the SWG.

In the event that the Chair is not able to fulfill these duties, the Co-chair will step in and assume the leadership role until such time as the Chair is able to resume their duties. Failure of the Chair and/or Co-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 dissolved.

6.7.8.  SWG Voting

SWGs operate under the same general voting rules as other sub-groups of the TC, namely Votes in an SWG follow the same guidelines as for the Technical Committee except that quorum is 1/2 of active voting members (see Clause 6.7.9) unless the SWG votes to have a larger fraction be quorum. See Clause 5.5 for electronic votes for sub-groups of the TC. The one notable exception related to SWG votes is that only member representatives who have opted into the SWG may vote.

6.7.9.  Caveat on Voting Rights — If you do not participate on a regular basis

If you join a SWG and have voting privileges, you have a responsibility to participate in the teleconference and email dialogues. If you do not participate in the teleconferences and email discussions and vote on items and issues, you will lose your voting privileges and have your SWG member status changed from “Voting” to “Group Member”. The SWG Chair has the authority and the ability to make these changes based on the following policy.

Quorum for votes on any items or issues brought before a SWG is based on the number of voting members for that SWG. Insuring 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 votes shall be deemed as inactive and will not count toward quorum after the second missed vote. 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. If the voting member wishes not to assign their proxy, they can ask to change their status to “Observer” and still actively participate in the SWG.

6.7.10.  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.

6.7.11.  SWG Work Environment

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.

6.7.11.1.  SWG use of collaboration environments

SWGs are free to use collaboration environments such as GitHub to store text of their draft standard, link that text 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 SVN 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.

6.7.12.  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, to another standards organization, or to the public for comment. Such an action requires a formal SWG motion and SWG vote as per Clause 6.7.8.

6.7.12.1.  Release of document(s) for public comment

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 encouraged 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 OGC Communications to generate a press release and properly create the Request For Comments (RFC) on the OGC website.

6.7.13.  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 an update, extension, or profile of a standard.

The proposed Task must be presented to the TC at a plenary. Otherwise, a PowerPoint or video 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 TCC 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 (see Clause 5.3) or by a two-week email vote (see Clause 5.6). 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.

6.7.14.  Umbrella SWGs

From time to time, two or more existing SWGs need to collaborate and coordinate on a regular basis. In such cases, the SWGs may propose to create an umbrella SWG. To create an umbrella SWG:

  • All affected SWGs shall vote to agree to participate in the umbrella SWG;

  • All affected SWGs shall have the same IPR policy; and

  • The existing charters for the affected SWGs shall be updated to state that the SWG is part of an umbrella SWG.

Once approved, the existing operational SWGs will be dissolved and reformed under the new IPR umbrella. All existing voting members would remain voting members in their respective SWGS. However, opting to participate in one SWG shall mean that the member is opting as an observer to all SWGs that are part of the umbrella SWG.

7.  Document Types and Document Processes of the TC

This section describes the various OGC documents and document handling processes that are the responsibility of the TC.

7.1.  An OGC Policy Document

A policy is a principle, rule or process that guide 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 P&P 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 shall be reviewed and approved by both the Technical and Planning Committees. Approval of a policy document shall follow the e-voting rules as defined in Clause 5.4. If the TC approves the Policy document, then a simple majority of the PC Voting Members must approve the TC recommendation.

Policy documents have version numbers that shall start at 1.0

7.2.  The Standards Document

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 (with the exception of Community standards14) that can be downloaded in Word format from: https://portal.opengeospatial.org/?m=public=templates=1 or which is available in the OGC GitHub repository as a series of AsciiDoc files.

OGC uses a multi-track standards policy with three possible states: OGC Community standard, OGC standard, and OGC standard with Compliance Suite. These are described in The Clause 8.2.

Approval of an OGC standard is described in Clause 8.

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.

7.3.  The OGC Reference Model

The TC will periodically be asked to review and vote on the OGC Reference Model (ORM) Document. The ORM describes a framework for the ongoing work of the OGC and our standards and implementing interoperable solutions and applications for geospatial services, data, and applications. The ORM can be found at:

http://www.opengeospatial.org/standards/orm

Any version of the ORM, once approved by the TC and the PC, is released as a public document.

7.4.  Discussion Papers

WGs and SCs shall often be used to hear presentations in their interest area. Further, a WG or SC can generate Discussion Papers for the industry covering a specific technology area germane to the WG’s or SC’s interest area. In either case, the WG or SC makes a recommendation to the TC for release of the document as a Discussion Paper.

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

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. 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.5.  Public Engineering Reports

Any OGC Interoperability Initiative, such as a Test Bed or Interoperability Experiment, will have Engineering Reports (ER) as a deliverable. These ERs are typically posted to pending documents and presented and discussed in a WG at an OGC TC face-to-face 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 TCC.

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.  Best Practice and Community Practice Documents

OGC Members, TC subgroups, or Interoperability Initiatives may generate Best Practice (BP) and Community Practice (CP) Documents for the industry 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.

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.6.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.

  • Presentation of the contents of the proposed BP at an OGC face-to-face meeting. The presentation may be done remotely using OGC communication tools, such as GoToMeeting.

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

7.6.2.  Approval of OGC Best Practice and Community Practice Documents

Both document types are an official OGC position statement. Therefore, BP and CP Documents shall be approved by formal electronic vote. Motions to initiate a BP and CP e-vote may originate from a WG with TC approval, from a motion at a TC Plenary, or from a motion by the TCC.

A BP and CP vote has the same rules as a standards adoption vote (Clause 5.4).

The BP and CP document authors shall respond in writing (email is acceptable) to any comments received during the voting period. If necessary, the document authors shall edit the document. If the TCC deems that the edits to the document are more than editorial, then the document shall be posted to pending and a new BP or CP approval e-vote shall be initiated.

Each BP and CP distributed by the OGC shall include a cover page with the statement as specified in Policy Directive 7.

7.7.  Documents and Distribution

The numbered document (see Clause 7.7.1) as distributed to members is to be considered the official document of the TC. Electronic mail shall be used for day-to-day discussion of OGC documents. The preferred mechanism for document sharing is the OGC Members-only Portal. OGC Communication shall be used for announcing the availability of new official documents. The actual documents will not be distributed by email unless a member requests receiving a document by email. All official documents will be posted to the Portal. Other electronic forms of documents can be made available at the written request of members.

The Members section of the OGC Portal (http://portal.opengeospatial.org) shall provide the default method of disseminating documents in electronic form. The TCC or his designee shall determine the electronic distribution format15 of these documents. OGC Consensus Standards proposals, Discussion Papers, Best Practices Documents, and Engineering Reports must be provided in one of the formats defined in Clause 7.7.4. However, the preferred document format is the Word .doc format. The format for dissemination may change as distribution technology changes. Up until mid 2014, all approved Abstract Specification Topics and standards were only available in PDF format. Please note that the OGC has moved to publication of OGC standards documents in HTML16.

7.7.1.  Document Numbers

All member submitted documents shall be assigned a document number. Members can obtain pending document numbers using the members only Portal, OGC Pending Documents page located at https://portal.opengeospatial.org/?m=public=default=1.

Instructions for obtaining a Pending Document number and posting the document can be found at https://portal.opengeospatial.org/?m=public=instructions=1.

7.7.2.  Document version numbers

The guidelines for version/revision numbers for documents are as follows.

  • All non-specification/standards documents do not have version numbers at publication.

  • 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.

See also Policy Directive 18.

7.7.3.  Change Proposal Format

Change Proposals for any OGC document shall use the procedures and format as documented in Clause 8.9.

7.7.4.  Other Document Concerns

All documents with official OGC Document Numbers that are to be considered and discussed at a TC face to face meeting shall be made available electronically to all members at least three (3) weeks before the next TC meeting. However, this clause does not apply to informational documents for which there will not be any motions or actions. Numbered documents shall be posted to Pending Documents.

The TC will enforce this policy under the conditions described for the Clause 5.2.

All documents shall be made available in one or more of the following formats:

  • Microsoft Word including .docx17 format (preferred),

  • Rich Text Format (RTF),

  • Portable Document Format (PDF),

  • Hypertext Markup Language (HTML),

  • Microsoft PowerPoint (preferred for presentations),

  • Microsoft Excel (preferred for tabular information such as lists of URLs),

  • AsciiDoc, or

  • ASCII Text.

7.7.5.  Policy for the 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 extensions to that standard; such a fate is version-dependent: only the extensions specific to the exact version of the standard being retired, deprecated, or rescinded will share that fate. Deprecation of a standard does not automatically result in the deprecation of a profile of that standard.

7.7.5.1.  Retiring OGC Documents

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

  • A document is no longer technically up to date;

  • A document is not actively downloaded from the OGC website;

  • A document is no longer considered to be of interest by the Membership;

  • The document is no longer valid due to new OGC documents being published; or

  • For a standard, no one is implementing the standard.

At the one-year anniversary for a Discussion Paper, the two-year anniversary of a Public Engineering Report and at the three-year anniversary of any standards document18, the OGC shall determine whether the document should be retired or remain an active Member document. The TCC shall compile a list of such documents prior to any OGC Face-to-Face meeting. The OGC Staff shall also compile download statistics. This information shall be compiled into a single document, posted to pending documents, and an announcement of availability broadcast to the Membership.

For discussion papers, public engineering reports, and best practices, the TCC shall create a set of motions related to documents for consideration for retirement by the TC Membership. The form of the motion shall be:

“The TCC recommends that OGC document <xyz> remain an active OGC document.”

A positive vote indicates that the document shall not be retired. These motions shall be presented at the closing plenary at a TC meeting. Based on the results of the vote, the target documents shall either be retired or remain active.

In the case of a OGC standard, a formal electronic vote by the TC Voting Members is required to approve retirement.

Retired documents are not removed from the OGC public website. Instead, they are moved from the current document archive to the “Retired” archive. Further, any retired document 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.

7.7.5.2.  Deprecating OGC standards

OGC policy documents may be deprecated by vote of the TC. A deprecated document is no longer supported, but is made available to the public on the OGC website and other resources.

  • In the case of Policies and Procedures, approval of a revision automatically deprecates the previous version.

  • Standards and Best Practices may be deprecated by vote of the TC. Deprecation must be preceded by a 60-day public comment period informing the community that the standard is proposed for deprecation and requesting evidence to support or reject deprecation. Any comments received during the public comment period must be presented to the TC during the request to deprecate the standard19. Where the document is proposed for deprecation because a new version of the document is to be approved, the deprecation vote may be part of the adoption vote for the new document. In this case, when the motion is made to the TC at a face-to-face meeting or email vote to approve the start of an electronic vote for a standard or Best Practice, that motion shall include a request to deprecate the previous version, if the previous version is recommended for deprecation by the WG. Where the document is proposed for deprecation and no future version is in consideration, then an electronic vote is required as described for Clause 7.7.5.1.

7.7.5.3.  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 Clause 7.7.5.1.

8.  Policies and Procedures for Adoption and/or Revisions of Standards

This section covers procedures for adoption, revision, and maintenance of OGC standards. For the purposed of clarity, the term “standards” covers both the candidate abstract and implementation cases.

8.1.  Standards Proposed for Adoption — Caveats

Only Voting TC Members of the OGC may propose candidate standards for adoption by OGC.

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.

The TC e-vote is to recommend to the PC approval of the results of an adoption vote. This will ensure that all TC voting members have the opportunity to vote on the most important work done by the Consortium. Lack of a vote does not count as a vote of Abstain; only an actual vote of Abstain counts as such a vote.20

The policy of the OGC is that proposed standards resulting from a OGC Consensus Standards process evaluation may be recommended to the PC for acceptance conditional on certain changes to the standard, which the TC deems necessary, within a specified time frame.

Acceptance of the TC recommendation for adoption is always with the caveat that the PC may verify that the standard’s sponsor organization(s) is/are in a position to develop (or have developed for the sponsor organization) or commercialize an implementation of the standard. Further, for candidate standards developed external to the OGC and submitted into the OGC process, the PC may verify that the submitting organization has provided a duly executed submission of technology form. In addition, the TC recommends acceptance contingent on the PC’s finding that the sponsoring organization(s) makes the technology available as per the OGC Intellectual Property Policies and Procedures.21

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 standardss track. 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.

Table 2

SWGEvidence of ImplementationModular SpecCompliance TestOGC TemplatePublic CommentOAB ReviewIPR to OGCMember Vote
Community standardNR*StrongNR*PartialYesYesYesYes or SharedYes
Full standards Track
draft standardYesNoYesNR*YesYesYesYesYes
standardYesYesYesNR*YesYesYesYesYes

*NR — Not required.

Community standard: This is a document, developed by communities external to the OGC, such as GeoRSS, 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. Please visit Section 9.5 and Annex C to read more about the requirements for submitting a Community standard as well as a checklist of steps in the Community standard submission, review, and approval process.

Full standards track, which consists of two possible target levels of 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. A draft standard is often derived from output of requirements discussions in DWGs, results of Innovation Program activities, and/or the OGC Technology Strategy which links key innovation activities to anticipate standards needs for emerging technologies.

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: API, service, and exchange protocol 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 Approved Before the Two Track Standards Process

OGC standards approved prior to the effective date of Revision 24 of these Policies and Procedures (05-020r24) 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 (Clause 8.4) 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.

Please note: A new standards activity can also be initiated when there are outstanding change request proposals. Change Request Proposals (CRPs) (Clause 8.9) provide details for revisions to existing Abstract Specifications or 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 CRs against an existing OGC standard is evidence that a revision process for that standard should be initiated. In this case, the TCC may request members consider a standards activity using the OGC Consensus Standards process.

The following section provides details on the OGC standard development processes.

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 standards track only. Please also refer to Annex B of this document for a synopsis of the steps in the OGC Consensus Standards process for the Full standards track.

8.4.1.  Conditions for Submission of a Candidate Standard

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; evidence of the endorsement via a letter or email to the submitter must be provided to the TC Chair.

  • A Voting Member is the lead for 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.

  • For a Community standard, the submission team completes a written justification as to why the Community standard track is being requested. This step is described in more detail below.

  • All required documents (see below) must be ready for submission to the OGC for consideration through a OGC Consensus Standards process.

8.4.2.  Intent to Submit a Candidate Standard (All)

Any organization that intends to submit a candidate standard via the OGC Consensus Standards submission process must inform the TCC via email or written correspondence that a new candidate standard is being submitted. At least three different OGC Member organizations must commit to being part of the submission team. The primary submitter must be a TC Voting Member. The TCC will announce via OGC Communications that there is intent to submit a candidate standard.

8.4.3.  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 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 Form22. 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 has reviewed the current Policy Regarding Intellectual Property Rights of OGC and agrees that its submission is being made in full compliance with those Policies.

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

  • OGC Candidate Standard submitters must provide an agreement 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 the OGC may copy, distribute and otherwise make available this submission for the purpose of evaluation, and that in the event that the submission is accepted, 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 in soft or hard copy form.

8.4.4.  Specific process requirements for the submission of a Community standard (CS)

8.4.4.1.  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:

The companies <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.

8.4.4.2.  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 (OGC 16-113, Community Standard Justification Template).

Once the submission team completes a draft of the justification document, they shall provide the TCC the draft. The TCC shall review the draft and provide comments and guidance back to the submission team. The Submission Team reviews the TCC comments and modifies the justification as required. When the Submission Team agrees that the justification document is complete, the convener shall post the justification document to pending documents. The document shall be posted as a Public document.

8.4.4.3.  Submission justification document: Member review process

Once the justification document is posted to pending, the TCC shall:

  • 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; and

  • Have the proposed Community standard submitters present the justification to the TC at a Plenary or via a web 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.

8.4.4.4.  Approval of the proposed Community standard work item

Upon completion of the review and comment process, the TCC shall initiate an official e-vote to approve (or not) the proposed work item for processing a Community standard. This vote shall follow the e-vote process and policies as defined in Clause 5.4 of the OGC Technical Committee Policies and procedures. 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.

8.4.4.5.  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 Clause 8.4.6.7.

8.4.5.  Required components of the OGC Consensus Standards process Submission Package

In addition to the candidate standard document, all OGC Consensus Standards process submissions must include a signed Cover Letter and if required a signed OGC Technology Submission form for each submission.

8.4.5.1.  Submission Cover Letter (All)

The lead organization on each OGC Consensus Standards process submission shall provide a Cover Letter stating the intent of the organization to support the SWG and related OGC Consensus Standards process. The cover letter may be in the form of an email correspondence.

8.4.5.2.  OGC Technology Submission Form (Externally developed submissions only)

The following clause applies to candidate standards developed external to the OGC and then submitted by the Members for consideration as an OGC standard.

Assurances are required at the time of submission that the Intellectual Property Rights 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.

In order to assure this result, any organization submitting a OGC Consensus Standards process Proposal Package where the candidate standard was developed outside the OGC SWG or DWG 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.

8.4.5.3.  Additional Member endorsements (All)

Any submission requires that three or more distinct Member organizations support the submission. In addition to the submission team lead, each other organization supporting the submission shall provide the TCC with an email stating their organization’s support of the submission.

8.4.6.  Main Steps in the OGC Consensus Standards Process

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

8.4.6.1.  Submission of the OGC Consensus Standards process package to the OGC (All)

The OGC Consensus Standards process Submission team shall provide the submission package to the OGC TCC. The TCC shall review the proposal in terms of required documents.

For a Community standard, the submission package shall include:

  • Cover letter,

  • Endorsements,

  • Justification document (see Clause 8.4.4.2),

  • Agreement in writing that the OGC has rights to use, modify, copy, and distribute the candidate standard (See Clause 8.4.5.2), and

Candidate standard document.

For a Full standard, the submission package shall include:

  • Cover letter,

  • Endorsements,

  • SWG Charter (See below), and

  • Candidate standard document if one exists. For proposed new standard, providing a document is not required.

Documents being submitted as Full standards shall use the document formatting and content, in common use by the OGC at the time of submission, of standards submitted under the OGC Consensus Standards process. There is a detailed guidance document for using the template.

Documents being submitted as Community standards do not need to follow the OGC document template for an OGC standard. However, the submission team for a Community standard is strongly encouraged to provide the candidate standard to the OGC using the document template.

Proposals that require changes to the Abstract Specification must include acceptable documentation (at the discretion of the OGC TC) of these changes.

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

See Clause 6.7.1.3 on the Policies specific to the formation of a new SWG and SWG processes.

8.4.6.3.  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 review 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 a 30-day public comment period. The OAB shall review a candidate standard prior to the actual release for public comment.

Community standard: The community standard submission team and the TCC must agree that the candidate standard is ready for review and the TCC will submit the candidate standard for internal review by the OAB and OGC-NA.

8.4.6.4.  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 in terms of the rationale for how the candidate standard fits into the current adoption plans of the OGC (and/or the current Abstract Specification), for Full standards compliance with the Modular Specification Policy23, and how the proposal is consistent24 with the current OGC standards baseline. 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.

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

Concurrent with the OAB review of the candidate standard, the SWG shall provide a list of all new OGC identifiers specified in the candidate standard to be issued for persistent public OGC resources. This list shall be submitted to the OGC Naming Authority for review. This submission may be done by email. The specific policy is specified in the TC Policy Directives.

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 http URI policy [OGC 06-135 — Directive 21], the editor shall submit the candidate standard’s list of doc25, spec and XML Namespace URIs for OGC-NA review formatted into an Excel spreadsheet or as a Persistent Uniform Resource Locators (PURL)26 configuration document, which is valid according to the batchPurls.rng schema.

8.4.6.6.  Release for Public Comment Period (All)

The candidate standard is released for a 30-day public comment period27. During the RFC comment period, any party (including all classes of OGC members, as well as any non-member of OGC) may send comments on the proposal to OGC Headquarters or to the address announced with the RFC issuance. OGC staff will manage collection of the comments. OGC Communications will insure that the SWG or Community standard submission team membership is informed regarding submitted comments. It is important to note that anyone may make a comment on an outstanding RFC. RFC’s are available to the public, not just members, and are publicized.

8.4.6.7.  Review of the Received Comments (All)

Once the RFC comment period closes, the candidate standard submission team “collects” the comments and integrates them into a single RFC comment document. The team reviews the comments and determines how each comment will be responded to. The team may decide to:

  • Accepts the comment as is and edits the candidate standard accordingly;

  • Accepts the comment with modification and edits the candidate standard accordingly;

  • Accepts the comment as a future work item; or

  • Rejects the comment with an associated reason.

    NOTE  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 the RFC comment document. Further, the team shall notify each individual who submitted a comment as to the disposition of the comment. This could be done by pointing the individual to the public comment response document.

The comment response document shall be a public document. The comment responses can be provided in a document or a Wiki.

Finally, the team may need to make a decision as to the fate of the OGC Consensus Standards process. If the team decides that comments received are sufficient to halt the OGC Consensus Standards process, then the OGC Consensus Standards process “fails” and adoption of the proposal halts. The submitter(s) may then make changes and resubmit the OGC Consensus Standards process proposal.

If, however, the comments received do not cause the team to halt the OGC Consensus Standards process, then the team edits the document based on the comments received during the comment period (See above).

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

8.4.6.8.  Member briefing for Candidate standard (All)

Once the final document has been posted to pending, the submission team shall brief the TC Membership on the contents of candidate standard. This briefing shall occur prior to a final adoption vote. This briefing may be at a face-to-face meeting or via an official OGC GoToMeeting session (webinar). The briefing shall be announced via formal OGC communications at a minimum of three weeks prior to the briefing. Further, if the briefing is via a webinar, the submission team shall identify two separate dates and times for the briefing. This is to accommodate OGC members in all time zones. Alternatively, the submission team may create a video of a briefing and make this video available to the OGC membership.

8.4.6.9.  Vote to Approve Candidate standard (All)

After the candidate standard has been briefed to the TC, the TCC will request that the TC approve the start of an electronic vote to recommend approval of the candidate standard by the PC. This vote can occur in a Plenary (see Clause 5.3.2) or via email (see Clause 5.6).

Upon approval of the TC to start an electronic vote, the TCC will initiate a 45-day electronic vote to recommend approval of the candidate standard by the PC. This vote will follow the rules specified in Clause 5.4.

A YES vote by the TC to recommend approval by the PC will initiate a PC vote, further described in the PC Policies and Procedures.

8.4.7.  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 TCC with written documentation that the standard meets the criteria for evidence of implementation per the Clause 8.2.1. The candidate standard must then proceed with the RFC (Clause 8.4.6.6) through Voting (Clause 8.4.6.9) steps.

8.4.8.  Specific policies regarding profiles moving from a Best Practice to a standard

In the case where an OGC-approved Best Practice is a profile of an active standard (i.e., not retired, deprecated, nor rescinded) and members wish to submit the profile for adoption as a full standard, the standard approval process is modified as follows.

NOTE  if the Best Practice is a profile combined from multiple standards, then the profile must be advanced as a standard via the normal full standards track process. The single standard to which the profile applies may itself have normative references to other standards; such a situation does not make the profile “combined from multiple standards.”

  1. The submitters of the Best Practice must agree to proceed with the standard adoption process.

  2. The SWG responsible for the parent standard (i.e., the standard to which the profile applies) must vote to proceed with the standard adoption process per the normal SWG processes and voting rules.

  3. The candidate standard is reviewed by the OAB and the OGC-NA.

  4. The candidate standard will be assessed against the same criteria applied to the parent standard. For instance, if the parent standard was approved prior to publication of the Modular Specification, then the candidate standards will not be required to be compliant with the Modular Specification.

  5. The candidate standard is released for a 30-day simultaneous TC and public request for comment.

  6. Comments are reviewed and addressed by the submitters to the satisfaction of the TCC.

  7. The candidate standard is voted upon by the TC and PC per Clause 8.4.6.9. Note that the Best Practice was already approved by the TC and PC, so a presentation to and request to start a vote from the TC will not be required.

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 an Authoritative Standards Development Organization (Authoritative SDO) or are joint standards activities between OGC and the Authoritative SDO. The remainder of this subsection provides details on the approval of such documents as OGC Abstract specifications.

8.5.1.  Authoritative Standards Development Organization

An Authoritative 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 PC. 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 Standards Program. 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.

8.5.2.  Scope and Content

The scope of the Abstract Specification (AS) will include any items that the OGC Technical Committee deems appropriate for achieving interoperability in the geodata and geoprocessing market. The AS may include data models, processing models, or other items necessary to implement the mission of the Technical Committee as defined by the OGC Planning Committee from time to time.

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

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

There are two categories of potentially unacceptable Abstract Specification change proposals, including:

  • Proposals that directly affect the content of an outstanding OGC Consensus Standards process effort (a decision made by the subgroup responsible for processing the proposed changes); and

  • Proposals that affect the content of a completed OGC standard (these issues should be handled in the revision process because they potentially affect both the Abstract Specification and Implementation standards).

8.5.3.  Authoritative SDO Documents as OGC Abstract Specifications28

A new AS Topic Volume or a revision to an existing AS Topic volume 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. There are the two cases: A document entirely developed in the Authoritative SDO and then recommended by OGC members to be an Abstract Specification and a document jointly developed by the OGC and Authoritative SDO memberships. Each case is now described.

8.5.3.1.  Authoritative SDO Standard as an OGC Abstract Specification Topic Volume

For this case, the Authoritative SDO Standard in question must be at a published or FDIS (Final Draft International Standard, in the case of ISO) status.

  • The Authoritative SDO Standard is presented and discussed in an OGC Working Group.

  • The WG Members determine that the Authoritative SDO Standard should be a new OGC AS Topic Volume or should be a revision to an existing OGC AS Topic Volume.

  • The WG makes a recommendation that the OGC TC should consider the motion to issue an adoption e-vote for the candidate Abstract Specification.

  • The recommendation is presented to the TC for discussion — usually at an OGC face to face TC meeting.

  • The TC can approve or not the recommendation to approve the adoption e-vote.

  • A minimum three-week review period is required prior to issuance of an adoption e-vote.

  • The adoption e-vote is initiated and conducted as per the E-vote policy as defined in Clause 5.4.

NOTE  for this case, the TCC 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.

8.5.3.2.  Joint OGC-Authoritative SDO Standard as an OGC Abstract Specification Topic Volume

For this case, the OGC and the Authoritative SDO have agreed to have a joint standards development activity. This decision is captured by approval of the Authoritative SDO (in the case of ISO / TC 211 as an official New Work Item Proposal (NWIP)) and approval of an official OGC SWG Charter. The OGC SWG shall be open to participation by both OGC and the Authoritative SDO members. The work of the SWG shall be under the OGC PnP for all activities related to the development and approval of an OGC standard. There will also be a parallel Edit Committee or equivalent in the Authoritative SDO to process all of the Authoritative SDO requirements for editing, review, and approval of an Authoritative SDO Standard. The SWG Chair shall have responsibility of communicating and coordinating the joint activity.

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 in a Closing Plenary or by email to approve the submission per the rules for Clause 5.

8.7.  Appeals Process

Appeals by any OGC member must be made before the OGC Architecture Board (OAB). Each appeal or issue will be taken on a case-by-case basis, but rulings made by the OAB with approval of the 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.

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 actual physical editing and maintenance of the standard document. The editor is neither 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 (approval of a CRP or edit and the language of the edit) 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 going around in circles, in an endless round of modification; and

  • Maintaining a 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.

The Editor and the SWG Chair may or may not be the same individual.

8.9.  Change Request Proposals (CRP) to an OGC document

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. The change could be an identified error (see Clause 8.12), an inconsistency, a requested enhancement, or a major proposed enhancement. Completed CRP’s shall be submitted on-line using the CR submission application on the OGC web site. Submitted CRP’s are catalogued and stored on a publicly accessible site.

The CR App URL is: http://ogc.standardstracker.org/

CRP’s are used as the basis for new SWG work items. The SWG will only consider proposed changes and enhancements to an adopted implementation that have been documented using the CRP template.

If a SWG does not exist for a given standard and there are CRP proposals for that standard, the TCC shall constitute a new SWG under the P&P outlined in the Clause 6.6.

8.9.1.  Submission of Change Request Proposals

Once a CRP is completed, it shall be submitted to the OGC by posting to the Public Change Request page. If a CRP is to be discussed during a face to face SWG meeting, such as during a TC meeting, then change requests should be submitted to the CRP archive by the meeting 3-week rule. All CRPs shall be publicly available.

8.9.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) explaining the rationale for rejection and then allow the submitter(s) the opportunity to respond and/or resubmit their CRP with modifications.

The disposition of any CRP will be noted on the pubic CRP web site.

8.9.3.  Completion of a Change Request Proposal

When a SWG has processed a CRP, the status of the CRP will be changed on the OGC CRP archive. The status and disposition will be modified based on the SWG decisions. The CRP will remain public and available for future reference. The normal procedure for this process is:

  • At the completion of the work of the SWG, the SWG chair shall provide the TCC or his designee a list of completed change proposals; and

  • The TCC or his designee shall update the status of those CRs on the OGC website.

8.10.  The Standard Revision Process (Full standard)

A primary function of a Standards Working Group (SWG) is to edit a candidate 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). If any member feels that a standard needs to be changed, edited, or enhanced, they must submit a Change Request Proposal.

All voting in a SWG, whether for processing a candidate standard or for revisions to an existing standard will follow the rules as defined for Clause 6.7.8.

8.10.1.  The Revision Process

The SWG reviews requests for revisions and corrections to a standard. Requests for revisions must be in the form of comments received during any public review period, such as for the OGC Consensus Standards process, or in the form of official CRPs. Ad-hoc emails and verbal requests at meetings will not be considered as official CRPs. However, the SWG may vote to 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 standards 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.

8.10.1.1.  SWG Review of Change Proposals

As part of a revision process, the SWG processes CRPs. Please refer to Clause 8.9 for additional policies and procedures related to change request proposals. Once a list of change proposals has been compiled and the SWG has discussed the proposed changes, the SWG voting members shall vote on the disposition of each of the proposed changes. The SWG has the right to reject a recommended revision, comment, or correction but must provide a written justification for the rejection.

Based on the outcome of the votes, SWG members then make the revisions and corrections to the target standard. Comments or CRPs received after the formation of a new SWG may or may not be considered for incorporation. This is at the discretion of the members of the SWG.

8.10.1.2.  Internal Review and Public Comment

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

From this point on, the processing of the revision to the standard is the same as defined in Clause 8.4.6.7 and subsequent sections.

8.10.2.  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.

A cut-off date can be announced to the TC using the following rule: That a cut-off takes effect the end of the next meeting after it has been announced. For example, an announcement at a June meeting would take effect at the next TC meeting, which is usually in September.

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

The SWG shall perform the following tasks.

  • Develop a plan and schedule for completion of the new revision of the given standard. The Plan and Schedule, also known as a Road Map, will be made available to all OGC members as well as the Public.

  • 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.

  • At completion of revisions to a standard and before the new version is voted on, provide a “release notes” document that describes all the changes to the standard. The revised standard will not be considered for adoption until this document is complete.

  • 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.

  • Try to complete their work in a timely manner.

  • Endeavor to reflect their perception of the consensus of the TC.

8.11.  The Standard Revision Process (Community standard)

Revision of a Community standard is treated as a new Community standard submission and all processes for approval of a Community standard from submission of a Work Item to vote for final approval are required.

8.12.  Corrigendum (errata) Changes to OGC Standards

From time to time, members and the public will discover errors in a published and approved OGC standard. In such cases, a process is required to document and publish the corrections without forming a SWG29 or submitting a new Community standard Work Item and that follows the formal TC review and voting process. Under the corrigendum process, an error (or errors) in a published document discovered after adoption and publication is shown with its correction(s) under a separate sheet (or addendum).

This process operates as follows.

  1. An identified error is documented and submitted to the OGC using the Corrigendum Proposal (CRP) template. The submitter(s) of the Corrigendum notify the TCC.

  2. The TCC or designee evaluates to candidate corrigendum to verify that a specific error is being documented.

  3. The TCC or designee communicates the documented error to the editor/author of the specified standard.

  4. The editor/author checks the validity of the error and then communicates this information to the OGC membership for comment using standard OGC communications. The reason for the TC broadcast is that there may be many implementations of the standard for which an error has been documented.

  5. If there is concurrence that the corrigendum documents a valid error, the editor/author writes the corrigendum and submits back to the TCC or his designee.

  6. The Membership votes to release (or not) the error (deficiency) correction as a corrigendum. A Corrigendum vote will ask if there is any objection to unanimous consent. In order to speed the process, these votes will last for only two weeks or occur in a TC Meeting Closing Plenary and there is no IPR review requirement.

  7. The corrigendum is published via OGC communications.

8.13.  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 SWG will insure that all inconsistencies are highlighted and documented. These will be incorporated into a Standard Revision Release set of notes that must accompany the new revision. Release notes document all enhancements, changes, and compatibility issues resulting from the revision of the interface standard. Both the TC and the PC 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 PC may elect to reject the proposed revision.

9.  Proprietary Rights, Copyrights, and Disclosure

9.1.  Proprietary Rights30

During any meeting of the OGC Technical Committee or any subgroup of the TC, no participant shall disclose proprietary information.31

In addition, no information of a secret or proprietary nature shall be made available to the OGC as official documents, and no such documents (or documents marked as such) shall be made OGC official documents or forwarded to the membership.

All proprietary information that may nonetheless be disclosed by any participant during any meeting of the TC or any subgroup of the TC shall be deemed to have been disclosed on a non-confidential basis, without any restrictions on use by anyone (except that no valid copyright or patent right shall be deemed to have been waived by such disclosure).

9.2.  Copyrights

All proposals intended to affect the contents of OGC standards, once submitted to the TC, (a) convey sufficient royalty free license rights to OGC to permit it to publish, license and sublicense the same freely to all third parties, and to permit OGC and all such third parties to own any derivative works base thereon without financial obligation to the submitter, but (b) do not in any way indicate that the submitter has surrendered or waived any copyright or patent in such proposal.

9.3.  Disclosure

It is the policy of the TC that the all pending proposals and documents shall be restricted to member internal distribution. The exceptions are:

  • Change Requests Proposals. All CRPs shall be made public; and

  • When an external standards organization requires access to a members’ only document. The TCC, after due consideration and dialogue with the members, may determine that a given document can be shared with the external standards organization.

10.  TC Planning Committee Representatives

10.1.  Role and Responsibilities

As stated in the Bylaws of the OGC, the OGC TC has the right to seat two representatives on the OGC PC. Up to seven representatives may be available in a “pool” and the TCC will work with the representatives to choose the two to attend a specific PC meeting. This section details the role and responsibilities of these individuals and the process for their election.

The role of a TC Representative to the PC is to bring issues of concern to the general TC membership to the attention of the PC and to keep the TC apprised of the activity of the PC. Responsibilities of the representatives include the following:

  • Accept documented issues from TC members and bring these forward at PC meetings;

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

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

  • Vote.

10.2.  Elections

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 PC 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.

  • Up to seven representatives may be elected, from which no more than two can attend any PC meeting.

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

10.3.  Term of Office

The term of office for TC representatives to the PC 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 TCC may determine that a given TC representative to the PC is not fulfilling their obligations, such as not attending PC meetings on a regular basis. For example, if the TC representative misses two or more meetings in a row. In such a case, the TCC may ask the TC representative to resign and the rules for election will be invoked to fill the vacancy.

11.  Temporarily Overriding Specified Procedures

The Technical Committee may temporarily override specific procedures set forth in this document by a specific 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.

12.  Adoption of This Policy Document

In order to be accepted or modified, this document must be ratified by electronic vote per Clause 5.4 rules.


Annex A
(informative)
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): A document (or set of documents) containing an OGC consensus computing technology independent specification for application programming interfaces and related specifications based on object-oriented or other IT accepted concepts that describes and/or models an application environment for interoperable geoprocessing and geospatial data and services products.

BOD: (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.

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, usually as part of a standards adoption vote.

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.

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.

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.

IP (OGC 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 the IP can be found at www.opengeospatial.org/initiatives.

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 PC.

Items: Items are proposed standard adoption questions that come before the committee for discussion, resolution and, potentially, final recommendation to the PC. Items come about through TC voting membership motions and seconds, typically in response to RFCs, PC 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.

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 PC 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 (http://www.opengeospatial.org), 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 PC 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, 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.

PC (Planning Committee) − The OGC 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.

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.

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.

WP (White 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 White Paper often explains the results or conclusions of research. A White Paper is not an official position of the OGC.


Annex B
(informative)
OGC Consensus Standards Process Outline: Draft OGC Standard

Table B.1

Full standard: Process Checklist Responsible
Contact Technical Committee chair about intent to submit or start Convener and TCC
Identify submission team (3 or more Members, one is TC Voting Member) Convener
Signed Submission of Technology form (optional) TCC and convener
TC Chair says great, write SWG Charter TCC
Submission Team writes draft Standards Working Group Charter Submission Team
When draft ready, the team sends the draft to the TCC Convener
TC Chair reviews draft and provides comments back to the submission team TCC
Submission Team reviews TCC comments and modifies charter as required Submission Team
When ready, convener posts draft charter to pending documents. Convener
After posting, the TCC shall notify the membership of the draft TCC
30 day public comment and review period
45 day TC approval vote Members
OGC Portal Update Staff
Press release to announce formation of new SWG Staff and Submission team
TCC does a call for participation (always open) TCC
SWG officially starts. First order of business is to elect chair etc SWG
Call for Change Requests (optional) SWG
Call for CR’s — Press Release (optional) Staff and SWG
Work on candidate standard happens SWG
For a revision to an existing standard, collate all CR’s and prepare summary SWG
For a revision to an existing standard, process all CR’s SWG
Editor(s) edit the document based on change requests Editor(s)
Release for public comment SWG and TCC
Notify TCC of intent for release for public comment SWG Chair and TCC
Develop Press release and make OGC web site updates SWG and Staff
OGC Architecture Board Review OAB
OGC Naming Authority Review OGC-NA
Post to SWG portal project as a public read access document SWG Chair and editor
30 day public comment period Community
The SWG Compiles a list of the comments into a document SWG
SWG Processes the public comments. SWG
Editor(s) edit the document based on comments Editor(s)
For a revision, write release notes SWG
SWG Briefs TC Membership on contents of candidate standard SWG Chair or designee
SWG Votes to release candidate standard for adoption vote SWG
SWG Chair tells TC Chair the result of the SWG Vote SWG Chair and TCC
TCC reviews candidate standard and makes suggestions TCC
SWG Posts candidate standard to pending documents. SWG Chair
TCC Announces adoption vote TCC and Staff
45 day adoption vote happens Voting Members
Vote completes
Announcement to OGC Members TCC
Planning Committee Approval TCC and PC
SWG process any comments received during the adoption vote SWG
SWG updates Change Request status for each CR processed SWG
Confirm list of contributors TCC and SWG Chair
TCC does final review of adopted standard TCC
Create Press release to announce new standard SWG and OGC staff
Schema processing SWG and OGC staff
Schemas validated and errors corrected SWG and OGC staff
Standard published OGC staff
Update PURL server for new spec artefacts OGC-NA and Staff
Press release released OGC staff
Done. Congratulations!!

Annex C
(informative)
Community Standard

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. Does the submission team understand that copyright and intellectual property (PR) shall be vested or shared with the OGC? Note: If the plan is to move the document to Provisional or Full standard status, all IP shall be vested to the OGC.

  2. Does the submission team understand that if the candidate standard is approved as an OGC standard that life-cycle governance shall be vested with the OGC[1]?

  3. Is there sufficient evidence of broad implementation?

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

  5. 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

Table C.1

Community Specification: Process ChecklistResponsible
Contact Technical Committee chair about intent to submit or start a community spec processConvener and TCC
Identify submission team (3 or more Members, one is TC Voting Member)Convener
Signed Submission of Technology form (optional)TCC and convener
TC Chair says great, provide justification.TCC
When draft ready, the team sends the draft to the TCCConvener
TC Chair reviews draft and provides comments back to the submission teamTCC
Submission Team reviews TCC comments and modifies justification as requiredSubmission Team
When ready, convener posts draft justification document to pending documents.Convener
Two week review period. Comments can be provided.Members
TC Chair asks TC if there are any objections to accept community spec into OGC processTCC and members
Concurrently, TC Voting members have formal vote to bring community spec into the OGC processTCC and TC voting members
Press release to announce formation of new OGC activityStaff and Submission team
Any edits on candidate standard happen. Normative content may not changeTeam
Approval process for public commentTeam Chair and TCC
Develop Press release and make OGC web site updatesTeam and Staff
OGC Architecture Board ReviewOAB
OGC Naming Authority ReviewOGC-NA
30 day public comment periodCommunity
The Submission team consolidates the comments into a single documentTeam
Submission Team reviews comments and modifies document as requiredTeam
Team Briefs TC Membership on contents of candidate standardTeam Chair or designee
TCC reviews candidate specification and makes suggestionsTCC
Team Posts candidate specification (can be HTML, Word, ZIP).Team Chair
TCC Announces adoption voteTCC and Staff
45 day adoption vote happensVoting Members
Vote completes
Announcement of results to OGC MembersTCC
Planning Committee ApprovalTCC and PC
Team process any comments received during the adoption voteTeam
Confirm list of contributorsTCC and Team Chair
TCC does final review of adopted standardTCC
Create Press release to announce new standardTeam and OGC staff
Schema processingTeam and OGC staff
Schemas validated and errors correctedTeam and OGC staff
Standard publishedOGC staff
Update PURL server for new spec artefactsOGC-NA and Staff
Press release releasedOGC staff
Done. Congratulations!!

NOTE  Please note that for external standards brought into the OGC, such as KML, the external community is still able to develop, test, and document new functionality and changes to the standard. This is per the OGC Best Practice “KML — Standard Development Best Practices” [OGC 08-125]. Once the external community is ready, these changes shall be documented and submitted into the OGC using the OGC Change Request Process