Many commonly used GIS data sharing specifications were not developed inside a standards organization. Some were developed by a community of experts that needed to share geospatial data across jurisdictional and/or political boundaries, often on a global basis. Other specifications were developed by commercial entities to meet customer requirements.
There are scores of community-developed and community-maintained specifications, such as GeoTIFF, GeoJSON, GeoSciML, and GeoRSS. And then there are the commercially developed ones, including the Esri shapefile and Google KML formats. Such specifications are often termed de facto standards, meaning they are used so widely that they are considered standard for a given app, though they have no official status.
Over time, a variety of market and procurement forces—such as demands for stability, formal endorsement, branding, openness, and transparency—may cause a community or company to consider taking the specification to a formal standards organization, such as the Open Geospatial Consortium, Inc. (OGC). But submitting a community specification can raise concerns. Some groups get nervous about losing control over the development of the specification, some are concerned about having two different versions of it, and some wonder how revision will happen going forward.
To properly address these concerns, members of OGC explored how to define a process, along with a set of related policies, for accommodating the submission of widely used, mature specifications developed independently from OGC. A key goal was to establish a lightweight approach by which non-OGC groups, as well as OGC member organizations, could feel comfortable submitting external specifications into the formal OGC standards approval process. The primary requirements for this approach were
- Assuring submitters that OGC would not alter the content of a specification (unless it discovered errors), would not take over the development and maintenance of that specification, and would not annex anyone’s intellectual property.
- Fulfilling government requirements that de facto standards get vetted and branded by a formal standards development organization, such as OGC.
- Ensuring that OGC standards could refer to externally developed de facto standards as normative.
- Furnishing a stable, unchanging version of a de facto standard.
In 2015, members of OGC formally approved new policies and procedures for community organizations and private companies to submit their de facto standards to potentially become what are now called OGC Community Standards. When a specification becomes an OGC Community Standard, OGC has reviewed, voted on, and approved it as an official OGC standard.
Existing OGC Community Standards
Since Community Standards were established, a number of organizations have submitted their de facto standards to be reviewed, edited, approved, and published as official OGC Community Standards. These include Esri’s I3S, the American Society for Photogrammetry and Remote Sensing’s (ASPRS) LAS, and the GeoRSS file formats. In addition, Cesium’s 3D Tiles specification has been approved as a new work activity for consideration as a Community Standard. OGC is looking at other submissions as well.
OGC considers Community Standards to be normative, meaning they become part of the OGC Standards Baseline—the list of OGC standards that can be used in interfaces, app schemas, best practices documents, and more. A normative standard specifies how to comply with the requirements, or rules, defined in the standard. Many organizations mandate the use of normative standards in procurements.
The key feature for a Community Standard is that there is strong evidence of implementation—and the organization submitting the standard to OGC needs to provide information on how widespread its use is via a justification document. Members of OGC then review the justification document and vote on whether to accept the candidate Community Standard as an OGC work activity.
A Community Standard is a snapshot of a mature specification. The group that submits the specification retains control over how it evolves. Furthermore, the external version and the OGC version of the document can remain identical so that, no matter which version a user accesses, the documentation will be the same. Finally, the specification’s originator either shares intellectual property rights with OGC or grants unlimited free use of it to all implementers.
Having a lightweight approval process is extremely important to OGC. Many groups worry about the time and resource commitments required to go through a traditional standards development process. Yet formal reviews, comment periods, and voting remain critical to developing relevant Community Standards. To that effect, some normal OGC procedures aren’t required to establish a Community Standard, such as forming a Standards Working Group, complying with the OGC Modular Specification process, and requiring compliance tests. Finally, OGC cannot change the normative content of a Community Standard.
The net result of all this is that moving a Community Standard through the OGC process takes considerably less time than for a traditional OGC standard—that is, approximately 6–9 months compared to 18–24 months or more, respectively.
The Benefits of Submitting Mature Standards
Now that several specifications have been through the Community Standards process, OGC has identified a number of benefits to the process:
- The formal review process pinpointed a variety of spelling and grammatical errors in each submitted specification. These were corrected, which improved the quality of the documents.
- In the case of GeoRSS, errors were identified and documented. These were corrected, generating an even more robust standard.
- In the case of I3S, OGC document editors and Esri were able to align it much more closely with the current OGC/ISO Standards Baseline, especially in terms of coordinate reference systems. This is an important consideration for organizations that specify OGC and ISO standards in procurement language.
To date, the OGC Community Standards process has been a success. Given that this is a relatively new process, it will certainly undergo minor refinements as OGC learns from recent and future submissions.
But the benefits are clear. OGC Community Standards allow proven, widely used technology to be adopted as OGC standards, which enables them to be treated as full-fledged, member-approved OGC standards. Not only does this advance community- and organization-developed specifications, but it also helps modernize the OGC’s Standards Baseline.
Community Standards provide huge—and synergistic—advantages to the entire GIS community. OGC can leverage the expertise of a very large technology community to broaden its suite of standards while staying consistent with a range of technology and market trends. In return, GIS users and the procurement community can feel secure that they have access to stable, fully vetted, and freely available standards not controlled by a single vested interest.
About the Author
Carl Reed is a geospatial technology professional. He holds a PhD in geography from The State University of New York at Buffalo, where he specialized in GIS technology development and systems engineering and design. Reed has more than 40 years of experience in GIS software development, architecture, and standards. He generated the original idea and initial policies and procedures for the OGC Community Standards process.
Take a closer look at the three recently adopted OGC Community Standards: I3S, LAS, and GeoRSS.
I3S
Innovative technologies are making it possible to assemble highly accurate digital representations of the real world. New data types and collection methods generate large datasets that users want to employ in distributed mobile and web apps.
For this rapidly developing market, the data being collected is often 3D. In 2015, to coincide with its release of new platform technologies that work well with 3D GIS, Esri produced a new specification for storing, packaging, and streaming large quantities of geospatial 3D content—Indexed 3D Scene (I3S) layers.
Esri released the I3S specification publicly to have its partners and users help drive innovation. The company wanted to encourage interoperability and give users confidence that their data would always be open and accessible.
With I3S, layers define the types of data that make up a single dataset. Currently, the public I3S specification includes 3D object, 3D point, and integrated mesh data types. 3D objects are typically used for assets such as buildings, 3D points are used for simpler features such as trees and signs, and integrated meshes combine textures and triangles into large layers that are often derived from reality capture methodologies. Additionally, a new point cloud I3S layer type will be added to the specification this year.
I3S is a key interoperability tool for growing 3D capabilities across the ArcGIS platform. ArcGIS Earth, the WebGL Scene Viewer in ArcGIS Online and ArcGIS Enterprise, and ArcGIS Pro all consume I3S layers and can combine them with other spatial data types, such as KML files, GeoREST services, and WMS layers. ArcGIS Online, ArcGIS Enterprise, and ArcGIS Pro can publish and create I3S content as well.
I3S has been widely adopted, with notable companies such as Vricon and Bentley Systems now producing content directly in I3S. A Czech startup, Melown Technologies, has even created a data production pipeline, a server, and a web client that work with I3S, demonstrating that I3S can be implemented without the use of any Esri technology.
In response to requests from partners and users, Esri began working with OGC and industry partners in 2016 to submit I3S into an appropriate OGC standards process. It was decided to submit the I3S specification for consideration as a Community Standard to reflect how I3S originated within the industry, was experiencing increased adoption, and had a community-based change management process.
By August 2017, I3S was approved as an OGC Community Standard. Called the OGC Indexed 3D Scene Layer (I3S) and Scene Layer Package Format Specification, the approved standard includes not only the structure of I3S content but also a packaging mechanism that allows I3S to be used as local packages on clients that are disconnected from the Internet.
I3S has become a standard technology across ArcGIS. Users can create I3S content from ArcGIS Pro, ArcGIS Enterprise, and ArcGIS Online. ArcGIS web clients, including Scene Viewer, Web AppBuilder for ArcGIS, and Esri Story Maps apps, allow anyone to use I3S to share interactive 3D maps as streamed services. Esri desktop clients, such as ArcGIS Pro and ArcGIS Earth, can access I3S content as either services or local files. And I3S content can be used as analytical content within 3D scenes using interactive tools for viewshed, line-of-sight, and 3D measurement analyses.
The public I3S standard is available on the OGC website. Find out more information about I3S on the Esri Developers site and on the ArcGIS Blog. Learn more about the different layer types in I3S and get downloadable examples in this story map.
LAS
LAS is a community-developed specification for point cloud file formats. The LAS format is primarily used for transmitting laser point cloud data (lidar), but it can also be used for any general 2D or 3D point-oriented encoding.
The LAS specification defines a relatively compact binary encoding of point location and point attribute data. Rather than store attributes in referenced records, LAS’s lightweight attribute data is stored in the same record as the point data, keeping everything in a single data file.
LAS is based on work done by EnerQuest Systems in the late 1990s and then released into the public domain. In the early 2000s, a small community of companies teamed up and developed a draft for LAS version 1.0. About a year after this industry group defined the initial specification, ASPRS agreed to take over ownership and expanded the community of contributors. ASPRS released version 1.0 in 2003.
The initial version of LAS 1.4, released in 2011, is the version the community agreed to submit into the OGC Community Standards process. OGC membership endorsed LAS 1.4 as an official OGC Community Standard in October 2017. As part of the evidence of implementation, OGC Point Cloud Working Group asked the OGC membership who was using LAS. Almost 80 percent of the more than 180 respondents reported that they used it.
Support for LAS (versions 1.0 through 1.4) is included in both ArcMap and ArcGIS Pro. These apps enable users to view point clouds directly along with all other geospatial data in both 2D and 3D. Users can filter the points based on return and classification codes, which describe the surface or objects—such as treetops and vegetation—being detected by the sensor system. Profile views are also available, and users can edit the coding of the point if they wish. The point clouds can also be used as input for a range of analysis tasks or to create different surfaces.
ArcGIS provides an extensive set of editing, rendering, and analytical tools for LAS-related workflows. And in the near future, I3S will support point clouds, enabling highly efficient scene rendering of lidar point cloud data provided in the LAS format.
Get more information about how ArcGIS supports LAS files.
GeoRSS
GeoRSS was designed as a lightweight, community-driven way to extend existing Really Simple Syndication (RSS) feeds with geographic information. As such, GeoRSS is a simple model and encoding method for geoenabling, or tagging, RSS feeds with location data.
One big advantage of using GeoRSS feeds is that they make incident and emergency communication, Internet searches, geotagging, and map information aggregation more focused, encompassing, and powerful. Rather than get RSS feeds for a particular city or ZIP code, GeoRSS enables users to perform Internet searches by applying myriad geographic criteria. For instance, a homeowner can search all the earthquake-related incidents within 20 miles of his home and get the results delivered to his mobile phone, or a businesswoman with an hour-long commute can get an RSS feed of all the traffic accidents along her daily route. RSS feeds that contain location information power all sorts of apps.
OGC members and their associates began discussing how to geoenable RSS feeds as early as 2003. A small group began collaborating to design and implement GeoRSS in 2005. The initial version of the community-built GeoRSS specification became publicly available in early 2006. Aside from some minor modifications that were made early on, the GeoRSS specification has remained unchanged for the last 10 years. And since its release, GeoRSS has been implemented in hundreds of operational apps from national mapping agencies, multinational institutions, private companies, nonprofit organizations, and more.
GeoRSS was approved as an official OGC Community Standard in 2017. Currently, there are two GeoRSS serializations: GeoRSS Simple and GeoRSS GML. GeoRSS Simple is lightweight but also limits extensibility, while GeoRSS GML is a formal Geography Markup Language (GML) profile that supports a greater range of features than GeoRSS Simple—most notably, coordinate reference systems other than the World Geodetic System 1984 (WGS84) latitude-longitude. Although GeoRSS is designed for use with Atom 1.0, RSS 2.0, and RSS 1.0 web feeds, it can be used just as easily in other languages or encodings, such as JavaScript.
ArcGIS Online has provided full GeoRSS support since 2013, and Map Viewer implements encoding for both GeoRSS Simple and GeoRSS GML.
Find out more about how ArcGIS Online supports GeoRSS.
