The OGC provides a collaborative, consensus process for developing and approving open, international standards for the geospatial domain. “International standards” 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 Section 3.2) facilitates the TC process.
The TC P&P:
- Documents all TC voting processes and procedures;
- Documents the formation, scope and processes required for TC subgroup and committee activities;
- Documents the processes and procedures for submitting, reviewing, and approving a new standards using the Request for Comment procedures;
- Documents the process for revisions to adopted OGC(r) standards.
As the needs and purpose of the TC change, these policies and procedures changes are approved by an electronic vote of the Voting Membersof OGC TC or by recommendation of the OGC Planning Committee.
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 IT domain.
The OGC Principles of Conduct govern personal and public interactions in any TC activity.
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:
- May or may not have been accredited by any national or global entity;
- Is usually (but not always) international in membership and objectives;
- May have a very narrow or a broad mission (but still generally within a single focus area);
- Has as its primary goal(s) the creation and/or promotion of international standards (most commonly in the ICT area);
- Creates what would be acknowledged to be “open” standards made available on RAND terms;
- May engage in additional activities, such as the creation of white papers, training and certification, but which rarely becomes a “trade association” in the non-tax sense.
The OGC is defined as a Voluntary Consensus Standards Organization.
Purpose and Composition of the Technical Committee
The OGC Corporate bylaws state that the OGC Technical Committee (TC) shall be responsible for developing Standards through a cooperative consensus process involving the Members. The bylaws provide authority to:
- Design and maintain an Abstract Specification for a computing technology independent application environment for interoperable geo-processing and geospatial data products;
- Use the Abstract Specification as a reference to solicit, propose, review, recommend revisions to, and recommend adoption of Standards, also known as OGC standards.
- Provide the forum for discussing, reviewing, and adopting changes to existing approved OGC standards.
- Accept, discuss, review, and recommend action on documents developed in the OGC Interoperability Program and then submitted to the TC.
- Discuss, review, and recommend action with regard to standards and relevant standards developed in other standards organizations.
- Discuss and agree on requirements, use cases, and change requests to existing OGC standards.
Above all, the Technical Committee 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 Conduct govern personal and public interactions in any TC activity.
The structure of the TC is discussed in Section 4 of this document. Section 5 describes the policies and procedures for the submission, evaluation, and potential recommendation for adoption of a new or revised Standard.
Composition of the TC
The OGC Bylaws provide the enabling authority for the OGC Technical Committee. The TC has the following composition:
- The Technical Committee Chair (appointed by the BOD).
- Representatives of all member organizations of the OGC.
- Other individuals deemed appropriate by the BOD or Planning Committee.
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 for RFCs are issued and processed in a timely, orderly manner.
- 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.
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 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, etc.
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.
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 four primary subgroups: the OGC Architecture Board, the OGC naming Authority, Working Groups (WG) and Subcommittees (SC) to:
- Evaluate and provide guidance on architecture issues;
- Carry out the development of new proposals;
- Evaluation of proposals;
- Provide a forum for the discussion and documentation of requirements for interoperability.
WGs will be formed, carry out their work, and when their work is completed be dissolved. Working Group Policies and Procedures are defined in the section 7.0.
OGC Architecture Board (OAB)
The mission of the OAB is to provide a forum within which Consortium wide standards architecture issues can be discussed and deliberated with the intent of providing guidance and recommendations to the TC and the PC on these issues. The OAB is a sub-committee of the TC. There is a separate OAB Policies and Procedures
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, 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.
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 do they 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. Subcommittees are long-standing entities with general portfolios or mission. OGC staff can chair TC Subcommittees. Any OGC member can attend a SC meeting and participate.
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 Technical Committee. 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.
Domain Working Group
A group (organizationally, a subgroup of the TC – Section 7.5) 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 Technical Committee. 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.
- 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 Requests 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 Papersor Best Practices Papers.
- Informational presentations and discussions about the market use of adopted OGC Standards.
- Have all-member voting policies (unless otherwise stated).
- Have missions and goals defined by the TC.
A DWG Does Not work on RFC 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.
A DWG may determine that they wish to have public collaboration, such as in teleconference, email discussions, or a public twiki. In this case, the DWG shall make a motion to the TC to approve public participation in the DWG.
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 section 7.7 for details on the P&P 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 RFC submission.
- Process a new RFC submission candidate standard 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;
- 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.
Unless the SWG voting members decide otherwise, SWGs are dissolved once they have completed their work as described in their charter.
Meetings of the Technical Committee
This section describes the Policies and Procedures for meetings of the OGC Technical Committee.
Meetings of the TC
Technical Committee meetings shall be conducted under the general guidance of Robert’s Rules of Order. Meetings shall be facilitated by the 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.
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.
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 paragraph 6.2). Subgroups having non-member participation policies may not meet during the course of regularly scheduled TC meetings (the meetings cannot overlap temporally), without approval of the TCC or PC.
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 or a Standards Coordination meeting, NDAs are not required.
The invited quest will receive a colored badge at check-in at the meeting registration desk. 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.
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:
- 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.
The invited speaker may receive a colored badge at check-in at the meeting registration desk. If they wish 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. 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).
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 his designated representative, and will be modified prior to the meeting as appropriate. One to two weeks prior to a meeting, the TCC shall, via email, provide the TC a summary document of keys actions and presentations.
The WG Chairs shall provide the TCC or his 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 one week 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).
Policies related to the recording of an OGC Meeting
If there is a GoToMeeting (or similar technology) session assigned for a specific OGC Working Group, TC Plenary, or PC meeting, there is the option to record the session for later use by OGC staff and OGC members. Guidance for such recording is as follows:
- The members attending the meeting need to be notified that the meeting is being recorded. If there are objections, then the meeting shall not be recorded.
- The recording shall remain members only and shall not be available to the public. The exception is for open meetings in which the public is invited to attend.
- All recordings shall be uploaded to the appropriate meeting folder on the OGC portal.
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, for Policies and Procedures of the TC, and for other purposes consistent with the purpose of the TC as described in these Policies and Procedures. TC will make recommendations to the PC concerning adoption of a candidate standard, changes to a standard, or changes in process.
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 to insure 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. In this case, a simple majority vote of those TC Voting members present constitutes a successful vote.
Voting TC members may send substitutes to TC meetings but these substitutes may only vote if they have submitted a written proxy statement to the TCC or his designee (see section 6.7) by the Voting TC Member of his or her organization. A paper (postal or facsimile) vote by a Voting TC Member may also be accepted at a TC meeting. Please note that these proxies are only required for voting in a TC Plenary. They are not required for voting in a TC Subcommittee or WG.
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 three-week rule clause ensures that Voting TC members can enforce adequate time to read, distribute and gather comments on documents before voting on the document at the following TC meeting. If deemed appropriate, the TC may override the 3-week rule by a 2/3-majority vote of Voting TC members in attendance at a meeting (see section 9).
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.
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.
- Move to modify the charter of a DWG.
All of these motions and DWG are recommendations to the full TC.
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.
|Vote Type||Who can Vote|
|White Paper, Discussion Paper, or Engineering Report||Any member except an Individual Member|
|Election of TC reps to the PC||Any member except an Individual Member|
|Approval of a DWG Charter||Any member except an Individual Member|
|Approval of deprecation or retirement of DP or BP||Any member except an Individual Member|
|Approval of an OGC Best Practices Document||TC Voting Member|
|Approval for adoption of an OGC Standard||TC Voting Member|
|Approval of a revision of an OGC standard||TC Voting Member|
|Approval of a new TC P&P or other policy document||TC Voting Member|
|Election of members of the OGC Architecture Board||TC Voting Member|
For “Any Member” votes, only one member representative from a given Member Organization may vote.
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:
Often the following clause is added:
Best Practice and standards adoption votes shall have the following language:
Proxy Format and Content
Not every OGC TC Voting member can attend every Technical Committee 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 TC Chair.
Proxies are 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.
Please sign and email to the TC Chair or bring the signed proxy to the TC meeting and give it to the TC Chair. The TC Chair shall send reminders to the Voting Members prior to the meetings.
TC Electronic Voting
At any time, the TC Chair, the TC or a subgroup of the TC may recommend starting an electronic vote. 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;
- Approval and adoption of a OGC Policies and Procedures;
- Approval of an OGC Best Practice;
- Approval of the slate of nominations for the OGC Architecture Board;
- Approval of a Standards Working Group Charter and a new standards work activity.
Unless otherwise stated by the TCC or his 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 Sufficiency). The start and end dates for any given vote are set by OGC staff and are posted with the ballot and announced.
Except for the following reasons, an electronic vote shall remain open for the duration as stated in Duration (6.5.1):
- A WG withdraws the motion to approve a candidate standard (see Withdrawal)
- The TC Chair, the OAB, or the SWG identifies a procedural error and requests the vote be stopped.
All Voting TC Members in good standing at any time during the electronic vote can participate in electronic voting, whether or not they have participated in any preceding TC meeting or electronic vote. All such Members are referred to as “Eligible Voters”. Each Eligible Voter shall have one vote.
Number of Eligible Voters
For each electronic vote, the number of Eligible Voters shall be determined as of the date of the start of the electronic vote. The number of Eligible Voters for a given vote shall be determined by OGC staff and shall be posted with the ballot and announced. This number shall not change for an active vote regardless of whether members gain or lose voting eligibility.
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.
For all votes on any OGC document or OGC policy, sufficiency requires 33% 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.
In addition to Sufficiency thresholds, for documents that are official OGC positions, such as a standard, an OGC Best Practice, or an OGC policy, a motion passes (is approved) if the number of YES votes is twice the number of NO votes. All other documents pass with a simple majority
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. If this is a standards adoption vote, then the SWG shall respond in writing to all comments within 30 days of the completion of the vote. If this is a not an adoption vote, 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 Withdrawal) then no response to comments is required.
A motion may only be withdrawn by the Working Group that made the original motion. 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 TC Chair shall then communicate the decision to withdraw a motion to the entire Membership.
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 SWG can at any time request the TC Chair initiate new vote;
- If a SWG withdrew a motion and the content of the document is changed, then the SWG needs to restart the RFC process (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 RFC approval process with an OAB review, public comment, final edits to the document and a new adoption vote).
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.
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 SWG can vote to make public the comments and SWG responses to the comments - but shall not provide the name of the Voter who made a given comment.
Assuming Successful TC vote, what next?
Once the e-vote completes and assuming a successful TC vote, the following must occur:
- The TC Chair 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 TC Chair 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.
Procedure for email or portal votes in subgroups of the TC
The procedures for holding email 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.
- 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 group (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 an email vote as a “measures to obtain a quorum” (RONR 2011, page 336). The procedure will be as follows:
- A motion is made and seconded on the group’s email reflector or during a meeting (such as a teleconference) that may not have a quorum.
- The chair (or the presiding person at the meeting where the motion was made in conjunction with one of the groups elected chairs) announces that an email vote or 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).
- 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
- 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.
- For an email 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. 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 his vote by emailing again at anytime before the close of the vote. The last vote cast by the member before the closing date and time is his official vote.
- For an electronic vote using the portal e-vote application, any valid voting member of the WG 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.
- Only one vote is allowed per OGC Member organization.
- Protests on the procedures involving the vote will be addressed to the group chair, with a final appeal to the TCC and the membership of the TC.
- If at least a quorum of the group 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.
1. Proxy Format and Content
A proxy template can be found at:
Please sign and either fax to the OGC or bring the signed proxy to the TC meeting and give it to the TCC.
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).
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, even if voting in that group has been closed. 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 (section 7.7.3).
- A Working Group may close their voting memberships for particular Items, but are not required to do so (except in the case of Standards Working Groups). The reasons for closing a WG include delineation of quorum and voters for voting reasons; avoidance of late vote-packing in the subgroup; and creation of a working core of people. In order to close WG voting membership, the WG must announce the deadline for membership requests a minimum of twelve weeks in advance, to the entire Technical Committee.
- 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.
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:
- A list of persons attending the meeting;
- A list of motions, seconds, and outcomes;
- A section that details specific actions taken by members of the subgroup.
- The Chair will send 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.
- Recommending schedule and work plan and managing subgroup resources to accomplish the mission of the subgroup.
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.
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 section 5.1). However, there are some restrictions on the decisions that a Working Group may take at a meeting that is not co-located with that of its parent body.
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.
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.
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:
- DWG Charter: https://portal.opengeospatial.org/files/?artifact_id=3247
- SWG Charter: https://portal.opengeospatial.org/files/?artifact_id=25120
Approval of a Sub-Group Charter
Once the Charter is completed and agreed to by the members of the Ad-hoc: NOTE: For a SWG Charter, please review section 7.7 of the PnP for specific requirements related to the formation of a Standards Working Group (SWG).
- The charter is reviewed by the Technical Committee Chair (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 document or video 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 TC Chair shall notify the membership that a revision of the charter has been posted.
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: Committee, Domain Working Group, and Standards Working Group. In all cases, the TC Chair 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.
- DWG: The approval of a charter for a DWG is a simple majority vote of the membership. These votes happen at the Closing Plenary during a Face-to-Face TC meeting.
- SWG: This is a TC Voting Member vote. Approval of the charter is a simple majority. The TC Chair initiates a vote to approve the Charter and the formation of the SWG. This is an electronic vote under the e-vote rules as stated in section 6.5 (e-votes) above. The TC Chair 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 SWG.
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.
Policies Specific to a Domain Working Group
This section describes the formation, role, and responsibilities of a Domain Working Group (DWG).
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.
Changes to a DWG Charter
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 shall then notify the full membership. 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. Please refer to 7.5.3 above.
Policies Specific to a Standards Working Group (SWG)
A SWG may be formed whenever:
- Three or more members provide an RFC 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 RFC process. The new candidate standard could be an interface, encoding, profile, application schema, or extension package;
- 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 RFC 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 TC Chair. The TC Chair will discuss the process and next steps. The TC Chair 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 section7.5.3. The policies and procedures defined below are in addition to the requirements to form an OGC Domain WG.
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:
IPR rules for a new SWG
The charter of each SWG shall also specify whether the SWG to be formed is a RAND-Royalty Free SWG or a RAND- for Fee SWG. For a complete discussion of the OGC Intellectual Property Rights (IPR) policies, please refer to:
The OGC IPR policy is similar to those of other voluntary standards organizations.
Ordinarily, a SWG completes the work as defined in the Scope of Work and then disbands. However, there are cases in which a SWG needs to be “persistent”. These cases include the ability to work on multiple revisions of an existing OGC standard or to insure that long-term collaboration with other SWGs can be maintained. In this case, the Charter Members can request that the new SWG have a status “Persistent”. The Charter template has a section that specifies whether a SWG is persistent or not.
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 Section 7.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.
“Charter” members of the SWG
The charter members for a SWG will be:
- Any members that are part of an RFC submission team;
- Any member who asks to join the SWG during the three week SWG Charter review period;
- 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.
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.
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.
SWG voting members
All of the SWGcharter 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. The exception is for Individual Members. Individual Members cannot become voting members of a 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.
“Opting in” to participate in a SWG
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.
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 his designated representative.
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 TC Chair of the results of the Chair and Co-chair election.
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.
Responsibilities of the SWG Chair and Co-Chair
In addition to the sub-group Chair and Co-chair responsibilities as outlined in Section 7.2, the SWG Chair is responsible for organizing the activities of the SWG, including:
- 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;
- 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.
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 for how a quorum is computed. See the section above for the procedure for email 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.
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.
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, such as OGCNetwork, to another standards organization, or to the public for comment. Such an action requires a formal SWG motion and SWG e-vote as per 7.7.10.
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 Call for Comments (RFC) on the OGC website.
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;
- 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.
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.
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 section 5.5 above. 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
The Standards Document
The standards document is the principal document type that captures the work and the consensus of the OGC membership. Standards documents must use one of the two OGC standards document templates that can be downloaded from: http://portal.opengeospatial.org/index.php?m=public&subtab=templates&tab=2 .
Approval of an OGC standard is described in section 9.0 of this document.
Each standard distributed by the OGC shall include a cover page with the statement as specified in section 4 of the Policy Directives for Writing and Publishing OGC Standards: TC Decisions.
Standards documents have version numbers that shall start at 1.0
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:
Any version of the ORM, once approved by the TC and the PC, is released as a public document.
DWGs shall often be used to hear presentations in their interest area. Further, a DWG can generate Discussion Papers for the industry covering a specific technology area germane to the DWGs’ interest area. In either case, the DWG 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 DWG 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 section 4 of the Policy Directives for Writing and Publishing OGC Standards: TC Decisions.
Discussion Papers do not have a version number.
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 DWG at an OGC TC face-to-face meeting. The DWG 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 DWG 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 section 4 of the Policy Directives for Writing and Publishing OGC Standards: TC Decisions.
Engineering Reports do not have a version number.
Best Practices Documents
OGC Members, TC subgroups, or Interoperability Initiatives may generate Best Practices (BP) 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. A best practice is a technique or methodology that, through experience, implementation and research, has proven to reliably lead to a desired result.
BP documents have version numbers that shall start at 1.0.
Submission of documents to be considered as an OGC Best Practice
In order to be considered for approval as an OGC Best Practice, the document submitters shall:
- Shall provide 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.
- Shall provide a short (one page or less) written justification explaining why a submitted document should be considered for approval.
- Shall present 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.
Approval of OGC Best Practice Documents
A BP is an official OGC position statement. Therefore, BP Documents shall be approved by formal electronic vote. Motions to initiate a BP e-vote may originate from a DWG with TC approval, from a motion at a TC Plenary, or from a motion by the TCC.
A BP vote has the same rules as a standards adoption vote (Section 6.5).
The BP document authors shall respond in writing (email is OK) 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 approval e-vote shall be initiated.
Each Best Practice Paper distributed by the OGC shall include a cover page with the statement as specified in section 4 of the Policy Directives for Writing and Publishing OGC Standards: TC Decisions.
Documents and Distribution
The numbered document (see 8.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 format of these documents. RFC proposals, Discussion Papers, Best Practices Documents, and Engineering Reports must be provided in one of the formats defined in Section 8.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 and Standards were only available in PDF format. Please note that the OGC has moved to publication of OGC standards documents in HTML.
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 http://portal.opengeospatial.org/index.php?m=public&orderby=Manage&tab=2. Instructions for obtaining a Pending Document number and posting the document can be found at: http://portal.opengeospatial.org/index.php?m=public&subtab=instructions&tab=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.
Change Proposal Format
Change Proposals for any OGC document shall use the procedures and format as documented in section 9.10.
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 Technical Committee 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 in paragraph 6.3.
All documents shall be made available in one or more of the following formats:
- Word for Windows including .docx format (preferred for proposals and other textual documents),
- Rich Text Format (RTF),
- Portable Document Format (PDF),
- Hypertext Markup Language (HTML),
- PowerPoint (preferred for presentations), or
- ASCII Text.
Policy for the Retirement of OGC Documents
This section provides the policy and procedure for 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;
- 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 document, 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. A retirement vote for a standard shall be 30 days duration. A simple majority of the active Voting Members is required to retire an OGC standard.
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.
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.
General Subgroup and Technical Committee Recommendation Process
In general, all subgroup recommendations and voting procedures follow the process described in this section. The subgroup will reach the point of making a decision on recommendation of some action. The subgroup will vote to recommend that the TC take the action. If the vote is affirmative, then the TC will vote on the action. If the TC concurs with the subgroup recommendation, then the action is approved and further processes can carry the action forward, such as Planning Committee approval. If either the subgroup or the TC votes down the recommendation, then a determination of further action must be made. Exactly what happens depends on the nature of the action. For example, documents may return to submitters for further work, be forwarded to subgroups for more deliberation, and so forth. If no further action is required then the action is halted. If further action is required, then the subgroup or TC must define what the further action is and who is responsible.
Standards Proposed for Adoption – Caveats
Only Voting TC Members of the OGC may propose candidate standards for adoption by OGC.
All OGC standards adoption votes will be electronic. Only Voting TC Members may vote on an adoption vote.
The TC e-vote is to recommend to the Planning Committee (PC) for 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.
It is the policy of the OGC that proposed standards resulting from an RFC 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.
Steps for Adoption and/or Revision to a Standard
There are three possible paths for proposing and approving candidate standards or proposing and approving revisions to an existing adopted standard. These are:
- The Request for Comment (RFC) Process (Section 9.4). This is the approach for proposing a new candidate standard, submitting an externally developed specification into the OGC process, extensions to an existing standard, profiles of an existing standard, or an application schema for consideration by the membership. The RFC process is well suited for moving candidate standards, usually resulting for the IP Initiative environment, into the formal standard adoption process. A SWG manages the RFC process.
- Change Request Proposals (CRPs) (Section 9.10) 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.
The following section provides details on the OGC standard development processes. The RFC Process (see below) is the primary mechanism by which a candidate standard is submitted to the membership for consideration. Any OGC member can submit Change Request Proposals by posting the Proposal to the OGC Members Pending Document archive on the OGC members’ portal
Policies Regarding Candidate Standard Adoption via the RFC Process
The following sections details the requirements, policies, and procedures for adoption of a candidate standard using the OGC RFC process. Please also refer to Appendices 13, 14, and 15 of this document for a synopsis of the steps in the RFC process.
Conditions for Submission of an RFC
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 RFC process given that the submission:
- Conforms to all applicable OGC Standards and Abstract Specifications. If the candidate standard does not conform or is not harmonized with other adopted OGC Standards and Abstract specifications, reasons are given for the non-harmonization for consideration by the TC and PC.
- In the case of an existing candidate standard, there already exists in a viable implementation and is supported by evidence of a continued commitment to commercialize and/or support the implementation
The candidate standard must be ready for submission to the OGC for consideration through a Request for Comment (RFC) process.
Intent to Submit an RFC
Any organization that intends to submit a candidate standard via the RFC submission process must inform the TCC via email, fax, or written correspondence that a new candidate standard is being submitted. At least three 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.
Terms and Conditions for RFC submissions.
In the RFC process, the submitters agree to the following set of terms and conditions.
- Work with OGC staff to develop a new SWG Charter.
- All RFC submissions originating from work done external to the OGC consensus process and then submitted into the OGC for consideration as an OGC standard shall require a signed original of the OGC Submission of Technology Form This form shall be provided to the OGC prior to the adoption vote.
- The Submitter 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.
- RFC 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.
- RFC submissions must contain a commitment by at least one of the members of a submission team to make the implementation available on commercially reasonable terms, applied in a non-discriminatory fashion within twelve months of adoption by the OGC Planning Committee. This pledge is to be made in the Cover Letter.
- 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.
Required components of the RFC Submission Package
In addition to the candidate standard document, all RFC submissions must include a signed Cover Letter and if required a signed OGC Technology Submission form for each submission.
Submission Cover Letter
The lead organization on each RFC submission must provide a Cover Letter stating the intent of the organization to support the SWG and related RFC process. The cover letter may be in the form of an email correspondence.
If the organization submitting the Cover Letter is committing to commercialize the Standard, then the letter must contain a commitment to make the implementation available on commercially reasonable terms, applied in a non-discriminatory fashion within twelve months of adoption by the OGC Planning Committee. The suggested words for the cover letter can be obtained from the OGC.
OGC Technology Submission Form
The following clause applies to specifications 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 incorporated into an approved standard, be made available under license to all implementers, members and non-members alike.
In order to assure this result, any organization submitting a RFC Proposal Package where the candidate standard was developed outside the OGC SWG or DWG process is required to complete, sign and deliver a Submission of Technology Form. Please contact OGC staff for a copy of a SoT form. The signed SoT shall be provided prior to the adoption vote.
Steps in the Standard Track (RFC and SWG) Process
The steps in the OGC RFC Process are as follows.
Submission of the RFC package to the OGC
The RFC Submission team submits the package to the OGC Technical Committee Chair The TCC shall review the proposal in terms of formatting. Proposals shall use the formatting and content, in common use by the OGC at the time of submission, of Standards submitted under the RFC process. There is a detailed guidance document for using the template.
Proposals that require changes to the Abstract Specification must include acceptable documentation (at the discretion of the OGC TC) of these changes.
Formation of a new SWG to work on the RFC submission
See section 7.7 on the Policies specific to the formation of a new SWG and SWG processes.
Review and Vote by SWG to release candidate standard for Public Comment
Once the SWG determines that the candidate standard is ready for OAB 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.
Review by the OGC Architecture Board (OAB)
Once the SWG approves the candidate standard for public comment, the candidate standard is reviewed by the OAB. The OAB has the responsibility to insure that the RFC 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), compliance with the Modular Specification Policy, and how the proposal is consistent with the current OGC standards baseline.
Review of OGC Identifiers (http uri’s, etc) by the OGC Naming Authority
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 “Policy Directives for Writing and Publishing OGC Standards: TC Decisions”.
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 doc, spec and XML Namespace URIs for OGC-NA review formatted into an Excel spreadsheet or as a Persistent Uniform Resource Locators (PURL) configuration document, which is valid according to the batchPurls.rng schema.
Release for Public Comment Period
The candidate standard is released for a 30-day public comment period. 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 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 industry, not just members (as are other Requests), and are publicized just as are other requests.
SWG Review of the Received Comments
Once the RFC comment period closes, the RFC submission team “collects” the comments and integrates them into a single RFC comment document. The SWG reviews the comments and determines how each comment will be responded to. The SWG 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;
- Rejects the comment with an associated reason.
In all cases, the SWG shall document their decision in the RFC comment document. Further, the SWG 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 response document can be a Word document or a Wiki (preferred).
Finally, the SWG may need to make a decision as to the fate of the RFC. If the SWG decides that comments received are sufficient to halt the RFC, then the RFC “fails” and adoption of the proposal halts. The submitter(s) may then make changes and resubmit the RFC proposal.
If, however, the comments received do not cause the SWG to halt the RFC, then the SWG edits the document based on the comments received during the comment period (See above).
Specific Policies Regarding Abstract Specifications
The OGC Abstract Specification Development, Revision, and Approval process is the same as for any OGC standard except as noted below:
- ISO Documents: A new AS Topic Volume or a revision to an existing AS Topic volume may be proposed by the OGC members where the document has been created as an ISO TC 211 activity. The document may be an ISO document or a joint OGC and ISO TC 211 developed document.
- No 60-day IPR review is required for approval of an OGC AS Topic Volume.
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 RFC (a decision made by the subgroup responsible for processing the proposed changes).
- Proposals that affect the content of a completed RFC (these issues should be handled in the revision process because they potentially affect both the Abstract Specification and Implementation Standards).
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.
The Standard Revision Process
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 RFC 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 in section 6.
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 RFC process, or in the form of official Change Request Proposals (CRP). 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.
SWG Review of Change Proposals
As part of a revision process, the SWG processes change request proposals. Please refer to section 9.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.
OAB 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 OGC Architecture Board 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 section 188.8.131.52 and subsequent sections.
Cut-off date for accepting new Change Request Proposals
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.
Additional Guidance and Responsibilities of a revision SWG
The SWG shall:
- 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 insure that revisions to the Standard are consistent and harmonized with other related OGC standards.
- Work to insure 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.
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.
- 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.
Change Request Proposals to an OGC document
At any time, any OGC member or non-member can submit a Change Request Proposal (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 section 9.11, Corrigendum Changes), 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://www.opengeospatial.org/standards/cr
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 section 7.8.
Submission of Change Request Proposals
Once a Change Request Proposal 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 Technical Committee meeting, then change requests should be submitted to the CRP archive by the meeting 3 week rule. All CRPs shall be publicly available.
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;
- 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. 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.
Completion of a Change Request Proposal
When a SWG has processed a Change Request Proposal, the status of the CRP will be changed on the OGC CR archive. The status and disposition will be modified based on the SWG decisions. The CR 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 TC Chair or his designee a list of completed change proposals.
- The TC Chair or his designee shall update the status of those CRs on the OGC website.
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 SWG 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 is very similar to the ISO Technical Corrigendum Process
Under this process:
- 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.
- The TCC or his designee evaluates to candidate corrigendum to verify that a specific error is being documented.
- The TCC or his designee communicates the documented error to the editor/author of the specified standard.
- 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.
- 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.
- 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 and there is no IPR review requirement.
- The corrigendum is published via OGC communications.
A Technical Amendment to an existing Standard
From time to time there will be cases where it has been verified that an OGC Standard is used, that it should continue to be made available, but that technical changes are needed, a deliverable may be proposed for amendment. An amendment alters and/or adds to an existing OGC standard. The determination as to whether one or more Change Request Proposal(s) result(s) in an Amendment or a complete revision shall be determined by the TCC in consultation with the Editor(s) of the standard. The OGC Architecture Board shall provide a final review and approval of a proposed amendment. By way of guidance, an amendment may consist of additional reference examples, use cases, schema changes, and other normative and informative content or clarifications.
Where it is decided that the OGC standard can be amended using the technical amendment process, an existing SWG may make the necessary edits without a Charter change.
An amendment will result in a new version number of the document. Further, as an amendment may contain both normative and informative changes, an electronic vote and associated IPR review period is required. However, a vote of the TC is required but may be done at a TC meeting or by e-vote.
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.
Proprietary Rights, Copyrights, and Disclosure
During any meeting of the OGC Technical Committee or any subgroup of the TC, no participant shall disclose proprietary information. 
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).
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.
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.
- 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.
TC Planning Committee Representatives
Role and Responsibilities
As stated in the Bylaws of the OGC, the OGC Technical Committee has the right to seat two representatives on the OGC Planning Committee. This section details the role and responsibilities of these individuals and the process for their election.
The role of a Technical Committee Representative to the Planning Committee 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.
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.
- The representative will be selected as follows:
- If both vacancies are open, then the two nominees with the most votes will be selected.
- If one vacancy is open, then the nominee with the most votes will be selected.
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.
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
Adoption of This Policy Document
In order to be accepted or modified, this document must be ratified by a two-thirds (2/3) vote (under the rules herein) at a TC meeting, electronic, or via electronic vote. Changes to this document are to be presented to the TC, included in the meeting’s minutes, and ratified by the same procedure. Meetings in which a vote on acceptance or modification of this document is to occur must include the change in the published agenda for the meeting. Alternatively, the OGC Planning Committee can make changes to these Policies and Procedures by its normal operational process.
Annex A: Terms and Definitions
AP (Application Profile) -Set of one or more base standards and - where applicable - the identification of chosen clauses, classes, subsets, options and parameters of those base standards that are necessary for accomplishing a particular function [ISO 19101, ISO 19106]
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.
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.
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 Interoperability Program):A global, collaborative, hands-on engineering and testing program designed to deliver proven candidate standards into the OGC Standard Development 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.
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 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 Advisory Committee.
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, or RFC (See Section 9.4):An explicit request to the industry for comments concerning a particular candidate standard that a Standards Working Group is considering for adoption as a Sponsored Standard satisfying a portion of the Abstract Specification. An RFC begins as an unsolicited proposal from a Voting TC Member or members and results, if successful, in an OGC Standard. The RFC process is typically how interface and encoding standards developed in the OGC Interoperability Program move into the formal OGC TC standards approval process.
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.
SAC (Strategic Advisory Committee):The SAC is granted authority to operate by the OGC by-laws. The SAC 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 and best practices documents.
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: RFC Process Outline: Full OGC Standard
The following are the steps required for the RFC process.
- RFC Submitter(s) contact TCC or his designee by normal OGC communications about their desire to submit a candidate standard.
- RFC submitters commit to having considered the OGC standards baseline in the development of their submission. Any deviations or differences are noted and documented. If the OGC Abstract Specification is impacted, these impacts are noted and documented.
- RFC submitters provide to the OGC a Candidate Standard (CS). The CS is accompanied by several other documents, as described in the RFC process. This bundle of documents is called an RFC Proposal. The Candidate Standard can be the result of work performed in an OGC Interoperability Initiative and documented in an IP Report. The RFC proposal package is submitted to the TCC or his designee and includes:
- A cover letter that specifies the commitment of the organization to support the candidate standard submission.
- If required, a signed OGC SUBMISSION OF TECHNOLOGY FORM (This can be found at www.opengeospatial.org/legal).
- Any vidence of implementation for the CS. Prototypes and demonstration implementations are fine
- The CS. This is the actual document defining the standard and must be provided in the appropriate OGC standard template format. This template can be found on the OGC web site or can be provided by the TCC or his designee.
- The TCC or his designee notifies the TC of the availability of a new RFC submission package.
- The submission team develops a charter for a new SWG and announced to the TC. The team shall submit the charter to the TCC for review.
- A SWG is formed and a call to the TC membership is made. Member representatives can opt-in or not to work on the candidate standard.
- The SWG votes as to whether the CS should be released for public comment.
- The OAB reviews the candidate standard. Any OGC names (http uri’s) are submitted to the OGC Naming Authority for review and approval.
- The announcement is for public comment using normal OGC Communications and the CS along with instructions is posted to the Public section of the OGC web site.
- Industry responds to the Request by submitting comments (these are delivered to the TC and to the RFC submitters). This comment period typically lasts 30 days. All comments must be provided to the OGC through the formal mechanism described at the time of RFC release.
- At the end of the comment period, all comments are packaged and sent to the SWG.
- If required, the SWG will then modify the Candidate Standard and resubmit it along with a Response to the Comments back to the TCC or his designee. The SWG will need to modify the Candidate Standard if:
- A comment identifies an error in the candidate standard;
- A comment identifies an inconsistency in the candidate standard that makes it non-functional;
- A comment identifies a major inconsistency in the candidate standard that “breaks” interoperability with existing adopted OGC Standards.
- Once all comments have been processed and the necessary changes made to the standard, the SWG votes to recommend to the TC for an IPR review and concurrent e-vote for adoption.
The TC adoption vote and 60 day IPR review period begins.
 As defined in ISO/IEC Directives, Part 2
 OGC Standards are member approved interface and encoding engineering specifications developed via the OGC Consensus process that are publicly and openly available for use in the geospatial and IT community.
 Proposals as used here is meant to be a general term to cover RFCs, Discussion Papers, Best Practices, and Engineering Reports.
 http://www.robertsrules.com/ Roberts Rules of Order, Tenth Edition, 2000.
 In order to ensure that business moves along, voting by proxy is allowed, duly noting the dangers of voting without physical proximity. We feel that the notification requirements for the different phases of technology sponsorship sufficiently protect member organizations from adoption without due ability to oppose.
 The total of Strategic, Principal, Technical, and Technical Aggregate Members
 NOTE: All approved OGC Technical Committee document or policy recommendations are then presented as a recommendation to the OGC Planning Committee (PC). The PC shall review the recommendation and either approve the recommendation as is, ask the TC for clarification, or in very few instances not approve the recommendation and ask the TC to provide clarifications or more require more work on the document.
 Except for votes initiated by the TCC, such as the election of OAB members.
 Even if the meeting where the motion is made has a quorum, and thus could cast a legal vote, the membership may delay the meeting for some period to allow for research into issues that may affect their votes. Under RONR, a motion to “Postpone the motion to a certain time” would be appropriate (see RONR page 172). The limits on such a motion applies, such as the postponement cannot be beyond the end of the next scheduled meeting, and certain motions cannot be postponed (adjournment for example) and must be voted on in their normal order.
RONR allows such procedures in the absence of a quorum under the “measures to obtain a quorum.”
 In the past, some groups have not met for a considerable time and are no longer active. The existence of these groups can be misleading to those trying to understand what OGC is currently doing. This proposal suggests a mechanism for reviewing subgroups, and taking some action when appropriate. This will help ensure the groups in OGC are aligned with the actual work being done within the TC.
 For a Standards Working Group (SWG) charter, the ad-hoc is the submission team.
 It was felt that WGs should be able to use all of the expertise at hand in arriving at recommendations. All TC member organizations could be represented (and vote) at WG meetings in order to allow the expression of all members’ opinions. OGC Voting TC Members are protected from control by non-voting members by virtue of the fact that WGs may only form recommendations to the TC and not final TC votes. WG minutes are also available to all members of the TC, so that other TC members may understand and accept or reject WG recommendations.
 Reasonable and non-discriminatory
 Typically, official documents are provided to the public in Word “.doc” format or Adobe PDF format. However, various presentations, draft documents, and so forth can also be distributed in PowerPoint format, HTML, and other formats as provided by the Members. The TCC reserves the right to reject a document that is in a non-industry standard distribution format.
 Initial publications in 2014.
 Microsoft provides conversion tools for backwards compatibility.
 If a standards document is retired, any associated Best Practice document shall automatically be retired,
 It is felt that this most important TC vote should encompass the entire Voting TC membership, rather than a portion of a meeting quorum, to allow all OGC Voting TC Members to have control over the issue. Note that the TCC does not cast a vote in the specification adoption process as the TCC vote may only be used in the case of a tie. Under the rules of the new OGC IPR policy, all Specification votes will be by electronic vote. As such, the entire TC voting membership will have the opportunity to vote.
 It was felt that it is not within the TC’s purview to determine the ability or intent of an OGC member and technology sponsor to commercialize a technology. However, it was felt that the TC’s work would be fruitless without such ability and intent. Therefore, recommendations to the PC shall implicitly or explicitly include such caveats.
 If a candidate standard is developed entirely within the OGC process, then a SoT is not required.
 The Specification Model - A Standard for Modular specifications (08-131r3)
 As specified in OGC 09-046, 09-047, and 09-048 (latest versions) found at http://www.opengeospatial.org/ogc/policies/directives
 The SWG may determine that a longer comment period is required.
 The members may determine that a SWG should be formed to properly discuss the necessary changes to correct the deficiencies. In this case, the SWG Revision P&P will be followed.
 Please read the OGC IPR Policy documents located at www.opengeospatial.org/legal for the complete text and description of the OGC IPR policy. If at any time there is confusion or conflict between what is stated in the TC P&P and the OGC IPR Policy, the OGC IPR Policy takes precedent.
 This section clearly places the onus of protection of proprietary rights on the owner of those rights. No discussion of proprietary technology can take place during a TC or TC subgroup meeting, protecting the participants in the meeting from accidental exposure to proprietary information (and consequent future legal problems with that participant’s own intellectual property rights). If a TC member wishes to present information of a proprietary nature to members of the TC, he or she may arrange a meeting of the interested parties totally separate from the TC process and meeting.