International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XXXIX-B4, 2012 
XXII ISPRS Congress, 25 August - 01 September 2012, Melbourne, Australia 
417 
3.1.1 Browser-side Middleware: The browser-side 
middleware includes an SESQL compiler for SVG, an 
SVG2GML translator, a cache structure, and a decision-maker. 
The SESQL compiler carries out syntax, sentence, and semantic 
analysis for users’ SESQL sentences. The SVG2GML translator 
is employed to translate SVG data into GML data. 
The cache structure records which spatial data are available on 
the browser side. Careful studies of different spatial analysis 
tasks show that spatial objects are a basic unit of many spatial 
operations. Therefore, a very fine granularity for organizing and 
transmitting the spatial data is employed: spatial objects as a 
unit of organizing and transmitting spatial data. The following 
is the data structure of the cache structure. 
Class cache layer 
/ 
i 
String slayerlD; //the ID of the layer 
ArrayList<string> OhjectIDs; //the IDs of spatial objects 
//which are available on the browser side 
Bool bExecuted; //true if the layer is created by the browser 
//side’s execution, bExecuted= true also means that the 
//layer can only be j'ound on the browser side 
Bool bAllTransmitted; //true if all the objects in this layer 
//are available on the browser side 
l 
> 
ArrayList<cache_layer>Cache; //record the transmitted data 
In the above structure, if bExecuted=true, the value of 
bAllTransmitted will be set as true. This is mainly due to the 
fact: an “executed” layer always contains all the spatial objects 
which should be in this layer. The value of bAllTransmitted is 
an important indicator for the decision-maker when a whole 
layer is involved in a spatial query (i.e., an SESQL sentence). 
The decision-maker figures out the needed spatial data (spatial 
objects) from the FROM and WHERE clauses of the SESQL 
sentence by invoking the SESQL compiler, and checks whether 
all the needed spatial data are available on the browser side (by 
examining the cache structure). If necessary, the decision-maker 
sends the request to the server-side middleware. 
3.1.2 Server-side Middleware: The server-side middleware 
includes an SESQL compiler for GML, a GML2SVG translator, 
and a decision-maker. The GML2SVG translator is employed to 
translate GML data into SVG data. The decision-maker is 
responsible for receiving the requests from the browser-side 
middleware, and employing some decision rules to distribute a 
spatial query to either the server or the browser sides based on 
the network transmission cost of that query. 
3.2 Decision Rules for Distributing Spatial Queries 
The general principle of load balancing spatial analysis is to 
execute a spatial query on the server side if the cost of server- 
side execution (C server ) is less than the cost of browser-side 
execution (C hrowser ), and vice versa. This principle is applied 
when designing the decision rules for both browser-side’s and 
server-side’s decision-makers. 
3.2.1 Decision Rules in Browser-side’s Decision-maker: 
Every time users submit a spatial query (as an SESQL sentence) 
through their browser (e.g., Internet Explorer), browser-side’s 
decision-maker will figure out the needed input data (spatial 
objects) from the FROM and WHERE clauses in the SESQL 
sentence, and check whether the needed spatial data are 
available on the browser side. If yes, this query will be executed 
by the SESQL compiler on the browser side. Otherwise, the 
SESQL sentence, the names (IDs) of the needed input data 
(only those which are not available on the browser side), and 
the data size lnput browser and names (IDs) of the other input data 
whose bExecuted is true (the data can only be found on the 
browser side) will be sent to server-side’s decision-maker. 
3.2.2 Decision Rules in Server-side’s Decision-maker: 
Server-side’s decision-maker receives requests from browser 
sides, and employs some decision rules for distributing spatial 
queries. In order to identify these rules, we analyse the spatial 
operators designed for GML/SVG in Section 2, mainly focusing 
on comparing the input and output data sizes. When two or 
more tables (i.e., layers) are involved in an SESQL sentence, 
the styles of its SQL JOIN should be also considered when 
comparing the input and output data sizes. For example, an 
SESQL sentence like “select intersection (cities.d, rivers.d) 
from cities, rivers'" will return a table with many rows. 
In terms of distribution of input data, two possible cases exist: 
1) all the needed input data are available on the server side; 2) 
the needed input data are located on both browser and server 
sides. Figures 2 and 3 show the decision trees for them. 
Figure 2. Decision tree for the case when all the needed input 
data are available on the server side 
Figure 3. Decision tree for the case when the needed input data 
are located on both browser and server sides