Migrating from relational GIS to GIS objects a utility implementation perspective
New ways to think of GIS features
BLOBs (binary large objects) such as images and video are stored better in ODBMS’s.
While RDBM’s support BLOBs they cannot query them in the way they query tabular
data and they introduce a high level of performance loss.
Network contribution can be defined in the object model. Features that control network
activities can have a source and termination qualifier. The behavior of the utility network,
through the relationships defined in the object model, can be analysed based on
situational criteria. This capability is also available in relational models but required
much custom programming and processing to produce results. Changes introduced in
relational models intoduce a lower level of reliability in the analysis thus requiring more
custom programming. In object data models the probability of exercising reuseable code
is higher.
Connectivity that constructs the utility network model is not a new concept but
traditionally defined in custom application code which explicitly detected junction
characteristics or analyzed the intersecting features and, through an iterative process,
compared the potential connections with predefined perimeters listed in a table. This
implementation many times took a while for the transaction to be processed. Connectivity
in an object model is defined in a diagram and must be adhered to by the editing software
reducing code overhead and processing time.
Open architecture that many COM compliant applications can access to:
- produce reports
- produce customized maps
- imbed maps into documents
- perform data model analysis
- produce system schematics
“Relational models can be represented with objects. OO class hierarchies can be more
difficult to model with RDBMS. Many ODBMS products provide means of integrating
with RDBMS. The GIS translation problem is easier and does not require a generic
translation capability.”1
Things to think about
Object model characteristics contribute:
- Location-based objects that can have geometry
- Features that contain specific behaviors
- Attributes with valid value domains without a separate link to a table
- A more real world representation of utility networks than relational designs
Migration strategies should result in:
- A Migration Specification Document that maps the current data structure to
the new one and identifies and verifies critical attributes
- Compatibility with new field technologies to use maps and data in COM
compliant interfaces
- Accommodating the requirements of new users
- A single facility database fot the entire enterprise
Application support considerations for new model:
- Asset management
- Work management
- Dispatch
- Crew management
- Service Requests
- Emergency analysis and response
- Field based data capture and update
The utility should think of the new model as GIS / Data centric. Features (class objects)
have relationships to the geometry information (abstract object class). Attribute values
and their domains are inherited from subtypes to abstract classes of the basic geometric
element without re-establishing run time links or table joins. Many departments, whether
they require GIS or just access to the ODBMS, can be sharing the most up to date version
of the enterprise facility database.
What data is required when creating the object repository? Consider potential users and
entities during the development of the new object model. Application developers using
relational models tended to provide a “one size fits all” concept to minimize maintenance
costs that did not afford utilities to design what they really needed. In many utilities other
systems had been brought on line since the initial data requirements analysis was
performed. Requirements introduced via experience with the old design and interaction
with other potential users can now be considered for the object model design.
A facilities centric view of the enterprise becomes more of a reality. Custom applications
can be created as before to use the data, but the data can also be used by inexpensive
commonly used software. Database administration is enhanced with versioning
capabilities making GIS even more accessible to casual users through specific user-type
interfaces.
Field applications are available to download and upload maps and documents. Remote
users can utilize the processing capabilities of the server while access permissions and
type restrict functionality and accessibility to data.
There are several techniques to migrate relational data to an object GIS. One method is to
join tables that contain feature geometry and geographic reference data with tables that
house the feature tabular data. Some systems offer wizards to create the object database
from GIS network maps. This method is a feature-centric approach to data migration.
This means that processes can be designed to operate on one feature class at a time, to
gather information then create homogeneous graphic and attribute data files from the
digital sources. The data can then be migrated to discrete themes or logical layers in the
target ODBMS. For example, linear features such as pipes and conductors can be
recognized from the source design files and transferred to a layer with linear topology.
The linear features will have attribute tables that preserve all of the design file properties, including the relational linkage tags that associate each feature to a specific record in a
specific RDBMS table.
Feature attributes can be encapsulated for portability. This means that attributes from
RDBMS tables can be physically copied to the appropriate feature tables in the GIS data.
Enterprise-wide migration would more appropriately leave the RDBMS data outside of
the GIS layers to avoid redundancy of data and maintenance operations such as data
validation. This approach can be effective in the pilot project in which a sampling of data
is required to assess the proposed migration process and the functionality of an
application.
UML diagrams of the utility model will contain abstract features, feature definitions,
feature subtypes, feature relationships, network relationships, connectivity, and
cardinality. The way the legacy features relate to each other will change little if at all.
Still all of the assets that form the network need to have their network contributions
modeled, as they would operate in the real world. The ability to create complex data
structures lends real world capabilities to the features that control network loads,
capacity, and flow. Some relational models treated every nuance of a utility feature as a
separate entity when behavior was essentially the same as all other features in the same
class. Subtypes will provide a more efficient way of defining the features and their
interaction within the utility network. The relationships between network features and
non-network features will provide a road map for other applications to follow when GIS
is not the tool used for analyzing features and their history or status.
The UML will, through inheritance, identify where data redundancy has occurred in the
relational design. This redundancy can be eliminated within the object model. Data
migration may present issues when duplicate data is discovered and decisions need to be
made as to what source is more accurate and provides the best information to the most
people.
