Experiment
ESRI and MVD agreed to demonstrate the use of ESRI's SDE software using sample
data from the Rock Island and Vicksburg Districts, representative of the former UMV and
LMV Divisions, respectively. The implementation design was for demonstration purposes
and was not meant as a fully implemented system. The demonstration did, however, bring
to light some of the many decisions necessary if SDE is chosen as a solution to the prob-
lem.
Observations
Since SDE is middleware, it provides little to observe by way of demonstration. If it is
functioning with data loaded properly, it is virtually invisible. Most traditional types of
live demonstrations of SDE in action on a computer, at events such as conferences, work-
shops, or vendor exhibits, can only provide an abstract description of what the software is
doing, followed by the display of data of a GIS using SDE as a server. What one ends up
seeing is data in an ARC/Info, ArcView, MGE, or other GIS or CADD display. To under-
stand SDE, it is helpful to see it applied to a real-world problem, such as the sharing of the
disparate data types of the UMV and LMV Divisions. A further difficulty in understand-
ing SDE thoroughly is that one needs to have an understanding of the technologies with
which it operates, namely the particular GIS, CADD, and RDBMS softwares with which
it is to be used. It makes sense that a technology that offers a solution to such complex
problems will be somewhat complex to implement.
The most important part of applying SDE to a given situation is planning. It is impor-
tant to analyze the data that are to be loaded into SDE, so that proper choices can be
made concerning geodata issues (e.g., projection) and RDBMS issues (e.g., a proper data-
base schema). At the same time, considerations must be made based on how the data are
involved in the process flows of the organization and the logistics implied. By way of
example, several of the decisions faced in the MVD demonstration are described below.
Projection of geospatial data
UMV data were projected in UTM (Universal Transverse Mercator) while LMV used
Mississippi State Plane. Options in such a situation include: reprojecting data to a com-
mon projection before loading it into SDE, using client software to project data as it is
being served from SDE (if this is possible with the client software), or using the SDE pro-
jection engine "service" to handle projection "on the fly" as it serves the data. Of course,
other issues of projection can come into play. For instance, the UTM data were in zone 15.
If all data were to be projected to zone 15, this would have created problems, since all the
data being joined may not lie in the same UTM zone. By the same token, all the data are
not within Mississippi State Plane West. Projecting all data to decimal degrees may solve
this problem in terms of combining everything in SDE, but this solution may be unac-
ceptable for other reasons, such as incompatibility with established business practices or
exchange of data products among users and customers.
Spatial indexing grid
When loading data into the SDE system, up to three spatial indexing grids can be
defined. Choosing the size of the grid depends on the type of data, such as the size, shape,
and density of features.
Database schema
One database scheme uses SDE to communicate with the DBMS to create tables to
hold the data and then uses SDE to load the data into the tables. SDE groups its data into
three types of tables in the DBMS:
"F" tables, where features are stored
31
31
Previous Page
