spatial order operators
, West, West North,
operators (Max Dist,
cometrical operators
er).
f spatial operators are
SOL (SESQL), which
sides for spatial query
mple, a query of “list
an be implemented as
om city, river where
v.d)=true”. The only
analysis on SVG and
, compiler.
AL ANALYSIS
patial analysis can be
. This section focuses
^wares to distribute a
des based on its cost.
ldlewares compare the
,) and browser-side
n Cow» €Xecute the
t data to the browser.
wser, and carry out the
spatial query includes
query) and network
1e query). As a normal
istically improved, the
en server and browser
of the spatial queries.
, and Cypser mainly
cost. Our discussions
rk transmission cost.
b), a simple solution,
arity (by layers) for
, was proposed to the
cle will improve the
sing a finer granularity
re flexible and precise
'ations.
yn costs and distribute
ware and a server-side
the architecture.
ets
3rowser side
SVG dataset | | HTML interface
SESQL Compiler for SVG
Decision-maker
SVG2GML translator
Cache structure
Browser-side middleware —
incing middlewares
31.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
String slayerID; //the ID of the layer
ArrayList<string> ObjectIDs; //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 found on the browser side
Bool bAllTransmitted; //true if all the objects in this layer
/lare available on the browser side
}
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 bAl/Transmitted 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.
32 Decision Rules for Distributing Spatial Queries
The general principle of load balancing spatial analysis is to
&Xecute a spatial query on the server side if the cost of server-
side execution (Cserver) is less than the cost of browser-side
éxecution (Chronser), 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 Inputp,onser 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 SOL 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.
Only one layer
involved
Y: N.
ontaining
“intersection ’/
‘union ’/ ‘difference’
Executing on:
Server side
Figure 2. Decision tree for the case when all the needed input
data are available on the server side
Only one layer
involved
Y N.
Contaming
‘intersection’/
‘union /‘difference’
Executing on:
Server side
Figure 3. Decision tree for the case when the needed input data
are located on both browser and server sides
