Chapter 10

From The SDI Cookbook

Contents 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 1.7 Foundational Standards 1.8 Discussion 1.9 Conclusions 1.10 References 1.11 Appendix A

Chapter 10: Standards Suites for Spatial Data Infrastructure

Editor: Carl Reed creed {[at]} opengeospatial.org

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

Introduction

For over twenty years, SDI activities have been progressing at the local, regional, and national 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:

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. To often, individual SDI initiatives define standands best practices without regard as to how thier neighbor's SDI use those same standards. Interoperablity across independent SDI's require agreements on which standards are used, what version of a given standard is used, and so forth. Without these agreements, severe limits are imposed on our ability to implement a virtual global SDI (GSDI).

Problem statement

In 2005, after a year of concentrated effort, the U.S. National Geospatial Intelligence Agency (NGA) announced approval of an OGC spatial data infrastructure 1.0 (SDI 1.0) specification baseline. The problem NGA then faced was how to carefully consider and specify the actual baseline of standards (including versions) and interdependencies between the standards. Further, there was then no general reference architecture for defining a framework as to how these standards work together to enable a standards-based SDI.

Dozens of SDI initiatives are implementing a variety of international standards for data and service discovery, data access, visualization, and analysis. The use of different versions of these standards limits interoperability between systems and initiatives. Further, different SDI initiatives are using different content models for key data themes, such as land cover and land ownership. Guidance on best practices and approaches to solving these interoperability issues is critical to our ability to define and implement a GSDI.

Scope and objectives

This chapter focuses on the identification of compatible, mature geospatial standards that will allow maximum technical interoperability based on general evaluation criteria. For the purposes of this chapter, we term this compatible suite of standards SDI 1.0. The chapter also proposes a candidate suite of standards for future SDI deployments or enhancements. SDI 1.0 is intended for all SDI communities interested in providing and accessing geospatial data over the Internet. Transnational SDIs, also known as global geospatial data infrastructures (GDI), are loosely defined environments in which participants interact to develop and share geospatial content and services to the common benefit of a nation or, in the case of Europe, a continent.

Background and rationale

A coordinated SDI standards suite is intended to manage the complexity of available standards and version change and to encourage globally compatible solutions.

Complexity. Nearly 100 standards can be identified that can be considered as part of the architecture and deployment of interoperable geospatial solutions, including various standards in information and communications technology community. The selection of an appropriate technical architecture can be daunting, and independent selection of standards may lead to incompatibilities between adjacent SDI implementations. The definition of a relatively small suite of standards allows a shorthand reference for nominal capabilities in an SDI environment, with provision for identifying optional supplemental standards.

Evolution cycles. Standards evolve and are changed based on new requirements and implementation experience. Too often thse changes are rarely coordinated with changes in other normatively referenced standards. Therefore, the identification of a specific set of standards (and their version numbers) that are known to work well together is of great benefit to implementers and adopters. Adapting to frequent changes in standards is expensive and prone to issues of incompatibility. Minimizing the number and frequency of version changes is a goal of this proposal. The intent of having an SDI standards suite version number, i.e., 1.0, is to document such compatible versions. The SDI 1.0 suite will iteself need to be incremented in the future to incorporate revisions of the standards used in the suite.

Global compatibility. Through the identification of a common set of standards for SDI usage, the development of software that supports an SDI in one part of the world 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.

Standards considered

Geospatial standards are primarily developed by the International Organization for Standardization (ISO) Technical Committee 211 (TC 211) and the Open Geospatial Consortium (OGC). Their are often dependent on other industry standards, such as those of the World Wide Web Consortium (W3C) and OASIS, which develop e-business standards. International standards for country codes and coordinate reference systems existed prior to the 1990s, but the more detailed standardization efforts began in earnest in 1994 with the formation of TC 211 and the OGC.

The geospatial standards development process has advanced over the past twelve years largely in the context of the World Wide Web and its emerging standards and infrastructure. Including underlying Internet standards, well over 75 standards may be relevant to the geospatial domain. Versions of these standards exist in various states—development, endorsement, implementation, or deprecation – so deployment of all standards in a coordinated manner is not practical. Further, there is no assurance that they will function well together.

The identification of a common set of standards is already a practice in national SDI/GDI contexts. The Canadian Geospatial Data Infrastructure (CGDI) recognizes and promotes the use of a selected suite of standards through its Technology Advisory Panel. The U.S. National Spatial Data Infrastructure (NSDI) supports selected standards through its Geospatial One-Stop portal, geodata.gov. In both national contexts, such standards allow for the federation of a large number of provider-operated services and for data to be discovered, visualized, and accessed by Web browsers and software applications.

Criteria for inclusion

Given the number of geospatial standards and the versions of these standards, definition of a compatible suite reduces risk and enhances interoperability among and between SDIs. Inclusion of a standard in SDI 1.0 is based on the following criteria:

Evidence of implementation. The adoption of a standard is dependent on many factors, such as simplicity, market need, educational materials, policy, and so forth. In terms of SDI 1.0, there is a requirement for stability and evidence that a given standard is widely implemented and supported in both commercial and open source technology. Documenting evidence of implementation helps determine which standards need to be included in the baseline. The approach has a focus on reducing costs and risks while increaseing value by leveraging existing services and content.

Commercial and noncommercial software solutions and documentation (publications, how-to guides, and workbooks) are useful metrics in identifying mature standards. For example, the OGC web site lists implementing products that have implemented OGC standards. Also, several OGC members have developed tools that search the Web looking for publicly available OGC Web Service-enabled servers. Based on this search capability, there are over 1000 operational instances of the OGC (r) WMS Interface Standard (Refractions, 2006) (these numbers do not include instances of OGC standards that are hidden behind a firewall).

Dependencies. Standards rarely are monolithic or stand-alone and 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. There are horizontal and containment relationships or dependencies as well. The latest version of a standard is not necessarily the one that will work with a selected set of 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 as widely adopted may cause problems with interoperability. Minimizing the number of dependencies can facilitate migration to newer versions of standards, considering that related standards may evolve on an independent schedule.

Stability and conformance. The implementation of technical standards to ensure interoperability requires that the standards have some means of being assessed or tested for conformance or compliance. The availability of tests—testing service, assessment methodology, model assertions, or testing software—promotes the adoption of interoperable solutions. An example of a compliance testing environment is the OGC CITE capability for testing WMS and WFS compliance (http://www.opengeospatial.org/resources/?page=testing).

Core or supplemental status. Whereas several geospatial standards appear to be common and required to implement local, regional, and national SDIs, a number of other standards may be optional. The “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 identify optional, well-known capabilities.

Reference matrix. Table 1 lists the standards used by four major SDI projects. The first group are formal standards referenced by SDI initiatives, whereas the last five represent prototype implementations not yet approved as final standards. The CGDI selections represent both endorsed and recommended standards. The U.S. NSDI selections represent the standards required by the Geospatial One-Stop portal in its interaction with community data and services. The NRW (North Rhein-Westphalia [Germany]) selections represent a combination of standards in use by the local GDI project as well as a cross-border project operated in a partnership with the Netherlands. The Catalonian selections represent current technology implemented in the first phase of the SDI. This table is not intended to be an exhaustive exploration of adopted standards but illustrates commonality and differences between national and regional SDI environments.

Foundational Standards

Table 2 lists fundamental standards on which the geospatial standards may be dependent. Not all of these standards are required for implementation of SDI 1.0 standards, but they may be required or expected to be present in a community’s operating environment.

Table 2: Foundations for SDI standards

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)

Information content standards. The following standards apply to information content:

ISO IS19115/DTS 19139 metadata standard. Metadata standard ISO 19115:2003 contains an abstract model represented in UML depicting the content and relationships of descriptions of geographic data and services. The 19115 standard 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 Draft Technical Specification 19139 was scheduled for release in late 2006. The primary content of interest in this specification is a set of XML schema documents that can be used in the validation and structuring of compliant ISO metadata, derived from the 19115 metadata model.

Although a number of software packages and systems claim to support 19115 metadata, the delayed availability of the official encoding in DTS 19139 means that there will be few compliant implementations until the new schemata are adopted and implemented. Due to the lack of implementation practice, 19115/19139 should be considered supplemental to the SDI 1.0 standards suite.

FGDC Content Standard for Digital Geospatial Metadata. The U.S. Federal Geographic Data Committee (FGDC) approved version 1.0 of the Content Standard for Digital Geospatial Metadata (CSDGM) in 1994 and version 2.0 in 1998. The standard includes only an abstract model of content, relationships, obligation, and repeatability of properties that describe geospatial data. The FGDC has published schemata (XML document type declaration and XML schema documents) on its Web site to facilitate the validation and processing of metadata according to the standard. A metadata parser (mp) program is available from the U.S. Geological Survey for stand-alone and Web usage to validate metadata according to this standard. Extensions for biological and remote sensing data are available as well.

CSDGM is the most widely deployed metadata standard in the world. As of March 2006, over 8 million metadata records existed on the Internet in searchable collections that support the CSDGM. Metadata collections supporting this standard have been developed for 32 countries in at least four languages: English, French, Spanish, and Portuguese.

Since its acceptance as an international standard in 2003, ISO 19115 has been slowly replacing the CSDGM internationally, with validation through ISO DTS 19139 XML encoding. By 2008 the ISO metadata standard will likely supersede CSDGM in a future SDI standards suite version. Until there is wide adoption and deployment of 19115/19139, CSDGM remains a primary vehicle for the description of geospatial data used in SDIs. It is recommended for inclusion in the SDI 1.0 standards suite.

OGC Geography Markup Language. The OGC Geography Markup Language (GML), also an ISO International Standard (19136 and OGC GML 3.2.1), 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.

The OGC community uses two major versions of GML that are different and are not backwardly compatible. Version 3.1.1 is currently the most widely deployed, as it is frequently paired with implementations of WFS, although the WFS standard does not preclude the service of GML 3.2.1-encoded data. GML 3.1.1 is being widely used to express basic data themes, known as framework data in the United States, and for similar data modeling efforts in Australia.

Given its prevalence, GML version 3.1.1 is recommended for the core SDI 1.0 standards suite. GML 3.2.1, , is recommended as a supplement to the SDI 1.0 standards suite. We expect 3.2.1 to see broader implementation in 2009.

OGC Filter Encoding specification. The OGC Filter Encoding (FE) specification 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. FE version 1.1 was approved in 2004 and is recommended for inclusion in the SDI 1.0 standards suite.

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. SLD support is an optional feature of WMS and as such should be considered supplemental to the SDI 1.0 standards suite.

OGC Web Map Context. According to the OGC adopted-specifications page, “The ... Context specification 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. This description is known as a ’Web Map Context Document‘ [WMC] or simply a ’Context.’” Version 1.1 of WMC is coordinated with WMS version 1.1.1. Like the SLD, WMC version 1.1 support is an optional feature of WMS and as such should be considered supplemental to the SDI 1.0 standards suite.

Service and interface standards. The following standards apply to access to geospatial information and build upon the information content standards above.

OGC Catalogue Service specification. The Catalogue Service specification provides both an abstract model and protocol-specific solutions for the discovery of geospatial resources. Catalogues contain some form of metadata (searchable descriptive information) 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.

Three protocol bindings are described in Catalogue Service version 2.0: CORBA, Z39.50, and HTTP, the latter also known as Catalogue Services for the Web (CS-W). The HTTP binding requires the declaration of an additional application profile to define the specifics of interaction within a community. Two major application profiles have been approved: one for a general registry information model (ebRIM) and the other for data and service objects based on the semantics and structures of ISO 19115/19119/19139 metadata. Schemas for metadata responses are published with the draft profile documents and can support limited validation testing. A formal OGC compliance test suite has been formally developed or endorsed. A third ad hoc profile of CS-W has been drafted to query and present FGDC CSDGM metadata. Given the early stages of adoption and uncertain interoperability of these CS-W profiles, the CS-W protocol binding is recognized as an emerging candidate for a future SDI standards suite and is recommended as a supplement to the SDI 1.0 standards suite.

Of the three protocols, Z39.50 (also adopted as ISO 23950) has been implemented most widely, with over 400 registered servers from seven vendors supporting the geospatial query and response rules. Although no official conformance suite exists for the protocol, Z39.50 server compliance is tested by the FGDC using online query tools and a validation suite executed within the Geospatial One-Stop portal. OGC Catalogue Service Z39.50 protocol binding is recommended for the SDI 1.0 standards suite.

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, it requires the use of a unique TCP/IP communication port that is not commonly configured for public access, and it requires operating a different service and software than those used by other Web protocols. Given these issues and increased implementation testing of CS-W, it is likely that CS-W and its application profiles will supersede Z39.50 as the preferred standard in the future.

OGC Web Map Service. By far the most popular and widely implemented of the geospatial standards, the OGC Web Map Service (WMS versions 1.1.1 and 1.3; ISO 19128) supports the request and display of maps derived from data accessed by the service. Maps, delivered as graphical images (GIF, JPEG, TIFF, etc.) may be requested from one or more WMSs overlaid in browsers or client applications. Features ”behind” the map can also be queried, and their properties can be returned to a requesting client. As discussed above, SLD and WMC files are used optionally to interact with the rendering or recall of maps, respectively.

Schemas for validating the “capabilities” of an XML file returned from a WMS service exist, and compliance testing is available through the OGC for assessing WMS performance on all key functionalities.

WMS version 1.1.1 is the most widely deployed (ISO 19128, however, is harmonized with WMS version 1.3 but is not yet widely deployed) and is recommended for inclusion in the SDI 1.0 standards suite.

OGC Web Feature Service. According to the OGC adopted-specifications page, “the OGC Web Feature Service allows a client to retrieve and update geospatial data encoded in Geography Markup Language (GML) ... from multiple Web Feature Services. The ... interfaces must be defined in XML ... GML must be used to express features within the interface ... the predicate or filter language will be defined in XML and be derived from CQL [Common Query Language] as defined in the OpenGIS Catalogue Interface Implementation Specification.” The WFS provides an abstraction of the underlying data store, expressed in GML, as defined through GML application schemas referenced by the service.

The most common implementation of WFS is version 1.0. However, the number if WFS 1.1 implementations is rapidly growing and in 2009 will surpass the number of WFS 1.0 implementations. WFS 1.0 implementations typically return features encoded using GML 2.1 or GML 3.1.1. A growing number of services based on WFS 1.1 It is recommended that WFS version 1.0 be included in the SDI 1.0 standards suite, with required support for GML 2.1 and GML 3.1.1 response encoding.

OGC Web Coverage Service. The OGC Web Coverage Service (WCS) “...extends the Web Map Server (WMS) interface to allow access to geospatial ’coverages’ that represent values or properties of geographic locations, rather than WMS generated maps (pictures),” according to the OGC adopted-specifications page. WCS can return different representations of continuous data surfaces (coverages) for any location: grids, triangulated irregular networks (TINs), point sets. Most commonly, however, the form of coverage most often returned is a grid in a declared coordinate reference system and common format such as GeoTIFF. WCS version 1.0 (with Corrigendum) has been available since 2003 and is recommended for inclusion in the SDI 1.0 standards suite for the exchange of raster or grid data (not rendered imagery).

Candidate SDI 1.0 standards. Table 3 lists the standards for SDI 1.0 and for future versions.

Table 3: Core, supplemental, and future SDI standards

SDI 1.0 core standards	Future SDI standards
OGC Web Map Service 1.1.1 OGC Web Feature Service 1.0 OGC Filter Encoding 1.1 OGC Web Coverage Service 1.0 OGC Geography Markup Language 3.1.1 OGC Catalogue Service 2.0.2 Z39.50 protocol binding FGDC Content Standard for Digital Geospatial Metadata (CSDGM, 1998)	OGC Web Map Service 1.3 OGC Web Feature Service 1.1 OGC GML 3.2.1 OGC Catalogue Service 2.0.2 HTTP protocol binding (CS-W) ISO DTS 19139:2006 metadata
SDI 1.0 supplemental standards

ISO metadata standard 19115:2003 and ISO DTS 19139:2006

OGC Catalogue Service 2.0.1 HTTP protocol binding (CS-W) ebRIM and ISO Profiles

OGC Geography Markup Language 3.2.1

OGC Styled Layer Descriptor 1.0

OGC Web Map Context 1.1

OGC Catalogue Service 2.0 HTTP protocol binding, CS-W

 

Discussion

Establishing an SDI standards baseline serves many market purposes. Some fundamental relationships that best illustrate the need for a well-defined and -managed SDI 1.0 and some of the market and policy forces dictating the requirements for an SDI standards suite are discussed below. Analogies to other information technology communities that faced a similar set of issues and market drivers are also drawn.

Evolution of the SDI standards suite. The coordination of the release cycles of the various standards is currently limited. This lack of coordination can impede maintenance of operational capabilities as new versions of standards are made 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, one 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 a key requirement for preserving customer investments in the overall technology. Exceptions to backward compatibility may be tolerated by users if the relationship of new functions creates enough value to fully compensate customer investments in change management. These considerations also apply to new versions of SDI applications.

The period between standard releases is also relevant to software life cycle management. Factors that need to be considered include relationship investments, the added value of the new suite, return on investment, and the ability to enhance SDI applications in a timely manner. A new SDI suite needs to add enough value to justify upgrading an SDI application or portal. Based on previous studies, we know that the initial investment in using SDI 1.0 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 return on investment (ROI) decision point will new investments for implementing the next generation of the SDI suite be available. The expression “generation of value” applies to SDIs and SDI applications. Although the longevity of a given version of an SDI standards suite cannot be determined yet, the concept of generations is helpful for identifying which functions should be included in the first release and which could be moved to a future release (candidates).

SDI zones. User interface requirements, pricing, processing functions, security, and rights management requirements can vary broadly from region to region. These variations are due to local customer requirements, government policies, legal systems, and so forth. A monolithic approach may not work for an SDI that crosses jurisdictional boundaries. This market force is very similar to what the telecommunications industry has to deal with on a daily basis. In telecommunications, standards-based infrastructures effectively deal with different policy, tax, legal, and pricing requirements by accommodating regional variations.

SDIs face similar regional variations. We call them “SDI zones.” Rather than forcing every jurisdiction to use the same SDI implementation, architecture, and policy framework, we suggest creating SDI zones to meet local requirements while maintaining interoperability between zones. The advantages of distinct but connected zones are lower dependencies and reduced risks of bottlenecks. If an SDI zone or a connection to it is not operational, other zones are not affected directly. The current SDI 1.0 design should take zones into account and offer a zone-to-zone connection mechanism.

Different zones may implement different versions of the SDI standards suite, or they may implement the same version at different times. Therefore, the connection mechanism also needs to connect zones with different versions.

Zone compatibility. Applications often address a specific user need and thereby create great value for that specific purpose. A classic example in the PC world is graphics programs for professionals. On the one hand, these programs create enormous value for the professional; on the other hand, the number of potential (professional) users and their total investment potential are relative small.

Compatibility between SDI zones is a key requirement for selling an application to a larger market. Conversely, the number of (addressable) early adopters for a specific application has a direct impact on the willingness of developers to invest.

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. Electricity, a classic example, is produced in a power plant, distributed over a network, and then used in an application, e.g., a radio or a heater. The infrastructure interface is located at some well-defined point behind an electric meter. Therefore, the responsibility of the infrastructure ends at this interface point, where the downstream power supply is measured 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 often are 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.

Another well-known example is SUN’s Java Developer Kit (JDK). Although it consists of a large number of functions and interface specifications, the package is released with a single number, e.g., JDK 1.4. Application developers and operators can simply define the requirements and state, “JDK 1.4 is required.” The Java Community Process (JCP) is used for new projects, demonstrating the value of collaboration between institutions.

In the future, the concept of SDI should include SDI applications as well as the SDI interfaces. OGC’s Geospatial Decision Support (GeoDSS), for example, could easily be implemented using an SDI 1.0 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 SDI 1.0. A future generation of SDIs could include additional functions.

Governance. SDI 1.0 requires an international 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 1.0 framework and future revisions, and effective life cycle management.

GSDI, INSPIRE, ANZLIC, CGDI, GDI NRW, the U.S. NSDI, and various e-government initiatives can provide an excellent forum for refining SDI 1.0, having identified best practices for developing standards-based SDIs and having played active roles in the OGC.

The OGC Architecture Working Group could take responsibility for documenting and reviewing the standards baseline for SDI 1.0. The formal vetting of the SDI 1.0 framework would occur in the OGC Architecture Board (OAB), a key OGC committee responsible for enforcing consistency and ensuring proper life cycle management of the OGC standards baseline. Life cycle management rigor will ensure that SDI 1.0 is coordinated effectively and that revisions are carefully considered and documented.

Conclusions

SDIs are becoming a major resource for access to geospatial data and services. Partnerships between the public and private sectors are paying off in higher returns on investment. Perhaps even more importantly, SDIs are contributing to sound decision making, enhanced e-government applications, and better services and are poised to take the next step in their evolution: SDI networks. SDI networks are necessary for emergency preparedness and response, counterterrorism, monitoring of and response to pandemics, and environmental protection. In order for these transnational applications to be effective, SDIs (or SDI zones) must interoperate. The interoperability can be achieved only through consistent and structured implementation of interface and encoding standards. This article proposes a suite of standards for all SDIs.

We recommend that the concept of an SDI standards suite be considered by the global SDI community as an important work item. OGC members agree that SDIs need a well-defined and -managed suite of standards. We therefore propose that the OGC take formal responsibility for providing life cycle management and documentation of the suite and that the global SDI community take responsibility for defining the actual standards.

References

Federal Geographic Data Committee, http://www.fgdc.gov/

Java Community Process http://jcp.org

NGA 2005: NGA Announces Requirement for OGC and Complementary Standards, NGA, 2005, http://www.nga.mil/NGASiteContent/StaticFiles/OCR/nga0518.pdf

National Aeronautical and Space Agency (NASA), Geospatial Interoperability Office, 2005: Geospatial Interoperability Return on Investment Study. Study performed by Booz, Allen, and Hamilton.

Nebert, Douglas, 2004. Developing Spatial Data Infrastructures: The SDI Cookbook. GSDI, 2004, www.gsdi.org/docs2004/Cookbook/cookbookV2.0.pdf

Moore 1965: Gordon E. Moore’s Law, Electronics Magazine, 19 April 1965, http://en.wikipedia.org/wiki/Moore's_law

Refractions 2006. Personal correspondence with Paul Ramsey. Refractions has developed a Google based application for “crawling” the web looking for instances of WMS and WFS enabled servers.

Appendix A

Requirements for SDI Best Practice Implementations

As designated by the Global Spatial Data Infrastructure Association

To be designated as a SDI Best Practice Implementation by the Global Spatial Data Infrastructure Association and have the right to use the designation, an implementation must:

1. meet minimum interoperability requirements by implementing and adhering to a set of core standards of any annually issued Recommended Minimum Software Standards Suite for Spatial Data Infrastructure by the GSDI Association as set forth under section I below, and
2. meet minimum accessibility requirements by implementing and adhering to the Spatial Data Infrastructure Minimum Accessibility Requirements as set forth under section II below.

I. Recommended Minimum Software Standards Suites for Spatial Data Infrastructure (issued annually as needed)

A. 2008 Recommended Minimum Software Standards Suite for Spatial Data Infrastructure (SDI-REMSSS 2008)

Software Products: A single software product may meet the standards in one or more of the three categories of standards listed in Table 1 at the end of this document. By example, a single software product might meet both the requirements of OGC WMS 1.1.1 and OGC WMS 1.3. Many software products that support a recent standard will also support previous versions of the same standard.

Implementations: For a Spatial Data Infrastructure implementation to be designated by the GSDI Association as a SDI Best Practice Implementation, it must support at a minimum the core standards listed below. These core standards listed have been shown to interoperate effectively in numerous implementations. The implementation may additionally support supplemental standards and future candidate core standards as shown in Table 1 as well as other standards not listed but these are not required to gain designation as an SDI Best Practice Implementation.

SDI-REMSSS 2008 Core Standards

OGC Web Map Service 1.1.1

OGC Web Feature Service 1.0

OGC Filter Encoding 1.1 (used in conjunction with WFS)

OGC Geography Markup Language 3.1.1

Plus

OGC Catalogue Service 2.0 HTTP protocol binding, CS-W and

OpenGIS Catalogue Services Specification 2.0.2 - ISO Metadata Application Profile (1.0.0) (Note: supports ISO Metadata Standard 19115:2003 and ISO DTS 19139:2006)

Or

OGC Catalogue Service 2.0 Z39.50 protocol binding and

FGDC Content Standard for Digital Geospatial Metadata (CSDGM, 1998)

Thus, to be designated as a SDI Best Practice Implementation under the 2008 standards, the implementation must offer at a minimum a web map service, a web feature service and a catalogue service for significant proportions of its data holdings meeting the listed core standards.

II. Spatial Data Infrastructure Minimum Accessibility Requirements (issued annually as needed)

Implementations: For a Spatial Data Infrastructure implementation to be designated by the GSDI Association as a SDI Best Practice Implementation, it must support at a minimum the GEOSS Data Sharing Principles for its web map service, web feature service and catalogue service as applied to significant proportions of the SDI’s data holdings. For the latest version of the principles, consult http://xxx.xxx

Further, the GSDI Association highly recommends and encourages adherence to the GEOSS Data Sharing Principles for all SDI holdings with appropriate exceptions as noted in the principles.

III. Applying for Designation as a SDI Best Practice Implementation

SDI implementations are assessed for designation as a SDI Best Practice Implementation through information provided by an appropriate organization representative to the GIK Network. Based on the information provided, a review team will approve or disapprove the designation and may investigate the matter further. The team will NOT at this time pursue a formal Compliance Testing Program. Those SDI’s approved as meeting the minimum requirements for a SDI Best Practice Implementation will be so designated on the GIK Network web site and the SDI hosts will be allowed and encouraged to use the designation on their own web sites.

∗ Abbreviations are as specified at http://www.opengeospatial.org/resource/products

2009 Recommended Minimum Software Standards Suite for Spatial Data Infrastructure (REMSSS-SDI 2009)
SDI Core Standards	OGC Abbreviation for Standard*
Web Map Server interface (ISO 19128:2005), OGC Web Map Service, Version 1.3	WMS
Web Feature Service (ISO DIS 19142), OGC Web Feature Service, Version 1.1 or OGC Web Feature Service (Transactional)	WFS or WFS(T)
Filter encoding (ISO DIS 19143), OGC Filter Encoding, Version 1.1 (used in conjunction with WFS)	Filter
Geography Markup Language (ISO 19136:2007), OGC Geography Markup Language Version, 3.2.1	GML
OGC KML, Version 2.2	KML
OGC Web Coverage Service, 1.1.2	WCS
plus
OGC Catalogue Service, Version 2.0.2 HTTP protocol binding, CS-W and	CAT CSW
OpenGIS Catalogue Services Specification 2.0.2 - ISO Metadata Application Profile (1.0.0) (Note: supports ISO Metadata Standard 19115:2003 and ISO DTS 19139:2006)	CAT2 ISO AP
or
OGC Catalogue Service, Version 2.0 Z39.50 protocol binding (GEO Profile) and	CAT Z3950
OpenGIS Catalogue Services Specification 2.0.1 - FGDC Application Profile supporting FGDC Content Standard for Digital Geospatial Metadata (CSDGM, 1998)	FGDC AP
SDI-REMSSS 2009 Supplemental Standards
OGC Styled Layer Descriptor, Version 1.0	SLD
OGC Web Map Context, Version 1.1	WMC
OpenGIS Sensor Model Language, Version 1.0.0	SensorML
OpenGIS Sensor Observation Service, Version 1.0.0	SOS