GeoWorld Issue Date: May – 2006, Posted On: 5/1/2006
GML DEVELOPMENT-What Exactly Is a Spatial Data Infrastructure?
By Ron Lake, Chairman and CEO, Galdos Systems Inc.; e-mail: rlakegaldosinccom.
Although the ambition and name of a spatial data infrastructure (SDI) have been around for a long time, only recently have standards and technologies actually enabled a true SDI to be built. As a result, it’s important to revisit existing notions of SDI and understand where this technology may be headed in the near future. The rationale for an SDI is old and well founded. The world around us is a unified one – it’s not divided into the arbitrary administrative units seen on maps. It doesn’t know about private- or public-sector jurisdictions over such things as transportation, water, weather, oceanography, or urban development. The problems people face are likewise unified, and dealing with them requires information from many sectors and jurisdictions. Most countries have national SDI programs, and many have had such programs for more than 20 years. This might seem curious given that there are few, if any, such operational systems.
Realizing the Dream
Recently, however, the dream of SDI has begun to move from abstract concept to operational reality, and people can begin to look forward to local, national and global SDIs in the near future. However, these may turn out to be rather different than the early ideas and concepts. Most early SDI concepts centered on some notion of a data catalog. Because there were few, if any, reliable data networks with adequate bandwidth, the early SDIs were little more than catalogs of datasets. Later versions enhanced this by providing the ability to order data electronically and, in some cases, download them to a user’s site via FTP or other forms of file transfer.
Advent of Standards
The advent of open standards such as Geography Markup Language (GML), Web Feature Service (WFS) and Web Registry Service (WRS) are beginning to change the way people look at SDI. WRS, a profile of the Open Geospatial Consortium (OGC) Catalog 2.0 Specification that’s based, in part, on the OASIS e-business information model (ebRIM) specification, is one of the key standards. It enables the deployment of conventional dataset catalogs (like the old SDI) using metadata schemas such as FGDC, ISO 19115 or 19139, or a custom schema. WRS also can be readily deployed as a service catalog using service offers modeled by OGC Capabilities or Web Service Description Language documents as well as metadata schemas from ISO 19119. The power of a WRS, however, is much greater. Unlike conventional data catalogs, a WRS can be readily extended to manage a wide range of artifacts that are essential to deploying a modern SDI. Such artifacts include quality-assurance policies, dataset/image descriptions, subscription policies, coordinate reference systems, application schemas, units-of-measure definitions, service offers, access-control policies, map styles, symbol libraries and others. Moreover, a WRS is capable of managing this diversity of objects and relating them to one another. Users and (increasingly) machines can look for datasets and rapidly locate services that access data or are suited for data processing. The workhorse of an SDI, however, is the WFS. Although many see this as a means of moving data from spatial databases to user-oriented clients, this is a less likely role in an SDI than it is in moving data from one database to another. This is especially true as an increasing number of data creation, decision-support, dispatch and planning applications are database-centric.
Moving spatial data from one jurisdiction to another isn’t a straightforward matter. A water company may have the authority to capture the location of water mains, but it isn’t responsible for changes to a parcel boundary or road centerline, even if it determines that these are in the wrong place. Other organizations, such as the road administration or municipal authority, have jurisdiction over such data. But the valuable observation made by the water survey crew should be saved. Such a transfer is made more complex by the fact that an SDI integrates existing applications in administrative organizations with their own data models or vocabularies of “real-world” entities. One person’s parcel isn’t another’s, while one person’s road may be another’s street. Furthermore, integrating data from multiple sources often reveals significant errors that may be absolute or relative in nature. Error detection and, in some cases, correction is required. Security issues also are critical to any operational SDI, so open standards are vital. These enable the sharing and wide-area management of policies for access control, something that’s essential for an open and extensible SDI community.
For many people, SDIs are associated with a portal. Although portals are important in providing presentation services, they are of more importance to SDI administrators than users. Although there are users who want to “look” for data and services, most real applications are based on known data sources, and the “library” view of SDI isn’t that important. Therefore, although map-viewing and discovery clients are necessary components, their existence is hardly sufficient to create an SDI. The collection of such portal components (clients) would leave the largest part of the data access and integration task in the hands of users, and this isn’t a good way forward. One could say the same thing in relation to Web Map Service (WMS) components with client-map-viewing portal components. Although they provide useful exploration tools, they may play only a small role in an operational SDI. Of greater importance is a WMS variant called a Feature Portrayal Service (FPS). Unlike a WMS, an FPS doesn’t have any data of its own. It’s a processing service that responds to WMS map requests by issuing data requests to one or more WFSs and applying styling rules to the returned GML data. A graphical visualization then is displayed in a conventional Web browser or in clients such as Google Earth or NASA World Wind.
An FPS can serve a useful function as a quality-assurance and inspection tool by rapidly generating map visualizations for data from one or more of the SDI’s WFS constituents. An SDI provides universal data discovery and access, but, more importantly, it strives for transparent, policy-driven integration of spatial databases and related applications. When it works, no one but SDI administrators will know it’s there. This picture may be different from the one expected, but it’s consistent with the need, long-ago expressed, of transparent access to an integrated view of the world.