1Kentucky Geological Survey
228 Mining and Mineral Resources Bldg.
University of Kentucky
Lexington, KY 40506
Telephone: (859) 257-5500
Fax: (859) 257-1147
e-mail: jerryw@kgs.mm.uky.edu
2Indiana Geological Survey
611 North Walnut Grove
Bloomington, IN 47405
Telephone: (812) 855-7636
Fax: (812) 855-2862
e-mail: neaton@indiana.edu
3Kansas Geological Survey
1930 Constant Ave.
Lawrence, KS 66047
Telephone: (785) 864-3965
Fax: (785) 864-5317
e-mail: nelson@kgs.ku.edu
|
Figure 1. Categories and types of geographic databases used for the MIDCARB ArcIMS project. |
Tabular databases from the participating organizations currently use either Oracle or SQLServer relational database management systems (RDBMS). Environmental Systems Research Institute's (ESRI) Spatial Database Engine (ArcSDE) software was chosen so that the spatial data sets could also be managed in an RDBMS. ArcSDE software is installed on each state survey's RDBMS and acts as an interface between GIS software and the underlying relational database (e.g., Oracle). SDE allows GIS data to be managed by a traditional enterprise-scale relational database and manages requests for information from a variety of ESRI applications, including ArcMap, ArcCatalog, and ArcIMS. Staff of the project elected to use this software solution because each of the organizations was using some or all of the ESRI products and because of ESRI's diverse off-the-shelf application support. ArcIMS was chosen as the platform for integrating all the distributed information in a single Web application. Figure 2 shows the logical architecture for the MIDCARB data integration system.
|
Figure 2. Architecture of the MIDCARB distributed database system. Gray objects show existing configuration that uses a Web browser to interact with the data through ArcIMS. White objects show alternative data pathways where ESRI clients (e.g., ArcView or ArcExplorer) could access spatial data directly from an SDE database. |
The KYGS maintains numerous large spatial data sets that cover a diverse spectrum of natural resource themes. These include general-purpose GIS data, such as base maps and geologic maps, as well as specialized themes such as the carbon-sequestration layers developed specifically for the MIDCARB project. The KYGS decided to maintain all its spatial data in a single ArcSDE database, using sub-tables for organizing the data thematically, rather than creating separate ArcSDE databases (Figure 3). This approach alleviated the necessity for users to make the many database connections required by a multiple database scenario. Data layers were prepared in a single coordinate system and datum (NAD83, decimal degrees) to simplify data integration. All data were added to ArcSDE as simple, unregistered feature classes--no complex geodatabase functionality, such as feature editing, custom object behaviors, or versioning, has yet been enabled.
|
Figure 3. Configuration of the Kentucky ArcSDE database, showing feature-class naming scheme. Thematic tables represent the sub-databases within ArcSDE. Theme names are formatted to easily identify feature classes and their characteristics within an application's database connection dialog (e.g., ArcView). |
The KYGS point databases (oil, gas, coal, and water well/sample locations) that are maintained in a relational database as tabular datasets were spatially enabled by adding their location and basic descriptive information to ArcSDE feature classes. This greatly simplifies the task of using these data in mapping applications (e.g., eliminating the need to add data files to ArcView for event theme creation). Attribute data for well locations are still managed by the relational database system; however, updating location information is more problematic. At the present time, there is no convenient procedure to update ArcSDE locations that are maintained in a relational table. The best solution would probably be to manage location information in ArcSDE and create a method for updating the coordinate attributes stored in the relational database.
Using a single ArcSDE database presents logistical challenges for user access. The large number of ArcSDE themes listed in ÒAdd ThemeÓ dialogs (e.g., in ArcView) can confuse the user. One solution to this problem is to manage groups of feature classes with permissions. For example, all coal (and some related) themes could be made accessible only to a default ÒcoalÓ user. Such users would not see other unrelated feature classes. KYGS implemented a table-naming scheme as an alternative solution to this problem. Thematic groupings are added to ArcSDE tables named with a four-character code (e.g., COAL, GEOL). Feature classes within the groups are named with a two-letter state prefix, followed by a three-character scale integer, and then a meaningful theme name (Figure 3). This format results in a connection list that is sorted first by theme type, and then by data scale and name, with each designation nearly in vertical alignment. Most relational databases limit such table names to approximately 32 characters.
Another challenge for managing ArcSDE data relates to the potentially large size of statewide databases. For example, the KYGS 1:24,000-scale geologic map database, when complete, will comprise 707 detailed vector data sets that have been edge matched and joined into statewide feature themes. Although ArcSDE does support spatial queries using tiling methods, they will not be effective with such databases because many of the merged features can cover as much as 30 percent of the state. ArcSDE's tile methods return all features that touch the tiles within the current view extent. The KYGS staff decided to pre-intersect these complex feature classes with commonly queried geographic extents (i.e., county and quadrangle outlines). This not only facilitates faster queries, but simplifies the process of preparing finished map layouts by eliminating the need for clipping for common map extents.
Finally, most of the current MIDCARB feature themes are relatively simple--point locations and simple geographic outlines. Serving complex and large spatial databases from distributed locations will require extensive testing for efficiency and development of methods for filtering the data that are returned to the user.
Example 1. Example workspace reference in ArcIMS AXL file used to specify a connection to a remote data server.
<WORKSPACES>
<SDEWORKSPACE name="sde_ws-48"
server="kgsdata" instance="port:5151" database=""
user="jerryw_sde" encrypted="true" password="PKOTJKSWGTKNGMKR"
geoindexdir="c:\tmp\" />
</WORKSPACES>
Example 2. Example dataset reference in ArcIMS AXL file used to specify specific feature layer from a remote database connection.
<DATASET name="SEQUESTER.DBO.IB_500_SPRINGFIELD_COAL_OVR" type="polygon" workspace="sde_ws-48" />
It is transparent to the user, both from a design and efficiency perspective, that map layers are being loaded from more than one location. All data layers relevant to the five-state area are viewable from a single ArcIMS page. Figure 4 shows an example of a custom map view that integrates Illinois and Indiana oil and gas fields. Users control the themes to be displayed by activating layers in the ArcIMS Web page table of contents. The amount of data returned to the Web page from the various servers also can be limited by use of the zoom function, which uses ArcSDE's database tiling capabilities. All themes can be queried for attribute information using tools provided in the standard template. Because of the large number of themes provided in the MIDCARB map service, the standard table of contents required customization to clarify and simplify the user legend.
Figure 4. Example view of the MIDCARB ArcIMS site, showing oil and gas fields accessed from the Illinois and Indiana ArcSDE databases. |
|
Figure 5. ArcIMS legend customization. A. Subject categories (Select Map Layers) provide hyperlinks to respective parts of the legend. Clicking on CO2 Sources results in scrolling to that part of legend. B. Active feature classes (checked items in legend) expand to custom explanations that are inserted as GIF images. |
Figure 6. Data pathways for a typical tabular data request. 1. A data request is sent from the Web browser to the ArcIMS server that passes it to the ColdFusion Server. 2. The ColdFusion server sends a formatted SQL request to the appropriate databases. 3. The RDBMS returns the requested data to ColdFusion. 4. The ColdFusion Server prepares a formatted HTML report and returns it to the user's browser. 5. For some requests, data are transferred to a JAVA program that prepares a formatted graph and returns it to the browser. |
The number of potential themes available to MIDCARB users is large and continues to grow. Much work needs to be done to simplify the user interface so that only desired themes are shown. This simplification could be accomplished with a query interface to collect information from users about what they want to see. The results of each query would be used to construct a customized view of the MIDCARB data.
The current implementation of the MIDCARB ArcIMS service uses version 3.1 software. New capabilities for accessing metadata from an ArcSDE database will greatly enhance the functionality of the service when version 4.0 is implemented.
The technological challenges for implementing a distributed data site are considerable, but the greatest challenge is designing an interface that clearly communicates the function of the site and how to use it.