You are using an outdated browser that does not fully support the intranda viewer.
As a result, some pages may not be displayed correctly.

We recommend you use one of the following browsers:

Full text

Proceedings, XXth congress

International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B-YF. Istanbul 2004

Z1 Geo-Union


= Network se
N Cache
ure Geo-Union
- 2 - Spatial = = Client 2, Client
= _ Database - i dd

Data Proxy
t d Geo-Union| +
Figure 2 Spatial Cache Framework


(1) Cache for spatial database. Geo-Union server is the bridge
between Geo-Union client and ORDB, so cache for spatial
database is maintained by Geo-Union server. Cache is stored in
both local file and memory. Because Geo-Union server can
manage different spatial data resources, and also can reply
different spatial data requests from different clients, so cache
for spatial database is a global cache.
(2) Network spatial cache. The bandwidth of different users in
network is different, but public users of Internet always have
low bandwidth. So when people use WebGIS applications, it is
a lethal delay when spatial data is transferred from Geo-Union
server. In Geo-Union client, we adopt a two-level spatial cache
mode to relief transmission bottleneck of the network:
The first network cache is used to help a single client access
remote data: building a spatial cache in local place. This kind of
cache is a partial cache, which is also a popular method in
today's browser.
The second network cache is used to help many clients in a
LAN access remote data: building a common spatial cache for a
LAN (cache server). Once a local client in the LAN accessed
some spatial data, other clients can reuse the spatial data in
cache server. Cache server is still a partial cache.
Cache server can realize massive spatial data cache by means of
the shared resources, which will speed up the hit rate of cache
greatly, so as to improve efficiency of all local clients, and save
resource of all local clients. Cache server solves the speed
conflict between local disk data access and remote data access,
and the speed conflict between the high-speed LAN and WAN
with narrow bandwidth.
(3) Spatial data proxy server. Because the distribution of users
in Internet is not well-proportioned, so different Geo-Union
servers are unbalanced. Some Geo-Union server and its
communication may overload. Aiming to this problem, we
design spatial data proxy server for those Geo-Union servers to
improve performance.
Spatial data proxy server is an initiative cache server.
Overloaded Geo-Union server selects a suitable Geo-Union
client and builds a spatial data proxy server there to response a
special group of users.
In Geo-Union, spatial data proxy server serves as special server
in Internet to provide spatial data access services for public
users. The structure and implementation of spatial data proxy
server is same as cache server, but they play a different role in
Cache server is private of a LAN, and clients in the LAN have
to get an authorization before accessing to cache server. Spatial
data in cache server is changing with different requests of
clients in the LAN.
Spatial data proxy server is public to all clients. Spatial data
proxy server may serve as a peer of Geo-Union server. Spatial
data proxy server can be built anywhere in Internet if needed. If
spatial data in a spatial database is unchanged for a long time,
spatial data proxy server can cache all spatial data of that spatial
Building spatial data proxy servers properly in Internet will
make Geo-Union applications more effective.
2.2 Organization of Spatial Cache
In Geo-Union, spatial cache is organized as three levels: layer,
slot and entity.
When creating a layer in spatial database, a GUID (Global
Universal Identification) is generated to identify the layer,
which is named as /ayer/D. When reading a layer into cache,
the system will allocate a separate space for the layer according
to its /ayerID. Whether a layer is valid in cache is determined
by the /ayerVersion of the layer both in cache and in spatial
Entities in a layer are always separated into different slots
according to a certain rule. When reading a layer into cache, we
do not read the whole layer, but read some slots of the layer.
Slot brings two benefits: almost all spatial queries do not need a
whole layer but only a certain scope in the layer, so when the
layer is massive, reading relative slots can satisfy the
requirement and will reduce network load greatly; less data will
exhaust less computing resource and storage resource. The rules
to organize slot are various. We can organize slots in a layer
according to a correlativity of geographical location or a
neighborhood geographical location. 4A correlativity of
geographical location means we can put entities along a railway
into a slot, and a neighborhood geographical location means we
will put entities in a certain spatial scope into a slot. Every
entity in a layer belongs to a slot. When entities in any slots
changed, the s/otVersion of the layer will change too.
An update operation may modify only one or several entities in
a layer, so /ayerVersion and slotVersion of the layer cannot
reflect the latest modification of entities. We set a
versionNumber for every entity, and when a entity changes, its
versionNumber changes too. The entityVersion of a layer is the
max versionNumber in the layer. When the versionNumber of a
layer in cache is less than that in spatial database, some entities
in cache is invalid and those entities that have larger
versionNumber should be reloaded from spatial database into
2.3 Refresh and Pro-load Spatial Cache
Refreshment of spatial cache can be done online or offline.
Online refreshment means updating spatial data in cache at the