id not the 
d, into the 
reely regis- 
ined by the 
d in a GIS, 
intain and 
r example, 
rector data 
ler may be 
ote sensed 
, geological 
'erver node 
luring data 
iat. 
ver will be 
| number of 
er must be 
» workload. 
omputer, a 
of worksta- 
buted com- 
ine (PVM) 
specialized 
ailability of 
ions of the 
rations. An 
Server is to 
j| their pro- 
allel virtual 
Queries 
tion that is 
th PEX ex- 
he DxClient 
indow’s en- 
rkstation is 
nd as such, 
t needed. A 
ne DxServer 
.ccess either 
:e of the Dx- 
de or by ex- 
1mon global 
(DAL). The 
is the sim- 
plest. This will normally be the mode for public 
usage [14]. 
Using this mode of interaction, a client in- 
terrogates its default server for the collection of 
databases available. This collection consists of 
the databases globally available and accessible to 
the user and those residing in the local database 
of the client’s server. The client may request that 
some data be retrieved and made GIS ready in 
the client’s environment. This is done by simply 
specifying the source data set name, the required 
features and the destination of the data. 
For example, from a set of vector formatted 
map sheets, a user may request only specific fea- 
tures of a particular map sheet. The result of 
such a request is the digital vector data of the 
same map sheet that is topologically structured 
and restricted only to the selected features. The 
unit of data access is a collection of selected fea- 
tures from a specific data set. 
The DzServer to which a client is currently 
connected may not necessarily execute the service 
requested by the client. The transaction may be 
forwarded to the appropriate DzServer with the 
result forwarded directly to the client. 
Advanced users may utilize a lower level query 
facility in which the data access is done by spec- 
ifying a query in the common data access lan- 
guage (DxDAL). The common data access lan- 
guage in the current implementation is a mod- 
ified SQL for multi-database access (MSQL). A 
user in a DxClient environment, has access to 
the DxDIS database and the local database di- 
rectories or catalogues. A query is expressed 
in MSQL with reference to a global table as 
“database_name @server_name.tablename”. Ac- 
cess using the GUI is still executed indirectly by 
the underlying MSQL. 
In its simplest form, a query in MSQL is issued 
from a client to the connected DzServer. This is 
then analyzed and decomposed into subqueries 
that are destined to the respective LDBMS hold- 
ing the data repositories referenced in the sub- 
queries. A DxzServer agent of the receiving 
LDBMS, translates its subquery into the specific 
local database query. This is then passed on to 
the local DBMS for execution. The results of the 
respective subquery execution are then passed to 
the coordinator (the server originating the query 
on the client’s behalf) who then assembles the re- 
sult for the requesting client. All remote queries 
are executed as read-only transacions. Updates 
to database are carried out only at the local 
database management system. This is not a lim- 
itation but the desired mode of operation since 
the autonomy and independence of the DzServers 
must be respected. 
Since remote client requests are read-only, dis- 
tributed two-phase commit is not an issue in the 
model of distributed access. Remote queries that 
arrive at a local node is transformed to a lo- 
cal tranasction that is excuted concurrently with 
other local transactions. Hence a simple time- 
out mechanism is sufficient to coordinate multi- 
databse transactions and maintain database con- 
sistency. 
4 Common Spatial Data Model 
4.1 The Delta-X Approach 
Essential to the mode of operation is a com- 
mon data representational scheme. This is de- 
fined in Delta-X by the common global concep- 
tual data model. Consider the problem of provid- 
ing topologically structured vector data to dif- 
ferent GIS clients. Delta-X maintains a com- 
mon global database scheme which may or not 
be adopted by any inndividual GIS as its repre- 
sentational data model. This is the conceptual 
data model into which other GIS internal rep- 
resentations can be mapped without information 
loss. The Delta-X spatial data model, for vector 
data in this case, maintains up to degree degree 
four topology. This global scheme is considererd 
to be virtual since no explicit global data repre- 
sentation exists other than the database of the 
directory information service. 
This global conceptual scheme forms the in- 
termediate transition schemes for data exchange 
between different GISs. The global conceptual 
data model has a mapping onto either a relational 
database, as a collection of relational tables, or 
into an object-base as a colony of categories. A 
DzServer maintains the vector data in a rela- 
tional database if the underlying database man- 
agement system is relational, e.g., Ingres, Oracle, 
Informix, etc. Similarly, the DzServer retains the 
data in a set of equivalent category classes in an 
object oriented database, if the underlying DBMS 
is object-oriented, e.g., ODE, ObjectStore, Ob- 
jectivity. The significant idea is that DzServer 
507