"Business" tables, which store the feature attributes or tabular data
"S" tables, which provide spatial indexing one for each "F" table.
Meanwhile, since the attribute data are in the RDBMS, they may be linked with data-
base queries to other tables.
This implies that thought must be given to how the tables are designed. In the MVD
demonstration, this was handled differently for the UMV and LMV data. In the case of
UMV, the process was straightforward. ARC/Info coverages were converted to ArcView
shapefiles. These were loaded into the database with SDE functions that essentially create
database tables with columns configured automatically to match the ArcView shapefile
The LMV REEGIS data required use of the SDE CADD client software because the
data being used in the demonstration were created using MGE. Since the DBMS being
used was the same that is used by the MGE system, the tabular portion of the data that
were linked to the CADD data did not need to be loaded; elements that contained the
MSLINKS before storage in the SDE system would be returned with the same linkages.
The CADD client uses an interesting mechanism for dealing with the differences between
GIS and CADD representations of features. For instance, CADD is based more in geom-
etry, so that a center and radius may represent a circle object. Thus, if SDE is to be able
to serve CADD data to a GIS, there must be some reasonable way to make the translation.
The solution used by the CADD client is to create two columns for a given object in the
table holding geospatial data. One column holds the CADD object exactly as it is repre-
sented in the CADD, the other holds a GIS-styled representation of the object. Thus, if a
GIS requests the feature, it gets a representation it understands, but if the CADD requests
the object, it can get the original CADD object as it was created.
Some geospatial data, such as state boundaries, are static; others, such as riverbank
lines, change over time. Changes can include moving lines or points, such as in the case
of a meandering river; adding or deleting features, for instance, when a control structure
is installed or removed; or changing attributes, such as changing a name field when a
new owner buys a land parcel. The impression we have of SDE is that it does not support
dynamically changing geospatial data. The easiest type of change to make would be to
attribute data, e.g., the changing of a parcel owner's name, since such a change could be
done with a simple SQL (structured query language) change via the DBMS.
At the demonstration of SDE at the MVD, there was little discussion about how data
updates might be accommodated. The overt implication was that all data were static, but
in reality this would be rare. There will always be updates to a geospatial database such as
MVD's, so these needs should be included in the design of the system. Depending on the
frequency of changes and the need to publish the changes to the system, one way to deal
with updates is by making changes over time to the "source" data in their native format,
then at prescribed time intervals the old data in the SDE system could be replaced with the
updated source data using the same steps to load it, including any projecting or transform-
ing that was required.
Recall how the data in ARC/Info coverage format were first converted to ArcView
shapefile format before loading into SDE. It is likely that if updates were to be made, it
would be done with ARC/Info (rather than ArcView), since it has the GIS capability to
ensure the geospatial data integrity. This brings up the important point that, while SDE is
designed to handle geospatial data, it does not provide specialized functionality, such as
building or maintaining topology. The design of SDE expects the program that was used
to create the data (MGE, ARC/Info , etc.) is the "expert." Therefore, before data are loaded
into SDE, they should be properly created and "cleaned."
At the time of the MVD SDE demonstration, a looming issue for REEGIS was the Tri-