'Estimation of shrub
airborne LiDAR and
aging." International
omparison between
ISPRS Journal of
-3): p83-94.
' image registration
UR) 24(4): 325-376.
Photogrammetric and
linear features."
sensing 71(6): p699-
Registration of aerial
ntroids of plane roof
'E Journal of Civil
tegration of terrestrial
m calibration." The
ctry, Remote Sensing
egistration methods: a
1):p 977-1000.
nt-based approach to
eometric distortion."
'ransactions on 32Q):
86). "A region-based
h subpixel accuracy."
emote Sensing 24(3):
"Matching images to
ction via clustering."
:e, IEEE Transactions
"Registering coronal
ith coronal sections of
variants and B-spline
ransactions on 17(6):
ent of a feature-based
for multitemporal and
E.
ing based planar roof
lation of LIDAR data
| for Linear Features
s, IEEE.
of Photogrammetry.”
any.
INCORPORATING LOAD BALANCING SPATIAL ANALYSIS INTO XML-BASED
WEBGIS
Haosheng Huang
Institute of Geoinformation and Cartography, Vienna University of Technology, 1040 Vienna, Austria —
haosheng.huang@tuwien.ac.at
KEY WORDS: WebGIS, XML, GML, SVG, Spatial Analysis, Load Balancing, Performance
ABSTRACT:
This article aims to introduce load balancing spatial analysis into XML-based WebGIS. In contrast to other approaches that
implement spatial queries and analyses solely on server or browser sides, load balancing spatial analysis carries out spatial analysis
on either the server or the browser sides depending on the execution costs (i.e., network transmission costs and computational costs).
In this article, key elements of load balancing middlewares are investigated, and relevant solution is proposed. The comparison with
server-side solution, browse-side solution, and our former solution shows that the proposed solution can optimize the execution of
spatial analysis, greatly ease the network transmission load between the server and the browser sides, and therefore lead to a better
performance. The proposed solution enables users to access high-performance spatial analysis simply via a web browser.
1. INTRODUCTION
Technological advances in the Internet/Web have triggered a
move toward Web-based geographic information systems
(WebGIS), which aim at providing GIS functionality and
services (such as web mapping and spatial analysis) to users
through a common web browser, such as Internet Explorer and
Firefox. Due to its openness, eXtensible Markup Language
(XML) /Geography Markup Language (GML) / Scalable Vector
Graphics (SVG) -based solutions have been shown to be
promising for building WebGIS (Peng and Zhang, 2004; Chang
and Park, 2006, Huang et al., 2011a). Recently, as more and
more web browsers start to provide "native" SVG supports,
XML-based WebGIS have become increasingly popular.
The ability to support spatial analysis is viewed as one of the
key characteristics which distinguish GIS from other
information systems. Initial development often adopts a server-
side solution to provide spatial analysis in WebGIS, that is,
executing all the spatial analytical tasks on the server side, and
sending the results to the browser side for visualization (Lin and
Huang, 2001; SuperMap 2010). These server-side solutions,
sometimes, become impractical, as the server cannot handle a
large volume of concurrent requests. Additionally, spatial
analysis is a complex task; users often have to try different
querying solutions before they are satisfied with the results. As
spatial queries often result in a large amount of data (such as
Intermediate results which users may not need), there will be a
high transmission load between the server and the browser sides
(Huang et al. 2011a). Recently, in recognition of the limitations
ànd with the advancements in web technologies, browser-side
Solutions are proposed, in which spatial analysis tasks are
&Xecuted directly on browser sides (Peng, 1997; Huang et al.,
2011a). These browser-side solutions avoid the “bottleneck”
Problems, and are very promising and appcaling due to the
pid performance advancements of normal personal computers
(PCs). However, browser-side solutions might also become
Impractical, as some spatial operations may result in far less
output than input (c.g., estimating the length of a river) and
hence need to be implemented on server sides.
It is important to note that these server-side and browser-side
solutions are two extreme cases of realizing spatial analysis in
WebGIS. Careful study shows that certain operations will give
better overall performance if they are executed on the server
rather than on the browser, and vice versa. In recognition of the
limitations, the concept of load balancing spatial analysis is
proposed (Vatsavai et al., 2006; Huang et al., 2011b), in which
spatial operations are executed on either the server or the
browser sides, depending on execution costs (i.e., network
transmission costs and computational costs). The core element
of load balancing spatial analysis is a load balancing
middleware which distributes a spatial operation to either server
or browser sides. However, little work has been done on
designing and implementing this middleware.
This goal of this article is to design and implement load
balancing middlewares to enable high-performance spatial
analysis in XML-based WebGIS. We extend our former work in
Huang et al. (2011b), in which a very coarse granularity (by
layer) for organizing and transmitting spatial data was
employed. In this article, the concept of load balancing spatial
analysis is comprehensively studied. More importantly, a finer
granularity (by spatial objects) of organizing and transmitting
spatial data is proposed, and some more flexible and precise
decision rules for distributing spatial operations to server or
browser sides are identified. With these, high-performance
spatial analysis can be provided to users via a web browser.
The rest of this article is structured as follows. In Section 2, we
briefly describe SVG (browser sides)/GML (server sides)-based
spatial information representation and spatial analysis. Section 3
discusses the load balancing middlewares. Some case studies
are implemented to evaluate the proposed solution in Section 4.
Also, comparisons with server-side solution, browser-side
solution and our former solution are provided and discussed in
