Start GeoSurf Start FTP
     

Home

How To Download

First Time User

Available Data

Current Status

FAQ's

On-Line Mapping

Partners

About the UASL

New Features

Contact

CAST Home

Center for Advanced Spatial Technologies

About UASL: History | In the News | Design & Architecture

The UASL Project is currently in development. Information on these pages will be updated accordingly. If you have any questions or comments please email Bob Harris boss@cast.uark.edu

Design and Architecture V 1.5

Executive Summary

UASL Enterprise Architecture

UASL Architectural Design

Design and Operational Considerations available in a zipped pdf document for printing. (1.2 mb, approx. 3 min download on 56 k)

 

Need for a Publicly Accessible Spatial Data Warehouse

Access to comprehensive, accurate, and timely geospatial information has become an essential component of state and local governments, university researchers and students, private business and K12. It has become critical that multiple data sets from a wide range of different sources be quickly accessible as a central, coordinated resource while maintaining individual control and needed security. Since the events of September 11, a particularly pressing need is to provide rapid and accurate access to facility and transportation information to those responsible for public safety and emergency response. A wide range of sources provides data for these groups. An effective spatial data warehouse (SDW) should provide a transparent and easy-to-use mechanism for "data producing" groups to provide current data while providing the information to consuming units. In addition, rather than serving as a simple warehouse of data, an effective SDW will provide an "active" back-end to support a wide range of end-user applications. In addition to serving as a data "store" for many data sets the system should also serve (using interoperability) as a "virtual" source of geo-data that may reside in other locations. Because many geospatial applications utilize the same, enterprise data, they can be developed more rapidly with less duplication.

Spatial Data Warehouse Architecture

In the past, centralized warehouses of geospatial data were composed of collected files of geographic (map) data. Those wishing to use the data downloaded the files to their local computer and performed needed analyses. While such systems have increased the accessibility of data they have a number of limitations. File based data requires that users download an entire file and extract selected data even when they only need a limited amount of data. Frequently the area of interest is at the boundary of one or more files, so that multiple files are downloaded. A second limitation of these systems is that the data are provided in a predefined format with respect to the particular software format (e.g. vendor) and map projection and datum. Map projections and datums are technical characteristics of mapping data and different users have different requirements. As a result, it is necessary to either insist that all data providers utilize similar specifications or convert the data provided. Requiring a one-size-fits-all approach has repeatedly proven to be ineffective as different data providers have different technical requirements - and these requirements limit accessibility. On the other hand, conversions by the end-user places substantial, and unneeded technical demands on that group. More significant, however, is that the timeliness of a file-based system is difficult to maintain. Changes to any single feature in a file-based system require that the entire file be replaced. As an example, suppose that a transportation agency closes a bridge. The change will not be reflected in the statewide system until a completely new file is provided and added to the system. If (for example) emergency responders are accessing the data from the file based system they will be unaware of the closed bridge until the file has been updated. Additional limitations to these file based systems revolve around the difficulties they represent for multi-user access with differing levels of security control and similar well-known, basic multi-user information technology related issues.

Using a Spatially Enabled Data Base Management Structure

A new approach using a robust spatially-enabled multi-user database system provides a solution to these problems. In the spatially enabled Database Management System (DBMS) each geographic feature (a bridge, a road segment, a building, etc.) is a single record in an object-relational data structure. Because each feature is an individual record it is only necessary to change the affected records to affect an update. This is much more efficient than older, file-based systems in which an entire file must be updated, even if only a single feature changes. The spatially enabled DBMS approach also views the data warehouse as a core, enterprise-level information technology system -- allowing multi-agency dynamic update access as well as strong multi-user security. Such a system is the only effective way to support these multiple objectives. Initial costs for a database system will typically be larger than the initial costs for a file-based system but long-term costs are less, particularly when objectives such as multi-agency update and analysis are considered and when the system is integrated into the larger view of IT architecture. The DBMS based approach is also much more scalable. DBMS based systems also support multiple client applications so that the same initial investment can be amortized over multiple agencies and applications. Because of the very robust security capabilities of these DBMS based systems it is possible to provide variable levels of access. This means that the same data system can be used for both secure and public purposes. This dual-use potential means that the same core data can be used and this reduces the potential that multiple systems can become out-of-sync and also allows the core operational investment to be distributed over a larger user base.

Data Providing Coordination, Update, and Access

The spatially enabled DBMS structure provides the infrastructure that allows multiple data providers to locally maintain their own internal information while electronically updating the enterprise system. In this architecture software "triggers" can be installed in an individual agency system that will automatically post updates/changes to the enterprise system as they are made. In the case of the bridge closing, for example, as soon as the transportation agency makes this change in their local information it will be posted to the enterprise system, meaning that any agency accessing the enterprise system will have the most current data. Such an approach also allows the option to dynamically link multiple systems together using the interoperable standards developed by the Open GIS Consortium.

Moving to the Object-Relational "Geo-Database" System

It is important to specify that the SDW approach does not require that all geographic data reside on a single computer or in a single database. Use of the growing suite of OpenGIS Consortium (OGC) interoperability specifications permits multiple systems to interact effectively. That said, however, for effective interoperability it is necessary to develop interoperable data models and institutional rules that allow the movement and integration of data from different sources. This process can be substantially facilitated through some initial level of centralization of core data in a SDW. A very effective approach is the development of a comprehensive (but not exhaustive) SDW. A key aspect of this activity is the initial effort needed to achieve key data model specifications. Once this is achieved then the actual data may physically reside in a single SDW or may be distributed in interoperable systems and provided to the user as a "virtual" SDW. Substantial effort is underway in a number of arenas towards the development of interoperable data models. For example Arkansas GIS users community is currently reviewing the Spatial Data Standards for Facilities, Infrastructure and Environment (SDSFIE) SDSFIE (http://tsc.wes.army.mil/products/TSSDS-TSFMS/tssds/html/) to determine if these models or similar ones (e.g. http://arconline.esri.com/arconline/datamodels.cfm) may be adopted.

 

UASL Design and Operational Considerations
April 12, 2002

By
Douglas Meredith, Deborah Harmon, John Wilson, Robert Harris, James Sullins
and W. Fredrick Limp

Center for Advanced Spatial Technologies
University of Arkansas, Fayetteville

Center for Advanced Spatial Technologies
University of Arkansas
Ozark Hall, Room 12 Fayetteville AR 72701
Phone: (479)575-6159 | Fax: (479)575-5218 | Email: info@cast.uark.edu