Why Open Standards?
Whether you’re using electricity or data, standards help assure things work together – that they are interoperable. The same logic for the benefits of standards applies to electricity as it does to geospatial data services. When standards are used, consumers can “plug and play” with supplier services with ease, while lowering costs and increasing the reliability of their experience. Productivity gains compound in scenarios of cross-border or cross-industry collaboration and exchange. Anyone that has traveled to another continent has felt that pain and cost of needing to purchase an electric converter for your phone charger.
In the world of geospatial data, standards and specifications define requirements to ensure that users can exchange and use data across software products while the content remains consistent in accuracy, structure, format, and style. As a publisher, when I share geospatial data in open standard formats and specifications, such as a Comma Separated Value (CSV) file or an OGC Web Feature Service (WFS), I trust that it will increase access to my data and lower the costs of use to my diverse set of data consumers on the whole.
For example, in wildfire response scenarios across state or country lines, command centers need fire perimeter data, shared in ready-to-use formats and services, regardless of the source. When time is of the essence, the firefighters’ mobile applications, or the managers’ crew positioning and risk assessment decision support tools, should be able to “plug and play” with that data. Using that data should take as few clicks as possible without needing extra time or money for intermediary translation tools or quality control workflows.
With ArcGIS, one system can serve many purposes. Publishers can easily provide geospatial data in standards-compliant downloadable formats and as web services. These include open standards – specifications adopted by the International Organization for Standardization (ISO) and developed by the Open Geospatial Consortium (OGC). In parallel, publishers can provide data through the de facto GIS industry standard ArcGIS web services and file geodatabase formats, many of which are also open specifications. Using international open standards in parallel with de facto standards and open specifications maximizes interoperability, usability, scalability, and permanence.
These multiple sharing options are available with only a few clicks in ArcGIS Enterprise software and ArcGIS Online software-as-a-service products. For example, checking the “Export in Multiple Formats” option box in the item settings for an ArcGIS Feature Service (that you have published in ArcGIS Online or ArcGIS Enterprise) enables data downloads simultaneously in open standards formats like CSV, KML, GeoJSON as well as industry standard formats like the Shapefile, Excel, and File Geodatabase.
With just a few more clicks, data providers can publish the ArcGIS Feature Service as an OGC Web Feature Service (WFS), and as of recent, the new OGC API – Features service (a.k.a. the “OGC Feature Layer”), currently in ArcGIS Online. Publishing de facto industry standard Raster and Vector Tile Layer services are also easy options. Exporting to the OGC GeoPackage format from a file in ArcGIS Pro or from a Hosted Feature Service are also options. Consuming standards-compliant services provided by third party software is also supported across ArcGIS desktop and web applications as described in the image below.
Modern technology patterns and practices prioritize architectures that enable access to streaming web services. Let’s explore further ArcGIS support for open standards of geospatial web services, or APIs.
ArcGIS Support for Open Standards for Web Services
ArcGIS historically supports the publication and consumption of several open geospatial web services standards developed by the OGC, including the Web Map Service (WMS, also ISO 19128), Web Feature Service (WFS, also ISO 19142), Web Coverage Service (WCS), Web Map Tile Service (WMTS), and Web Processing Services (WPS).
At their best, standards should constantly evolve with technology. Esri product teams have been closely following the evolution of the next generation of OGC APIs. OGC API – Features (ISO 19168-1) is the first of these next generation OGC APIs to be adopted by international standards development organizations. We will provide more detail about ArcGIS support for the OGC API – Features in a separate post soon. To see the new service type in action, Esri recently began publishing a collection of U.S. National Geospatial Data Assets in the OGC Feature Layer format in partnership with the U.S. government.
Esri will continue to support the previous generation of OGC web services for the foreseeable future and participates in annual certification processes with each new major product release. Users can further explore details regarding Esri’s compliance certifications by product version at the OGC website.
However, we strongly encourage governments to start considering this new generation of modern web services. We look forward to the continued OGC progress on these APIs, and we welcome feedback from users.
Send us a question or comment in the Esri Community Open and Interoperable space.
Open Standards in the United States Government
Not all standards are created equal. For over 25 years in the United States, both the Legislative and Executive branches have repeatedly codified, emphasized and institutionalized the preference that agencies prioritize technology that leverages domestic and international voluntary consensus standards. Usually, that language is qualified by two exceptions– when doing so neither conflicts with other legal obligations nor is otherwise impractical.
Esri has a decades-long commitment to open standards-based interoperability as well as providing open specifications for the de facto industry standards it creates. In the world of geospatial formats and services the International Standards Organization (ISO), International Hydrographic Organization (IHO), and the Open Geospatial Consortium (OGC) lead standards development and management. In the U.S., the American National Standards Institute (ANSI) represents US government interests related to Geographic information within the ISO Technical Committee 211 that covers Geospatial information/Geomatics. They are the open standards bearers.
Esri actively participates alongside other U.S. federal agencies, academic institutions and private companies in the development of open standards via the OGC, ISO, and the IHO. Esri also provides a leadership within the OGC as a member of the OGC board of directors, as well as the planning and technical committees. Esri employees have also participated in numerous Innovation Program testbeds, pilot projects, and specification development sprints facilitated by OGC.
Esri has also opened up many of its originally proprietary specifications that are also de facto industry standards. This includes the Shapefile in the 1990s, the GeoServices REST specification (aka “Web Feature Service”) around 2011, and the Indexed 3D Scene layers (I3S) and 3D Scene Package (SLPK) in 2017. These specifications are non-proprietary and are licensed to support royalty-free implementation and replication. to support commercial innovation and interoperability. For example, The Indexed 3D Scene (I3S) service was adopted as an OGC Community Standard in 2017 and later updated to include additional features and capabilities. Several external vendors have adopted this specification, and open source developer tools have been built to support seamless conversions between i3s and the other OGC Community Standard for 3D data transport specification, 3D Tiles. If you want to see support for I3S services in CesiumJS, please like this community post or comment in Github on our source code submission, which is pending action by the open source maintainers!
Supporting performance and scalability
While Esri supports open standard web services, our primary focus is supporting our users’ workflow needs. As such, ArcGIS web services specifications constantly evolve based on feedback from a wide range of users and applications. With each new release, ArcGIS REST APIs unlock new advanced capabilities, for example, related to performance and security needs. Often, these requirements are difficult to anticipate or realize through international, consensus-based standard development processes. For example, the OGC Web Feature Service still does not provide robust support for editing in disconnected environments with effective synchronization post editing. Whereas, the ArcGIS Feature Service does.
Sometimes, the timing of evolving user needs and technologies do not match up with lagging standards development cycles. This reality can make standards impractical to use in certain operational workflows. Further, if services and capabilities are needed to support a narrow set of use cases or users, the theoretical benefits of standards-based interoperability approaches may not outweigh the costs for vendors of all sizes to create new or updated standards from a consensus-based process.
For these reasons, Esri pursues multiple paths to achieve openness and interoperability. These include opening up ArcGIS web service specifications, supporting open source libraries that can use and create ArcGIS web services, and partnering with FME and others to provide translation tools to support a variety of deployment scenarios. We look forward to continued dialogue on these and other approaches to ensure that ArcGIS remains open and interoperable.