ude) forms 
erence sys- 
are related 
] database 
coordinate 
spatial ob- 
nt. 
S 
erated spa- 
it is impor- 
graphic In- 
d with the 
tabase that 
jon. 
m is better 
ers, system 
[he desired 
depend on 
r data con- 
uire to ad- 
ontrol over. 
available to 
ation devel- 
th the com- 
iders would 
nvestiment. 
nctions are 
e functions 
» databases 
retrieve the 
me desired 
ystem point 
vare on top 
1t of Delta- 
ictionalities 
tabases; 
rom the un- 
ver and an- 
transfers; 
e cooperating with specific vendor GIS soft- 
ware to translate retrieved data into the GIS 
specific format; 
e monitoring and informing clients of the sta- 
tus and progress of requested service; 
e logging the relevant information about 
clients, for accounting and billing purposes 
when the data being accessed has a cost as- 
sociated. 
eo authenticating authorized users and exercis- 
ing security measures. 
o forwarding requests or migrating transac- 
tions, to other DzServers where the server 
cannot process a request or complete the 
transaction; 
The above discussions give some of the services 
carried out by a DzServer. From the DzClient 
standpoint, a user invokes operations either us- 
ing the graphical user interface or the common 
query language (MSQL). The functions achieved 
through the DzClient include: 
eo request for the transfer of data-set between a 
client's local DzServer and a DzClient work- 
station, i.e., DzServer-to- DzClient transfers 
and DzClient-to- DzServer transfer; 
eo selective data retrieval by features; 
e incremental visualization of spatial features 
in different modes: vector maps, photo- 
images, remote sensed data digital elevation 
models, approximation models, etc.; 
e seamless horizontal and vertical spatial nav- 
igation; 
eo display of attributes, free text and docu- 
ments associated with spatial features; 
There are a number of functions that require 
cordinated support between the local database 
management systems and the multi-database 
management systems. These are normally not 
initiated from users at remote clients but as 
database administrator of the respective local 
DzServers. We refer to these as special admin- 
istrative functions. They are functions such as: 
509 
e monitoring and maintaining data access pro- 
file for subsequent performance tuning; 
e billing users for data that is accessed at some 
cost; 
eo data revision and control for efficient access 
to information in the past and processing of 
temporal queries; 
e granting user authorization to access infor- 
mation and protecting against unwarranted 
data access; 
e recovering from system failure; 
e  validating the consistency of data, partic- 
ularly with respect to different referencing 
mechanisms at different servers; 
5.2 Global Policy Administration 
Ideally, one would prefer an operational system 
that is self administering with respect to enabling 
and disabling the local databases from anyone 
participating DzServer. One central control site 
(DzMaster) overseas the admission and depar- 
ture of sever nodes into the federation. Unfortu- 
nately, there are still rules that must be discussed 
and agreed upon by participating members in the 
federation. Therefore, some policies must be es- 
tablished servers administrators must make every 
effort to adhere to these policies for efficient and 
non-disruptive service to clients. 
While the autonomy and independence of the 
data sources for GIS application development 
must be respected, some common agreement 
must be reached as to whom has the authoritative 
control of a particualr data set. For example, it 
is possible for one agency to purchase data from 
some source, restructure the data into a cleaned 
data with some added values and enhancements 
and make it accessible to the public as a better 
alternative to the original data. Such an action 
could be detrimental to the prestige of the origi- 
nal provider of the data. Matters of this nature 
and other legal issues need to be addressed as 
policies of participating member in the federa- 
tion.