OGC blogs

  • Innovations and Standards
    Contributed by: 
    George Percivall

    OGC, as a standards developing organization, provides a stable baseline for innovation. It could be perceived that innovation and standards are opposing ideas; in reality, the two ideas work together to prevent the extremes of stagnation and chaos: standards bring order to chaotic implementations of new ideas, additionally providing a baseline for new innovation to flourish. That innovation, in turn, feeds the creation of new and updated standards. One of the first computer scientists, Herbert Simon, inThe Architecture of Complexity coined the heuristic that “complex systems will evolve much more rapidly if there are stable intermediate forms than if there are not.” Standards are those stable intermediate forms necessary for innovation and evolution.

    This blog highlights several recent innovations in OGC processes: Changes in the OGC Innovation Program; Community Standards in the OGC Standards Program; and Geospatial Trends Tracking by the OGC Architecture Board. Further discussion of innovation in an agile environment will be the topic of a blog in the very near future by Dr. Luis Bermudez, the new Executive Director of OGC’s Innovation Program.

    In 2014, the OGC Planning Committee adopted an ‘Innovation Statement’ that laid out how OGC must maintain its current standards while simultaneously addressing the evolution in technology and markets. While ensuring harmonization in OGC standards, OGC must simultaneously respond to the Christensen’s ‘Innovators Dilemma.’ The OGC identified several actions to implement its Innovation Statement:

    • Extend or adapt the present baseline of OGC standards;
    • Recognize that new standards may overlap with or diverge from existing standards, along with guidance to evaluate among options;
    • Develop harmonization techniques (brokers, facades) for interoperability.

    To frame a discussion about innovation and standards, consider this view of open standards development as developed by Mark Reichardt, OGC President:

    1. Based on competition in the marketplace, over time a specification emerges as a de facto standard in the market. The specification may be publicly available but it is owned and controlled by an entity as a ‘proprietary standard’ (e.g. Microsoft’s Word .doc).
    2. As the market develops, the owner of a proprietary standard may see value in ‘opening up’ their specification by assigning the intellectual property to a Standards Developing Organization (SDO). KML, as licensed to OGC by Google, is an example of what OGC now calls the Community Standards process.
    3. As an alternative to development by a single organization, a group of organizations may collectively identify the need for a standard and develop a specification in anticipation of its widespread use. The OGC WMS as developed in the OGC Innovation Program is an example of an ‘anticipatory standard’

    Based on this framework, examples of the OGC process for innovation are described next.

    The OGC Innovation Program, previously known as the Interoperability Program, provides a collaborative agile process for advancing new anticipatory standards. The first Innovation Program initiative was in 1999, when the Web Mapping Testbed took place and helped to develop the most popular OGC standard: the Web Map Service (WMS). Since 1999, another 95 initiatives have brought together sponsors and technology implementers to solve problems, produce prototypes, develop demonstrations, and write engineering reports that anticipate the needs of the sponsors and the marketplace.

    The OGC Standards Program is now processing the first OGC Community Standards. This new process welcomes innovative specifications developed outside of the OGC. The process allows for a commonly-used specification, along with its intellectual property, to come in to OGC as a snapshot of that specification. The snapshot is then voted to become an OGC Community Standard. The process not only recognizes that innovation occurs in many communities, but also provides the visibility for future evolution of standards and provides a stable baseline of externally-developed standards for use in the OGC process.

    To anticipate innovation, the OGC Architecture Board (OAB) has taken on a part of the OGC Innovation Statement by defining a process to track geospatial technology trends. The OAB monitors trends to identify technology gaps or issues related to the OGC baseline. The OAB Technology Trends process is used to establish innovation topics for several OGC activities: Future Directions sessions in the Technical Committee; Location Powers emerging technology summits; and prospective topics for initiatives in the OGC Innovation Program.

    OGC has been developing innovative standards for over 20 years, but we have more to learn. Several excerpts from The Innovators book by Walter Isaacson provide a historical perspective on technology innovation on which OGC can build:

    1. The digital age may seem revolutionary, but it was based on expanding ideas handed down from previous generations.
    2. Innovation comes from teams more often than from lightbulb moments of lone geniuses.
    3. Most of the successful innovators and entrepreneurs had one thing in common: they were product people. They cared about, and deeply understood, the engineering and design.

    We invite you to participate in the advancement of geospatial technologies based on open standards. Your contribution to OGC Innovation Initiatives by sponsoring new ideas or helping develop solutions and prototypes will save lives and make this world a better place.

    If you have a question or comment on OGC’s approach to innovation, contact George Percivall, OGC CTO and Chief Engineer. gpercivall at opengeospatial dot org.

    Co-authors of this blog post include: Luis Bermudez, Scott Simmons and Terry Idol.

  • Looking Forward / Looking Back
    Contributed by: 
    Mark Reichardt, CEO & President OGC

    As we transition into the 2017 New Year, I thank OGC members for their continuing contributions to improve location information sharing and interoperability.

    By all accounts, 2016 was a successful year. OGC completed one of its largest interoperability testbeds to date – OGC Testbed 12, which pushed the limits on a range of topics from geospatial quality frameworks to aviation and compliance. With over 100 in attendance, the TB12 demonstration in late November provided sponsors and attendees with insight into the developments made throughout the testbed. TB12 produced more Engineering Reports and Guides (a new implementer oriented document) than any previous Testbed. Engineering Reports described advancements based on implementations in many areas including: new capabilities for Geopackage, refinements in Web Map Tiling Service (WMTS) and Web Coverage Service (WCS) for Earth Observations; investigations in vector and raster tiling schemes; and various REST and JSON topics. Fundamental advancements were demonstrated in the General Feature Model.

    Project activity in Europe continued to build with OGC Europe leading theH2020 ESPRESSO (systEmic Standardisation apPRoach to Empower Smart citieS and cOmmunities) project to empower Smart Cities through advancement of a standards enabled information framework, as well as supporting a NextGEOSS initiative which will advance a next generation hub for discovering, accessing and exploiting Earth Observation data. We also had some amazing progress in our consensus process with member dialog expanding in the areas of point clouds, the Internet of Things, integration of geospatial / civil engineering and the built environment, 3D visualization, and modeling and simulation. Further, we implemented a new community standards process that welcomes broadly implemented market technologies into the OGC for potential adoption. All these areas of interoperability emphasis are relevant and useful across many markets and domains of use, but they all converge as integrative capabilities to enable Smart and Resilient Cities.

    The OGC Compliance Program continued to develop new tests and support an increasing number of certifications. New compliance tests made available in December 2016 included Catalogue (CAT) 3.0, GeoPackage 1.0 and the Web Map Tiling Service (WMTS) 1.0.

    Looking forward, 2017 is also shaping up to be a great year. OGC Testbed 13 is underway and we expect to focus on a range of new topics – with a planned renovation of OGC Web Services, which will include a close look at evolving a set of OGC Essentials – more elemental components of OGC standards – to ease implementation, especially in the app developer world. We will be implementing streamlined ‘Implementer Guide’ versions of our OGC standards to make it easier for developers to support integration and implementation of our standards. A standards incubator is being stood up within our Standards Program to encourage new ideas and concepts to be advanced – with very little process overhead. As stated on the OGC website, the Incubator promotes community “prototypes that push the boundaries of our work and perhaps provide a pathway to future standards”. Several projects have already been initiated by contributors from the community.

    We will continue to leverage our OGC Location Powers Summits to interact with the community on emerging topics, trends and challenges. Location Powers events bring together both private and public sector experts from across the globe to stimulate highly interactive, cross-community discussion and to shape industry guidance of value to the OGC process. Summits held in prior years covered topics such as Smart Cities, Sensor Web, and Geospatial Big Data. In 2017, OGC will be convening summits on Big Linked Geodata (March, 2017), Underground Infrastructure (June, 2017) and Agriculture (December 2017). Input from Location Powers summits help drive OGC’s direction in these and other areas.

    Clearly, location has become an underpinning enabler across many markets and domains of use. OGC standards and best practices are enabling rapid mobilization of geospatial data and technologies into systems, enterprises, and the decision cycle. Much more opportunity lies ahead for OGC to help communities to benefit from the power of location.

  • 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 areGeoTIFF, GeoJSON*, andGeoRSS. Such specifications are often termed as “de facto” standards. Ade facto standard is something that isused 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 organizationscould 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.



    Evidence of Implementation

    Modular Spec

    Compliance Test

    OGC Template

    Public Comment

    OAB Review

    IPR to OGC

    Member Vote

    Community standard

    Not required


    Not required

    Not required




    Yes or Shared


    Full Standard Track:






    Not required






    standard with Compliance Suite










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

Markus Schneider blog

Simple Features

On INSPIRE, rich application schemas, GML and deegree in general
  • INSPIRE Download Services with deegree 3.2: Part Three
    The second part of this series focussed on harmonized INSPIRE datasets and their GML encoding. It also lined out why the technical features of the deegree WFS make it an excellent choice for serving valid, harmonized, GML-encoded INSPIRE datasets. Why … Continue reading
  • Writing processes for deegree WPS
    Finally, there’s an updated documentation for writing processes for the deegree WPS. It’s part of the new deegree webservices documentation, which has been released together with deegree 3.2. deegree WPS is an implementation of the OGC Processing Service specification. Notable … Continue reading
  • deegree webservices 3.2.1 released
    Today, the first maintenance release for deegree webservices 3.2 has been released. Get it here: http://www.deegree.org/Download Changelog: Pull request #85: WMS: Fixed outputting of layers if the corresponding theme has no layers and subthemes Pull request #86: WFS: Fixed default … Continue reading
  • INSPIRE Download Services with deegree 3.2: Part Two
    The first part of this series described the different classes of INSPIRE Download Services and why a Direct Access Download Service is most versatile. It also lined out that a Download Service may be interoperable or non-interoperable and that data … Continue reading
  • INSPIRE Download Services with deegree 3.2: Part One
    Why has deegree webservices 3.2 been dubbed “INSPIRE release”? This blog post series explains why it is an excellent choice for providing compliant INSPIRE Download Services, especially if you want the full monty: Interoperable Direct Access Download Services that serve … Continue reading

feed-image Feed Entries