The use of Oracle Spatial and ArcSDE for

geodatabase access

Doru I. Pacurari

Problem Report submitted to the College of

Engineering and Mineral Resources
at West Virginia University
in partial fulfillment of the requirements
for the degree of
Master of Science
in
Computer Science

Dr. Frances L. Van Scoy, LDCSEE, Chair

Dr. John M. Atkins, LDCSEE
Dr. Trevor Harris, Dept. of Geography
Morgantown, West Virginia
2002

Keywords: Oracle Spatial, ArcSDE, GIS, databases

ABSTRACT

The use of Oracle Spatial and ArcSDE for geodatabase access

Doru I. Pacurari
The ability to store and manage spatial data inside Oracle 8i Enterprise Edition,
combined with Environmental Systems Research Institute (ESRI) newest generation of
GIS software, sets the foundation for what is one of the most remarkable and far-reaching
impacts in information technology.
The overall objective of this project was to demonstrate the storage of a
geodatabase in an Oracle 8i database using Oracle Spatial and make it available to the
full range of ArcGIS software, namely to create a multi-user GIS.
Oracle Spatial provides an SQL schema and functions that facilitate the storage,
retrieval, update, and query of collections of spatial features in an Oracle 8i database. For
our project, Oracle Spatial was used to store the spatial data in the Oracle 8i database,
using an Object-Relational model.
ArcSDE was used as a GIS gateway for the data stored in the Oracle 8i database.
ArcSDE was used to access and manage the GIS data stored in the geodatabase, and it
mainly served as an application server that delivered spatial data to many users and
applications. ArcSDE was defined as an open interface to the database systems, and it
allowed the ArcGIS system to manage the information stored in the Oracle 8i Enterprise
Edition database.
The project consisted in creating a Oracle 8i geodatabase with data of Monongalia
County, WV, and then establishing multi-user access to the data in the Oracle 8i database
using ArcSDE as middleware. Implementing the geodatabase with the ArcSDE
application server allowed providing access to multiple users for both query and update
(read/write) of the geographic data. ArcSDE and ArcInfo support for long transactions
through versioning allowed the users to simultaneously create multiple, persistent
representations of the database without data replication. Since all the change are recorded
in the delta tables, the users can edit the same features or rows without explicitly applying
locks to prohibit other users from modifying the same data.

ACKNOWLEDGEMENTS
First, I would like to thank God for guidance, wisdom and strength.
I would like to express my gratitude to my committee members, Trevor Harris, PhD.,
John M. Atkins, PhD., and my Committee Chair, Frances L. VanScoy, PhD., for their
support and assistance.
I would especially like to thank Dr. VanScoy for her guidance and reviews, and Dr.
Harris for allowing me to work in the Department of Geography.
Additionally, I would like to thank to all my friends from the Department of Geography:
Jesse, Sue and Jackie, and to all my friends from the Virtual Environments Lab. A special
thank to Vic Baker, who allowed me to work long hours out of the VE Lab during the
project completion.
Last, but not least, I want to thank my wife, Maria, and my daughter, Paula, for their love
and support during the long hours of working on this project.

iii

GLOSSARY OF ACRONYMS

API
ArcCatalog
ArcIMS
ArcMap
ArcSDE
ArcSTORM
ArcToolbox
ArcView GIS
Cadaster
COM
DBA
DEM
ERDAS
ESRI
FGDC
GIS
Map LIBRARIAN
MapObjects
MBR
Middleware

NAD27
NSDI
OLTP
OpenGIS

Application Programming Interface

Spatial data browser application in the ArcGIS system
Application for creating, designing and managing Web sites with
GIS capabilities
Spatial data display, editing, query, and analysis application in the
ArcGIS system
Arc Spatial Database Engine, the gateway to a multi-user
commercial DBMS
Arc Storage Manager, a data storage facility and transaction
manager for ArcInfo based coverage data
Application that provides access to all of ArcInfos coverage
processing and analysis functions
Easy-to-use desktop GIS for exploring, analyzing and querying
geographic data
A public record, survey, or map of the value, extent, and
ownership of land as a basis of taxation
Component Object Model
Database Administrator
Digital Elevation Model
Earth Resources Data Analysis System
Environmental Systems Research Institute
Federal Geographic Data Committee
Geographic Information Systems
A set of software tools to manage and access large geographic
datasets in a map library
A collection of software building blocks that can be used by
developers to create GIS applications
Minimum Bounding Rectangle
Program that serves to "glue together" or mediate between two
separate and usually already existing programs. A common
application of middleware is to allow programs written for access
to a particular database to access other databases.
North American Datum 1927
National Spatial Data Infrastructure
Online Transaction Processing
Open Geodata Interoperability Specification, provides a baseline
for accessing and using distributed geodata. It comprises an
architectural framework supporting data modeling and application
programming, a detailed specification document, a consensusbased process for developer and user community involvement, and
a series of testbeds for prototyping and testing. The model is based
iv

RAID
RDBMS
SGA
SQL

TCP/IP
TIFF
TIN

UTM

on distributed object technology, and supports a wide range of

applications, datastores, and services.
Redundant Array of Inexpensive Disks
Relational Database Management System
System Global Area, which are memory structures that store the
most recently queried data from the database
Structured Query Language. A syntax for defining and
manipulating data from a relational database, it has become the
industry standard for query languages in most RDBMS, i.e. Oracle
Transmission Control Protocol/Internet Protocol
Tagged Image File Format. A widely used format for storing
image data
Triangulated Irregular networks, which are a specific type of
unstructured grid which are made up of layers of nodes and
triangles
Universal Transverse Mercator

TABLE OF CONTENTS
ABSTRACT ...................................................................................................................... II
ACKNOWLEDGEMENTS........................................................................................... III
GLOSSARY OF ACRONYMS......................................................................................IV
TABLE OF CONTENTS................................................................................................VI
TABLE OF FIGURES ..................................................................................................... X
1.

INTRODUCTION..................................................................................................... 1
1.1
1.2

2.

PROJECT OBJECTIVES ........................................................................................... 4

PROJECT TIMELINE ............................................................................................... 7

OVERVIEW OF ORACLE SPATIAL ................................................................... 8

2.1
OBJECT-RELATIONAL AND RELATIONAL MODELS CHARACTERISTICS ................. 8
2.1.1
The Object-Relational Model ...................................................................... 9
2.1.1.1 SDO_GTYPE .......................................................................................... 9
2.1.1.2 SDO_SRID............................................................................................ 10
2.1.1.3 SDO_POINT ......................................................................................... 11
2.1.1.4 SDO_ELEM_INFO............................................................................... 11
2.1.1.5 SDO_ORDINATES .............................................................................. 12
2.1.1.6 Geometry Metadata Structure ............................................................... 13
2.1.2
The Relational Model ................................................................................ 14
2.2
BENEFITS OF THE OBJECT-RELATIONAL AND RELATIONAL MODELS .................. 14
2.2.1
Benefits of the Object-Relational Model ................................................... 14
2.2.2
Benefits of the Relational Model ............................................................... 15
2.3
INTRODUCTION TO SPATIAL DATA ..................................................................... 15
2.4
GEOMETRIC TYPES FOR THE OBJECT-RELATIONAL MODEL ............................... 16
2.5
THE SPATIAL DATA MODEL ............................................................................... 18
2.6
THE QUERY MODEL ........................................................................................... 19
2.7
INDEXING OF SPATIAL DATA .............................................................................. 20
2.7.1
R-tree Indexing.......................................................................................... 22
2.7.2
Quadtree Indexing..................................................................................... 23
2.7.2.1 Tessellation of a Layer During Indexing............................................... 25
2.7.2.2 Fixed Indexing....................................................................................... 26
2.7.2.3 Hybrid Indexing .................................................................................... 28
2.8
SPATIAL RELATIONS AND FILTERING ................................................................. 31
2.8.1
The SDO_RELATE operator..................................................................... 31
2.8.2
The SDO_WITHIN_DISTANCE operator................................................. 33
2.8.3
The SDO_NN operator.............................................................................. 34

3.

ARCSDE GIS GATEWAY FOR THE DATA STORED IN THE RDBMS .. 35

vi

3.1
INTRODUCTION ................................................................................................... 35
3.2
THE APPLICATION SERVER .................................................................................. 36
3.3
BENEFITS OF USING ARCSDE AS GIS GATEWAY FOR THE DATA STORED IN THE
RDBMS......................................................................................................................... 38
3.3.1
Database connection configuration options ............................................. 39
3.3.1.1 The three-tiered architecture ................................................................. 39
3.3.1.2 The two-tiered architecture ................................................................... 40
3.3.2
Spatial data representation ....................................................................... 41
3.3.3
Database portability.................................................................................. 42
3.3.4
Application portability .............................................................................. 42
3.3.5
Data integrity ............................................................................................ 43
3.3.6
Application programming interface .......................................................... 43
3.3.7
Database and application development costs ........................................... 44
3.3.8
Applications and development tools.......................................................... 44
3.4
DATA STORAGE AND DATA ACCESS .................................................................... 44
3.4.1
Data Storage ............................................................................................. 44
3.4.2
Coordinate Reference and Projections ..................................................... 45
3.4.3
Data Access ............................................................................................... 47
4.

GEODATABASES .................................................................................................. 49
4.1
DEFINITION OF GEODATABASES.......................................................................... 49
4.2
DATA STORAGE IN THE GEODATABASE .............................................................. 50
4.2.1
Vector data ................................................................................................ 50
4.2.2
Raster data ................................................................................................ 53
4.2.2.1 Supported raster formats ....................................................................... 55
4.2.3
Other types of data in the geodatabase..................................................... 56
4.2.3.1 Locators................................................................................................. 56
4.2.3.2 Triangulated Irregular networks (TINs)................................................ 56

5.

MULTI-USER GIS ACCESS WITH ORACLE SPATIAL AND ARCSDE..... 58

5.1
INTRODUCTION ................................................................................................... 58
5.2
ORACLE INSTALLATION AND DATABASE CREATION .......................................... 59
5.2.1
The database creation script ..................................................................... 62
5.3
ARCSDE INSTALLATION AND CREATION OF THE SDE USER .............................. 66
5.3.1
ArcSDE installation................................................................................... 66
5.3.2
Creation of the SDE user .......................................................................... 69
5.4
DESIGNING THE GEODATABASE .......................................................................... 71
5.4.1
Feature datasets ........................................................................................ 72
5.4.2
Geometric Networks.................................................................................. 73
5.4.3
Relationship Classes and Feature-linked Annotation............................... 73
5.5
ESTABLISHING CONNECTIONS TO THE GEODATABASE ....................................... 74
5.5.1
Creating and starting the Net8 listener service ........................................ 75
5.5.2
Net8 Client installation and configuration................................................ 78
5.5.3
Connection to the Oracle 8i net service name or to an ArcSDE service .. 79
5.5.3.1 Direct Connecting to the Oracle 8i instance from ArcCatalog ............. 79
5.5.3.2 Connecting to an ArcSDE service from ArcCatalog ............................ 80
5.5.4
Monitoring the connections to the ArcSDE services................................. 82
vii

5.6
LOADING THE DATA THE INITIAL LOAD .......................................................... 83
5.6.1
shp2sde ...................................................................................................... 85
5.6.2
cov2sde ...................................................................................................... 86
5.6.3
Creating and populating raster columns .................................................. 87
5.6.4
Loading Annotation................................................................................... 87
5.7
COMPRESSING THE DATABASE ........................................................................... 87
5.8
LOADING THE DATA APPENDING DATA TO AN EXISTING FEATURE CLASS ...... 89
5.9
TUNING THE APPLICATION ................................................................................. 91
5.9.1
Map Documents and Layer Files .............................................................. 91
5.9.1.1 Scale suppression and overview layers ................................................. 92
5.9.1.2 The right classes in the right map documents ....................................... 93
5.9.1.3 Choosing the right symbology .............................................................. 93
5.9.2
Working with Data .................................................................................... 95
5.9.2.1 Browsing the data.................................................................................. 95
5.9.2.2 Creating metadata.................................................................................. 97
5.9.2.3 Using the edit cache .............................................................................. 98
5.9.2.4 Versioning the data................................................................................ 99
5.9.2.5 Different accounts for different users.................................................... 99
5.10 INDEXING AND QUERYING THE DATA .............................................................. 100
5.10.1
Indexing the tables .................................................................................. 100
5.10.1.1
SDO_TUNE.ESTIMATE_TILING_LEVEL ................................. 101
5.10.1.2
R-tree index creation ....................................................................... 102
5.10.1.3
Quad tree index creation (fixed size) .............................................. 103
5.10.1.4
Using the Oracle Spatial Index Advisor.......................................... 104
5.10.2
Querying the data.................................................................................... 106
5.10.2.1
Query example 1 Determine the areas larger then 150 hectares and
smaller than 200 hectares in the Cass Tax District ............................................. 108
5.10.2.2
Query example 2 - Is the tax parcel selected within 15 km of the
Morgantown Airport?.......................................................................................... 109
5.10.2.3
Query example 3 What are the average slope and the average
elevation of the tax parcel selected for auction? ................................................. 111
5.10.2.4
Query example 4 How is the area of the parcel grouped into
different angle slopes (Using PL/SQL)? ............................................................. 113
5.10.2.5
Query example 5 How is the area of the parcel grouped into
different angle slopes (Using SQL)?................................................................... 115
5.10.2.6
Query example 6 - Are there any roads or rivers inside the selected
tax parcel? 116
5.10.2.7
Query example 7 - Is Scotts Run creek inside Monongalia County
Boundary? 118
5.11 DIAGNOSING THE GEODATABASE..................................................................... 120
5.11.1
Application/Program tuning ................................................................... 120
5.11.2
Database design and indexing ................................................................ 121
5.11.3
Database tuning ...................................................................................... 121
5.11.3.1
Buffer cache hit ratio....................................................................... 122
5.11.3.2
Data dictionary cache hit ratio ........................................................ 123
5.11.3.3
Memory sort hit ratio....................................................................... 123

viii

5.11.3.4
I/O disk contention .......................................................................... 125
5.11.4
OS Tuning................................................................................................ 126
6.

CONCLUSION...................................................................................................... 127

REFERENCES .............................................................................................................. 131

ix

TABLE OF FIGURES
Figure 1.1. The place of ArcSDE in the ArcGIS system (from West, 2001) ....................... 3
Figure 2.1. Layered model of spatial data....................................................................... 16
Figure 2.2. Geometry types used by the Object-Relational Model ................................... 17
Figure 2.3. Spatial Data Model for the Object-Relational Model .................................... 18
Figure 2.4. Query Model for Oracle Spatial..................................................................... 20
Figure 2.5. Quadtree Decomposition and Morton Codes................................................. 25
Figure 2.6. Fixed-Size Tilling with many small tiles ........................................................ 27
Figure 2.7. Fixed-Size Tilling with fewer large tiles ........................................................ 28
Figure 2.8.Variable-Sized Tile spatial indexing ............................................................... 30
Figure 2.9.The 9-intersection model ................................................................................. 32
Figure 2.10. Distance buffer for point, lines and polygon with a hole ............................. 34
Figure 3.1.The place of ArcSDE in the ArcGIS System (from ArcSDE Overview, 2001) 36
Figure 3.2. The ArcSDE application server (from West, 2001)........................................ 37
Figure 3.3. The three-tiered architecture (from Harris, 2000)......................................... 40
Figure 3.4. The two-tiered architecture (direct connect) (from Harris, 2000)................. 41
Figure 3.5. Data access facilitated by the application server .......................................... 47
Figure 4.1. Three level of a pyramid for a raster dataset................................................. 54
Figure 5.1. Oracle Universal Installer window showing the Available Products ............ 60
Figure 5.2. Distribution of datafiles and tablespaces in the gis database........................ 65
Figure 5.3. Installation of ArcSDE for Oracle 8i setup window....................................... 67
Figure 5.4. Repository setup using the sdesetupora8i administration command ............. 68
Figure 5.5. Creation of the esri_sde service ..................................................................... 69
Figure 5.6. The Welcome panel for the Net8 Configuration Assistant ............................. 76
Figure 5.7. The Spatial Database Connection Panel for Direct Connection ................... 80
Figure 5.8. The Spatial Database Connection Panel for ArcSDE service connection..... 81
Figure 5.9. The command used to display the ArcSDE user session information ............ 82
Figure 5.10. Example of the shp2sde administration command used to load the Roads
shapefile into the ArcSDE geodatabase ............................................................................ 85
Figure 5.11. Example of usage of the cov2sde administration command and the use to
load the Elevation point coverage into the ArcSDE database .......................................... 86
Figure 5.12. A run of the administration command sdeversion o compress................... 88
Figure 5.13. A run of the administration command sdetable o update_dbms_stats....... 89
Figure 5.14. The layer created from the gis geodatabase ................................................ 92
Figure 5.15. Symbology used to display the Morgantown area roads ............................. 94
Figure 5.16. Thumbnails used to browse the connection to the ArcSDE service ............. 96
Figure 5.17. Metadata for the Monongalia county, DB_BND feature class .................... 98
Figure 5.18. The panel of the Oracle Spatial Index Advisor .......................................... 105
Figure 5.19. Areas selected using the Selection menu in ArcMap.................................. 109
Figure 5.20. Measuring the distance between the chosen tax parcel and the Morgantown
Airport ............................................................................................................................. 111

1. INTRODUCTION
The idea of pursuing this project occurred to me in the Fall of 2000, when an
article published in ESRIs ArcNews magazine announced that ESRI Passed Oracle
Spatial Integration Test.
As part of ESRIs continued commitment to interoperability provided through
the OpenGIS Consortiums Simple Feature Specification for SQL, ESRI and Oracle
recently jointly tested ESRIs software with Oracle Spatial. The results of the tests were
that ESRIs software passed all Oracles tests for vendor integration with Oracle 8i
Spatial.
Passing Oracles integration tests means that ESRIs scalable family of
Geographic Information System (GIS) software is fully compliant with Oracle 8i
Enterprise Edition and Oracle Spatial 8.1.6. (ESRI ArcNews, 2000).

The purpose of a Geographic Information System (GIS) is to provide a spatial

framework to support decisions for the intelligent use of Earths resources and to manage
the man-made environments. The information presented in a GIS is usually in the form of
maps and symbols. A map indicates where things are, what they are, how can they be
reached using roads or other transport means, and what things are adjacent and nearby.
A geographic data model is an abstraction of the real world that employs a set of
data objects that support map display, query, editing and analysis. ArcInfo 8 introduced a
new object-oriented data model, named the geodatabase data model that is capable of
representing natural behaviors and relationships of features. This model is overcoming

some of the shortcomings of the previous geographic data models, the CAD data model
and the coverage data model (Zeiler, 1999). The CAD data model is a complicated,
limited data model (did not support the raster data), while the coverage data model has to
look up for several related tables to collect the data to be displayed.
The defining purpose of the geodatabase data model is to let the user make the
GIS features in the dataset smarter by endowing them with natural behaviors, and to
allow any sort of relationship to be defined among features. The geodatabase model
brings a physical data model closer to its logical data model, because the data objects in
the database are mostly the same objects that you would define in a logical data model,
such as owners, buildings, parcels and roads.
One way of implementing the geodatabase is by using the ArcInfo 8.1 tools, such
as ArcCatalog. A different approach to creating the geodatabase is to use Oracle Spatial,
which enables the spatial data to be stored, accessed and analyzed quickly and efficiently
in an Oracle database. The Spatial Database Engine (ArcSDE) would be implemented as
middleware between the ArcInfo 8.1 and the relational database. The use of ArcSDE
will facilitate the multi-user access of the geodatabase using the ESRIs software
products, such as ArcInfo 8.1 and ArcView GIS. A figure illustrating access to the
geodatabase can be seen below:

Figure 1.1. The place of ArcSDE in the ArcGIS system (from West, 2001)

Some of the advantages of using an RDBMS such as Oracle as a central repository for
spatial data include:

Expanded database size limits;

Support for the larger number of users required for enterprise implementations;

The ability to take advantage of enhanced DBMS features such as administration

and maintenance utilities, replication, and faster backup and recovery;

The availability of Java and Structured Query Language (SQL) as open

application programming interfaces (APIs);

Easier integration of spatial data with other core organizational data;

The emergence of spatial standards for interoperability;

The ability to publish and distribute spatial data over private Intranets or the
public Internet (ESRI, 2000a).

1.1 Project Objectives

The overall objective of this project was to demonstrate the linkage of a

geodatabase to Oracle Spatial and make it available to the full range of ArcGIS software,
namely to create a multi-user GIS.

Specifically, the subtasks of the project involved:

Identify the data to be used in the project. The geodatabase should contain both
raster and vector data characteristic of GIS databases. The data should be
compliant with the National Spatial Data Infrastructure (NSDI) framework, and it
should contain all of the frameworks data themes. The NSDI framework seven
data themes are: geodetic control, orthoimagery, elevation, transportation,
hydrography, governmental units and cadastral information (Federal Geographic
Data Committee, 1997).

Create the schema for the geodatabase. Establish the type of schema for Oracle
Spatial geodatabases.

!"Identify limitations on using certain schemas on geodatabase

creation.
!"Identify if the schema of any geodatabase needs to be normalized,
e.g. using Third Normal Form (3NF).

!"Identify the data types that need to be created to accommodate the

spatial data (abstract data types, varying arrays and nested tables).

Load the geodatabase into Oracle Spatial ORDBMS

!"Identify the tools to be used for loading the data from geodatabase.
The raster data and the vector data will use different tools, some of
them not provided in Oracle Spatial.
!"Identify the type of spatial indexes to be used on the data, and
apply them.

Query the geodatabase and perform spatial operations such as proximity,

intersection and containment

Install ArcSDE Application Server and perform the tuning necessary for both
ArcSDE and Oracle

!"Store the configuration parameters, alter the physical storage of

data, create tablespaces, create SDE users and grant them with
privileges (Harris and Stauder, 2001).
!"Identify if the spatial indexes will be a burden for effective access
and communication between geodatabases and ArcSDE.

Establish multi-user access to the geodatabase from ArcInfo 8.1 and ArcView
GIS through the ArcSDE Application Server

Perform queries and spatial operations on the geodatabase from ArcInfo 8.1 and
ArcView GIS in the established multi-user environment

!"Identify if the query and the spatial operations performance is

affected by using the ArcSDE Application Server as a
middleware between the geodatabase and the GIS software
products (ArcInfo 8.1, ArcView GIS).
!"Compare the spatial operations and the queries executed in the GIS
environment with those performed in the Oracle Spatial
environment.

Evaluate and comment on the integration of Oracle Spatial and ArcSDE with
geodatabases and Arc GIS.

1.2 Project Timeline

Activity
Indentify database
Acquire and install Oracle 8i Enterprise Edition
Review literature
Create schema for the geodatabase
Load the geodatabase into Oracle Spatial
Perform queries on the geodatabase
Install ArcSDE. Perform tuning of the geodatabase and
of ArcSDE
Establish multi-user access to the geodatabase
Perform queries and spatial operations on the
geodatabase from ArcInfo 8 and ArcView GIS in the
established multi-user environment
Evaluate and comment on the integration of Oracle
Spatial and ArcSDE with geodatabases and Arc GIS

July
*
*
*

Aug

*
*

2 0 0 1
Sept Oct

Nov Dec

2002
Jan

*
*
*

*
*

*
*

2. OVERVIEW OF ORACLE SPATIAL

Oracle Spatial has been adopted by leading GIS and mapping vendors, and it is
incorporated into Oracle Customer Relationship Management (CRM) and Enterprise
Resource Planning (ERP) applications.
Oracle Spatial provides an SQL schema and functions that facilitate the storage,
retrieval, update, and query of collections of spatial features in an Oracle8i database.
The advantages of using Oracle Spatial are that Oracle Spatial:

Stores vector geometries in the database;

Provides index vector geometries;

Allows for querying the spatial relationships between geometries;

Performs spatial operations on geometries;

Enhances applications performance.

The spatial attribute of a spatial feature is the geometric representation of its shape in
some coordinate space. This is referred to as its geometry.

2.1 Object-Relational and Relational Models characteristics

Oracle Spatial supports two mechanisms, or models, for representing geometries,

the object-relational model and the relational model.
For the project, we used the object-relational model, and all the following information
will mostly refer to the object-relational model.

2.1.1 The Object-Relational Model

The object-relational model uses a table with a single column of type

MDSYS.SDO_GEOMETRY and a single row per geometry instance.

Any table that has a column of type SDO_GEOMETRY must have another column, or
set of columns, that defines a unique primary key for that table. Tables of this sort are
sometimes referred to as geometry tables.
Oracle Spatial defines the object type SDO_GEOMETRY as:

CREATE TYPE sdo_geometry AS OBJECT (

SDO_GTYPE NUMBER,
SDO_SRID NUMBER,
SDO_POINT SDO_POINT_TYPE,
SDO_ELEM_INFO MDSYS.SDO_ELEM_INFO_ARRAY,
SDO_ORDINATES MDSYS.SDO_ORDINATE_ARRAY);

2.1.1.1 SDO_GTYPE

SDO_GTYPE indicates the type of the geometry. Valid geometry types correspond to
those specified in the OpenGIS Simple Features Specification For SQL (with the
exception of Surfaces) (OpenGIS Consortium, 1999). The numeric values differ from
those given in the OGIS specification, but there is a direct correspondence between the
SDO_GEOMETRY names and semantics, where applicable. Table 2.1 shows the valid
SDO_GTYPE values.

Table 2.1. Valid SDO_GTYPE Values

Value Geometry Type

Description

d000

UNKNOWN_ GEOMETRY

Oracle Spatial ignores this geometry.

d001

POINT

Geometry contains one point.

d002

LINESTRING

Geometry contains one line string.

d003

POLYGON

Geometry contains one polygon with or

without holes.

d004

COLLECTION

Geometry is a heterogeneous collection of

elements. All polygons must be disjoint.

d005

MULTIPOINT

Geometry has multiple points.

d006

MULTILINESTRING

Geometry has multiple line strings.

d007

MULTIPOLYGON

Geometry has multiple, disjoint polygons

(more than one exterior boundary)

The d in the Value column of table 2.1 is the number of dimensions: 2, 3, or 4. For
example, a value of 3003 indicates a 3-dimensional polygon.

2.1.1.2 SDO_SRID
SDO_SRID can be used to identify a coordinate system to be associated with the
geometry. If SDO_SRID is null, no coordinate system is associated with the geometry. If
SDO_SRID is not null, it must contain a value from the SRID column of the
MDSYS.CS_SRS table, and this value must be inserted into the SRID column of the
USER_SDO_GEOM_METADATA view.

10

An example would be an SDO_SRID value of 26717, which associates the geometry with
the NAD 1927 UTM Zone 17N coordinate system.

2.1.1.3 SDO_POINT

SDO_POINT is used to store point geometries. SDO_POINT is defined using an object

type with attributes X, Y, and Z, all of type NUMBER. If the SDO_ELEM_INFO and
SDO_ORDINATES arrays are both null, and the SDO_POINT attribute is non-null, then
the X and Y values are considered to be the coordinates for a point geometry. Otherwise
the SDO_POINT attribute is ignored by Oracle Spatial.
2.1.1.4 SDO_ELEM_INFO

SDO_ELEM_INFO is defined using a varying length array of numbers. This attribute

allows interpreting the ordinates stored in the SDO_ORDINATES attribute.

Each triplet set of numbers is interpreted as follows:

SDO_STARTING_OFFSET -- Indicates the offset within the

SDO_ORDINATES array where the first ordinate for this element is stored.
Offset values start at 1.

SDO_ETYPE - Indicates the type of the element. Valid values are 0 through 5, as
well as the following: 1003 and 2003 (variants of 3), and 1005 and 2005 (variants

11

of 5). SDO_ETYPE values 1, 2, and 3 are considered simple elements.

SDO_ETYPE values 4 and 5 are considered compound elements.

SDO_INTERPRETATION - Means one of two things, depending on whether or

not SDO_ETYPE is a compound element.
If SDO_ETYPE is a compound element (4 or 5), this field specifies how many
subsequent triplet values are part of the element. If the SDO_ETYPE is not a
compound element (1, 2, or 3), the interpretation attribute determines how the
sequence of ordinates for this element is interpreted.

The combination of the SDO_ETYPE and SDO_INTERPRETATION determines the

type of element stored in the SDO_ORDINATES varying array. For example, if
SDO_ETYPE has a value of 3 and SDO_INTERPRETATION has a value of 1, the type
of element stored is a simple polygon whose vertices are connected by straight-line
segments.
2.1.1.5 SDO_ORDINATES

SDO_ORDINATES is defined using a varying length array (1048576) of NUMBER type

that stores the coordinate values that make up the boundary of a spatial object. This array
must always be used in conjunction with the SDO_ELEM_INFO varying length array.
The values in the array are ordered by dimension. For example, a polygon whose
boundary has four 2-dimensional points is stored as {X1, Y1, X2, Y2, X3, Y3, X4, Y4,
X1, Y1}. If the points are 3-dimensional, then they are stored as {X1, Y1, Z1, X2, Y2,
Z2, X3, Y3, Z3, X4, Y4, Z4, X1, Y1, Z1}. Spatial index creation, operators, and

12

functions ignore the Z values because this release of the product supports only 2dimensional spatial objects. The values in the SDO_ORDINATES array must all be valid
and non-null.

2.1.1.6 Geometry Metadata Structure

The geometry metadata describing the dimensions, lower and upper bounds, and
tolerance in each dimension is stored in a global table owned by MDSYS (which users
should never directly update). Each Oracle Spatial user has the following views available
in the schema associated with that user:

USER_SDO_GEOM_METADATA contains metadata information for all spatial

tables owned by the user (schema). This is the only view that a user can update,
and it is the one in which Spatial users must insert metadata related to spatial
tables.

ALL_SDO_GEOM_METADATA contains metadata information for all spatial

tables on which the user has SELECT permission.

DBA_SDO_GEOM_METADATA contains metadata information for all spatial

tables on which the user has SELECT permission if the user has the DBA role.

Oracle Spatial users are responsible for populating these views. For each spatial column,
the user must insert an appropriate row into the USER_SDO_GEOM_METADATA
view.

13

2.1.2 The Relational Model

The relational model uses a table with a predefined set of columns of type NUMBER
and one or more rows for each geometry instance.

These models roughly correspond to two alternatives described in the Open GIS
ODBC/SQL specification for geospatial features (Oracle Spatial User's Guide and
Reference, 2000; OpenGIS Consortium, Inc., 1999). The object-relational model
corresponds to an SQL with Geometry Types implementation of spatial feature tables,
and the relational model corresponds to an implementation of spatial feature tables using
numeric SQL types for geometry storage.

2.2 Benefits of the Object-Relational and Relational models

2.2.1 Benefits of the Object-Relational Model
The following are some of the benefits of using the object-relational model:

Additional geometry types are supported: arcs, circles, compound polygons,

compound line strings, and optimized rectangles.

Ease of use is improved for creating and maintaining indexes and for performing
spatial queries.

Indexing is maintained by the Oracle8i database server.

Geometries are modeled in a single row, single column.

Performance is greatly improved.

14

2.2.2 Benefits of the Relational Model

The following are some of the benefits of using the relational model:

Database replication is supported.

Distributed databases are supported.

Table partitioning and parallel index loading are supported.

When Oracle introduces replication and distributed support for objects in a future release,
there will be no benefits to using the relational model.

2.3 Introduction to Spatial Data

Spatial data is modeled in layers, and each layer is defined by the same object space
and coordinate system. For example, the spatial representation of a city might include
separate layers for outlines of political boundaries, every business and domestic location,
land use and land geography, the roads network and the maze of water, gas, sewer and
electrical lines. Once this data is stored in an Oracle database, it can be easily
manipulated, retrieved, and related to all the other data stored in the database.

15

Figure 2.1. Layered model of spatial data (ESRI, 1999)

2.4 Geometric Types for the Object-Relational Model

The geometric types supported by the object-relational model are as follows:

1. 2D point and point cluster (elements composed of two ordinates, X and Y, often
corresponding to longitude and latitude);
2. 2D line strings (one or more pairs of points that define line segments);
3. 2D n-point polygons (connected line strings that form a closed ring and the
interior of the polygon is implied);
4. 2D arc line strings (All arcs are generated as circular arcs.)
5. 2D arc polygons
6. 2D compound polygons
7. 2D compound line strings

16

8. 2D circles
9. 2D optimized rectangles

Examples of all of the geometry types can be seen in Figure 2.2. The first three
geometry types (1 through 3), namely 2D point and point cluster, the 2D line strings
and the 2D n-point polygons, are considered primitive types. The primitive types are
the only types supported in the relational model.

Figure 2.2. Geometry types used by the Object-Relational Model

17

2.5 The Spatial Data Model

The Spatial data model is a hierarchical structure consisting of elements,

geometries, and layers, which correspond to representations of spatial data. Layers are
composed of geometries, which in turn are made up of elements (Figure 2.3).

Spatial Layer

Geometries

Elements

Point

Line string

Polygon

Compound
Line string

Compound
Polygon

Figure 2.3. Spatial Data Model for the Object-Relational Model

An element is the basic building block of geometry. The supported spatial element types
are the nine geometric types described at section 2.4 - The Geometric Types for the
Object-Relational Model. Each coordinate in an element is stored as an X, Y pair. The
exterior ring and the interior ring of a polygon with holes are considered as two distinct
elements that together make up a complex polygon.
A geometry (or geometry object) is the representation of a spatial feature, modeled as
an ordered set of primitive elements.

18

A layer is a heterogeneous collection of geometries having the same attribute set. For
example, one layer in a GIS might include topographical features, while another
describes population density, and a third describes the network of roads and bridges in
the area (lines and points).

2.6 The Query Model

Spatial uses a two-tier query model to resolve spatial queries and spatial joins. The term
is used to indicate that two distinct operations are performed to resolve queries. The
output of both operations yields the exact result set. The two operations are referred to as
primary and secondary filter operations. The primary filter permits fast selection of
candidate records to pass along to the secondary filter. The primary filter compares
geometry approximations to reduce computational complexity and is considered a lowercost filter. Because the primary filter compares geometric approximations, it returns a
superset of the exact result set.

The secondary filter applies exact computations to geometries that result from
the primary filter. The secondary filter yields an accurate answer to a spatial
query. The secondary filter operation is computationally expensive, but it is only
applied to the primary filter results, not the entire data set.

19

Large
Input
Data
Set

Primary
Filter

Smaller
candidate
set

Secondary
Filter

Exact
Result
Set

SDO_GEOM.
RELATE

Figure 2.4. Query Model for Oracle Spatial

The purpose of the primary filter is to quickly create a subset of the data and reduce the
processing burden on the secondary filter. The primary filter therefore should be as
efficient (that is, selective yet fast) as possible. This is determined by the characteristics
of the spatial index on the data.
The function SDO_GEOM.RELATE is used as a secondary filter. It evaluates the
topological relationship, such as whether two given geometries touch, cover each other,
or have any other interaction.

2.7 Indexing of Spatial Data

The introduction of spatial indexing capabilities into the Oracle database engine is
a key feature of the Oracle Spatial product. A spatial index, like any other index, provides
a mechanism to limit searches, but in this case based on spatial criteria such as
intersection and containment. A spatial index is needed to:

20

i.

Find objects within an indexed data space that overlap a given point or area of
interest (window query)

ii.

Find pairs of objects from within two indexed data spaces that interact spatially
with each other (spatial join)

A spatial index is considered a logical index. The entries in the spatial index are
dependent on the location of the geometries in a coordinate space, but the index values
are in a different domain. Index entries take on values from a linearly ordered integer
domain, while the coordinates for a geometry may be pairs of integer, floating-point, or
double-precision numbers.

Oracle Spatial allows the use of R-tree indexing (the default) or quadtree indexing, or
both. Each index type is appropriate in different situations. It is possible to maintain both
an R-tree and quadtree index on the same geometry column.
In choosing whether to use an R-tree or quadtree index for a spatial application, should
consider the following.

With R-tree indexes:

The approximation of geometries cannot be fine-tuned. (Oracle Spatial uses the

minimum bounding rectangles, or MBR.)

Index creation and tuning are easier than with quadtree indexes.

Less storage is required than with quadtree indexes, except for point-only data,
where there is no significant difference.

21

If the application workload includes nearest-neighbor queries (SDO_NN

operator), R-tree indexes are faster.

If there is heavy update activity to the spatial column, an R-tree index may not be
a good choice.

With quadtree indexes:

The approximation of geometries can be fine-tuned by setting the tiling level

(SDO_LEVEL) and number of tiles (SDO_NUMTILES).

Tuning is more complex than with R-tree indexes, and setting the appropriate
tuning parameter values can affect performance significantly.

More storage is required than with R-tree indexes, except for point-only data,
where there is no significant difference.

Heavy update activity does not affect the performance of a quadtree index.

2.7.1 R-tree Indexing

A spatial R-tree index can index spatial data of up to 4 dimensions. An R-tree

index approximates each geometry by a single rectangle that minimally encloses the
geometry (called the minimum bounding rectangle, or MBR). For a layer of geometries,
an R-tree index consists of a hierarchical index on the MBRs of the geometries in the
layer. This R-tree index is stored in the spatial index table (SDO_INDEX_TABLE in the
USER_SDO_INDEX_METADATA view). The R-tree index also maintains a sequence
number generator (SDO_RTREE_SEQ_NAME in the

22

USER_SDO_INDEX_METADATA view) to ensure that simultaneous updates by

concurrent users can be made to the index.
If a spatial index is created without specifying any indexing parameters, it will be an Rtree index. For example, the following statement creates a spatial R-tree index named
roads_idx using default values for parameters that apply to R-tree indexes:

CREATE INDEX roads_idx ON db_rds (shape)

INDEXTYPE IS MDSYS.SPATIAL_INDEX;

If a spatial index is created without specifying the SDO_LEVEL or SDO_NUMTILES

keyword in the PARAMETERS clause, it will thus be an R-tree index.

2.7.2 Quadtree Indexing

In the linear quadtree indexing scheme, the coordinate space (for the layer where
all geometric objects are located) is subjected to a process called tessellation, which
defines exclusive and exhaustive cover tiles for every stored geometry. Tessellation is
done by decomposing the coordinate space in a regular hierarchical manner. The range of
coordinates, the coordinate space, is viewed as a rectangle. At the first level of
decomposition, the rectangle is divided into halves along each coordinate dimension
generating four tiles. Each tile that interacts with the geometry being tessellated is further
decomposed into four tiles. This process continues until some termination criteria, such
as size of the tiles or the maximum number of tiles to cover the geometry, is met.
Oracle Spatial can use either fixed-size or variable-sized tiles to cover a geometry:

23

Fixed-size tiles are controlled by tile resolution. If the resolution is the sole
controlling factor, then tessellation terminates when the coordinate space has been
decomposed a specific number of times. Therefore, each tile is of a fixed size and
shape.

Variable-sized tiling is controlled by the value supplied for the maximum number
of tiles. If the number of tiles per geometry, n, is the sole controlling factor, the
tessellation terminates when n tiles have been used to cover the given geometry.

Fixed-size tile resolution and the number of variable-sized tiles used to cover a geometry
are user-selectable parameters called SDO_LEVEL and SDO_NUMTILES, respectively.
Smaller fixed-size tiles or more variable-sized tiles provide better geometry
approximations. The smaller the number of tiles, or the larger the tiles, the coarser are the
approximations.
Spatial supports two quadtree indexing types, reflecting two valid combinations of
SDO_LEVEL and SDO_NUMTILES values:

Fixed indexing: a non-null and non-zero SDO_LEVEL value and a null or zero
(0) SDO_NUMTILES value, resulting in fixed-sized tiles. Fixed indexing is
described in Section 2.7.2.2.

Hybrid indexing: non-null and non-zero values for SDO_LEVEL and

SDO_NUMTILES, resulting in two sets of tiles per geometry. One set contains
fixed-size tiles and the other set contains variable-sized tiles. Hybrid indexing is
described in Section 2.7.2.3.

24

2.7.2.1 Tessellation of a Layer During Indexing

The process of determining which tiles cover a given geometry is called

tessellation. The tessellation process is a quadtree decomposition, where the twodimensional coordinate space is broken down into four covering tiles of equal size.
Successive tessellations divide those tiles that interact with the geometry down into
smaller tiles, and this process continues until the desired level or number of tiles has been
achieved. The results of the tessellation process on a geometry are stored in a table,
referred to as the SDOINDEX table.
The tiles at a particular level can be linearly sorted by systematically visiting tiles in an
order determined by a space-filling curve as shown in figure 2.5. The tiles can also be
assigned unique numeric identifiers, known as Morton codes or z-values.
The terms tile and tile code will be used interchangeably in this and other sections related
to spatial indexing.

Figure 2.5. Quadtree Decomposition and Morton Codes

25

2.7.2.2 Fixed Indexing

Fixed-size tile spatial indexing is the preferred indexing method for the relational
model, and also for the object-relational model. This method uses tiles of equal size to
cover a geometry. Because all the tiles are the same size, they all have codes of the same
length, and the standard SQL equality operator (=) can be used to compare tiles during a
join operation. This results in excellent performance characteristics.
Two geometries are likely to interact, and hence pass the primary filter stage, if they
share one or more tiles. The SQL statement for the primary filter stage is:

SELECT DISTINCT <select_list for geometry identifiers>

FROM table1_sdoindex A, table2_sdoindex B
WHERE A.sdo_code = B.sdo_code;

The effectiveness and efficiency of this indexing method depends on the tiling level and
the variation in size of the geometries in the layer. With a small fixed-size tile as shown
in figure 2.6, selectivity is good, but a large number of tiles is needed to cover large
geometries. A window query would easily identify geometries A and B, but would reject
C.
The SDO_TUNE.ESTIMATE_TILING_LEVEL function helps determine an appropriate
tiling level for every data set.

26

Figure 2.6. Fixed-Size Tilling with many small tiles

With a large fixed-size tile as shown in Figure 2.7, fewer tiles are needed to cover the
geometries, but the selectivity is not as good. The same window query as in figure 2.6
would probably pick up all three geometries. Any object that shares tile T1 or T2 would
identify object C as a candidate, even though the objects may be far apart, such as objects
B and C are in Figure 2.7.

27

Figure 2.7. Fixed-Size Tilling with fewer large tiles

2.7.2.3 Hybrid Indexing

Hybrid indexing uses a combination of fixed-size and variable-sized tiles for

spatially indexing a layer. Hybrid indexing is considered the preferred method for
indexing the object-relational model, but it has some caveats discussed below. Variablesized tile spatial indexing uses tiles of different sizes to approximate a geometry. For
each geometry, there are a set of fixed-size tiles that fully cover the geometry, and also a
set of variable-sized tiles that fully cover the geometry.

28

The rare circumstances where hybrid indexes should be considered are as follows:

When joins are required between layers whose optimal fixed index level
(SDO_LEVEL) values are significantly different (4 levels or more), it may be
possible to get better performance by bringing the layer with a higher optimal
SDO_LEVEL down to the lower SDO_LEVEL and adding the
SDO_NUMTILES parameter to ensure adequate tiling of the layer. The best
starting value for SDO_NUMTILES in the new hybrid layer can be calculated by
getting a count of the rows in the spatial index table and dividing this number by
the number of rows with geometries in the layer, then rounding up. A spatial join
(QUERYTYPE=JOIN) is not a common requirement for applications, and it is
comparable to a spatial cross product where each of the geometries in one layer
will be compared with each of the geometries in the other layer.

When both of the following are true for a single layer, hybrid indexing may be
preferable: (1) the layer has a mixture of many geometries covering a very small
area and many polygons covering a very large area; and (2) the optimal fixed
tiling level for the very small geometries will result in an extremely large number
of tiles to be generated for the very large geometries, causing the spatial index to
grow to an unreasonable size. If both of these conditions are true, it may be better
to use the SDO_NUMTILES parameter to get coverage for the smaller
geometries, while keeping the fixed tile size relatively large for the large
geometries by using a smaller SDO_LEVEL value.

29

In Figure 2.8, the variable-sized cover tiles closely approximate each geometry. This
results in good selectivity. The number of variable tiles needed to cover a geometry is
controlled using the SDO_NUMTILES parameter.

Figure 2.8.Variable-Sized Tile spatial indexing

A variable tile is subdivided if it interacts with the geometry, and subdivision will not
result in tiles that are smaller than a predetermined size. This size, or tiling resolution, is
determined by a default SDO_MAXLEVEL value.
The SDO_TUNE package of Oracle Spatial has some functions that help determine
appropriate SDO_LEVEL and SDO_NUMTILES values.

30

2.8 Spatial Relations and Filtering

Oracle Spatial uses filter methods to determine the spatial relationship between
entities in the database. The spatial relation is based on geometry locations. The most
common spatial relations are based on topology and Euclidean distance. For example, the
boundary of an area consists of a set of curves that separates the area from the rest of the
coordinate space. The interior of an area consists of all points in the area that are not on
its boundary. Based on this, two areas are said to be adjacent if they share part of a
boundary but do not share any points in their interior. Two objects are said to be within a
given distance of one another if their distance is less than the given distance.

To determine spatial relations, Spatial has several secondary filter methods:

SDO_RELATE operator evaluates the topological criteria

SDO_WITHIN_DISTANCE operator determines if two spatial objects are within

a Euclidean distance of each other.

SDO_NN operator identifies the nearest neighbors for a spatial object.

2.8.1 The SDO_RELATE operator

The SDO_RELATE operator implements a 9-intersection model for categorizing binary

topological relations between points, lines, and polygons. Each spatial object has an
interior, a boundary, and an exterior. The boundary consists of points or lines that
separate the interior from the exterior. The boundary of a line consists of its end points.
31

The boundary of a polygon is the line that describes its perimeter. The interior consists of
points that are in the object but not on its boundary, and the exterior consists of those
points that are not in the object.
Given that an object A has 3 components (a boundary A-b, an interior A-i, and an
exterior A-e), any pair of objects has 29 possible interactions between their components.
Pairs of components have an empty (0) or a non-empty (1) set intersection. The set of
interactions between 2 geometries is represented by a 9-intersection matrix that specifies
which pairs of components intersect and which do not. Figure 2.9 shows the 9intersection matrix for 2 polygons that are adjacent to one another. This matrix yields the
following bit mask, generated in row-major form: 101001111.

Figure 2.9.The 9-intersection model

The 9-intersection matrix, which describes the topological relations between objects, has
a large number of binary topological relations (29 = 512), but only a small subset of them

32

can be realized. Egenhofer et al. (1994) associated names with the possible topological
relationships, and some of them are described below:

DISJOINT - The boundaries and interiors do not intersect.

TOUCH - The boundaries intersect but the interiors do not intersect.

OVERLAPBDYDISJOINT - The interior of one object intersects the boundary

and interior of the other object, but the two boundaries do not intersect. This
relation occurs, for example, when a line originates outside a polygon and ends
inside that polygon.

OVERLAPBDYINTERSECT - The boundaries and interiors of the two objects

intersect.

EQUAL - The two objects have the same boundary and interior.

CONTAINS - The interior and boundary of one object is completely contained in

the interior of the other object.

COVERS - The interior of one object is completely contained in the interior of the
other object and their boundaries intersect.

INSIDE - The opposite of CONTAINS. A INSIDE B implies B CONTAINS A.

COVEREDBY - The opposite of COVERS. A COVEREDBY B implies B

COVERS A.

ANYINTERACT - The objects are non-disjoint.

2.8.2 The SDO_WITHIN_DISTANCE operator

The SDO_WITHIN_DISTANCE operator determines if two spatial objects, A

and B, are within a specified Euclidean distance of one another. This operator first
33

constructs a distance buffer, Db, around the reference object B. It then checks that A and
Db are non-disjoint. The distance buffer of an object consists of all points within the
given distance from that object. Figure 2.10 shows the distance buffers for point, line, and
area objects. The buffer is rounded near the corners of the objects.

Figure 2.10. Distance buffer for point, lines and polygon with a hole

2.8.3 The SDO_NN operator

The SDO_NN operator returns a specified number of objects from a geometry

column that are closest to a specified geometry (for example, the five closest restaurants
to a city park). In determining how close two geometry objects are, the shortest possible
distance between any two points on the surface of each object is used.

34

3. ARCSDE GIS GATEWAY FOR THE DATA STORED IN

THE RDBMS

3.1 Introduction

ArcSDE allows a user to access and manage the GIS data stored in one of the
commercial databases, such as IBM DB2, Informix, MS SQL Server and Oracle.
ArcSDE plays a fundamental role in both multi-user and distributed GIS systems. With
ArcSDE 8 the GIS software (ArcInfo, ArcView GIS, ArcIMS, and others) can work
directly with spatial data managed in Oracle Spatial. ArcSDE provides the gateway
between ESRI's GIS software and Oracle Spatial, filling three roles:

As an integral part of a multi-user ArcGIS system;

As an application server to deliver spatial data to many users and applications;

As a developer tool for open access using either ArcObjects or its own Java or C
application programming interface (API).

Below can be seen an overview of the ArcSDE in the ArcGIS system:

35

Figure 3.1.The place of ArcSDE in the ArcGIS System (from ArcSDE Overview, 2001)

ArcSDE is completely integrated with and supports all the major functions and
capabilities of a "spatially enabled" ORDBMS like Oracle Spatial. Other advantages of
using ArcSDE include the ability to link to other data with non-spatial attributes, multiuser update and query access, and referential integrity.

3.2 The application server

ArcSDE is built with client/server technologya client application sends requests to the
server. In our case, the client is the Oracle Client application. In turn, the server receives
the request, generates results, and delivers them to the client. The ArcSDE server
disseminates spatial data based on highly efficient spatial search functions, provides
geometric data validation, and works within heterogeneous hardware and network

36

environments. Data can be delivered to any client from any server anywhere on a
network.
In a typical configuration, an ArcSDE application server resides with the relational
database on a server platform. The ArcSDE application server performs spatial searches
and sends data that meet the search criteria to the client. For example, a common query
handled by the ArcSDE application server is to retrieve all features in a particular map
extent to be drawn in the display window. ArcSDE sends data to the client using data
buffering. Processing and buffering data on the server are much more efficient than
sending all of the data across the network and having the client determine which data to
send to the end-user application. This becomes critical when applications are
simultaneously using thousands of records in the database. Figure 3.2 illustrates the way
the ArcSDE server handles simultaneous requests from multiple users to update and
retrieve information in a geodatabase.

Figure 3.2. The ArcSDE application server (from West, 2001)

37

ArcSDE uses cooperative processing, which means that data processing occurs on
both the client application machine and the server, depending on which is faster.
Some functions require no communication with the server. CPU-intensive tasks such as
polygon overlay and clipping are best performed by the client application to avoid
excessive demands on both the server and the available bandwidth.

The computer network connects many clients to the server. The network must
support TCP/IP. It can be a low-speed wide area network (WAN) or a fast local area
network (LAN). Network file system mounts are not required for data transfer between
the server and the client. This is an important performance and administrative benefit.

3.3 Benefits of using ArcSDE as GIS gateway for the data stored
in the RDBMS
Considering the trend toward large, widely shared spatial databases, ArcSDE provides a
number of key benefits:

Database connection configuration options;

Spatial data representation;

Database portability;

Application portability;

Data integrity;

38

Application programming interface;

Database and application development costs;

Applications and development tools.

3.3.1 Database connection configuration options

ArcSDE for Oracle8i (and also for SQL Server) provide two alternative methods of
connecting to the database instance: direct connection to the database instance in a twotiered architecture or connecting to the ArcSDE service in a three-tiered architecture.

3.3.1.1 The three-tiered architecture

ArcSDE allows distributing the GIS application processing between the database server,
the client, and the ArcSDE application server. Connecting to the ArcSDE application
server provides performance advantages as well as providing a mechanism for supporting
server side applications. Figure 3.3 illustrates the three-tiered architecture.

39

Figure 3.3. The three-tiered architecture (from Harris, 2000)

3.3.1.2 The two-tiered architecture

The system could be configured using the two-tiered architecture or the direct
connection. The application can connect directly to the RDBMS without using the
ArcSDE application server. Direct connections provide an easier way to achieve RDBMS
connectivity with less administration. The direct connection to Oracle Spatial allows only
40

for read-only access to the spatial database. Figure 3.4 illustrates the two-tiered (direct
connect) architecture.

Figure 3.4. The two-tiered architecture (direct connect) (from Harris, 2000)

3.3.2 Spatial data representation

The spatial data representation is built upon standard data types in the RDBMS. In the
case of Oracle 8i with the Oracle Spatial extension, ArcSDE can access and use the
geometric types provided for managing feature geometries. When necessary, ArcSDE

41

provides the mechanism for managing feature geometry. These storage methods provide
a fast and compact representation for spatial data.

3.3.3 Database portability

By using ArcSDE, it is possible to move data from one RDBMS to another without loss
of information. This feature is accomplished through ArcSDE data export and import
capabilities. This is especially important if an enterprise has a heterogeneous database
environment, possibly including work groups with the most advanced geodatabase
designs or personal database systems.

3.3.4 Application portability

ArcSDE defines a logical model for spatial data, implemented on top of a physical
database representation. Applications developed with the ArcSDE API will run, with
little or no change, on different physical schemas within an RDBMS. This lets the GIS
database administrator choose the best database schema for each individual dataset to
meet the requirements of an application. For example, one dataset can be maintained and
edited using a binary schema (stored as LONG RAW in Oracle), while another dataset
might be stored as Oracle Spatial geometry types. How the data is stored is transparent to
the end user application.

42

3.3.5 Data integrity

ArcSDE helps to manage the geometry types stored in the database by imposing rules of
storing the data. For example, polygon boundaries must be closed, that is, the first vertex
of a polygon must be identical to its last vertex (when the polygon is not stored using the
optimized polygon type). In addition, ArcSDE gateway can be used with ArcInfo to
implement additional integrity constraints on the data model that aren't practical to
implement in the RDBMS itself. For example, connectivity rules can be added for utility
networks.

3.3.6 Application programming interface

ArcSDE provides access to C and Java APIs, and they can be used for processing and
querying the spatial information. When the underlying RDBMS is Oracle Spatial,
Informix Spatial DataBlade or IBM DB2 Spatial Extender, ArcSDE is providing a
Structured Query Language (SQL) API that can work with the geometry columns in the
RDBMS.
ArcObjects is the Microsoft Component Object Model (COM) developers API for
ArcGIS Desktop. It provides the ability to access and work with the contents of
geodatabases as objects with advanced GIS behavior and relationships.

43

3.3.7 Database and application development costs

ArcGIS uses a large set of tools of applications. As a result, the combination between
ArcGIS and ArcSDE reduces the cost of building and maintaining a geodatabase.

3.3.8 Applications and development tools

ArcSDE is the standard interface that allows direct access to spatial databases from
ESRI's GIS software-ArcInfo, ArcEditor, ArcView, and ArcIMS. These applications and
their integrated developer tools provide a comprehensive framework for creating,
managing, and using spatial information.

3.4 Data storage and data access

3.4.1 Data Storage

In an RDBMS, features are managed in tables; an instance of a feature

corresponds to a row, and an attribute of a feature to a column.
The spatial attribute of a geographic feature is defined by its dimension and
location, and is referred to as the feature's geometry. The dimension of a geometry
describes its form in space. The information related to the geometry can be found in
Chapter 2 Introduction to Oracle Spatial.

44

The location of a geometry in space is defined by its coordinate system. The

coordinate system contains information about the number of ordinate values, the
mathematical rules for projecting the geometry coordinates, and how the coordinate
system is related to a datum on the earth's surface.

3.4.2 Coordinate Reference and Projections

All spatial data has a coordinate system. A coordinate system locates the data in
either 2D or 3D space. Knowing the datas coordinate system is very important if we
want to combine data from different sources. Most spatial data are in a geographic or
projected (planar) coordinate system. The model for coordinate reference systems
described here is based upon the OpenGIS specifications (OpenGIS Consortium, 2001).
Applications that use maps as analytical tools need the coordinate system and its
properties for all spatial data. ArcSDE uses a projection management system to store
projection and coordinate information in a format that is accessible to applications.
In addition to x,y planar coordinates, it can store z-coordinates or measures. The ArcSDE
software assumes planar data when performing calculations. The ArcSDE software can
store projected or geographic data but measurements and calculations on geographic
coordinates may not be accurate.
The ArcSDE Projection Engine does the actual creation and maintenance of the
coordinate system. The ArcSDE Projection Engine supports projected and geographic
coordinate system with the PE_PROJCS and PE_GEOGCS structures. A
PE_COORDSYS superclass also exists to manipulate active PE_PROJCS or

45

PE_GEOGCS objects. A geographic coordinate system object contains the following

information:

Name

Datum

Angular unit of measure

Prime meridian

A projected coordinate system contains the geographic coordinate system information

and the following:

Linear unit of measure

Map projection

Projection parameters

The ArcSDE Projection Engine has many predefined coordinate systems listed in a
header file named pedef.h that are accessible to the ArcSDE software by integer code. If
we need to define a new coordinate system, we must use the ArcSDE Projection Engine
to create it. Layers actually store a text representation of the coordinate system.
Because ArcSDE data is stored internally as integers, some additional information is
required to define and manipulate the data. The entire coordinate system information is
stored as an opaque pointer to SE_COORDREF in the SE_SPATIALREF structure. The
additional information converts between floating point world units and the integer system
units.

46

Each spatial column (layer) has a spatial reference associated with it. Shapes
inherit the spatial reference from their spatial column of origin. Shapes defined by an
application have a coordinate reference object associated with them at the time they are
created. A group of functions of the format SE_coordref_* work with the spatial
reference system of a layer. It is possible to retrieve or set the pieces of the
SE_COORDREF structure.

3.4.3 Data Access

Data access is built around the standard cursor model defined in the Structured
Query Language (SQL). The data access model builds on the traditional model by
supporting spatial and raster constraints in a query.

Figure 3.5. Data access facilitated by the application server

47

A database connection is a connection to a source of geographic data. It

represents the ArcSDE server, which can respond to requests for geographic information.
A query defines a specific set of features that we wish to retrieve from the
database connection. When a query is applied to a database connection, the user defines a
collection of geographic features that meet the criteria defined by the query. Queries can
be quite simple, involving only an attribute value comparison, or they can be complex,
involving multiple tables connected by primary/foreign key relationships with both
attribute and spatial components.
The result of a query is a cursor, which provides a mechanism for iterating over a
collection of geographic features. The cursor has an associated state, which represents the
current feature in the collection. Functions are provided on the cursor to step through
each individual feature in the collection. The cursor object is also responsible for
returning the values defined for the current feature.
The cursor returns values, which represent the state of an element in the result set.
Result set elements can have values of several different kindssimple types such as
numbers and strings or complex types such as a geometric shape.
In the ArcSDE C and Java API, the query and resulting cursor are implemented as
a stream. A stream is a container that associates the query with the cursor, and is
referenced by a unique stream handle. The stream also contains the buffering and data
transmission properties for transmitting the results of query between the server and the
client application.
In the Oracle Spatial implementation, the Oracle engine implements the
connection, query, and the resulting cursor.

48

4. GEODATABASES
4.1 Definition of geodatabases

A geodatabase is a repository containing the spatial data inside a RDBMS. It could

contain vector data, raster data, tables, and other GIS objects. The term geodatabase is
short for geographic database, a relational database containing geographic information.
Geodatabases come in many sizes and have any number of users. They can scale from
small, single-user databases to large work group and enterprise geodatabases used
simultaneously by many users. ArcSDE allows implementing a multi-user geodatabase of
any size in the RDBMS chosen by the user - Oracle, Microsoft SQL Server, IBM DB2,
and Informix (MacDonald, 2001). In our case, the geographic database is stored using the
Oracle 8i Enterprise Edition with the Oracle Spatial extension.
The geodatabase model supports an object-relational vector data model. In this
model, entities are represented as objects with properties, behavior, and relationships.
Support for a variety of different geographic object types is built into the system.
These object types include simple objects, geographic features (objects with location),
networks and topology (objects having spatial relationships with other features),
annotation features, and other more specialized feature types.
The geodatabase model allows defining relationships between objects, together
with rules for maintaining their referential integrity. The simplest geodatabase is one that
contains a number of independent feature layers. Each feature layer typically contains
points, lines, polygons, or annotation. This is analogous to how SDE layers are

49

implemented in ArcView shapefiles. In these data models, each layer contains a single,
standalone feature class.
The goal of this chapter is to briefly introduce the geodatabase model and how
geodatabases can be used to model geography.

4.2 Data Storage in the Geodatabase

The types of data possible to be stored in a geodatabase are:

Vector datasets

Raster datasets

Triangulated Irregular Networks (TIN) datasets

Locators

4.2.1 Vector data

Vectors are a versatile and frequently used geographic data representation, well suited
for representing features with discrete boundaries such as streets, rivers, states, and
cadastral parcels. Typically, features are spatially represented as points, lines, or
polygons. Below is a summary of the vector contents in a geodatabase (from MacDonald,
2001).

50

Object class. A database table with which you can associate behavior. Rows in a
table are object instances that have special behavior in the GIS.
An example of an object class is owners of land parcels. It is possible to
establish a relationship between the polygon features for land parcels and the
object class of owners.

Feature class. A collection of features of the same type. A feature is simply an

object that has a location stored as one of its properties or fields in the row. A
features geometry type is commonly point, line, polygon, or annotation.
Examples of feature classes are rivers, counties, and cadastral tracts. Feature
classes can be independent of one another or can be related to other feature
classes. When related to one another, feature classes are organized together in a
feature dataset.

Feature attributes. Properties stored as fields in a feature class table. Attributes

define standard and custom properties of features and can be numeric, textual, or
descriptive identifiers.

Spatial reference. The earth-based coordinate system in which the dataset is

represented. This specifies the datasets real-world location. The spatial reference
includes properties such as the map projection, the datum, the allowable range for
the coordinates (for example, the range for x, y or x, y, z), and so on.

Subtypes. A set of classes for the members of a feature class. A feature class may
contain features that have the same general behavior and properties but that have
a different meaning or role in the data model

51

Feature dataset. A collection of feature classes with the same spatial reference.
The feature classes in a feature dataset may be organized into networks or planar
topologies. In ArcInfo, feature datasets are analogous to coverages in that they are
collections of related feature classes; however, feature datasets are less restrictive
and more functional than coverages. Feature datasets are vital when the GIS must
model a system of spatially related features such as facilities networks, roads,
environmental layers (such as soils, surface topography, and vegetation), census
geography, and so on.

Relationships. A relationships is an association between two objects. A

relationship allows working with features and related rows in tables as well as
relationships between rows. Relationships are organized into relationship classes.
A relationship class defines a set of relationship instances between two feature
classes or object classes. For example, feature-based annotation can be modeled
using relationships. We can define what happens to the annotation if the feature is
moved or deleted, or if its attribute values change.

Geometric networks. A geometric network is a user-defined collection of feature

classes that form part of a connected network of edges, junctions, and turns. You
define the set of feature classes that participate in a geometric network and the
role for each feature class (for example, as edges or junctions), and organize these
feature classes into a feature dataset. For example, in a water network, valves and
meters play the role of junctions, while mains and service lines have roles as
edges.

52

Planar topologies. A planar topography is a user-defined collection of feature

classes that share geometry. A planar topology allows having one common set of
lines to represent the geometry of a number of feature classes. For example,
feature classes, such as soil types, vegetation, terrain, and water, can share
common polygon boundaries. Using topology editing tools, updating the
geometry of one feature class automatically updates all feature classes in the
planar topology sharing the boundary. Feature classes that participate in a planar
topology are organized into the same feature dataset.

4.2.2 Raster data

Geodatabases can contain raster datasets, which divide space into uniform cells or
pixels. A raster dataset stores a two-dimensional matrix with sampled values for each
cell. Each cell has the same width and height. The location (geographic coordinate) of the
upper-left corner of the grid, together with the cell size and the number of rows and
columns, defines the spatial extent of the raster dataset.
The cells in a raster dataset can depict a variety of data such as the reflectance of
light for part of the spectrum in a satellite image, a color value for a photograph, a
thematic attribute such as vegetation type, a surface value, or elevation.
A raster dataset contains one or more layers called bands. For example, a color
image has three bands (red, green, and blue), a digital elevation model (DEM) has one
band (holding elevation values), and a multispectral image may have many bands.

53

Each raster band contains the actual cell values, as well as key properties, such as:

Statistics (minimum, maximum, and mean cell values);

Histogram of cell values;

Value attribute table (optional additional attribute information about various cell
values);

Default color map for raster display (optional).

It is possible to build pyramids for a raster dataset in a geodatabase. A pyramid is a

series of reduced resolution representations of the dataset. Each level is a resampled
representation of the raster at a coarser spatial resolution. Pyramids are used to improve
the display performance of rasters when you are not working with the pixel information
at full resolution - for example, when zoomed out on a map. Pyramids contain a number
of layers, each resampled at a more generalized level.

Figure 4.1. Three level of a pyramid for a raster dataset

54

When working with an image that has pyramids, ArcGIS automatically determines the
most appropriate pyramid level to use each time the raster dataset is drawn. For example,
drawing a very large extent uses the most generalized layer in a pyramid, while the most
detailed pyramid layer is drawn when we are zoomed in very close.

4.2.2.1 Supported raster formats

All raster formats supported by ArcGIS can be used to create raster datasets in the
ArcSDE geodatabase. Some of the raster types that could be imported to a geodatabase
include (from MacDonald, 2001):

Grids (including Grid stacks)

TIFF

ERDAS IMAGINE Images

ERDAS .raw, .lan, and .gis files

ER Mapper images

BIL/BIP/BSQ band interleaved and sequential files

MrSID encoded images (not encoded in geodatabase)

BMP

JPEG

GIF

ADRG

PNG

CIB
55

CADRG

DTED Level 1 & 2

NITF

4.2.3 Other types of data in the geodatabase

Many other kinds of spatial data can be managed in a geodatabase. Many spatial data
types can be represented and managed with geodatabases including the following:
4.2.3.1

Locators

Addresses are among the most common descriptions of locations and can identify places
or features on a map. Other types of alphanumeric descriptions of locations are also
possible. Locators define processes for creating features that are described by these
alphanumeric descriptions of locations. The geodatabase can manage locators and the
relationships between these alphanumeric descriptions and the features that they describe.

4.2.3.2 Triangulated Irregular networks (TINs)

A TIN is built from a series of irregularly spaced points with values that describe
the surface at that point (e.g., an elevation). From these points, a network of linked
triangles is constructed. Adjacent triangles, sharing two nodes and an edge, connect to
form the surface.

56

TINs are not stored in geodatabases at the 8.1 release of ArcSDE, but TIN support
is planned for a future release. However, TIN can be exported to coverages and the
coverages can then be imported into the geodatabase.

57

5. MULTI-USER GIS ACCESS WITH ORACLE SPATIAL

AND ArcSDE

5.1 Introduction

As has been shown in the previous chapters, the ArcGIS geodatabase model is
being implemented on the object-relational database with the ArcSDE application server.
ArcSDE is defined as an open interface to the database systems, and it allows the ArcGIS
system to manage the information stored in the Oracle 8i Enterprise Edition database,
which is using the Oracle Spatial extension for storing the geospatial data.

The data set used meets the requirements of the National Spatial Data Infrastructure
(NSDI) framework, and it contains all of the frameworks data themes. The NSDI
framework seven data themes are: geodetic control, orthoimagery, elevation,
transportation, hydrography, governmental units and cadastral information (Federal
Geographic Data Committee, 1997). All the data sets selected belong to are of
Monongalia County, West Virginia. The data sets stored in the geodatabase were selected
from the West Virginia GIS Technical Center, and they are illustrated in Table 5.1.

58

Table 5.1. Source of data sets used in the database

Data Set
Geodetic control
data
Orthoimagery

Title
Geodetic Survey Control
Points
Orthorectified Mosaic of
ADAR images

Elevation

DEM derived from Landsat

TM Mapper imagery
Roads (TIGER)
Hydrography (TIGER)
County Boundaries

Transportation
Hydrography
Governmental
units
Cadastral
information

Monongalia County Tax

Districts (data for districts
Cass, Union, Morgan and
Clinton)

Primary Source
National Geodetic
Survey (NGS)
ADAR 5500
images acquired
March-April 1997
Landsat TM
Mapper
U.S. Census
U.S. Census
U.S. Geological
Survey
WV Department of
Tax and Revenue

Scale
1:24,000
5m pixel size
(resampled),
4 bands
30m pixel
size
1:100,000
1:100,000
1:24,000
1:24,000

The data sets used were preprocessed using the ArcGIS software or the ERDAS Imagine
software. All the data needed to be reprojected to the same coordinate system, and the
coordinate system chosen was Universal Transverse Mercator, with the North American
Datum 1927 (NAD27).

5.2 Oracle Installation and Database Creation

Oracle 8i Enterprise Edition version 8.1.7.0.0 with the Oracle Spatial extension was
installed on a computer named Donald. The computer was physically located in the GIS
Research Lab of the Department of Geography of WVU in order to have access to the
ArcGIS system license available in the department.

59

The Oracle 8i Enterprise Edition was installed using the Oracle Universal installer, using
a typical installation. The environment selected for the database to operate was OLTP,
which allow many users to run transactions that read and write to the database.

Figure 5.1. Oracle Universal Installer window showing the Available Products

The database created during Oracle 8i installation was never used, and the database that
hold the GIS System data, a database named GIS, was created at a later date, after having
a better understanding of how the data needed to be stored and accessed.
The first step in creating the Oracle database was to determine the optimal distribution of
the instances control files, redo log files, and rollback tablespaces, system tablespace,

60

user tablespace, temporary tablespace and archive files. Each of these is briefly described
below.

Control files maintain the structure of the database. The control files are required
to mount, open and access the database and are used to identify all database files
and log files. The control files must always be available for writing by the
database. Oracle recommends a configuration with a minimum of two control
files located on different disks.

Redo Log files record each change made to the database and are used for
recovery. There must be a minimum of two redo log files.

Rollback tablespace stores rollback segments that maintain the datas Before
Image Journaling (BIJ) of uncommitted transactions. The rollback segments
provide read consistency for queries started before transactions are committed.
Databases with frequent updates have a high degree of disk I/O to the rollback
files.

System tablespace, which is used by Oracle for the data dictionary. The data
dictionary stores metadata for each object in the databases and is accessed each
time an SQL statement is parsed to validate an objects existence and privileges.

User tablespaces are the storage containers for the databases tables and indexes.
The number of user tablespaces and their sizes is based on the size of the
database, the available hardware and the number of users.

Temporary tablespaces are used for building indexes, performing sort operations
and generating statistics.

61

Archive files are the copied redo log files, created following a log file switch and
used for media recovery. The size of the redo log files is determined by the
database transaction activity and the size of the redo log files.

The database that stored the GIS system data was named gis, and the SQL script to create
it is illustrated below.

5.2.1 The database creation script

rem ********** CREATE THE gis

DATABASE *********

CREATE DATABASE gis

CONTROLFILE REUSE
LOGFILE

'F:\oracle\oradata\gis\redo01.log' SIZE 1024K,

'F:\oracle\oradata\gis\redo02.log' SIZE 1024K,
'F:\oracle\oradata\gis\redo03.log' SIZE 1024K

MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXLOGHISTORY 1
DATAFILE
'E:\oracle\oradata\gis\system01.dbf' SIZE 264M REUSE
AUTOEXTEND ON NEXT 10240K
MAXDATAFILES 254
MAXINSTANCES 1
CHARACTER SET WE8ISO8859P1
NATIONAL CHARACTER SET WE8ISO8859P1;
rem ********** ALTER SYSTEM TABLESPACE *********
ALTER TABLESPACE SYSTEM

62

DEFAULT STORAGE (INITIAL 64K NEXT 64K MINEXTENTS 1

MAXEXTENTS UNLIMITED PCTINCREASE 50);
ALTER TABLESPACE SYSTEM
MINIMUM EXTENT 64K;

rem ********** TABLESPACE FOR ROLLBACK **********

CREATE TABLESPACE RBS DATAFILE
'E:\oracle\oradata\gis\rbs01.dbf' SIZE 520M REUSE
AUTOEXTEND ON NEXT 5120K
MINIMUM EXTENT 512K
DEFAULT STORAGE (INITIAL 512K NEXT 512K MINEXTENTS 8
MAXEXTENTS 4096);

rem ********** TABLESPACE FOR USERS **********

CREATE TABLESPACE USERS DATAFILE
'E:\oracle\oradata\gis\users01.dbf' SIZE 108M REUSE
AUTOEXTEND ON NEXT 1280K
MINIMUM EXTENT 128K
DEFAULT STORAGE (INITIAL 128K NEXT 128K MINEXTENTS 1
MAXEXTENTS 4096 PCTINCREASE 0);

rem ********** TABLESPACE FOR TEMPORARY **********

CREATE TABLESPACE TEMP DATAFILE
'E:\oracle\oradata\gis\temp01.dbf' SIZE 300M REUSE
AUTOEXTEND ON NEXT 640K
MINIMUM EXTENT 64K

63

DEFAULT STORAGE (INITIAL 64K NEXT 64K MINEXTENTS 1

MAXEXTENTS UNLIMITED PCTINCREASE 0) TEMPORARY;

rem ********** TABLESPACE FOR Tools **********

CREATE TABLESPACE TOOLS DATAFILE
'E:\oracle\oradata\gis\tools01.dbf' SIZE 12M REUSE
AUTOEXTEND ON NEXT 320K
MINIMUM EXTENT 32K
DEFAULT STORAGE (INITIAL 32K NEXT 32K MINEXTENTS 1
MAXEXTENTS 4096 PCTINCREASE 0);

rem ********** TABLESPACE FOR INDEX **********

CREATE TABLESPACE INDX DATAFILE
'C:\oracle\oradata\gis\indx01.dbf' SIZE 58M REUSE
AUTOEXTEND ON NEXT 1280K
MINIMUM EXTENT 128K
DEFAULT STORAGE (INITIAL 128K NEXT 128K MINEXTENTS 1
MAXEXTENTS 4096 PCTINCREASE 0);

CREATE PUBLIC ROLLBACK SEGMENT RBS0 TABLESPACE RBS

STORAGE (OPTIMAL 4096K);
CREATE PUBLIC ROLLBACK SEGMENT RBS1 TABLESPACE RBS
STORAGE (OPTIMAL 4096K);
CREATE PUBLIC ROLLBACK SEGMENT RBS2 TABLESPACE RBS
STORAGE (OPTIMAL 4096K);
ALTER ROLLBACK SEGMENT "RBS0" ONLINE;

64

ALTER ROLLBACK SEGMENT "RBS1" ONLINE;

ALTER ROLLBACK SEGMENT "RBS2" ONLINE;

Since the computer where the database was stored did not allow for the implementation
of a redundant array of inexpensive disks (RAID), the files and tablespaces belonging to
the gis database were distributed on the two hard disks available on the host computer.
The host computer has two physical hard disks partitioned into three logical disks, and
the distribution of the database instance and of the tablespaces can be seen in the diagram
shown in Figure 5.2.

(C:)

ORACLE_HOME

(F:)

(E:)
Control file 2

Control file 3

ROLLBACK

Redo log files 1..3

SDEHOME

SYSTEM

Control file 1

SDE
USERS
TEMPORARY
INDEXES
TOOLS

Figure 5.2. Distribution of datafiles and tablespaces in the gis database

If disk space is not an issue and the system allows creating a redundant array of
inexpensive disks, a RAID level 1 is the most beneficial providing full data redundancy.

65

Query and write performance are not impacted, and there are no write differences
compared to single disks. However, the read transactions are much faster than for single
disks.
The SDE tablespace was created at a later date, after the ArcSDE software was installed.

5.3 ArcSDE installation and creation of the SDE user

One of the most time consuming tasks of the project was the installation of
ArcSDE. This is due in part to the inability of the installation software to properly install
ArcSDE and setup the SDE user in the Oracle 8i database. Even if the ArcSDE
installation software comes loaded with a fairly explicit and well-designed GUI, the
installation does not do what it should do. For example, one step in the ArcSDE
installation is the creation of the esri_sde service, which could not be accomplished from
the GUI provided with the ArcSDE installation. After numerous attempts, the installation
was completed using the MS-DOS command line interface and the administration
commands provided by ArcSDE. The SDE user was created manually in the gis database,
and the SQL script for the SDE user creation will be illustrated in the next pages.

5.3.1 ArcSDE installation

The ArcSDE installation required the installation of a single feature, the ArcSDE server.
The window illustrating the final step of installing that feature is shown below.

66

Figure 5.3. Installation of ArcSDE for Oracle 8i setup window

The Post-Installation involved the use of SQLPlus Worksheet in order to create the SDE
user and the use of ArcSDE MS-DOS commands in order to run the initial setup program
for ArcSDE for Oracle 8i, and later to create the ArcSDE service.
The initial setup program provided by ArcSDE is named sdesetupora8i, and a run of the
program is illustrated below. This was a crucial step in the setup because it created the
ArcSDE Repository. The repository contains all the ArcSDE metadata for administrating
the ArcSDE database and the geodatabase for ArcGIS desktop applications.

67

Figure 5.4. Repository setup using the sdesetupora8i administration command

The following step was to create the SDE user, which is illustrated in 5.3.2 - Creation of
the SDE user.

68

The last step in the setup process was to create the ArcSDE service, which was named
esri_sde, and to define the license manager for the service. The administration command
is sdeservice o create, and it created the esri_sde service, it defined the License
Manager to be used, and automatically established the protocol to be used and the port,
namely TCP and port 5151. A run of the sdeservice o create command is illustrated
below.

Figure 5.5. Creation of the esri_sde service

5.3.2 Creation of the SDE user

69

A very important step comprised the creation of the SDE tablespace and of the
SDE user to store the ArcSDE and geodatabase system tables. For that, it was necessary
to logon to the Oracle 8i database as SYSDBA and to create the SDE tablespace and the
SDE user and to grant it with privileges.
ArcSDE for Oracle 8i uses the stored procedures of DBMS_PIPE and DBMD_LOCKS
Oracle built in packages. The stored procedures of DBMS_PIPE package store and
transmit row-ids. The stored procedures of DBMS_LOCK package add a row to the
PROCESS_INFORMATION table for each connected session.

Consequently, the Oracle DBA must connect to the Oracle instance as the SYS user and
grant execute on these packages to PUBLIC.
SQL> connect sys/<password>
SQL> grant execute on dbms_pipe to public;
SQL> grant execute on dbms_lock to public;

Next, the SDE tablespace was created, and it was located on the E: drive (see Figure 5.2).
Also, the SDE user was created, and it was assigned to the SDE tablespace. It should be
noted that at a later time, the size of the MAXEXTENTS for the SDE tablespace was
altered to UNLIMITED, to allow more data to be added to the SDE tablespace.

create tablespace sde datafile

'E:\oracle\oradata\gis\sde01.dbf' size 108M reuse
autoextend on next 1280K
minimum extent 128K
default storage (initial 128K next 128K minextents 1
maxextents 4096 pctincrease 0 );
70

create user sde

identified by *******
default tablespace sde
temporary tablespace temp
quota unlimited on sde
quota unlimited on temp;

The SDE user is considered a creator of data in the ArcGIS system. A creator is allowed
to connect to an ArcSDE database and create data objects. The creator may grant
privileges on their objects to other users or roles. Other users can grant select and insert,
update, or delete on data objects they own to a creator user, such as SDE. The privileges
granted to the SDE user are illustrated below:

grant select any table to sde;

grant create session to sde;
grant create table to sde;
grant create procedure to sde;
grant create sequence to sde;
grant create trigger to sde;
grant unlimited tablespace to sde;

5.4 Designing the geodatabase

The schema design phase of the geodatabase is critical to the ultimate performance of the
ArcGIS system. As shown in Chapter 4 - Geodatabases, the types of data that can be

71

stored in a geodatabase are feature datasets, geometric networks, relationship classes,

annotation and other types of data.

5.4.1 Feature datasets

Feature datasets are a way to group feature classes with the same spatial reference
so that they can participate in topological relationships with one another. The feature
datasets exist in the geodatabase to define a scope for a spatial reference.
Usually, feature datasets have a natural way of organizing the data, much like a folder in
a file system. The natural temptation is to group a large number of feature classes into
feature datasets, but this comes with a cost: when a feature class that belong to a feature
dataset is opened, and the feature class is opened or queried in ArcMap or ArcCatalog, all
of the other feature classes that are part of the same feature dataset are also opened. That
could make that process expensive and time consuming because of its potential ripple
effect in opening all the feature classes.
Consequently, the best approach is to create feature datasets where the underlying feature
classes have a clear topological relationship with each other, such as, for example, a
geometric network and the shared boundaries. Having stand-alone feature classes into
based on a single feature dataset is perfectly acceptable. Usually, the feature classes
should be grouped into feature datasets if they are used together in most of the
applications.
For our project, the feature classes were not grouped, and consequently each
feature class is considered a feature dataset.

72

5.4.2 Geometric Networks

A geometric network is a user-defined collection of feature classes that form part

of a connected network of edges, junctions, and turns. When editing geometric networks
in ArcMap, topological relationships between features and feature classes are maintained
while the editing is done on the fly. The benefit is that there is no need to perform a
postediting BUILD on the geometric network in order to build topology. However, some
cost is imposed, and that is the time necessary to add or modify features in the network
feature classes.
Topological connectivity in a network feature class is based on geometric
coincidence. When a new feature class is added to a geometric network, this geometric
coincidence must be discovered. Thus, each feature class in the network must be
analyzed by performing a spatial query against each other network class to determine if
the new feature is coincident with other network features at any point, and if that is true,
then the user must create the connectivity.
The best approach to creating a geometric network that is not too slow while
editing is to group together the feature classes using subtypes. Also, the use of the edit
cache in ArcMap would reduce the editing time when the number of feature classes is
large.

5.4.3 Relationship Classes and Feature-linked Annotation

73

Relationship classes allow maintaining associations between objects in the

geodatabase. The relationships can be simple and passive, or they can be composite.
Composite relationships imply parent/child or composition and they have behavior. The
behavior is triggered when changes occur to an object on one side of the relationship to
the objects on the other side of the relationship.
When editing composite features, edits such as move, rotate or delete are cascaded to the
related objects through the relationship class. The cost involved when navigating these
relationships is minimized when indexes are maintained for the primary and foreign keys
for the relationship class.
Feature-linked annotations maintain the link between a feature and its annotation
element through a composite relationship. Feature-linked annotations has additional
behaviors to a typical composite relationship in that every time a new feature is created, a
new annotation feature is also created in any related annotation classes, unless this
behavior was disabled. It is highly recommended to have the feature-linked annotation
included in the feature dataset, and that allows opening all the related classes once they
are added to a map in ArcMap.

5.5 Establishing Connections to the Geodatabase

Starting with ArcSDE 8.1 (which is also the version of ArcSDE installed on our
computer), ArcSDE client applications can connect to either an ArcSDE service or
directly to an Oracle8i instance, as has been illustrated at section 3.3.1 - Database
connection configuration options. The direct connection capability, added during the

74

ArcSDE 8.1 release, was achieved by embedding the ArcSDE application server
technology into the ArcSDE client software. Any application programmed with the
functionality of the ArcSDE 8.1 C or Java API libraries can connect directly to an
Oracle8i instance (ESRI, 2000b).
The ArcSDE clients that connect to an ArcSDE service send spatial requests to the
service. The ArcSDE service converts the spatial requests into SQL statements and
submits them to the Oracle 8i instance. Upon receiving results from the Oracle instance,
the ArcSDE service converts the result into spatial data recognizable to the ArcSDE
client.
To connect directly to an Oracle 8i instance it was necessary to configure the Oracle Net8
listener process on the database host, which listener process will listen for the Oracle 8i
client connections. The Oracle 8i Client must be installed on the client machines.
All ArcSDE client applications, such as ArcMap or ArcCatalog, function the same way
regardless of whether a user connects to an ArcSDE service or directly to an Oracle 8i
instance. The only difference occurs during the entry of the connection information.

5.5.1 Creating and starting the Net8 listener service

In order to establish a connection to the Oracle8i instance that is running on a remote

computer, it was necessary to configure and start the Oracle Net8 listener process. Oracle
allows configuring the Net8 listener to listen on just about any network protocol that
might exist in todays diverse computer network. However, the network protocol used for
our database host was the TCP/IP network protocol.

75

The Net8 configuration assistant was launched, and the listener was created in the
listener.ora file. The Welcome panel that appears can be seen in Figure 5.6.

Figure 5.6. The Welcome panel for the Net8 Configuration Assistant

The Net8 Configuration Assistant created the next listener.ora file:

# LISTENER.ORA Network Configuration File:

C:\oracle\ora81\network\admin\listener.ora

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))

76

)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = donald)(PORT =
1521))
)
)
(DESCRIPTION =
(PROTOCOL_STACK =
(PRESENTATION = GIOP)
(SESSION = RAW)
)
(ADDRESS = (PROTOCOL = TCP)(HOST = donald)(PORT =
2481))
)
)

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = C:\oracle\ora81)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = doru1.geo.wvu.edu)
(ORACLE_HOME = C:\oracle\ora81)
(SID_NAME = doru1)
)
(SID_DESC =
(GLOBAL_DBNAME = gis.geo.wvu.edu)
(ORACLE_HOME = C:\oracle\ora81)
(SID_NAME = gis)
77

)
)

The listener is using the TCP/IP network protocol and it is listening on port 1521.

In order to connect to the listener service, the listener should be started. That is
accomplished using the Services dialog box in the Control Panel window. After the
Services dialog box appears, clicking the Start button starts the Oracle Net8 service.

5.5.2 Net8 Client installation and configuration

To make a direct connection to an Oracle8i instance, Oracle Client must be

installed on the client machines. Oracle Client is shipped with the Oracle8i Enterprise
Edition. Oracle Client includes the installation of the Oracle Net8 software, which is
necessary to connect to an Oracle server.
The Oracle 8i Client is installed using the Oracle Universal Installer (Figure 5.1). In the
Oracle Universal Installer, the Net8 Configuration Assistant allows for the creation of
Local Net Service Name configuration, where the name of the database to connect to was
provided (in our case, gis.geo.wvu.edu) along with the network protocol to be used for
connection, namely the TCP/IP protocol. The name of the host computer needed to be
provided, in our case Donald. The Net8 Configuration Assistant allows testing the
connection, by entering the sde username and the password for that user.

78

5.5.3 Connection to the Oracle 8i net service name or to an ArcSDE

service

ESRI application software (ArcMap or ArcCatalog) uses the same graphical user
interface to connect directly to an Oracle8i instance as to an ArcSDE service.

5.5.3.1 Direct Connecting to the Oracle 8i instance from ArcCatalog

The SDE Connections dialog box appears after a double-click on the Database
Connections followed by a double-click on Add SDE Connection.
To connect to an Oracle 8i instance, enter sde:oracle in the Service field.
In the User Name field, enter the Oracle8i username. The username in this example is
sde. In the Password field, enter the Oracle8i password, optionally, followed by the at
sign "@" and the Oracle8i net service name.

The Spatial Database Connection Panel is illustrated in figure 5.7.

79

Figure 5.7. The Spatial Database Connection Panel for Direct Connection

5.5.3.2 Connecting to an ArcSDE service from ArcCatalog

The SDE Connections dialog box appears after a double-click on the Database
Connections followed by a double-click on Add SDE Connection.
To connect to an ArcSDE service, the user has to enter the server name in the Server
field.
In the Service field, enter the ArcSDE service.
In the User Name field, enter the Oracle username.

80

In the Password field, enter the Oracle password.

The Database field is not required for connections to ArcSDE for Oracle services.
The Spatial Database Connection Panel is illustrated in figure 5.8.

Figure 5.8. The Spatial Database Connection Panel for ArcSDE service connection

Some of the connection problems that occurred were solved courtesy of the technical
support of ESRI.

81

5.5.4 Monitoring the connections to the ArcSDE services

The connections to the ArcSDE services can be monitored using the sdemon
administration command. The command provides a variety of administrative information,
including:

The current mode of the ArcSDE service;

The number of clients using the service;

Information about each client/server connection;

Current ArcSDE service configuration.

To list all the server process information related to the current user connections, the
command to be used is sdemon o info I users, and an example of a run of the
command can be seen below.

Figure 5.9. The command used to display the ArcSDE user session information

82

5.6 Loading the data The Initial Load

After the geodatabase was designed and tuned, the data to be loaded into the
geodatabase was preprocessed by being reprojected to the same coordinate system (UTM
NAD27). Also, each of the coverages to be loaded into the geodatabase was clipped using
the West Virginia boundary coverage. The Elevation data was converted into two
coverages (elevation point coverage; slope and aspect polygon coverage) because the
TINs are not yet supported in the ArcSDE geodatabase.

Then, the tools used to convert the data from coverages, shapefiles and images into
geodatabase tables were administration tools provided by ArcSDE or ArcToolbox
conversion tools provided by the ArcGIS system.
In Table 5.2 can be seen which tool/administration command was used to convert the
data and load it to the geodatabase.

83

Table 5.2. ArcSDE administration commands and ArcToolbox tools used for data conversion

Data Set
Geodetic
control data
Orthoimagery
Elevation

Data type before

conversion
Shapefile
TIFF image, 3 bands
Point Coverage
Elevation data
Polygon Coverage
Slope and Aspect data

Transportation Shapefile
Hydrography

Shapefile

Governmental
units
Cadastral
information

Shapefile
Polygon Coverage for
each Tax District

Tool/Administration
command used
shp2sde ArcSDE
command
Raster to Geodatabase
tool from ArcToolbox

Geodatabase table
created
DB_SURVEY
MCO_ORTHO
DB_ELEV

cov2sde ArcSDE
command

shp2sde ArcSDE
command
shp2sde ArcSDE
command
shp2sde ArcSDE
command
cov2sde ArcSDE
commands

DB_SLOPE
DB_RDS
DB_HYDRO
DB_BND
DB_CAD_CASS,
DB_CAD_CLIN,
DB_CAD_MGN,
DB_CAD_UNION

Each of the ArcSDE administration commands, shp2sde and cov2sde includes a -o

create operation, which allows the user to create a new feature class within the ArcSDE
database.
The create operation does all of the following:

Creates the business table using the input data as the template for the schema;

Adds the feature class to the ArcSDE system tables;

Puts the feature class into load-only mode;

Inserts data into the feature class;

84

When all the records are inserted, puts the feature class into normal_io mode.

5.6.1 shp2sde

shp2sde converts shapefiles into ArcSDE feature classes. The spatial column
definition is read directly from the shapefile. The shpinfo command can be used to
display the shapefile column definitions.
An example of using the shp2sde administration command is illustrated in the figure
below.

Figure 5.10. Example of the shp2sde administration command used to load the Roads shapefile into
the ArcSDE geodatabase

85

5.6.2 cov2sde

The cov2sde command converts ArcInfo coverages, ArcInfo Librarian library

feature classes, and ArcStorm library feature classes into ArcSDE feature classes. The
create operation derives the spatial column definition from the coverages feature
attribute table.

Figure 5.11. Example of usage of the cov2sde administration command and the use to load the
Elevation point coverage into the ArcSDE database

86

5.6.3 Creating and populating raster columns

Raster columns are created from the ArcGIS Desktop using ArcCatalog or
ArcMap. To create a raster column, first it is necessary to convert the image file into a
format acceptable to ArcSDE. Then after the image has been converted to the ESRI raster
file format it is possible to convert it into a raster column. A raster column is added to a
business table, and each cell of the raster column contains a reference to a raster stored in
a separate raster table. Therefore, each row of a business table references an entire raster.

For our project, the raster file was converted into a 3-band TIFF file, and than
loaded into the geodatabase using the Raster to Geodatabase tool from ArcToolbox.

5.6.4 Loading Annotation

Annotations can be created in bulk in the geodatabase by converting labels to

annotation in ArcMap or by converting coverage annotation by loading it into an
annotation feature class. The annotation feature class will be added to the feature dataset.

5.7 Compressing the database

As the ArcSDE geodatabase is edited over time, the number of database states and
rows in each feature classs delta tables will increase. Some of the database states may no
87

longer be referenced by a version, but the edits or rows associated with those database
states may still exist in the delta tables. Unfortunately, all queries will become slower as
the number of rows increase in the delta tables, just as any query would as the number of
rows increased in the table.
Running the compress command from ArcCatalog or from ArcSDE removes all
database states that are no longer referenced by a version and move all the rows in the
delta tables, which are common to all versions, to the base table. By reducing the number
of rows in the delta tables, performance will improve. The Compress (in ArcCatalog) or
sdeversion o compress (in ArcSDE) command should be run periodically throughout the
life of the geodatabase.
An example of a run of the administration command sdeversion o compress is
illustrated in the figure below.

Figure 5.12. A run of the administration command sdeversion o compress

88

To achieve the maximum benefit when running the compress command, first it is
necessary to reconcile, post and delete each version with the DEFAULT version prior to
executing the command.
Finally, after performing the compress it is extremely important to update the database
statistics for each of the feature classes by running the ArcSDE command sdetable o
update_dbms_stats.
An example of a run of the administration command sdetable o
update_dbms_stats is illustrated in the figure below.

Figure 5.13. A run of the administration command sdetable o update_dbms_stats

5.8 Loading the data Appending Data to an Existing Feature

Class

After the geodatabase is built and the data is loaded, at some point in time it is
necessary to append another area of data to the existing database.

89

The administration commands to be used are shp2sde or cov2sde when there are to be
appended shapefiles or coverages to the existing data. These data loading commands
have an -o append operation for appending data. A feature class must exist prior to
using the append operation. If a feature class is multiversioned, it must be in an open
state. It is also advisable to change the feature class to load-only I/O mode and pause the
spatial indexing operations before appending the data to improve the data loading
performance. The spatial indexes will be recreated when the feature class is put back into
normal I/O mode. Because the feature class has been defined, the metadata exists and is
not altered by the append mode.
In the example below, there is data appended to the existing db_rds feature class (which
holds the roads of Monongalia County, WV). All the existing features remain intact, and
another shapefile, named rdshp2, is appended to the existing table /feature class in the
geodatabase.

sdelayer o load_only_io l db_rds,shape i esri_sde

-D gis

u sde p *********
shp2sde o append f rdshp2 l db_rds, shape i esri_sde
gis

-D

u sde p *********

sdelayer o normal_io l db_rds,shape i esri_sde

-D gis

u sde p *********
sdetable o update_dbms_stats t db_rds m COMPUTE n ALL
i esri_sde

-D gis

u sde p *********

90

Note the last command in the sequence. The sdetable o update_dbms_stats operation
updates the table and index statistics required by the Oracle cost-based optimizer.
Without the statistics the optimizer may not be able to select the best execution plan
when the table is queried.

5.9 Tuning the Application

A good enterprise geodatabase system does not stop at the data model and database
tuning. The way a user works with the data will play a large role in determining how well
the system performs. It is important to note that the map layers and the ArcMap
documents can be considered just as important a part of the geodatabase as the data in the
geodatabase itself. There are many details associated with working with a geodatabase,
and they will be discussed below.

5.9.1 Map Documents and Layer Files

The map documents and the layer files are important parts of the geodatabase.
They can be created and used to provide ArcMap environments that perform well and
prevent users for performing operations against the database that will take a lot of server
resources and slow the system.
An example of the layer files created from the data loaded into the geodatabase is
illustrated in the figure below.

91

Figure 5.14. The layer created from the gis geodatabase

5.9.1.1 Scale suppression and overview layers

It is useful to use scale suppression in both ArcMap and layer files such that
layers only draw at scales where their information can be visualized in a meaningful way.
Zooming out to a scale and drawing 500,000 features is very costly on both the server
and the client and does not have much benefit.

92

Also, there should be an overview layer that has a small number of features and
can be easily viewed at the full scale of the map such as a reference grid.

5.9.1.2 The right classes in the right map documents

Often there are a number of different types of users with different types of
interests regarding the job they do in the GIS enterprise. Therefore it is recommended to
create map documents that contain the classes from the database that are required by that
particular user or application. The fewer the classes on the map, the fewer queries against
the server every time an operation such as pan, zoom or identify is performed.

5.9.1.3 Choosing the right symbology

ArcInfo includes a large collection of symbology with symbols for various

industry domains. Some symbols are simple single-layer symbols, while others are a
more complex mixture of a number of layers. The time it takes to draw features is related
to the style of symbology you choose to draw them with.
It is important to realize the function that each group of users in the organization
is doing when choosing the symbology for that group of users. For example, users that
read the data from the database for the purpose of making maps and for performing visual
analysis will require maps with sophisticated symbology for helping in doing their tasks.

93

Those users who maintain and update the data may not require such complex symbology
to get their work done.
Below is illustrated an example of the symbology used to display the Morgantown
area roads.

Figure 5.15. Symbology used to display the Morgantown area roads

94

5.9.2 Working with Data

5.9.2.1 Browsing the data

When using ArcCatalog to browse the contents of the geodatabase it is very

useful to create thumbnails of the feature classes. Using thumbnails allows having a
visual representation of the data without having to actually open the feature class, execute
a query against the server and draw the data. This also prevents from unnecessarily
drawing large amounts of data at full scale, which would impose a heavy load on the
database server.
An illustration of the thumbnails used to browse the geodatabase feature classes
can be seen below.

95

Figure 5.16. Thumbnails used to browse the connection to the ArcSDE service

96

5.9.2.2 Creating metadata

Metadata stores information about the collection of data in the geodatabase.

Metadata in ArcCatalog consists of properties and documentation. Properties, such as the
extent of a feature class, are derived from the item itself. Documentation is descriptive
information supplied by the creator of the geodatabase.
The contents of the feature classes metadata can be documented using the
ArcCatalog metadata editor, which allows describing the project for which the data was
created, describing the general area in which the data is located, or giving a warning to
users that the data in the folder is incomplete. This type of information can be helpful
when people are browsing for data.
An example of the metadata entered for the DB_BND feature class is illustrated
in the figure below.

97

Figure 5.17. Metadata for the Monongalia county, DB_BND feature class

5.9.2.3 Using the edit cache

When editing the data in the geodatabase, one of the most important tools to use
to improve performance is the edit cache. The edit cache is caching the data from the
server on the client. This caching of data cuts down on the number of queries that the
client needs to execute on the server during editing.
The edit cache can not only make editing faster, but also drawing, selecting, and
identifying features that are cached. Spatial information is cached only so any attribute
98

queries or navigating to related objects outside the cache will not benefit from the cache.
Also, the undo operation is significantly slower when using the cache.
In order to use the cache, it is necessary to build the edit cache by clicking on the Build
Edit Cache command on the Editor toolbar of ArcMap. This command will create the
cache for the features in the current map extent. If the user pans or zooms out of that area,
the edit cache must be rebuilt.

5.9.2.4 Versioning the data

The geodatabase is designed to efficiently manage and support long transactions

using versioning. Versioning allows users to simultaneously create multiple, persistent
representations of the database without data replication. The geodatabase also allows
multiple users to edit the same versions at the same time. Each edit session in ArcMap is
its own representation of the version until it is saved. Saving the edit session applies the
modifications made to the versions, making these changes immediately accessible in the
database. The versions are maintained in the delta tables, and they can be accessed during
connection establishment to the database. In the Database Connection panel exits the
possibility to select the version the user want to work on, edit it and save the edits after
the editing work is complete.

5.9.2.5 Different accounts for different users

99

Each user of the geodatabase should have a separate database account. This is not
only an important security reason, but it is beneficial for database maintenance. Having a
different database account for each user means their selections will be written to their
own redo log tables and will not be contending with other users for writing to a common
redo log table.

5.10 Indexing and Querying the Data

5.10.1

Indexing the tables

The indexing methods that can be used in the tables belonging to the gis
geodatabase have been introduced in section 2.7 Indexing of Spatial Data. The indexing
methods we used are the R-tree indexing and the quadtree indexing. When a quadtree
index was used, the tiling level was estimated using the
SDO_TUNE.ESTIMATE_TILING_LEVEL function. An example of a run of the
function can be seen below. Another approach of estimating the tiling level is to use the
Oracle Spatial Index Advisor, provided by Oracle.

100

5.10.1.1 SDO_TUNE.ESTIMATE_TILING_LEVEL

This analysis method estimates a tiling level which is then used as a starting point
for the Sampling analysis method. To find the tiling level, the Wizard uses 10,000 tiles to
cover the minimum bounding rectangle (MBR) that encompasses all geometries.
An example of the SQL statement for the SDO_TUNE.ESTIMATE_TILING_LEVEL
method can be seen below.

SET SERVEROUTPUT ON;

DECLARE
table_name varchar2(32) :='DB_HYDRO';
column_name varchar2(32) := 'SHAPE';
maxtiles integer := 10000;
type_of_estimate varchar2(32):= 'AVG_GID_EXTENT';
ret_number number;

BEGIN
ret_number := SDO_TUNE.ESTIMATE_TILING_LEVEL(
table_name,
column_name,
maxtiles,
type_of_estimate);
DBMS_OUTPUT.PUT_LINE('Tiling level for: ' || table_name || '
is equal to: ' || ret_number);
END;

Tiling level for: DB_HYDRO is equal to: 13

101

5.10.1.2 R-tree index creation

The R-tree index is the default index used by Oracle Spatial. Some of the characteristics
of the R-tree index are specified below.

The approximation of geometries cannot be fine-tuned. (Oracle Spatial uses the

minimum bounding rectangles, or MBR.). The size of the MBR can be estimated
using the SDO_TUNE.AVERAGE_MBR procedure supplied by Oracle Spatial.

Index creation and tuning are easier than with quadtree indexes.

Less storage is required than with quadtree indexes.

If there is heavy update activity to the spatial column, an R-tree index may not be
a good choice.

An example of the SQL statement for creating an R-tree index can be seen below.

CREATE INDEX ELEV_INDX

ON DB_ELEV(SHAPE) INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS ('SDO_INDX_DIMS=2 TABLESPACE="INDX"');
Index created.

102

5.10.1.3 Quad tree index creation (fixed size)

Some characteristics of the quadtree indexes are specified below.

The approximation of geometries can be fine-tuned by setting the tiling level

(SDO_LEVEL) and number of tiles (SDO_NUMTILES).

Tuning is more complex than with R-tree indexes, and setting the appropriate
tuning parameter values can affect performance significantly.

More storage is required than with R-tree indexes.

Heavy update activity does not affect the performance of a quadtree index.

An example of the SQL statement for creating a quadtree index can be seen below.
CREATE INDEX HYDRO_INDX
ON DB_HYDRO(SHAPE) INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS ('SDO_LEVEL=13 SDO_COMMIT_INTERVAL=-1
TABLESPACE="INDX"')
Index created.

The indexes created for each of the tables belonging to the gis geodatabase are
summarized in the following table.

103

Table 5.3. Types and names of spatial indexes created in the geodatabases tables

Table name

DB_SLOPE
DB_ELEV
DB_SURVEY
DB_BND
DB_RDS
DB_HYDRO
DB_CAD_CASS
DB_CAD_CLIN
DB_CAD_UNIO
DB_CAD_MGN

Estimated
Tiling
Level
15
6
6
6
15
13
12
13
13
13

Type of index
created

Name of index
created

R-tree index
R-tree index
R-tree index
Quadtree index
Quadtree index
Quadtree index
R-tree index
R-tree index
R-tree index
R-tree index

SLOPE_INDX
ELEV_INDEX
SURVEY_INDEX
BND_INDX
RDS_INDX
HYDRO_INDX
CAD_CASS_INDX
CAD_CLIN_INDX
CAD_UNIO_INDX
CAD_MGN_INDX

5.10.1.4 Using the Oracle Spatial Index Advisor

The Spatial Index Advisor application helps database administrators to create,

analyze and tune Oracle Spatial indexes, in order to achieve good performance for spatial
queries. The application allows analyzing layers of spatial data (type
MDSYS.SDO_GEOMETRY). The data represents objects such as rectangles, circles,
polygons, and arcs, all of which are displayed graphically.
A spatial index contains a set of tiles, and the DBA controls the size and number of tiles.
As has been shown earlier, the coverage of the geometries by the tiles has a direct impact
on query performance. This application allows seeing the interaction of the tiles with the
geometries.

104

Figure 5.18. The panel of the Oracle Spatial Index Advisor

105

5.10.2

Querying the data

The query model for Oracle Spatial has been described in section 2.6 The Query
Model. Essentially, Oracle Spatial uses a two-tier query model, based on a primary filter
(that uses index tiles to reduce computational complexity, by using the SDO_FILTER
operator), and on a secondary filter (that uses the SDO_RELATE operator, and is
computationally more expensive).
Naturally, querying the data can be accomplished in both Oracle 8i and ArcMap.
In Oracle 8i the queries are created by using the SQL*Plus Worksheet, while in ArcMap
the queries are created using the Query Builder from the Selection menu. The main
differences are:

The SQL*Plus Worksheet allows for a whole range of SQL and PL/SQL
queries that are not possible to be built in ArcMap, but the results are in
text format only.

The ArcMap Selection menu allows for simplified queries, but the results
are visually displayed in the ArcMap panel.

The right combination of both types of queries would produce the best results. Some of
the most important geometry functions and procedures that are used to query the data are
illustrated in the table below.

106

Table 5.4. Geometric Functions for querying the Object-Relational Model

Name of function or procedure

SDO_GEOM.RELATE
SDO_GEOM.SDO_AREA
SDO_GEOM.SDO_BUFFER
SDO_GEOM.SDO_CENTROID
SDO_GEOM.SDO_DIFFERENCE

SDO_GEOM.SDO_DISTANCE
SDO_GEOM.SDO_INTERSECTION

SDO_GEOM.SDO_LENGTH
SDO_GEOM.VALIDATE_GEOMETRY
SDO_GEOM.VALIDATE_LAYER
SDO_GEOM.WITHIN_DISTANCE

Description
Determines how two objects interact
Computes the area of a two-dimensional polygon
Generates a buffer polygon around a geometry
Returns the centroid of a polygon
Returns a geometry object that is the topological
difference (MINUS operation) of two geometry
objects
Computes the distance between two geometry objects
Returns a geometry object that is the topological
intersection (AND operation) of two geometry
objects
Computes the length or perimeter of a geometry
Determines if a geometry is valid
Determines if all the geometries stored in a column
are valid
Determines if two geometries are within a specified
Euclidean distance from one another

Also, the spatial operators used for querying the data have been described in section 2.8 Spatial Relations and Filtering. The spatial operators used for querying are:
SDO_FILETER, SDO_NN, SDO_RELATE and SDO_WITHIN_DISTANCE.

Further, some queries will be created to illustrate the use of the data.

In order to query the data, we consider a simple scenario: determine an area of

land to be purchased by a federal agency, which needs a surface of 150 to 200 hectares of
land to build its facilities. The parcel needs to be within 15 km of Morgantown Airport, to
be for sale, to have access to road and possibly be close to a river, and to have a low slope
that permits for buildings to be raised.

107

5.10.2.1 Query example 1 Determine the areas larger then 150 hectares and
smaller than 200 hectares in the Cass Tax District

SELECT OBJECTID "PARCEL ID", SDO_GEOM.SDO_AREA(C.SHAPE,

M.DIMINFO)"AREA (IN SQUARE M)"
FROM DB_CAD_CASS C, USER_SDO_GEOM_METADATA M
WHERE M.TABLE_NAME = 'DB_CAD_CASS' AND M.COLUMN_NAME =
'SHAPE' AND AREA > 1500000 AND AREA < 2000000;

The result is illustrated below.

PARCEL ID AREA (IN SQUARE M)
---------- -----------------300

1632832.71

1824

1767479.18

The result is also obtainable using the Selection menu from ArcMap, and the selected
data can be displayed in the map. The selected data is illustrated below.

108

Figure 5.19. Areas selected using the Selection menu in ArcMap

It would be more appropriate to have information regarding ownership of the

parcels, but we did not have access to the table with owner names for each parcel. If we
had that table, we could easily import it and create a relationship between tax parcels and
parcel owners. For our scenario, we could consider that the parcel with the OBJECTID =
1824 is the one we are interested into, because it has an area close to our needs, namely it
has 176.7 hectares and we contacted the owner and determined that it is for sale.
5.10.2.2 Query example 2 - Is the tax parcel selected within 15 km of the
Morgantown Airport?

109

The following SQL script determines if the distance between the selected tax parcel and
the Morgantown Airport is within 15 km.

SELECT SDO_GEOM.WITHIN_DISTANCE(G.SHAPE, M.DIMINFO, 15000,

C.SHAPE, M.DIMINFO)
FROM DB_CAD_MGN G, DB_CAD_CASS C, USER_SDO_GEOM_METADATA M,
USER_SDO_GEOM_METADATA N
WHERE M.TABLE_NAME = 'DB_CAD_MGN' AND M.COLUMN_NAME =
'SHAPE'
AND N.TABLE_NAME = 'DB_CAD_CASS' AND N.COLUMN_NAME = 'SHAPE'
AND G.OBJECTID = 2124 AND C.OBJECTID = 1824;
SDO_GEOM.WITHIN_DISTANCE(G.SHAPE,M.DIMINFO,15000,C.SHAPE,M.D
IMINFO)
-----------------------------------------------------------TRUE

The distance between the tax parcel and the airport can more easily be determined using
the Measure tool in ArcMap. The distance determined is 14.5 km and it can be seen in the
figure below.

110

Figure 5.20. Measuring the distance between the chosen tax parcel and the Morgantown Airport

5.10.2.3 Query example 3 What are the average slope and the average elevation of
the tax parcel selected for auction?

The following PL/SQL script determines the average slope and the average elevation for
the tax parcel.

SET SERVEROUTPUT ON;

111

DECLARE
OBJ1 MDSYS.SDO_GEOMETRY;
AVG_SLOPE DB_SLOPE.DEGREE_SLOPE%TYPE;
AVG_ELEV DB_ELEV.SPOT%TYPE;
BEGIN
SELECT SHAPE INTO OBJ1 FROM DB_CAD_CASS WHERE OBJECTID =
1824;
SELECT AVG(DEGREE_SLOPE)
INTO AVG_SLOPE
FROM DB_SLOPE S
WHERE SDO_RELATE(S.SHAPE, OBJ1, 'MASK=INSIDE
QUERYTYPE=WINDOW') ='TRUE';
SELECT AVG(SPOT)
INTO AVG_ELEV
FROM DB_ELEV E
WHERE SDO_RELATE(E.SHAPE, OBJ1, 'MASK=INSIDE
QUERYTYPE=WINDOW') ='TRUE';
DBMS_OUTPUT.PUT_LINE('Average SLOPE for the tax parcel is
equal to: ' || AVG_SLOPE || ' degrees.');
DBMS_OUTPUT.PUT_LINE('Average ELEVATION for the tax parcel
is equal to: ' || AVG_ELEV || ' meters.');
END;

Average SLOPE for the tax parcel is equal to: 13.273

degrees.

112

Average ELEVATION for the tax parcel is equal to: 408.442

meters.
5.10.2.4 Query example 4 How is the area of the parcel grouped into different
angle slopes (Using PL/SQL)?

The following PL/SQL script determines the classification of slopes in the tax parcel we
have chosen. The window with the ID CASS_1824 that is used for filtering is stored in a
table named Windows.

SET SERVEROUTPUT ON;

DECLARE
CURSOR C1 IS SELECT S.DEGREE_SLOPE, S.AREA
FROM DB_SLOPE S, WINDOWS W
WHERE W.ID ='CASS_1824' AND SDO_RELATE(S.SHAPE,
W.SHAPE, 'MASK=INSIDE QUERYTYPE=WINDOW') ='TRUE';

AREA_SLOPE_MAX_5 DB_SLOPE.AREA%TYPE := 0;
AREA_SLOPE_5_15 DB_SLOPE.AREA%TYPE := 0;
AREA_SLOPE_MIN_15 DB_SLOPE.AREA%TYPE := 0;
TOT_AREA DB_SLOPE.AREA%TYPE := 0;
BEGIN
FOR C1_REC IN C1 LOOP
TOT_AREA := TOT_AREA + C1_REC.AREA;

113

IF C1_REC.DEGREE_SLOPE <= 5 THEN

AREA_SLOPE_MAX_5 := AREA_SLOPE_MAX_5 + C1_REC.AREA;
ELSIF
C1_REC.DEGREE_SLOPE > 5 AND C1_REC.DEGREE_SLOPE < 15
THEN
AREA_SLOPE_5_15 := AREA_SLOPE_5_15 + C1_REC.AREA;
ELSIF
C1_REC.DEGREE_SLOPE >= 15 THEN
AREA_SLOPE_MIN_15 := AREA_SLOPE_MIN_15 + C1_REC.AREA;
END IF;

END LOOP;
DBMS_OUTPUT.PUT_LINE (' FLAT AREA (SLOPE < 5 DEGREES): ' ||
AREA_SLOPE_MAX_5 || ' HECTARES');
DBMS_OUTPUT.PUT_LINE ('LOW SLOPE AREA (SLOPE BETWEEN 5 AND
15 DEGREES): ' || AREA_SLOPE_5_15 || ' HECTARES');
DBMS_OUTPUT.PUT_LINE ('HIGH SLOPE AREA (SLOPE > 15 DEGREES):
' || AREA_SLOPE_MIN_15 || ' HECTARES');
DBMS_OUTPUT.PUT_LINE ('TOTAL AREA ' || TOT_AREA || '
HECTARES');
END;
FLAT AREA (SLOPE < 5 DEGREES): 168224.92453 HECTARES
LOW SLOPE AREA (SLOPE BETWEEN 5 AND 15 DEGREES):
752806.53726 HECTARES
HIGH SLOPE AREA (SLOPE > 15 DEGREES): 407010.85907 HECTARES
TOTAL AREA 1328042.32086 HECTARES

114

It can be seen that the total area is not equal to the area of the tax parcel. That is due to
the topological relationship used (MASK INSIDE), that does not take into consideration
the parts of the slope polygons that are intersected by the tax parcels boundary.

5.10.2.5 Query example 5 How is the area of the parcel grouped into different
angle slopes (Using SQL)?

The same results from above can be obtained using an SQL query.

SELECT
SUM(DECODE(TRUNC(DEGREE_SLOPE/5, 0), 0, AREA))"SLOPE <5",
SUM(DECODE(TRUNC(DEGREE_SLOPE/5, 0), 1, AREA))"SLOPE 5-10",
SUM(DECODE(TRUNC(DEGREE_SLOPE/5, 0), 2, AREA))"SLOPE 10-15",
SUM(DECODE(TRUNC(DEGREE_SLOPE/5, 0), 3, AREA))"SLOPE 15-20",
SUM(DECODE(TRUNC(DEGREE_SLOPE/5, 0), 4, AREA))"SLOPE 20-25",
SUM(DECODE(TRUNC(DEGREE_SLOPE/5, 0), 5, AREA))"SLOPE 25-30",
SUM(DECODE(TRUNC(DEGREE_SLOPE/5, 0), 6, AREA))"SLOPE 30-35",
SUM(DECODE(TRUNC(DEGREE_SLOPE/5, 0), 7, AREA))"SLOPE 35-40",
SUM(AREA) "TOTAL AREA"
FROM DB_SLOPE S
WHERE SDO_RELATE(S.SHAPE, (SELECT SHAPE FROM DB_CAD_CASS
WHERE OBJECTID = 1824), 'MASK=INSIDE QUERYTYPE=WINDOW')
='TRUE';

The result is displayed below, and it has been flipped on its side for presentation purpose.

SLOPE <5

168224.925

SLOPE 5-10

478039.161

115

SLOPE 10-15

274767.377

SLOPE 15-20

309346.945

SLOPE 20-25

56542.2663

SLOPE 25-30

35046.8593

SLOPE 30-35

4672.91456

SLOPE 35-40

1401.87437

TOT_AREA

1328042.32

5.10.2.6 Query example 6 - Are there any roads or rivers inside the selected tax
parcel?

The SQL query for determining the roads inside the tax parcel is illustrated below.

COL RELATION FORMAT A10;

COL ROADID FORMAT 999999999;
SET PAGESIZE 80;
SELECT SDO_GEOM.RELATE(R.SHAPE, M.DIMINFO, 'DETERMINE',
C.SHAPE, N.DIMINFO) "RELATION",
R.OBJECTID "ROADID", R.FNAME "ROAD NAME"
FROM DB_RDS R, DB_CAD_CASS C, USER_SDO_GEOM_METADATA M,
USER_SDO_GEOM_METADATA N
WHERE M.TABLE_NAME = 'DB_RDS' AND M.COLUMN_NAME = 'SHAPE'
AND C.OBJECTID = 1824
AND N.TABLE_NAME = 'DB_CAD_CASS' AND N.COLUMN_NAME = 'SHAPE'
AND (SDO_GEOM.RELATE(R.SHAPE, M.DIMINFO, 'ANYINTERACT',
C.SHAPE, N.DIMINFO) = 'TRUE');

116

The SQL query for determining the rivers inside the tax parcel is illustrated below.

col RELATION format a10;

col RIVERID format 999999999;
SELECT SDO_GEOM.RELATE(R.SHAPE, M.DIMINFO, 'DETERMINE',
C.SHAPE, N.DIMINFO) "RELATION",
R.OBJECTID "RIVERID", R.FNAME "RIVER NAME"
FROM DB_HYDRO R, DB_CAD_CASS C, USER_SDO_GEOM_METADATA M,
USER_SDO_GEOM_METADATA N
WHERE M.TABLE_NAME = 'DB_HYDRO' AND M.COLUMN_NAME = 'SHAPE'
AND C.OBJECTID = 1824
AND N.TABLE_NAME = 'DB_CAD_CASS' AND N.COLUMN_NAME =
'SHAPE'
AND (SDO_GEOM.RELATE(R.SHAPE, M.DIMINFO, 'ANYINTERACT',
C.SHAPE, N.DIMINFO) = 'TRUE');

The roads information is presented below.

RELATION

ROADID ROAD NAME

---------- ---------- -----------------------------OVERLAPBDY

3231 County Rte 7/16

DISJOINT
INSIDE

3682 County Rte 7/16

The rivers information is presented below.

RELATION

RIVERID RIVER NAME

---------- ---------- -----------------------------OVERLAPBDY

827 Scotts Run

117

DISJOINT
OVERLAPBDY

915

DISJOINT
INSIDE

987

INSIDE

994

5.10.2.7 Query example 7 - Is Scotts Run creek inside Monongalia County

Boundary?

This query determines if a creek named Scotts Run is found in Monongalia County.

COL RELATION FORMAT A15;

SET PAGESIZE 80;
SELECT SDO_GEOM.RELATE(H.SHAPE, M.DIMINFO, 'DETERMINE',
B.SHAPE, M.DIMINFO) RELATION, H.OBJECTID, H.FNAME
FROM DB_HYDRO H, DB_BND B, USER_SDO_GEOM_METADATA M
WHERE M.TABLE_NAME = 'DB_HYDRO' AND M.COLUMN_NAME = 'SHAPE'
AND H.FNAME = 'SCOTTS RUN';

RELATION

OBJECTID FNAME

--------------- ---------- -----------------------------INSIDE

793 Scotts Run

INSIDE

795 Scotts Run

INSIDE

799 Scotts Run

INSIDE

800 Scotts Run

INSIDE

801 Scotts Run

INSIDE

802 Scotts Run

118

INSIDE

808 Scotts Run

INSIDE

809 Scotts Run

INSIDE

815 Scotts Run

INSIDE

820 Scotts Run

INSIDE

824 Scotts Run

INSIDE

827 Scotts Run

INSIDE

832 Scotts Run

INSIDE

833 Scotts Run

INSIDE

834 Scotts Run

INSIDE

835 Scotts Run

INSIDE

842 Scotts Run

INSIDE

843 Scotts Run

INSIDE

845 Scotts Run

INSIDE

846 Scotts Run

INSIDE

847 Scotts Run

INSIDE

848 Scotts Run

INSIDE

853 Scotts Run

INSIDE

872 Scotts Run

INSIDE

891 Scotts Run

INSIDE

894 Scotts Run

INSIDE

896 Scotts Run

INSIDE

899 Scotts Run

INSIDE

902 Scotts Run

INSIDE

905 Scotts Run

INSIDE

906 Scotts Run

INSIDE

919 Scotts Run

INSIDE

928 Scotts Run

INSIDE

933 Scotts Run

INSIDE

937 Scotts Run

INSIDE

939 Scotts Run

36 rows selected.

119

5.11 Diagnosing the Geodatabase

There are a series of recommendations outlined in the ArcInfo documentation, as

well as in the Oracle Spatial documentation. In this section I will discuss some of the
diagnostic tools that can be used to analyze the database performance.
The hard part about database tuning processes is identifying the performance problems
and where to look for bottlenecks.
One or all of the following can cause performance problems:

Application/Program tuning;

Database design and indexing;

Database tuning; and

OS Tuning.

Each one of the possible performance causes will be discussed below.

5.11.1

Application/Program tuning

Usually badly tuned queries can cause big performance problems. ArcInfo 8.1 and
ArcSDE 8.1 queries are optimized with database hints, but sometime those may fail.
Most causes for failure are incorrect statistics on the tables and indexes. Those are easily
fixed by recomputing statistics with the ANALYZE SQL statement. Missing indexes,

120

overindexing, or a badly configured System Global Area (SGA) might cause other
failures.

5.11.2

Database design and indexing

It is recommended to look for missing indexes and for overindexing, which can cause
bad performance with inserts. If the tables have not been analyzed and the statistics are
outdated, it is necessary to use the sdetable administration tool or the Oracles
ANALYZE command to analyze tables and indexes. An example of using the
ANALYZE command is shown below.

SQL> analyze table DB_HYDRO compute statistics;

Table analyzed.

5.11.3

Database tuning

Tuning a database is not a simple task and is an ongoing process. The Oracle SGA
must be properly tuned, and if necessary the performance monitor within the Oracle
Enterprise Manager should be used to check for memory usage, or write some SQL
scripts to do the same.
The data in the database should be spread on several disks (and possible devices) to avoid
I/O disk contention. The four most significant parameters to tune are

121

DB_BLOCK_BUFFERS, SHARED_POOL_SIZE, SORT_AREA_SIZE and

DB_BLOCK_SIZE.

In order to determine if the SGA is correctly configured, the following should be

checked:

Buffer cache hit ratio;

Data dictionary cache hit ratio;

Memory sort hit ratio;

I/O disk contention.

5.11.3.1 Buffer cache hit ratio

It lists the ratio in memory versus data read from disk for the system. The hit ratio should
be above 95%. If not, the DB_BLOCK_BUFFERS should be tuned.
The SQL script used to calculate the Buffer cache hit ratio was:

select
sum(decode(name, 'consistent gets', value, 0))"Consis Gets",
sum(decode(name, 'db block gets', value, 0)) "DB Blk Gets",
sum(decode(name, 'physical reads', value, 0)) "Phys Reads",
(sum(decode(name, 'consistent gets', value, 0)) +
sum(decode(name, 'db block gets', value, 0)) sum(decode(name, 'physical reads', value, 0))) /
(sum(decode(name, 'consistent gets', value, 0)) +
sum(decode(name, 'db block gets', value, 0)) ) * 100 "Hit
Ratio"

122

from v$sysstat;

The result is illustrated below.

Consis Gets DB Blk Gets Phys Reads

Hit Ratio

----------- ----------- ---------- ---------26566842

1135134

319669 98.8460426

5.11.3.2 Data dictionary cache hit ratio

The Data cache dictionary hit ratio displays the memory allocated for accessing Oracles
underlying tables. The value of the hit ratio should be above 95%, otherwise the
SHARED_POOL_SIZE should be tuned.
The SQL script used to calculate the Data dictionary cache hit ratio was:

select (1-(sum(getmisses)/sum(gets)))* 100 "Hit Ratio"

from v$rowcache;

The result is illustrated below.

Hit Ratio
---------99.2293617
5.11.3.3 Memory sort hit ratio

The Memory sort hit ratio displays the sorts performed in memory versus sorting from
temporary segments on the disk. It should be 99% or above. If not, the user should
123

increase the size of SORT_AREA_SIZE and SORT_AREA_RETAINED_SIZE. If the

SORT_AREA_SIZE is too high, it can cause the OS to run out of memory.

The SQL script used to calculate the Memory sort hit ratio was:

select a.value "Disk Sorts", b.value "Memory Sorts",

round (100*(b.value/decode((a.value + b.value), 0, 1,
(a.value + b.value))), 2) "Pct Memory Sorts"
from v$sysstat a, v$sysstat b
where a.name ='sorts (disk)' and b.name = 'sorts (memory)';
The result is illustrated below.
Disk Sorts Memory Sorts Pct Memory Sorts
---------- ------------ ---------------28

140433

99.98

124

5.11.3.4 I/O disk contention

The following script can be run to determine if the reads and writes are evenly
distributed.

drop table tot_read_writes;

create table tot_read_writes as select sum(phyrds)
phys_reads, sum(phywrts) phys_wrts
from v$filestat;
col name format a30
col phyreads format 999,999,999
col phywrts format 999,999,999
col read_pct format 999.99
col write_pct format 999.99
select name, phyrds * 100/trw.phys_reads read_pct, phywrts,
phywrts * 100 / trw.phys_wrts write_pct
from tot_read_writes trw, v$datafile df, v$filestat fs
where df.file# = fs.file#
order by phyrds desc;

The result is illustrated below.

NAME

READ_PCT

PHYWRTS WRITE_PCT

------------------------------ -------- ------------ --------E:\ORACLE\ORADATA\GIS\TEMP01.DBF

95.53

302,106

71.21

E:\ORACLE\ORADATA\GIS\SDE01.DBF

1.25

88,926

20.96

125

E:\ORACLE\ORADATA\GIS\SYSTEM01.DBF

.96

8,343

1.97

E:\ORACLE\ORADATA\GIS\RBS01.DBF

.47

18,562

4.38

E:\ORACLE\ORADATA\GIS\USERS01.DBF

.45

1,414

.33

E:\ORACLE\ORADATA\GIS\TOOLS01.DBF

.45

1,414

.33

C:\ORACLE\ORADATA\GIS\INDX01.DBF

.45

1,414

.33

E:\ORACLE\ORADATA\GIS\DR01.DBF

.45

1,414

.33

E:\ORACLE\ORADATA\GIS\OEM_REPO

.00

658

.16

SITORY.ORA
9 rows selected.

5.11.4

OS Tuning

There are a number of OS tools that can be employed to determine a problem with the
ArcSDE servers memory, the CPU and the disk configuration. Windows 2000 hasthe
Task Manager and the performance monitor which can monitor memory, processes,
disks, and so forth (Microsoft, 2000).

126

6. CONCLUSION
The ArcInfo geodatabase was implemented on an Object-Relational database in
Oracle 8i Enterprise Edition, which was extended with the Oracle Spatial option.
Implementing the geodatabase with the ArcSDE application server allowed providing
access to multiple users for both query and update (read/write) of the geographic data.
ArcSDE and ArcInfo support for long transactions through versioning allows users to
simultaneously create multiple, persistent representations of the database without data
replication. Since all changes are recorded in the delta tables, the users can edit the same
features or rows without explicitly applying locks to prohibit other users from modifying
the same data.
It is very important to understand that implementing a multi-user GIS system with
ArcInfo and ArcSDE requires planning and experimentation to be successful. Each stage
of the process, from the data model to database tuning and application design, has a
significant impact on how well the system performs. There are also some difficult tasks
to perform during ArcSDE installation and connections configuration, are not always
simple or easy to understand. Some problems we had were mainly solved using the
technical help provided by ESRI, and those problems required extensive experimentation
from our part until the correct results were achieved. One of the easiest tasks was
supposed to be the ArcSDE installation, but the whole process was repeated more than
five times until we were successful. Another problem was to establish a read/write
connection between the server and the client, and it took an extensive amount of time to
comprehend the exact process of doing that in the required way.

127

It is important to recognize that storing the data in a mature database application such as
Oracle would have a great impact on data maintenance and data retrieval and editing. The
main advantages of using a DBMS as a central repository for spatial data include:

Easier integration of spatial data with other core organizational data. The storage
of spatial and business data in the same database means reduced complexity,
management, and training costs;

Expanded database size limits;

Support for the larger number of users required for enterprise implementations;

The ability to take advantage of enhanced DBMS features such as administration

and maintenance utilities, replication, and faster backup and recovery;

The availability of Java and SQL as open application programming interfaces

(APIs);

The emergence of spatial standards for interoperability;

The ability to publish and distribute spatial data over private Intranets or the
public Internet.

On the other hand, ESRI's ArcGIS system, consisting of ArcInfo 8.1, ArcIMS 3, ArcSDE
8.1, ArcView 8.1 and other ESRI software programs, provides an open, standards-based
solution for environments ranging from handheld personal digital assistants (PDAs) to
thin Java-based browsers to thick clients used in traditional client/server environments.

ESRI's software in combination with the Oracle stored geodatabase can be used for a
variety of tasks including:

128

Data automation, maintenance, and publishing;

Simple query and access to content;

Data analysis;

Data and content display and map rendering;

SQL and geographic or spatial queries.

The combination of ArcInfo 8.1, ArcSDE 8.1, Oracle8i Enterprise Edition, and Oracle
Spatial provides a complete, integrated, and powerful enterprise GIS solution. In
summary, ArcInfo 8.1, with the ArcSDE 8.1 gateway, allows to:

Directly edit spatial information in Oracle Spatial;

Manage the edits of multiple users on the same geodatabase with long
transactions, alternate versions, and history;

Manage features in a geometric network. Connect and edit features as a graph of

related objects and perform network queries such as tracing and finding the
shortest path between locations;

Associate editing and mapping rules with features in the geodatabase. This means
that the user can define and manage associations between different feature classes
and objects such as between property parcels and owners or lot lines and zoning
boundaries.

If the ArcSDE application will become more user friendly in terms of installation
and the networking problems would be no more arcane, ArcSDE will become the

129

mainstream application server between the huge GIS data available and the users that
want to read or write that data. The ArcSDE application is highly recommended since
data will be more easily and naturally stored in spatially enhanced databases, i.e. Oracle
Spatial, that allow for much easier maintenance, and centralized storage and access to the
data. The process of accessing and editing the data would become more natural, while the
versioning of the data will allow for better and easier administration of the data.

130

References
ArcSDE Overview, May 26, 2001.
http://www.esri.com/software/arcinfo/arcsde/overview.html

Egenhofer, M., Clementini, E., Sharma, J., 1994. Modeling Topological Spatial
Relations: Strategies for Query Processing. Computers and Graphics, 18(6): 815822.

ESRI, 2000a. ESRI and Oracle Solutions for GIS and Spatial data Management, ESRI
White Paper, Environmental Systems Research Institute, Redlands, CA, 12 p.

ESRI, 2000b. ArcSDE Configuring and Tuning Guide for Oracle, ArcInfo 8.1,
Environmental Systems Research Institute, Redlands, CA, 164 p.

ESRI ArcNews, 2000, ESRI Passes Oracle Spatial Integration Test, vol.22 (3)

Federal Geographic Data Committee, 1997. Framework Introduction and Guide.

Federal Geographic Data Committee, Washington, D.C., 106 p.

Harris, M. and Stauder, R., 2001.Tuning and Configuring ArcSDE for Oracle and SQL
Server. Presentation at the 2001 ESRI Worldwide Business Partner Conference,
Palm Springs, CA, March 18-20, 2001.

Harris, M., 2000. Managing ArcSDE Services, Environmental Systems Research

Institute, Redlands, CA, 144 p.

Loney, K., Koch, G., 2000. Oracle 8i: The Complete Reference, Osborne/McGraw-Hill,
1308 p.

131

MacDonald, A., 2001. Building a Geodatabase, Environmental Systems Research

Institute, Inc., Redlands, California, 481 p.

Microsoft, 2000. Windows 2000 Performance Tuning, Microsoft Corporation, Redmond,

WA, 78 p.

OpenGIS Consortium, Inc., 1999. OpenGIS Simple Features Specification For SQL,
Revision 1.1. OpenGIS Project Document 99-049, May 5, 1999, 78 p.

OpenGIS Consortium, Inc., 2001. OpenGIS Implementation Specification: Coordinate

Transformation Services, Revision 1.00, OpenGIS Project Document 01-009, 12
January 2001, 117 p.

Oracle Corporation, 2000. Oracle Spatial User's Guide and Reference, Release 8.1.7,
September 2000. Part Number A85337-01, 464 p.

West, R., 2001. Understanding ArcSDE, Environmental Systems Research Institute, Inc.,
Redlands, California, 58 p.

Zeiler, M., 1999. Modeling Our World The ESRI Guide to Geodatabase Design.
Environmental Systems Research Institute, Inc., Redlands, California, 198 p.

132