Even the more sophisticated browsers such as Mosaic do not provide datasets to users in a form suitable to further analysis or explorations. WAIS adds capabilities for spatial query and basic geoprocessing (clip, select, etc), though at the expense of multi-media capabilities. In all cases, the information presented to users is in the form originally created by the data developer. For geographic information, this means coverages in a particular data structure (eg, Arc/Info, GRASS, Genamap, etc). More importantly for effective use, it means the data dictionary describing the content of the coverage, the attributes assigned to specific features, and the catalog of attribute definitions are all determined by the data provider.
Full disclosure of data structure types and attributes is a necessary component of information understanding, but it is insufficient for purposes of detailed analysis, using the tools the user may have at hand, without significant processing of the data into a common, canonical form. Moreover, a priori knowledge of data structure and content does not support dataset integration or provide the mechanisms for cross-comparison of divergent types. That is, information collected in response to a specific query may be too diverse to allow direct comparison without significant post-processing.
Example: A query for information about landcover within the drainages of Lake Tahoe could result in a vegetation polygon coverage using the Anderson land classification, a classified Thematic Mapper image derived from bands 1,2, and 4, and a stream network with gage observations at a set of latitude/longitude points. Associating specific landcover types with observed spectral response, and extrapolating those associations to other areas for comparison with stream flow, would require the user to convert all three datasets to a common format and implement a common schema covering all three datafiles.
The following objectives must be realized for this goal to be achieved:
The end product will be a set of tools and procedures that utilizes the protocols and technology of the Open GIS Interoperability Specification (OGIS) to advance the functionality of CERES. Specifically, this effort will create an OGIS environment for CERES -- a somewhat more detailed statement of the specification that focusses on the data cataloguing, modeling, and presentation requirements of CERES. Within this environment, will be constructed a series of locales that provide the substantive functionality needed within each of the CERES bioregions.
The basic premise of the CERES environment architecture is that of a gateway. That is, the system provides generic high level query service support to any authorized client, whether custom-designed for CERES or simply a Universal Resource Locator in WWW format. At the same time, it acts as a client with respect to private data stores, importing and transforming data from various sources into a well-known data model.
Effective searching requires a systematically derived metadata catalog. This will be best accomplished by establishing a CERES schema, based on FGDC guidelines, that provides an overall structure to metadata collection and organization. Then, for each bioregion, locale-specific data dictionaries will be layered on top of the schema that reflect the information requirements of users within the region.
For example, the CERES schema might specify that a land-cover map include designations to at least Anderson level 2 or 3, while the Klamath data dictionary specifies how forest canopy closure will be measured and documented.
Search tools, such as WAIS, can then query the metadata in a general way, and special purpose search clients can, using the same protocols, conduct more focussed searches based on specific attributes, spatial datatypes, availability, data quality, and so on.
Support for metadata (ie attribute) integration within a region is then relatively straightforward through the use of a inheritance-based (hierarchical) master catalog of thematic elements and features. Integration accross regions, ie. for statewide analysis, is a much more complex problem, requiring schema merger tools for combining disparate data. Such tools must allow the user to maintain rich information content without degradation of data to the lowest common denominator.
The value of metadata searching and cataloguing, and attribute integration, is only realized when the referenced geospatial data can be effectively combined into a common data model. The Open GIS Foundation's OGIS Project is addressing in detail the requirements and specifications for spatiotemporal data processing and the construction of protocols for rendering private data stores into a common framework. Using this as a base, a CERES environment may be designed which identifies the particular ways spatial objects may be assembled and how they relate to metadata and non-spatial attributes.
For example, OGIS identifies generic abstract data types for points, lines, polygons, volumes, and multi-dimensional grids. These are subtyped down to very specific types, such as x,y coordinate chains sequentially oriented to form a ring with an areal identifier. The CERES environment would constitute a class library of geospatial objects - such as geographic features, base maps, or monitoring records - that used the OGIS types as their spatiotemporal component.
A viewer is necessary to render CERES-modeled information in a way that supports meaningful query and analysis. In other words, simple graphics display is insufficient. Instead, CERES should undertake construction of a simple, easily distributed map reader that has visualization and query capabilities, perhaps with limited geoprocessing functionality. Note that to the extent CERES is OGIS-based, a broad range of commercial software will become available in the next few years which will provide similar functionality, albeit exclusive of built-in knowledge of the CERES schema and locale data dictionaries.
Access to private data stores requires construction of special purpose routines to model data in the CERES framework. Initially, these can be prototyped using macros running on data servers, but these should be reimplemented using providers' APIs (application programming interfaces). Ultimately, as GIS developers move toward a DBMS-like client-server design, network-based information brokers can pass queries and results among multiple hosts, independent of underlying formats and systems.
The success of CERES will largely depend on the degree to which data providers at the state, county, and local levels adhere to common schema guidelines. There is a unique opportunity over the next two years to leverage ongoing spatial data standards efforts into shared high-level abstractions of diverse, heterogeneous geodata. That is, as organizations begin to adopt SDTS for archiving and transferring information, they will find it necessary to be more rigorous and systematic about specifying spatial data content, georeference, lineage and quality, synoptic metadata, and so on. As system developers gradually transition to the use of SQL3 and the spatial (multi-media) extensions, tools for client-server access to private data stores will be considerably enhanced. As major governmental and commercial data providers and value-adders begin to support OGIS-based access into their repositories, the accessability of diverse information to CERES users will grow.