International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B2. Istanbul 2004
Initial Editors Post-Edit Reconciled
Versions Versions Versions
Default
Figure 2. A Disconnected Editing Versioning Scenario
Versioning strategies have to be well thought-out, and should
closely replicate quality assurance/quality control (QC/QA)
procedures within an organization.
3.3 Disconnected Editing
Another feature of database maintenance in the empirical
implementation is the use of disconnected editing functionality.
A corporate database is constantly changing in a production
environment. In the utility sector, field crews and office staff
are constantly collecting new data and updating database
contents respectively. To ensure that the database update
process is as seamless as possible, three factors are addressed in
our implementation:
1. The new data must be structured to the same
specifications as the data it replaces.
2. The links to unchanged elements must not be broken.
3. Links to new or modified features should be
automated as much as possible to avoid error and
maintain data integrity.
To address these factors, disconnected editing approach was
adopted. Disconnected editing is a new concept in spatial
database editing and updating. It pre-supposes that a
“snapshot” of a database can be taken to the field and edits and
changes made to the snapshot in a remote location(s). In this
scenario, it is also possible for the production database to be
undergoing changes at the same time as a result of editing from
other users (Figure 2). With prudent versioning architecture,
changes made at remote location(s) can be reconciled with
changes made to the production database. Conflicts are
assessed and addressed by the database administrator or
whoever has the final authority to make the decision. Once
conflicts have been resolved, changes to the disconnected
database are posted to the production database.
3.4 Rules and Relationships
While data update generally refers to actions that are executed
to input new data, delete existing data or change database
schema, in contrast, rules are often system specific, and are
designed to impose constraints on certain actions when the
database is being modified by the users.
Rules and relationships between database objects were
specified apriori at the database development and population
Un
phase. Rules help governs how database objects will interact
with each other and also impose restrictions on how changes
can be made to the objects and what happens when those
changes are made.
Besides, custom database functionalities are largely dependent
on established rules. For instance. triggering built-in-
relationships may be determined by the sequence of actions that
an editor performs. Moreover, rules may govern feature
class/table relationships in an edit mode (Table 1).
Rules, when used in conjunction with other data integrity
routines, especially a geometric network, provide powerful
tools for establishing data integrity especially to ensure that
positioning of facility data and spatial associations between
them are not compromised when features are being edited.
A geometric network is a one-dimensional non-planner graph
primarily designed to store connectivity information between
spatial features in a geodatabase. Once in place, a geometric
network preserves the database and eliminates data corruption
associated with data editing operations. In developing the
geometric network for the database (Table 2), careful
consideration is given to the following factors:
e The network rules must support the database without
any major change(s) to existing schema
e The rules should be simple enough to understand, and
should reflect accepted standards for modeling typical
electric networks
e The geometric network must support in-built front-
end functionalities
ARCSDE FIELDS MAINTENANCE
OBJECT RULE
FEATURE CLASS
Circuit Pri_Circuit# Null or empty value not
permitted if a line is
added to the GIS
Sec_Circuit# Null or empty values
permitted for single
circuit lines, otherwise
not permitted
TABLE
Secondary Sec_Circuit# Null or empty values not
permitted if a double
circuit line is added to
the database
This is the foreign field
for the Secondary
Circuit Info relationship.
Auto Concatenate
PRI_CIRCUIT# and
SEC_CIRCUIT# fields
to populate this field. If
DC segments are > 1,
add A, B, C etc after the
line number to
differentiate each
segment
Circuit Info
Circ OID
Table 1: Maintenance Rules for Feature Classes and Tables
Interndi
Role
Com]
edge
Simp
Junct
Snap
Snap
tolere
Sour
and €
Enab
Weig
3.5
Crea
impo
impa
infor
deriv
input
Meta
sour
relial
data
the d
com]
The |
solut
emp!
regai
The
solu
solu!
avail
prok
