The OGC Community Standard Process

Contributed by: 
Carl Reed

For many years, the OGC membership discussed and struggled with defining a process and set of related policies for accommodating submission of widely used, mature specifications developed outside the OGC standards development and approval process. Examples of these specifications are GeoTIFF, GeoJSON*, and GeoRSS. Such specifications are often termed as “de facto” standards. A de facto standard is something that is used so widely that it is considered a standard for a given application although it has no official status. The focus of the OGC discussions was to define a more lightweight process by which outside (non-OGC) groups as well as OGC member organizations could feel comfortable submitting specifications developed outside the OGC into the formal OGC standards process. The four driving use cases for the Community Standards process are:

  1. Submitters could rest assured that the OGC would not alter the content of the specification (unless errors were discovered), would not usurp the development and maintenance of the specification, and that the intellectual property could remain with the organization or group that developed the de-facto standard.
  2. A desire by government organizations to have de facto standards vetted and branded by a formal Standards Development Organization, such as the OGC, so that these de facto standards could be specified in procurement language.
  3. The need for OGC standards to be able to reference externally developed de-facto standards as normative.
  4. The ability to have a “version” of a de-facto standard that is stable and does not change. This allows such a document to be referenced in procurement, other OGC standards, and so forth.

After many months of OGC member discussion, in 2015 a new set of OGC policies and procedures for what became termed “Community Standards” were adopted by the OGC Membership. A number of de-facto standards have already been approved as candidate community standards and have entered the new OGC process workflow. These are Cesium 3D Tiles, ASPRS LAS, GeoRSS, and Esri I3S.

A Community standard is an official position of the OGC endorsing a specification or standard developed external to the OGC. A Community standard is considered to be a normative standard by the OGC membership and becomes part of the OGC Standards Baseline. A key consideration for a Community standard is that there must be strong evidence of implementation. The OGC does not take over the maintenance of the specification. Rather a Community Standard is a “snapshot” of a mature specification and the continued evolution and maintenance of the specification remains with the external group. Further, by submitting the specification into the OGC Community Standards process, there is no requirement to make any normative changes to the document; i.e. the external version and the OGC version of the document can remain identical. Finally, the originator has either shared the Intellectual Property Rights with the OGC or granted unlimited free use of the Intellectual Property to all implementers.

The following table is from the OGC Technical Committee Policies and procedures. The table compares the requirements for the two primary OGC standards types: Community and Full.

 

SWG

Evidence of Implementation

Modular Spec

Compliance Test

OGC Template

Public Comment

OAB Review

IPR to OGC

Member Vote

Community standard

Not required

Strong

Not required

Not required

Yes

Yes

Yes

Yes or Shared

Yes

Full Standard Track:

 

standard

Yes

No

Yes

Not required

Yes

Yes

Yes

Yes

Yes

standard with Compliance Suite

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

When defining the policies and procedures for processing candidate community standards, the membership agreed that having as light-weight as possible process was extremely important. Therefore, many “normal” OGC procedures are not required for Community Standards. These include formal Standards Working Group formation, complying with the OGC Modular Specification policy, and having compliance tests. Add in the fact that the OGC cannot change the normative content of a community standard and the net result is that the effort to move a community standard through the OGC process is considerably less than for a full standard. As a result, instead of 18 to 24 months to get a standards document through the OGC process, a community standard could – from submission to approval – be processed in as little as 6 months.

Recently, on behalf of the GeoRSS community and at the request of the US Federal Government, I submitted the GeoRSS specification into the Community Standards process. On February 2, 2017, the members approved the submission as a new OGC work item. OGC Architecture Review should occur later this month followed by a public/member comment period and an adoption vote. Hopefully, all steps for GeoRSS to become an official OGC Community Standards will be completed by May of this year – 6 months from the original submission.

Obviously, given that this is a new OGC process, we can expect minor refinements to the process as the OGC learns from the recent submissions. If you have any questions or concerns, please let the OGC know!

Carl Reed is a geospatial technology professional. Carl holds a PhD from SUNY Buffalo in Geography specializing in GIS technology development and systems engineering/design. He has 40 years of geospatial expertise in the commercial, government, and non-profit communities. Carl recently retired from the OGC where he was CTO and Executive Director Standards. Carl developed the original idea and initial PnP for the OGC Community Standards process.

[*] Please note that as of August 2016 GeoJSON is now an official Internet RFC (https://tools.ietf.org/html/rfc7946).