Object - Component GIS: The new
Customization and extensibility
As stated earlier, one of the problems of first generation object-oriented GIS was that
they had closed, proprietary data models and programming capabilities. Objectcomponents
based on industry standard component models (COM and Java) offer the
opportunity to use open approaches for AM/FM/GIS customization and extension. COM
is particularly interesting because it is programming language neutral. Any COMcompliant
programming language can be used to create a binary COM object. Examples
include Visual Basic, Visual C++, Visual J++, Delphi, Powerbuilder and Developer2000.
Visual Basic and its host-dependent derivative, Visual Basic for Applications (VBA), is
especially interesting for application scripting and user interface development because of
its highly interactive nature, ease of use, rich editing and debugging tools, forms-based
approach to development, rich collection of user interface controls, and widespread use.
For more advanced development many developers prefer VC++.
One interesting aspect of the COM standard is that objects derived from any source
(AM/FM/GIS software vendor, third party application development consultant, user, and
even Internet freeware!), can be plugged into the AM/FM/GIS at runtime and operate as
full first class system objects. COM also offers a model for object persistence and object
updates.
Data management
Historically, AM/FM/GIS have been implemented using hybrid or proprietary databases.
This is largely because until very recently commercial RDBMS were unable to deal
adequately with the special characteristics of spatial data (large data volumes, multiple
dimensions, variable record lengths, requirement for specialist spatial operators and need
for fast retrieval rate). Recent advances in AM/FM/GIS application server development
and, on some platforms, object-relational DBMS (ORDBMS) now mean that it is
possible to manage all AM/FM/GIS data in a single integrated DBMS. Many RDBMS
and ORDBMS now provide support for Abstract Data Types (ADTs). This means that
they can be extended to support spatial types (points, lines, polygons, etc.) and fmctions
(specialist indexing, and query operators such as touch, inside and overlap). Facilities
such as poles, pipes, reducers, and valves can now be stored in their entirety (geometric,
topology and properties) as rows in conventional tables. Spatial extensions to SQL (most
notably the emerging SQL3 multi-media standard) support spatial data definition and
data manipulation.
Unfortunately, none of the major DBMS vendors has yet provided long transaction and
versioning support, capabilities vital to providing multi-user access to continuous
databases in design and work order environments. This task has been left to AM/FM/GIS
software vendors who must either build their own database and design environment or
extend the short transaction model of a commercial DBMS. Approaches which truly
extend the DBMS are just emerging.
Managing AM/FM/GIS data in a standard DBMS offers many benefits:
-
All corporate data is centralized - this allows a single backup/ recovery and
database administration process for an organization.
-
Indexing - on some database platforms AM/FM/GIS can utilize the native kernellevel
database indexing. This offers reduced software development and
maintenance costs and on some platforms performance advantages.
-
Security - DBMS offer high levels of security in terms of user access, referential
integrity and long term data persistence.
-
Transactions - although there is a conspicuous absence of support for long
transactions and versioning (as described above), the standard short transactional
model of DBMS is usefil for attribute, and some types of spatial, update.
-
Platforms - commercial DBMS typically run on a range of hardware platforms
and operating systems. By using the database to store spatial data AM/FM/GIS
clients can take advantage of this platform independence.
