ul 2004
ig only
1at area,
adastral
ance of
son for
nent an
een the
on only
Ns new
inks in
rie and
which
lifferent
tes and
pt of an
(2003)
was to
n. The
3e cases
>cess to
e.
IRDB
'al-time
derable
: (ICA,
ls and
ions in
| going
ill.) are
ay) the
lucts of
nnot be
al-time
:d scale
ity that
umvent
use an
1e real-
lose to
on this
'essary,
ed for
an be
| Info-
| and
elivery
jakoski
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B4. Istanbul 2004
The main vision of GiMoDig is a mobile user, travelling within
a European country and receiving on-line information of his or
her environment on the mobile device. Even when crossing a
border, the type of information presented does not change, thus
having the situation, that seamless topographic information is
available. Furthermore, it is often required that the cartographic
data is generalised and/or integrated with other data before it is
sent to the user. To support the generalisation process at this
point, investigations in using an MRDB for this purpose were
undertaken (see section 2.3).
3.2 System Architecture
GiMoDig aims at distributing cartographic data from core
databases at national mapping agencies to mobile devices
(mainly following the Open GIS standards). Figure 2 shows a
simplified overview of the GiMoDig system architecture (see
Lehto, 2003 or Sarjakoski & Lehto, 2003 for details). The client
makes a request for a map. The request is transformed in the
layers below and is finally formulated as a WFS request (see
section 4). The response to this request is cartographic data in
the form of GML data (GML, 2004). The GML data are sent to
a processing layer. This layer performs generalisation of the
cartographic data as well as creating new queries to utilise the
MRDB. The processing layer then sends generalised
cartographic and service data to the layer above. Finally, in the
latter layer, the GML data is translated into, for example, an
SVG (SVG, 2003) or JPEG image for display at the client.
LH Client
Request i
=
A SVG, etc.
| Portal layer ]
Request Tow. (Generalised cartogr. data)
| Processing laver |
WFS Mis |
request Tov (Original cartogr. data)
Ë n
Figure 2. A simplified version of the GiMoDig system
architecture.
Data layer
The main processing platform in the processing layer is a Java-
environment called JTS/JUMP (JTS Topolgy Suite, JUMP
Unified Mapping Platfarm) (Vivid Solutions, 2004) which
provides certain functionalities to import, handle and
manipulate spatial data. The JTS Topology Suite is an API of
2D spatial predicates and functions. It conforms to the Simple
Features Specification for SQL (SFS, 1999) published by the
Open GIS Consortium and provides a complete, consistent and
robust implementation of fundamental 2D spatial algorithms.
JUMP provides an API giving full programmatic access to
functions, including 1/0, featurc-based datasets, visualisation,
and all spatial operations like buffer or overlay.
During the development phase of the prototype the JUMP
environment is also used as an authoring tool to visualise the
processed data. Later on the Java-code will work in a servlet
environment in the GiMoDig-service.
137
3.3 Creation of an MRDB
The creation and maintenance of the MRDB is described in
detail in Hampe et al. (2003). Here just follows a brief
description.
The cartographic data are stored in an object-relational database
called PostgreSQL (Postgres 2004) with its extension PostG/S
(Postgis 2004). As our base-data are of a high level of detail, for
the: scale 1:10k, the other layers were derived from this first
dataset by generalising the base data for the scales of 1:25k.
1:50k and 1:100k. Several algorithms to generalise spatial data
were developed e.g. for simplification, amalgamation and
typification whereas we concentrate on datasets containing
buildings or settlement areas and streets.
4. WEB FEATURE SERVICE STANDARD FROM OGC
4.1 Overview
Open GIS consortium (OGC, 2004) has specified standards for
cartographic web services. One of these standards is the Web
Feature Service specification (WFS, 2004). WES specifies a
number of requests from a client to a server; (wo of the most
basic requests in WFS are: GetCapabilities and GetFeature. A
GetCapabilities request could be sent from a client to a WFS
server (using HTTP) and then the client will receive
information (in form of an XML-file) about the cartographic
data available. Based on this information the client could
formulate a GetFeature request. When the WES server gets this
request it sends cartographic data in form of a GML file to the
client.
The GerFeature request contains information about which data
should be received (both the layers and a bounding box),
specification of the spatial reference system (SRS) and
sometimes also additional constraints on the data (e.g., that the
data should have specific attribute values).
4.2 WFS-access on MRDB
The applications of the case studies are all implemented in the
processing layer in the GiMoDig system architecture (cf. Figure
2). The source data will be requested from an MRDB in the data
layer via WFS requests. In the processing layer the data is
processed and then distributed to the layer on top in form of
GML-data. Finally, this data is converted to SVG for
distribution to the client. This combination of SVG-data,
derived from an MRDB by WFS-requests allows for new
possibilities to adapt the maps depending on the actual
situation. The user can point out certain objects in the SVG-
image and through new WFS requests certain objects or
attributes of interest can be retrieved from the database.
The problem here is that WFS does not support requests
specific for MRDB's. That is, it is not possible to utilise the
links between the layers in the WFS queries as such. Therefore
we have used a technique with repeated WFS requests (Figure
3). For example, the processing layer sends a WFS request of a
small-scale layer in the MRDB. When the data is received by
the processing layer the data is analysed. If necessary, a new
WFS request to a large-scale layer is then performed by
utilising the link information from the small-scale layer.
4
