Abstract

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

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

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

This document describes the OGC Technical Committee (TC) policies and procedures (P&P).The TC has been granted authority to operate by the OGC Bylaws.  The TC is composed of individuals representing organizations that are duly recognized members in good standing of the OGC.  The Technical Committee Chair (TCC - see Section 3.2) facilitates the TC process.

The TC P&P:

As the needs and purpose of the TC change, these policies and procedures changes are approved by an electronic vote of the Voting 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:

The OGC is defined as a Voluntary Consensus Standards Organization[2].

Purpose and Composition of the Technical Committee

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

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[4] 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:

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:

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:

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:

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:

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[6]. 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:

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

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.

Substitute Voters

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.[7] 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:

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.

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

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

Often the following clause is added:

“Pending any final edits to the document.”

Best Practice and standards adoption votes shall have the following language:

The <Name of the SC or WG> recommends that the TC approve an electronic vote for  releasing <OGC Document number and Name> as a <OGC Best Practice or Adopted Standard>.

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:

Duration

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.

Continuity

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

Eligibility

All Voting TC Members[8] in good standing at any time during the electronic vote can participate in electronic voting, whether or not they have participated in any preceding TC meeting or electronic vote. All such Members are referred to as “Eligible Voters”. Each Eligible Voter shall have one vote.

Number of Eligible Voters

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

Allowable Votes

The Voting Member may vote Yes, No, or Abstain. Abstain counts toward Sufficiency Comments may be provided with any vote. Any Eligible Voter may change their vote during the voting period but not after the vote is closed.

Sufficiency

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.

Approval[9]

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

Comments

Any Eligible Voter that votes may submit a written comment. If an Eligible Voter votes NO, then that Voter shall also submit a written comment explaining their reason for voting NO. 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.

Withdrawal

A motion may only be withdrawn by the Working Group[10] 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.

Multi-part Documents

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

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

Visibility

The following rules relate to transparency of the voting process.

Assuming Successful TC vote, what next?

Once the e-vote completes and assuming a successful TC vote, the following must occur:

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:

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:

  1. 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.[11]
  2. 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).
  3. All requirements for previous announcements as delineated in the TC policy and procedures must be met before the email or portal vote start date. These requirements may include posting of the associated supporting documents in advance of the vote and/or an official notice to the TC of a pending vote within the subgroup
  4. Votes must be cast before the end of the closing day at midnight in the time zone of the voter (as recorded by the email send protocol). This mail announcing the vote shall include a formal name for the vote in the subject field.
  5. 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.
  6. 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.
  7. Only one vote is allowed per OGC Member organization.
  8. 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.
  9. 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:

http://portal.opengeospatial.org/index.php?m=projects&a=view&project_id=82&tab=2&artifact_id=3238

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:

Role of Subgroup Chairs

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

Inactive Subgroups

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

Subgroup Meetings

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

Ad-hoc Meeting(s)

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

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:

Approval of a Sub-Group Charter

Once the Charter is completed and agreed to by the members of the Ad-hoc[13]: 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).

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.

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.[14]

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:

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:

 https://portal.opengeospatial.org/index.php?m=public&subtab=templates&tab=2

IPR rules for a new SWG

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

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

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

Persistent SWGs

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:

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:

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.

SWG Voting

SWGs operate under the same general voting rules as other sub-groups of the TC, namely Votes in an SWG follow the same guidelines as for the Technical Committee except 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.

Umbrella SWGs

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

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:

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

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

Discussion Papers

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:

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[16] 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[17].

Document Numbers

All member submitted documents shall be assigned a document number. Members can obtain pending document numbers using the members only portal, OGC Pending Documents page located at 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:

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:

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:

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[19], 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.[20]

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.[21]

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

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.

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[23], 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”.[24]

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[25], spec and XML Namespace URIs for OGC-NA review formatted into an Excel spreadsheet or as a Persistent Uniform Resource Locators (PURL)[26] configuration document, which is valid according to the batchPurls.rng schema.

Release for Public Comment Period

The candidate standard is released for a 30-day public comment period[27]. 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:

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:

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:

Appeals Process

Appeals by any OGC member must be made before the OGC Architecture Board (OAB). Each appeal or issue will be taken on a case-by-case basis, but rulings made by the OAB with approval of the Planning Committee that affect the process will be reflected in these Policies and Procedures. If the member making the appeal is not satisfied by the decision made at the OAB level, the OGC Board of Directors may be presented with the case for final deliberation.

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

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

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:

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[28] 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:

  1.   An identified error is documented and submitted to the OGC using the Corrigendum Proposal (CRP) template. The submitter(s) of the Corrigendum notify the TCC.
  2.   The TCC or his designee evaluates to candidate corrigendum to verify that a specific error is being documented.
  3.   The TCC or his designee communicates the documented error to the editor/author of the specified standard.
  4.   The editor/author checks the validity of the error and then communicates this information to the OGC membership for comment using standard OGC communications. The reason for the TC broadcast is that there may be many implementations of the standard for which an error has been documented.
  5.   If there is concurrence that the corrigendum documents a valid error, the editor/author writes the corrigendum and submits back to the TCC or his designee.
  6.   The Membership votes to release (or not) the error (deficiency) correction as a corrigendum. A Corrigendum vote will ask if there is any objection to unanimous consent. In order to speed the process, these votes will last for only two weeks and there is no IPR review requirement.
  7.   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.

Backwards Compatibility

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

Proprietary Rights[29]

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

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

Copyrights

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

Disclosure

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

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:

Elections

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

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.

The TC adoption vote and 60 day IPR review period begins.


Footnotes

[1] As defined in ISO/IEC Directives, Part 2

[2] http://www.nist.gov/standardsgov/omba119.cfm

[3] 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.

[4] http://www.opengeospatial.org/ogc/policies/conduct

[5] Proposals as used here is meant to be a general term to cover RFCs, Discussion Papers, Best Practices, and Engineering  Reports.

[6] http://www.robertsrules.com/ Roberts Rules of Order, Tenth Edition, 2000.

[7] 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.

[8] The total of Strategic, Principal, Technical, and Technical Aggregate Members

[9] 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.

[10] Except for votes initiated by the TCC, such as the election of OAB members.

[11] 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.”

[12] 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.

[13] For a Standards Working Group (SWG) charter, the ad-hoc is the submission team.

[14] 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.

[15] Reasonable and non-discriminatory

[16] 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.

[17] Initial publications in 2014.

[18] Microsoft provides conversion tools for backwards compatibility.

[19] If a standards document is retired, any associated Best Practice document shall automatically be retired,

[20] 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.

[21] 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.

[22] If a candidate standard is developed entirely within the OGC process, then a SoT is not required.

[23] The Specification Model - A Standard for Modular specifications (08-131r3)

[24] http://portal.opengeospatial.org/files/?artifact_id=40077

[25] As specified in OGC 09-046, 09-047, and 09-048 (latest versions) found at http://www.opengeospatial.org/ogc/policies/directives

[26] http://purl.oclc.org/docs/index.html

[27] The SWG may determine that a longer comment period is required.

[28] 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.

[29] 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.

[30] 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.