- 1 Chapter 10: Standards Suites for Spatial Data Infrastructure
- 1.1 Introduction
- 1.2 Problem statement
- 1.3 Scope and objectives
- 1.4 Background and rationale
- 1.5 Standards considered
- 1.6 Criteria for inclusion in an SDI standards baseline
- 1.7 Foundational Standards
- 1.7.1 Table 1: Standards used in deployed SDIs
- 1.7.2 Table 2: SDI standards baseline
- 1.7.3 Information content standards
- 1.7.4 Service and interface standards
- 1.8 Compliance testing
- 1.9 Xlink
- 1.10 XML Schemas
- 1.11 Discussion
- 1.12 Conclusions
- 1.13 Acknowledgements
- 1.14 References
- 1.15 For further information
Chapter 10: Standards Suites for Spatial Data Infrastructure
Editor: Julie Binder Maitra, +1-703-648-4627 (-5 h UTC/GMT), jmaitra [at] usgs.gov
The core of this chapter was originally published as “Doug Nebert, Carl Reed and Roland M. Wagner, Proposal for a Spatial Data Infrastructure Standards Suite: SDI 1.0, Research and Theory in Advancing Spatial Data Infrastructure Concepts (ed. Harlan Onsrud; Redlands, CA: ESRI Press, 2007), http://gsdidocs.org/gsdiconf/GSDI-9/papers/TS19.1paper.pdf
The successful implementation of Internet-based spatial data infrastructures (SDI) requires the specification and adoption of a compatible suite of standards to enable interoperability. The proliferation of new standards and new versions of old standards raises issues of dependency and compatibility that may impede the implementation of SDI architectures. This chapter proposes how to specify a suite of geospatial standards with an exemplar suite of SDI standards. The process is designed to facilitate the description and acquisition of compatible technology for SDIs worldwide, from local to regional to national to transnational to global SDIs. The application of a common set of standards for SDIs may reduce life cycle costs, enhance interoperability, decrease implementation risk, and improve services, particularly in the developing world.
For over 30 years, SDI activities have been progressing at the local, regional, national, transnational, and global levels. Spatial data infrastructures are the realization of technical and human efforts to coordinate and provide geospatial information and services for multiple purposes. The SDI Cookbook (Nebert 2004) introduces SDIs as follows:
The term “Spatial Data Infrastructure” (SDI) is often used to denote the relevant base collection of technologies, policies and institutional arrangements that facilitate the availability of and access to spatial data. The SDI provides a basis for spatial data discovery, evaluation, and application for users and providers within all levels of government, the commercial sector, the non-profit sector, academia, and by citizens in general.
A SDI may be defined in broad social terms as a framework for collaboration. The technical framework, including the effective use of standards, for a SDI enables interoperability for the access and exchange of geospatial resources. The problem is that too many current SDI activities operate as independent application “silos” with little or no interoperability between them. Too often, individual SDI initiatives define standards best practices without regard as to how thier neighbor's SDI uses those same standards. Interoperablity across independent SDI's require agreements on which standards are used, what version of a given standard is used, what compliance tests are passed, and so forth. Without these agreements, severe limits are imposed on our ability to implement a virtual global SDI (GSDI). The goal of achieving interoperability can be hampered.
SDI initiatives worldwide are implementing a variety of international standards for data and service discovery, data access, visualization, and analysis. The use of different combinations and/or versions of these standards limits interoperability between systems and initiatives. Guidance on best practices and approaches to solving these interoperability issues is critical to our ability to define and implement a SDI.
This document seeks to answer the following questions:
- What standards make up the SDI standards baseline?
- Which versions of core standards should be cited in the SDI standards baseline?
- What tests shall be performed to make sure that software is compliant with standards?
Scope and objectives
This chapter focuses on the identification of compatible, mature geospatial standards that allow maximum technical interoperability based on general evaluation criteria. For this chapter, we term this the SDI standards baseline. This baseline is intended for all SDI communities interested in providing and accessing geospatial data over the Internet.
The chapter also proposes candidate standards for future SDI deployments or enhancements.
Background and rationale
The SDI standards baseline is intended to manage the complexity, evolution, and compatibility of available standards and their associated versions and to encourage globally compatible solutions.
In addition to the large number of geospatial standards, many standards from the information and communications technology community can be considered as part of the architecture and deployment of interoperable geospatial solutions. Consequently, the selection of an appropriate technical architecture can become daunting, and independent selection of standards may lead to incompatibilities within or between SDI implementations. The identification of an SDI standards baseline allows a shorthand reference for basic capabilities in an SDI environment, with provision for identifying optional supplemental standards.
Standards evolve based on a variety of factors, including new requirements, new technical trends, and implementation experience. Too often, these changes are rarely coordinated with changes in other normatively referenced standards. Therefore, the identification of an SDI standards baseline that comprises standards (and their version numbers) that are known to work well together is of great benefit to implementers, integrators, and adopters. Adapting to frequent changes in standards is expensive and prone to issues of incompatibility. Minimizing the number and frequency of changes (and especially version changes) is a goal of this document.
Through identification of an SDI standards baseline, development of software that supports one SDI can be readily deployed for another SDI. This broadens the market reach of solution providers and reduces the cost of software development through targeted support of specific standard versions.
Geospatial standards are primarily developed by the International Organization for Standardization (ISO) Technical Committee 211 (TC 211), Geographic information/Geomatics and the Open Geospatial Consortium (OGC). These standards are often dependent on other industry standards, such as those of the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS), which develops e-business standards. Geospatial standardization efforts began in earnest in 1994 with the formation of TC 211 and the OGC.
Geospatial standards development has advanced, largely in the context of the World Wide Web and its emerging standards and infrastructure. Well over 75 standards, including underlying Internet standards, may be relevant to the geospatial domain.
Both ISO and OGC standards are copyrighted. OGC standards are free, while ISO charges for standards it publishes.
The identification of an SDI standards baseline is already a practice in SDI contexts. An SDI standards baseline allows for the federation of provider-operated services and for data to be discovered, visualized, and accessed by Web browsers and software applications.
Criteria for inclusion in an SDI standards baseline
Given the number of geospatial standards and the versions of these standards, definition of an SDI standards baseline reduces risk and enhances interoperability among and between SDIs. Inclusion of a standard in an SDI is based on the following criteria:
- Evidence of implementation
- Stability and conformance
- Core or supplemental status
Evidence of implementation
Many factors come into play when considering the adoption of a standard. Those factors include simplicity of the standard, market need, availability of educational materials, policy guidance, and others. In addition to those factors, stability and maturity of a standard are equally necessary as measured by evidence that a standard has been widely implemented and supported in both commercial and open source software.
Commercial and noncommercial software solutions and documentation (publications, how-to guides, and workbooks) are useful metrics in identifying mature standards. The OGC web site lists products that have implemented OGC standards. Several OGC members have developed tools that search the Web for publicly available OGC Web Service-enabled servers. There are also several recent presentations that document the number of instances of implementation of specific OGC web service interface standards: for example, State of Play of OGC Web Services across the Web speaks to the use of OGC standards in Europe and mapmatters.org provides a registry of hundreds of WMS instances.
Documenting evidence of implementation helps determine which standards need to be included in the SDI standards baseline. This approach focuses on reducing costs and risks while increasing value by leveraging existing services and implementations.
Standards frequently have implicit and explicit dependencies on other standards. Hierarchies of standards, such as the Open Systems Interoperability (OSI) stack, describe vertical hardware, operating system, protocol, and application relationships. Horizontal and containment relationships or dependencies also exist. The latest version of a standard might not necessarily work with other standards. Successful application of standards must clearly define the type, context, and version of related standards and their usage. Dependencies on other standards that are not mature or widely adopted may cause problems with interoperability.
Minimizing the number of dependencies can facilitate migration to newer versions of standards, as related standards may evolve on an independent schedule.
Stability and conformance
Implementation of technical standards to ensure interoperability requires that implementations can be assessed or tested for conformance or compliance against the standards. Availability of tests — testing service, assessment methodology, model assertions, or testing software — promotes the adoption of interoperable solutions.
Compliance testing determines that a specific product implementation of a particular standard complies with all mandatory elements specified in the standard and that these elements operate as described in the standard. Successfully completing compliance testing enables software development organizations to be licensed to use a certain trademark or certification mark, which can be used in marketing and product materials to inform users that the product complies with one or more specific standards and has passed compliance testing for those standards. An example of a compliance testing environment is the OGC Compliance & Interoperability Testing & Evaluation (CITE) program.
Availability of compliance tests for a standard is a sign of stability of a standard. It reduces risk and enhances interoperability among and between SDIs, and hence is an important criteria in considering the inclusion of the standard in a coordinated suite of SDI standards.
Core or supplemental status
Core standards should be viewed as the most widely implemented standards that provide baseline functionality in an SDI.
Supplemental standards may not be required for SDI implementation, but they may identify optional, well-known capabilities.
An SDI standards baseline is the primary reference for the core standards.
Table 1: Standards used in deployed SDIs
Table 1 lists foundational standards on which geospatial standards may be dependent. Not all of these standards are required for implementation, but they may be required or expected to be present in a community’s operating environment.
|W3C Recommendation: eXtensible Markup Language (XML) Version 1.1|
|W3C Recommendation: XML Schema Version 1.0|
|W3C Recommendation: Hyper Text Transport Protocol (HTTP) Version 1.1|
|W3C Recommendation: Simple Object Access Protocol (SOAP) Version 1.2|
|W3C Note: Web Services Description Language (WSDL), Version 1.1|
|Oil and Gas Producer (OGP, formerly EPSG) Geodetic Parameter Dataset, Version 6.9 (2006)|
|Geographic Tagged Image File Format (GeoTIFF) Version 1.0|
|JPEG-2000 (ISO/IEC 15444-1:2004)|
|Information retrieval (Z39.50)—application service definition and protocol specification (ISO 23950:1998)|
|W3C XLink 1.1 Schema|
Table 2: SDI standards baseline
Table 2 lists core and future standards for the SDI standards baseline. It also lists supplemental standards.
Descriptions of the standards in the SDI standards baseline follow Table 2. The standards are classified into two categories:
- information content standards
- service and interface standards, which apply to access to geospatial information and build upon the information content standards
|SDI core standards||Future SDI standards|
|SDI supplemental standards|
|OGC Styled Layer Descriptor 1.1|
|OGC Web Map Context 1.1/Corrigendum 1|
Information content standards
ISO 19115/TS 19139 metadata standards
ISO 19115:2003, Geographic information - Metadata contains an abstract model represented in the Unified Modeling Language (UML) that depicts the content and relationships of descriptions of geographic data and services. It does not provide guidance on the encoding or exchange of metadata, but serves as a guide for what information should be documented for data and services.
ISO/TS 19139:2007, Geographic information -- Metadata -- XML schema implementation, provides a set of XML schema documents that can be used in the validation and structuring of compliant ISO metadata derived from the ISO 19115 metadata model.
Both ISO 19115:2003 and ISO/TS 19139:2007 are core standards in the SDI standards baseline.
Many organizations around the world have implemented metadata content standards. The Content Standard for Digital Geospatial Metadata (CSDGM) developed and endorsed by the U.S. Federal Geographic Data Committee (FGDC) was one of the first geospatial metadata standards released. There are still a substantial number of metadata records in CSDGM in North America and elsewhere. Metadata collections supporting this standard have been developed for 32 countries in multiple languages. With the advent of the ISO metadata content standard, a transition from CDSGM to ISO is underway. The FGDC web site provides guidance on migration from CSDGM to ISO 19115:2003.
As of August 2012, ISO 19115-1, Geographic information - Metadata - Part 1: Fundamentals, which is a revision intended to replace ISO 19115:2003, is at the Draft International Standard (DIS) stage. ISO/TC 211 members approved ISO 19115-3, Geographic information — Metadata — Part 3: XML schema implementation of metadata fundamentals as a new project for inclusion into to the ISO/TC 211 programme of work.
OGC Geography Markup Language
The OGC Geography Markup Language (GML) provides a means of encoding geographic features and their properties using XML. GML is the expected packaging for features requested from an OGC Web Feature Server (WFS). Data encoded in GML versions 2 and 3 can be validated using XML schemas published with the standard and maintained in a schema repository by OGC.
GML 3.2.1 (also an ISO standard, 19136:2007) is a core standard in the SDI standards baseline. It is compatible with WFS 1.1.
In February 2012, OGC published GML 3.3. GML 3.3 builds on GML 3.2, and extends GML 3.2 with additional schema components and requirements. GML 3.3 is backwards compatible with GML 3.2.1 and ISO 19136. This is because all extensions are made in separate XML namespaces to support a more modular use of components from the GML schema.
ISO/TC 211 approved a new project ISO 19136-2, Geographic information — Geography Markup Language (GML) — Part 2: Extended schemas and encoding rules. This project is to process OGC 3.3 to become an ISO International Standard.
GML 3.3 is recommended as a future SDI standard.
There are no plans for GML 4.0. Instead, there will be focus on need for the tutorials, education materials, and best practices in general and on specific topics.
Google submitted the KML 2.1 Reference Manual to the OGC in April 2007.
Initially, the OGC membership approved the OGC 07-039r1 KML 2.1 as an OGC Best Practices Paper. Informative text was added to further describe the KML coordinate reference system (CRS) and geometry models and the resultant OGC 07-113r1 KML 2.2 – An OGC Best Practice document was approved by the OGC Members as an OGC standard in September 2007.
As stated in the OGC© KML standard:
- KML is an XML language focused on visualization, including annotation of maps and images and geographic data in earth browser applications. Geographic visualization includes not only the presentation of graphical data on the globe, but also the control of the user's navigation in the sense of where to go and where to look.
- From this perspective, KML is complementary to most of the key existing OGC standards including GML (Geography Markup Language), WFS (Web Feature Service) and WMS (Web Map Service). Numerous GML to KML and KML to GML transform applications are available.
OGC KML 2.2 is a core standard in the SDI standards baseline.
OGC Filter Encoding specification
The OGC Filter Encoding (FE) standard is used to express a query, or filter, using a predicate language or terms and operators that are stored in XML elements. FE is used in the request messaging sent to WFS and in the query sent to the OGC Catalogue Service CS-W. OGC hosts reference XML schema documents that can be used to validate queries structured according to the standard.
ISO published ISO 19143, Geographic information - Feature encoding in 2010. OGC published ISO 19143:2010 as OpenGIS Filter Encoding 2.0 Encoding Standard in November 2010.
Rich Site Summary (RSS) is a simple, brief, and structured XML format that includes only key descriptive elements like author, date, title, narrative description, and hypertext link, elements which help a reader (or an RSS "aggregator" service) decide what source materials are worth examining in more detail.
GeoRSS enables RSS feeds to be geotagged or described by location. GeoRSS serves as a simple easy-to-use geotagging language that is extensible and upwardly-compatible with more sophisticated formats like GML.
There are currently two encodings of GeoRSS:
- GeoRSS-Simple is a very lightweight format that developers and users can quickly and easily add to their existing feeds with little effort. It supports basic geometries (point, line, box, polygon) and covers typical use cases when encoding locations.
- GeoRSS GML is a formal GML Application Profile, and supports a greater range of features, notably coordinate reference systems other than WGS-84 latitude/longitude.
OGC Styled Layer Descriptor
The OGC Styled Layer Descriptor (SLD) standard defines the structure of an XML file that applies rendering or symbolization rules to features. An SLD can be invoked as an argument to a Web Map Service (WMS) to present a requested map according to submitted style rules. The current version is SLD 1.1.
SLD support is an optional feature of WMS, and SLD 1.1 is a supplemental standard in the SDI standards baseline.
OGC Web Map Context
The OpenGIS Web Map Context Implementation Standard "states how a specific grouping of one or more maps from one or more map servers can be described in a portable, platform-independent format for storage in a repository or for transmission between clients."
Version 1.1 of WMC is coordinated with WMS version 1.1.
WMC version 1.1 support is an optional feature of WMS, and WMC 1.1 and its Corrigendum are supplemental standards to the SDI standards baseline.
Service and interface standards
OGC Catalogue Service specification
The OGC Catalogue Service specification provides an abstract model and protocol-specific solutions for discovery of geospatial resources. Catalogues contain some form of searchable metadata and a query interface for returning the metadata properties to the requestor. Often embedded in these metadata are links to actual data or services that allow the catalogue to act as a referral service to other information resources.
Although three protocol bindings are described in Catalogue Service version 2.0.2, only the HTTP binding, also known as Catalogue Services for the Web (CS-W), is now in wide usage. The CS-W document specifies a baseline set of operations, query terms, and response payloads. To support robust metadata standards, two OGC Application Profiles have been published for CS-W – one using OASIS ebRIM metadata model and the other supporting the ISO Metadata standard. Communities will specify the use of baseline, ebRIM or ISO Application Profile to maximize information exchange and interoperability. Schemas for metadata responses are published with the profile documents and can support limited validation testing.
CS-W 2.0.2 and the ebRIM and ISO metadata profiles are core standards in the SDI standards baseline.
ISO 23950 (ANSI Z39.50) (see The Library of Congress Maintenance Agency page for International Standard Z39.50) has historically been the most widely implemented protocol for geospatial metadata catalogues. Although no official conformance suite exists for the protocol, the FGDC still tests Z39.50 server compliance using online query tools and a validation suite executed at registry.fgdc.gov.
Z39.50 has been the most widely implemented of the three protocols. Although no official conformance suite exists for the protocol, the FGDC tests Z39.50 server compliance using online query tools and a validation suite executed within Geo.Data.gov.
The following issues impede adoption of Z39.50 in a suite of Web service standards:
- Z39.50 is TCP/IP-based and is therefore not a conventional Web service
- Z39.50 requires the use of a unique TCP/IP communication port that is not commonly configured for public access
- Z39.60 requires operating a different service and software than those used by other Web protocols
Z39.50 is therefore not recommended for new development in SDI architectures.
OGC Web Map Service
The OGC Web Map Service (WMS) standard supports the request and display of maps derived from data accessed by the service. Maps may be requested from one or more WMSs overlaid in browsers or client applications and delivered as graphical images (GIF, JPEG, TIFF, etc.). Features ”behind” the map can also be queried, and their properties can be returned to a requesting client.
SLD files are used optionally to interact with the rendering of maps, while WMC files are used optionally interact with the recall of maps.
WMS version 1.3 is a core standard in the SDI standards baseline.
ISO 19128:2005, Geographic information -- Web map server interface, is harmonized with WMS version 1.3.
OGC Web Feature Service
The OGC Web Feature Service (WFS) specification defines interfaces for describing data manipulation operations on geographic features using HTTP as the distributed computing platform. Data manipulation operations include the ability to:
- Create a new feature instance
- Delete a feature instance
- Update a feature instance
- Get or Query features based on spatial and non-spatial constraints
These interfaces allow a client to retrieve geospatial data encoded in GML 3.2.1 from multiple Web Feature Servers.
In 2010, the OGC approved WFS 2.0. WFS 2.0 is equivalent to ISO 19142:2012, Geographic information -- Web Feature Service.
The INSPIRE implementing rules for network services (the legal act) distinguishes two types of "download" service: pre-defined dataset download services (for downloading whole datasets) and direct access download services (for downloading subsets of datasets defined by queries). Only the former is mandatory to be provided by INSPIRE implementers, the latter one is optional (needs to be implemented "where practicable"). For the former, the TG recommend Atom or WFS 2.0 with stored queries (to return the whole dataset). For the latter, it recommends WFS 2.0.
In the U.S., the Geospatial-Intelligence Standards WG voted to mandate WFS 2.0 in the Department of Defense IT Standards Repository. The FGDC Standards Working Group recommended that the FGDC endorse WFS 2.0.
WFS 1.1 will be identified as a legacy standard.
OGC Web Coverage Service
The OGC Web Coverage Service (WCS) specification supports electronic retrieval of geospatial data as "coverages," that is, digital geospatial information representing space/time-varying phenomena. Examples of coverages are:
- triangulated irregular networks (TINs)
- point sets.
A WCS provides access to coverage data in forms that are useful for client-side rendering, as input into scientific models, and for other clients.
As with WMS and WFS service instances, a WCS allows clients to choose portions of a server's information holdings based on spatial constraints and other query criteria.
WCS 1.1.2 is a core standard in the SDI standards baseline for exchange of raster or grid data (not rendered imagery).
The OGC published WCS 2.0 in October 2010. The OGC deprecated WCS 1.1.2, as there is no current and maintained valid test suite for WCS 1.1.2. WCS 2.0 is not backward compatible with previous versions.
Extensions to the core WCS 2.0 meet additional requirements, such as response encoding. Indeed, additional extensions are required to completely specify a WCS for implementation.
WCS 2.0, its extensions, and corrigenda are identified as future standards for the SDI standards baseline.
OGC Web Processing Service
Since the last version of this chapter was published in 2009, the OGC Web Processing Service (WPS) has seen strong and increasing implementation in SDI applications and portals.
The OGC WPS Interface Standard provides rules for standardizing how inputs and outputs (requests and responses) for invoking geospatial processing services, such as polygon overlay, as a Web service. The OGC WPS standard defines how a client can request the execution of a process, and how the output from the process is handled. It defines an interface that facilitates the publishing of geospatial processes and clients’ discovery of and binding to those processes. The data required by the WPS can be delivered across a network or they can be available at the server. WPS can describe any calculation (i.e. process) including all of its inputs and outputs, and trigger its execution as a Web service.
WPS has implemented to provide standard interfaces to a broad range of geoprocessing functions, including the entire GRASS API and applications ranging from typnonomy to buffering to weather modeling.
OGC WPS 1.0, with its corrigendum, is a core standard in the SDI standards baseline.
Implementation of OGC standards requires compliance testing: if you implement a standard, you shall ensure that your software passes compliance testing, if tests are available. The OGC CITE program has been identified in this document as an example of a testing environment.
The purpose of the OGC CITE program is to increase systems interoperability while reducing technology risks. It accomplishes this by providing a process whereby compliance for OGC standards can be tested. This program provides a mechanism by which users and buyers of software that implements OGC standards can be certain that the software follows the mandatory rules of implementation as specified in the standard.
Compliance testing may be performed online or locally.
Although the standards produced by the OGC provide a standard API between the client and server and server implementations can pass the CITE tests to prove compliance with those standards, there often remains issues interoperability issues between vendor implementations. Compliance does not always equate to interoperability. This can be due to a number of reasons including:
- CRS definitions
- Response formats
- Flexibility in understanding within the standards
- Examples in older standards may have been changed
In order to overcome this issue of interoperability, the OGC often facilitates Plugfests as part of the Compliance program. A plugfest is an event at which vendors gather in a cooperative effort to test and improve interoperability between their product implementations of OGC specifications. An example result from one of these Plugfests can be found in the Engineering Report located at the following link on OGC’s website: http://portal.opengeospatial.org/files/?artifact_id=36336
Ultimately, the result of a Plugfest should be a profile submitted back to OGC detailing the compliance requirements of a given community (meaning an SDI or a given organization) or official CRs against the compliance tests to update/improve the test requirements.
All OGC standards using the OGC version of the XLink Schema files will be converted to using the W3C XLink 1.1 Schema.
Core SDI standards (and versions) that are impacted by this change include:
- All versions of WMC
- All versions of GML since version 2.0.0
- All profiles of GML since 2.0.0
- All versions of SLD since 1.0.0
- All versions of Web Coverage Service
- Web Feature Service 2.0
XML Schemas for select standards in the suite of core SDI standards may be found at schemas.opengis.net.
Establishing an SDI standards baseline serves many market purposes. Some fundamental relationships that best illustrate the need for a well-defined and -managed SDI and market and policy forces that dictate requirements for an SDI standards baseline are discussed below. The discussion also draws analogies to other information technology communities that faced similar issues and market drivers.
Evolution of the SDI standards baseline
The lack of coordination between release cycles of various standards can impede maintenance of operational capabilities, as new versions of standards become available. The problem is compounded when interdependent standards are not revised and released in a coordinated manner. This situation is not much different from issues related to software product development and release cycles. Therefore, a major reason for having a well-defined and agreed-to SDI standards suite is to support software (and standards) life cycle management.
Any release of a new version of the SDI standards suite needs to be predictable and coordinated. Backward compatibility is key for preserving customer investments in the overall technology. Users might tolerate exceptions to backward compatibility if new functions create enough value to fully compensate customer investments in change management. These considerations also apply to new versions of SDI applications.
Transition to a new SDI standards baseline must add enough value to justify the upgrade. Based on previous studies, we know that the initial investment in using SDI will add value and reduce life cycle management costs (NASA, 2005). Over time, more and more users understand the value and potential of using a standards-based approach. The value may be expressed as money, but could also be measured by other indicators. Only if the first generation has generated enough value and passed the ROI decision point, will new investments for implementing the next generation of the SDI suite be available. The period between standard releases is also relevant to software life cycle management. Factors to be considered include recurrent software update costs, the added value of the new SDI standards baseline, return on investment in data or service migration, and the ability to enhance SDI applications in a timely manner.
SDIs versus SDI applications
Although the interface between an infrastructure and an application is often expressed technically, it can be defined at a specific point in the value chain on the basis of organizational and economic criteria.
For example, electricity is produced in a power plant, distributed over a network, and then used in an application, for example, a radio or a heater. The infrastructure interface is located at a well-defined point behind an electric meter. Therefore, the responsibility of the infrastructure ends at this interface point, where the downstream power supply is metered for upstream money compensation.
Using this analogy, an SDI is a transport mechanism for spatial data and services. Therefore, a defined gateway is needed to act as the organizational interface between the SDI operator and the SDI application customer.
The distinction between operating systems (OS) and applications in computers provides another analogy. This distinction is defined by a set of application programming interfaces (APIs) that connect programs and allow software applications to be written. The suppliers of operating systems are often not the suppliers of applications. In operating systems, a specific function can be augmented and made reusable if many applications use it. Classic examples are video and audio drivers. These functions were once considered application specific, but because they were used by many applications, a standardized API was eventually included in the operating system.
The concept and bounds of SDI include SDI applications as well as SDI interfaces. OGC’s Geospatial Decision Support (GeoDSS), for example, could easily be implemented using an SDI standards suite coupled with the OASIS Business Process Execution Language (BPEL) standard. The GeoDSS application would load data from different repositories, perform an analysis, load more data, perform another analysis, and so forth. However, the requirements for service chaining are outside the scope of the SDI standards baseline. A future generation of SDI could include additional functions. Further, a list of "standard" applications is beyond the scope of this current guidance for a SDI standards baseline.
SDIs require a consensus process to properly define, document, and manage the standards framework in order to ensure that the needs of the many constituents are properly represented. A structured and open process will facilitate dialogue, approval of the SDI framework and future revisions, and effective life cycle management.
GSDI, INSPIRE, ANZLIC, CGDI, NSDI (US), and various e-government initiatives can provide an excellent forum for refining SDIs, as they have identified best practices for developing standards-based SDIs.
Standards lifecycle management will ensure that the SDI standards baseline is coordinated effectively and that revisions are carefully considered and documented. The incorporation of SDI capabilities in agency enterprise architecture planning can be an effective approach towards integration and support for selected standards, as vetted by the SDI community.
SDIs are becoming a major resource for discovery and access to geospatial data and services. Partnerships between multi-tier public and private sectors are paying off in higher returns on investment. Perhaps more importantly, SDIs are contributing to sound decision making, enhanced e-government applications, and better services. Interoperability can be achieved only through consistent and structured implementation of interface and encoding standards. This document has proposed an SDI standards baseline identifying core, supplemental,and future standards.
We recommend that the concept of an SDI standards baseline be considered as an important work item by all levels of the SDI community, from local to regional to national to transnational to global. SDIs benefit from a well-defined and -managed suite of standards. The global SDI community will take responsibility for identifying and defining standards for the SDI standards baseline.
- Nadine Alameh, Glenn Guempel, Terry Idol, Doug Nebert, and Carl Reed for their review and comments
- Stan Tillman and Luis Bermudez for the section on Plugfests
- Michael Lutz, for input on use of WFS 2.0 by INSPIRE
For further information
FGDC Geospatial Applications and Interoperability (GAI) Working Group (inactive), 2003. A Geospatial Interoperability Reference Model (G.I.R.M.) Version 1.1, http://www.fgdc.gov/standards/organization/GIRM, accessed 2014-02-19
This 10-year-old document classifies standards using the following model:
Viewpoints and levels of abstraction Computation Viewpoint - Service Invocation Information Viewpoint - Information Transfer Implementation specifications ("how") Interface Encoding Abstract models ("what") Behavior Content
Land Information New Zealand (LINZ), 2011. Spatial Data Infrastructure Cookbook Version 1.1 - 17 November 2011, http://www.linz.govt.nz/sites/default/files/geospatial-office/SDI_Cookbook%20V1-1%20171111_0.pdf, accessed 2014-02-21.
This documents contains an initial list of standards suitable for New Zealand’s first steps in the journey toward formal national SDI. Standards are classified as:
- Essential (WMS and Metadata)
- Highly desirable
- Additionally useful
- Other standard interfaces
Natural Resources Canada, 2013. Geospatial Standards and Operational Policies, www.nrcan.gc.ca/earth-sciences/geomatics/canadas-spatial-data-infrastructure/8902, accessed 2014-01-30.
Canada classifies standards into the following categories:
- Syntax and Encodings
Standards in addition to the SDI standards baseline are used by the CGDI.
Not surprisingly, GeoConnections Canada uses this classification in the Spatial Data Infrastructure (SDI) Manual for the Americas http://www.cp-idea.org/index.php/component/jdownloads/finish/48-10-reunion-cp-idea/283-spatial-data-infrastructure-sdi-manual-for-the-americas?Itemid=0, accessed 2014-02-20, that it prepared for the United Nations Permanent Committee for Spatial Data Infrastructure of the Americas (PC-IDEA).
Open Geospatial Consortium Inc., 2011. OGC Reference Model Version 2.1, www.opengeospatial.org/standards/orm, accessed 2012-09-14.
The ORM classifies OGC standards into two categories:
- Geospatial Information Standards
- Geospatial Service Standards
Open Geospatial Consortium Inc., 2012. OGC Market Report: Open Standards and INSPIRE, www.opengeospatial.org/pressroom/marketreport/inspire, accessed 2012-12-03.
The section OGC Standards in Support of INSPIRE (pages 18-24) provides short description of select OGC standards, including standards in the SDI standards baseline. It also cites Observations and Measurements (O&M) and Sensor Web Enablement (SWE).
University of Geneva, 2013. Bringing GEOSS services into practice, http://www.unige.ch/sig/enseignements/GeossInPractice.html, accessed 2013-12-19.
The "Bringing GEOSS services into practice" workshop aims at teaching participants how to install, configure and deploy a set of open source software to publish and share data and metadata through GEOSS using OGC and ISO standards, many of which are cited in this chapter.
The web page is helpful in and of itself for its Q & A on what standards to use for storing, publishing, documenting, searching, processing, viewing, downloading, analyzing, and sharing geospatial data.