Full text: Proceedings, XXth congress (Part 4)

ul 2004 
Form of 
:r. Only 
| image, 
ns. An 
e results 
nments. 
ould be 
orm, the 
various 
cases on 
in the 
One of 
ocessing 
anguage 
forming 
tion has 
as a tool 
, dataset 
s created 
s, XSL 
ned for 
jurposes. 
table of 
yme data 
could be 
ic spatial 
rm of the 
Graphics 
yrmations 
ta model 
ralization 
y out the 
real-time. 
le. These 
applied, 
class or 
changing 
ed via the 
can be 
ment for 
different 
e system 
(e.g. area 
vritten out 
n schema. 
[ process 
100: De 
ral XSLT 
sk is too 
‘mation. 
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B4. Istanbul 2004 
An example of a simple XSLT declaration is shown in the 
Figure 2. XSLT declarations are expressed in the form of 
templates. The template in the example selects all elements 
representing buildings (*Rakennus' in Finnish) from the source 
tree that match to the selection phrase (expressed in a language 
called XPath) (W3C, 1999a), then filters out all elements for 
which the given test phrase inside the 'xsl:if element does not 
hold. All elements inside the template not belonging to the xsl- 
namespace are written to the result tree. For instance, in the 
example the Building-element forms part of the target common 
vocabulary, so the effect of the transformation in this case 
would be a change in the naming system (from the Finnish to 
English terms) and a change in the collection criteria (only 
buildings with area (‘pinta-ala’ in Finnish) larger than the 
threshold value will be included). After the instruction: 
'xsl:apply-templates', the process continues down the XML tree. 
The transformation goes on until no more matching elements 
are found. 
<xsl:template match="Rakennus"> 
<xsl:if test="pinta-ala > 200"> 
<Building> 
<xsl:apply-templates/> 
</Building> 
</xsl:if> 
</xsl:template> 
Figure 2. A sample XSLT template 
5. CASE: GIMODIG PROTOTYPE 
5.1 General 
The XSLT-based data integration transformation described is 
being tested in a European Union funded project GiMoDig. The 
Finnish Geodetic Institute acts as a coordinator for the project. 
The other participants are the University of Hanover and the 
NMAs of Finland, Sweden, Denmark and Germany (Sarjakoski 
et al., 2002). 
The objective of the GiMoDig project is to develop and test 
methods for delivering geospatial data to a mobile user by 
means of real-time data-integration and generalization. The 
project aims. at creation of a seamless data service providing 
access, through a common interface, to the primary topographic 
geo-databases maintained by the NMAs in various countries. A 
special emphasis is put on providing appropriately generalized 
map data to the user depending on a mobile terminal with 
limited display capabilities. 
In the GiMoDig system architecture each participating NMA 
provides geospatial data through the WFS interface, encoded in 
a country-specific XML-format (GML Application Schema). 
These datasets are processed by a middleware service on the 
Data Integration layer to integrate the pieces of data coming 
from individual countries into a common application schema 
and coordinate system. The middleware service employs the 
XSLT technology extensively in the process. The service is 
implemented as a Java servlet environment and the XSLT 
Processor used is a product called Xalan from the Apache 
community (Xalan, 2004). 
179 
5.2 Global Schema and Service Architecture 
In the GiMoDig project there are four different national data 
models involved. Each of the participating countries has 
organized the topographic map data in an individual way. For 
the purposes of the data integration a common data model, 
named GiMoDig Global Schema has been developed 
(GiMoDig, 2003b), (Aftlerbach et. Al, 2004). This data model 
consists of 17 different Feature types. These types are selected 
based on the data availability in the national databases on one 
hand, and on the requirements of the selected mobile use cases 
on the other. The list of the Global Schema Feature types is 
shown in Table 1. 
  
Feature type Geometry type 
Administrative Boundary Line 
Water (except inland) Area 
Watercourse Area or Line 
Lake / Pond Area 
Marsh / Swamp Area 
Park Area 
Building Area 
Contour Line (Land) Line 
Cropland Area 
Named Location Point 
Built-Up Area Area 
Railway Line 
Road Line 
Trail / Footpath Line 
Airport / Airfield Area 
Forest Area 
Grassland Area 
  
  
  
Table 1. The GiMoDig Global Schema Feature types 
The GiMoDig prototype service is built according to the system 
architecture illustrated in the Figure 1. As the aim in the project 
is to develop as open service architecture as possible, the access 
interfaces to cach of the service layers are based on 
internationally accepted standards. Consequently, the four 
national data services implement the OGC's WFS interface 
(OGC, 2002). 
The Data Integration service also implements the WFS interface 
providing a single access point to all of the participating 
national data services. As such, the Integration Service plays 
the role of a Cascading WFS. Query interface for the Data 
Processing layer (Generalization Service) has been developed 
in the project, as one does not exists as a result of the 
international standardization efforts. On the Portal layer the 
widely recognized Web Map Service (OGC, 2001) interface is 
used, together with the newer OpenLS Presentation Service 
interface (OGC, 2004). 
 
	        
Waiting...

Note to user

Dear user,

In response to current developments in the web technology used by the Goobi viewer, the software no longer supports your browser.

Please use one of the following browsers to display this page correctly.

Thank you.