In both cases, if more than one layer is involved in the current
SESQL sentence, we further estimate the number of result rows.
If it is bigger than the total number of input rows, we consider
the current SESQL query generating “too many join rows”. In
Figure 3, the Inputprouser iS the data size of the needed input data
which can only be found on the browser side, while Inputçerver 18
the data size of the rest input data. The rest input data can be
found on the server side.
With the above rules, decisions on where to execute a SESQL
sentence can be made. After execution, the cache structure on
the browser-side middleware will be updated accordingly.
4. IMPLEMENTATION, CASE STUDIES AND
DISCUSSIONS
4.1 Implementation
For the server-side middleware, spatial operators, SESQL
compiler, GML2SVG, and decision-maker are implemented as
Java Servlets. Specifically, JTS Topology Suite is employed to
implement the spatial operators. As SESQL is based on the
original SQL, we adapt the C++ codes provided in Levine et al.
(1992), and implement our own SESQL compiler by combining
the spatial operators. For the browser-side middleware, SESQL
compiler, SVG2GML, decision-maker, and cache structure are
implemented using JavaScript. We implement spatial operators
with JTS Topology Suite, and develop them as Java Applet.
Google Gears API * provides an SQLite compiler with
JavaScript-based API. We therefore implement a JavaScript-
based SESQL compiler with the Gears API. For spatial
operators embedded in the SESQL sentences, JavaScript
invokes the developed Java applet to execute the corresponding
spatial operations. JavaScript DOM API is also used to
assess/update SVG documents on the browser side. In order to
facilitate the interaction between the server-side and the
browser-side middlewares, we use AJAX (Asynchronous
JavaScript and XML) technology.
It is important to note that the load balancing middlewares are
completely transparent to the end users. Users can access spatial
analysis functions simply with an SVG-enabled web browser,
such as Internet Explorer, Firefox, and Google Chrome.
4.2 Case Studies and Discussions
We design three case studies to evaluate the proposed solution
as proof of concept. These case studies use geospatial data of
Guangdong Province (China), and implement several spatial
analysis tasks. In the case studies, comparisons among the
proposed solution, server-side solution, browser-side solution
and our former solution (Huang et al., 2011b) are also made.
421 Case Study 1: Suppose there is some toxic
contamination throughout river “R1”. The contamination affects
the areas that are within 20 km. This task is to list all affected
administrative districts and calculate their affected area size.
In order to investigate this issue, we have to create a buffer for
river “R17, and find out which administrative districts are
overlapped with this buffer, and then calculate the size of
overlapped area for each district. We carry out this task based
on the workflow described in Section 2. First, we identify the
" Google has stopped its support for Gears API. However,
similar functions can be found on HTML 5's LocalStorage.
needed data and the evaluation criteria by carefully analysing
this case study. And then based on the suggested model in
Section 2, we use GML to represent the needed spatial data
(river layer) on the server side. We also represent the district
boundary layer in SVG and deliver it to the browser side as the
initial User Interface (UI). We then submit SESQL sentences on
the browser side to carry out the spatial queries by the following
steps: 1) Calculate a 20 km buffer of river "RI" (using Buffer
operator); 2) Find out all the districts which are overlapped by
this buffer (using Overlap operator); 3) Find out all the affected
areas in each district (using Intersection operator); 4) Calculate
the size of affected area in each district (using Area operator).
The SESQL sentences are listed in the Appendix.
Figure 4 depicts the results. It lists the names of affected
districts, and their affected sizes in the listbox at the right-
bottom corner. These districts are also highlighted in the map.
vei
sv
Figure 4. Listing all the administrative districts
“R17”, and calculating their affected area size
affected by river
To illustrate the advantages of the proposed solution, we
compare
it with different solutions:
server-side solution,
browse-side solution, and layer-based load balancing solution
(i.e., our former solution in Huang et al. (201 1b)). We mainly
compare the data amount of the network transmission
(excluding the request/response sentences) between the server
and the browser sides. Table 1 depicts the results. The
difference between layer-based solution and the proposed
solution is mainly due to their employed granularities (layers
versus spatial objects). To sum up, the proposed solution has à
smaller network transmission load between server and browser
sides, and therefore leads to a better performance.
prem
Server- Client- Layer- The
side side based proposed
solution | solution | solution solution
Stepl: 1,925 36.559 [36,559 (on| 5,082 (on
Buffer browser) | browser
Step2: 5,267 0 0 (on | 0 (on
Overlap browser) browser
Step3: 3,095 0 0 (on | 0 (on
Intersection browser) browser
Step4: Area | 106 0 0 (on | 0 (on
browser) browser)
Total 10,393 136,559 |36,559 5,082
yao
a amount is
Table 1. Comparisons of the first case study (dat
measured by Byte)
422 Ci
of railway
through. S
needed spe
represent tl
browser si
following
district (us
each railwa
railway seg
have no r
Appendix.
relevant. di
shown at
highlighted
Figure 5.
€
€
We also co
different sol
the results,
network trar
|
Stepl: |
Buffer
Step2:
Length |
Step3 :
SUM
Step4:
Filter
Total
lL
Table 2. Cor
n
423 Cas
of each admi
change betw
Kcpresent the
layers) on |
boundary lay
Initial UJ.
