ISPRS, Vol.34, Part 2W2, “Dynamic and Multi-Dimensional GIS’’, Bangkok, May 23-25, 2001
320
GEOD2D: A FLEXIBLE SOLUTION FOR GIS DATA EXCHANGE BASED ON COM
Huayi WU 12 Xinyan ZHU 2
1 School of Business, Hubei University, Wuhan, 430062, China, wuhy@public.wh,hb,cn
2 Resarch Center for GIS, Wuhan University, Wuhan, 430079, China, zxv@rcgis.wtusm.edu ; _cn
KEYWORDS Data Exchange, COM/DCOM, ActiveX/OLE
ABSTRACT
This paper introduces our experiences of developing a flexible solution for GIS data exchange system based on COM. A series of
ActiveX Controls were developed for assembling various data exchange applications among GISs. Our experiences verified that
COM/DCOM model is a flexible and economic solution for GIS data exchange.
1. BACKGROUND
Data preparation is one of the hardest tasks in making a GIS
practicable. It is estimated that more than 80 percentages of a
GIS project is collecting, coordinating, inspecting and input data
into the GIS database. Generally, commercial GIS software
packages provide menu items to fulfill data exchange between
various data formats. But these menu items often fail to meet the
needs of various end users of GIS software. There are several
causes prevent the success of import and export data from GIS
to GIS or other graphic systems.
The data models are not identical between GISs or GIS
and other graphic systems. A typical example is the data
model of CAD, which is severely different from that of
usual GIS. Many entities in CAD have no counterparts in
GIS.
^ The user’s need for GIS varies from one user to another.
Urban planning department has its own convention that is
thoroughly different from that of surveying and mapping
department. An inflexible solution can not meet these two
kinds of different need simultaneously.
GIS solution providers also try to overcome these
problems. They provide many options for end user in the
data exchange menu items. These options in a certain
extend offer variable solution for end users, but it is far
from all needs of end users.
^ For GIS solution providers, another effort is made the data
standard. The OpenGIS consortium is an example.
Theoretically it is not difficult to abide by the OpenGIS
specification, but it is not rational to require a GIS
constructor to have all its data sets follow the OpenGIS
specification, especially those historically accumulated
data.
For GIS software developer, another puzzle is to keep
pace of the upgrading step of other graphic systems and
their data formats.
To solve all above problems, COM is an economic and flexible
solution. Our successful experience verified this selection.
2. COM/DCOM MODEL OF ActiveX TEHNIQUE
With the achievement of computer software engineering, the
component technique is promptly applied to design GIS.
Component GIS is designed to base itself on a series of
standard components. Some of these components are imported
from commercial providers. Others are developed specially for
spatial information. The most important feature of these
components is the flexibility of being rearranged into customized
system. Visual and standard interface makes these
customizations an easy and convenient building block to
construct a new system for end users.
Currently there are two mainstream models for developing
component system. One is Microsoft Component Object Model
(COM) and Distributed COM (DCOM). Another is OMG’s
Common Object Request Broker Architecture (COBRA).
Microsoft’s power position makes COM/DCOM the more popular
model to develop components. Incorporating the spreading of
COM/DCOM model, Microsoft released the ActiveX technique
and a series of supporting tools for designing, coding, debugging
and testing ActiveX components. ActiveX component is in
practice the most wide-adapted standard component for visual
programming. In the present stage, Component GISs are mostly
ActiveX components or its predecessor OLE components. This
paper will introduce our experiences of developing a series of
ActiveX components for GIS data exchanging.
ActiveX is a set of open techniques based on COM/DCOM. It
stands for a strategy of integrating application system and
Internet. No matter what language is utilized to develop an
ActiveX component, components abiding by this standard
support interoperation in PC or distributed environment.
There are three types of ActiveX component for common use.
They are Control, automation Server and Document. As a
reusable component, ActiveX Control appears an encapsulated
code block. It provides Attributes (member variables), Functions
and Events for communication with other programs. ActiveX
control is also a special OLE Control. It can be used not only in
container that supports OLE, but also as an Internet Control to
become part of web pages. ActiveX Control can be developed in
various language environments such as VB, VC etc. ActiveX
Control can be imported to various language environments, such
as VB, VC, Delphi, PB, VF etc., to incorporate the development
of application systems.
In this paper, VC++ is chosen to develop ActiveX Controls and
VB is chosen to test these ActiveX Controls with an experimental
system. Experiments of these components called by Delphi and
PB was also conducted with satisfactory results.
3. DESIGN OF DATA EXCHANGE
COMPONENTS FOR GIS
Among GIS users, there are about ten data formats frequently
used. Some famous of them are DWG, DXF, MIF, Coverage,
SHAPE etc. Traditionally, to provide a total solution for data
exchange among them, it is required to work out an executable
program for each pair of them. Designed by ActiveX technique,
what we have to do is to work out a series of ActiveX Controls
and customize them to final applications.
In our experiments, one component is designed for each type of
data format. For example, an ActiveX Control GeoDXF is
developed for dxf format and so is an ActiveX Control GeoVCT
for China's standard spatial data exchange format VCT. Each of
