International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B4. Istanbul 2004
schema transformations to be carried out before the datasets can
be combined.
3. OPEN SERVICE ARCHITECTURE
The task of data integration can be seen as a part of a larger
distributed data processing framework. The research described
in this paper has produced a design for layered service
architecture. This architecture has been developed in the
context of a cross-border map service aimed at mobile users,
but the same approach can be adapted in many different kinds
of online services involving geospatial data (GiMoDig, 2003a).
The open system architecture could be based on a layered
service stack, in which a service would make queries to the
service below it, do some processing on the data received as a
response, and provide the results of this process as a service to
the service layer above it. The level of detail in specifying the
layers is a matter of discussion, but if the services were to be
run on separate computers communicating through network, too
fine-grained service definition would create a significant
disadvantage in terms of overall system performance.
For the above-mentioned reason, five-level system architecture
is proposed (Figure 1) (Lehto, 2003). On the first level the data
providers (e.g. NMAs) would run a Data Service providing raw
spatial data in an XML-encoded form. Above the data services
is the Data Integration Service layer. The responsibilities of this
layer include for instance coordinate transformations to a
common reference frame and other data integration procedures,
like schema transformations.
| Client / Value-added Service Layer m
\AAA
Y
Portal Service Layer d
y
L Data Processing Layer x]
y
[ Data Integration Layer
y
Data Service Layer
Figure 1. The Open Layered Service Architecture
On the third level in the architecture is the Data Processing
layer. This layer is responsible for various data processing and
analysis tasks, like map generalization or dynamic labeling.
The fourth layer in the system architecture is called Portal
Service. The main responsibilities of this layer can be listed as:
provide basic metadata service to the client, process the service
requests coming from the client subsequently forwarding the
request in an appropriate form to the Data Processing layer
below, and transform the resulting piece of geospatial data into
an visual representation, according to the capabilities of the
client platform in question. It should be noted that in the service
architecture the query results are represented in the form of
XML -encoded spatial data (e.g. GML) up to Portal Layer. Only
there is the query dataset transformed into a visual map image,
styled appropriately for the client environment in use.
On the fifth layer are finally the client applications. An
advantage of the layered architecture approach is that the results
can be adapted to a wide set of different client environments.
For example the following three client platforms could be
considered: the traditional Web browsing on a PC platform, the
more restricted Web access on PDA devices and the various
different client applications on mobile phones.
4. XSLT TECHNOLOGY
As the number of XML-based spatial data services increases on
the Web, the need to employ XML-technologies in the
processes involving geospatial data becomes obvious. One of
the most significant technologies developed for processing
XML-encoded data is called Extensible Stylesheet Language
Transformation (W3C, 1999b), a mechanism for transforming
an XML document into another XML document.
The Extensible Stylesheet Language (XSL) specification has
been developed by the World Wide Web Consortium as a tool
for defining presentation characteristics of an XML dataset
(W3C, 2004b). In connection to this work the W3C has created
a specification for transforming XML documents, XSL
Transformations (XSLT). XSLT is primarily designed for
transforming XML documents for presentation purposes.
Typical examples include dynamic creation of the table of
contents, and creation of a tabular presentation of some data
values in the source document.
As an analogy in the geospatial data domain, XSLT could be
used to transform a dataset from an application-specific spatial
data structure into a map image, for instance in the form of the
new Web vector graphics standard, Scalable Vector Graphics
(W3C, 2003) (Lehto et al, 2001). The other transformations
being considered in geospatial applications include data model
transformations, coordinate transformations, and generalization
of spatial data (Lehto and Kilpeläinen, 2001).
The XSLT specification is a promising tool to carry out the
tasks encountered when integrating spatial datasets in real-time.
Most simple integration operations are readily available. These
include tasks like changing the naming system applied,
grouping data from several feature classes into one class or
dividing data from one feature type into several types, changing
code tables etc.
More sophisticated integration operations can be added via the
XSLT extension mechanism. The extensions can be
programmed e.g. in Java, offering an environment for
procedural programming. Typical examples include different
coordinate manipulations, like coordinate reference system
transformations, changes in geometric primitive types (e.g. area
collapsed to a point) etc. The integrated datasets are written out
as XML data, presented in a common GML application schema.
The extension mechanism available in the XSLT process
enables arbitrary, application-specific functions to be
introduced into the transformation process. Several XSLT
processes can also be chained together, if the task is too
complicated to be expressed as one individual transformation.
178
Intei
An
Figu
tem]
repre
tree
calle
whic
hold
nam
exar
voca
wou
Eng!
builc
thre:
xsl:
The
are f
5:1
The
bein,
Finn
The
NM,
et al.
The
meth
meat
proje
acce:
geo-
speci
map
limit
In th
prov;
a co
Thes
Data
from
and
XSL
imple
Proc:
comr
