Journal of Geographic Information System, 2014, 6, 59-69
Published Online February 2014 (http://www.scirp.org/journal/jgis)
http://dx.doi.org/10.4236/jgis.2014.61007
OPEN ACCESS JGIS
Transform i n g G ML to Presentation Languages by
Extending XSLT
Sajjad Hassany Pazoky, Farshad Hakimpour
Universit y of Tehran, Teh r an, Iran
Received December 22, 2013; revised January 22, 2014; accepted Januar y 29, 2014
Copyright © 2014 Sajjad Hassany Pazoky, Farshad Hakimpour. This is an open access article distributed under the Creat ive Com-
mons Attribution License, which permits unrestri cted use, distribution, and reproduction in any medium, provided the original work
is properly cited. In accordance of the Creative Commons Attribution License all Copyrights © 2014 ar e reserved for SCIRP and the
owner of the intellectual property Sajjad Hassany Pazoky, Farshad Hakimpour. All Copyright © 2014 are guarded by law and by
SCIRP as a guardian.
ABSTRACT
Diversity of practices and methods in all fields is the basis of emerging standards in different areas. World Wide
Web Consortium (W3C) has st andardized e Xtensible Markup Language (XM L) as a very convenient tool to
structure data fo r numerous purposes. OGC standardized Geography Markup Language (GML), which is an
XML-based language, to store a nd t r ansport geospatial data. Despite the fact tha t it is a medium to separate geo-
referenced data from prese nt ation, GML by itself is no t intended to v isualiz e geo-referenced data. One of the
solutions to v isua lize GML is to use eXtensible Style sheet Language Transformation (XSLT) as transformer to a
visualizat io n language such as Scalable Vector Graphic (SVG). Unlike the u su al procedure, the major advantage
of the proposed approach is that the transformation process is shifted to the client-side. XSLT as a median lan-
guage is a general-purpose transformation tool. As it is not specialized for map cartography, map making proc-
ess is very complicated using this primitive language. To facilitate transformation process, in this research,
XSLT is extended to meet cartography requirements. Furthermore, a graphical user interface (XCartoT) is de-
signed to set all the map properties interactively. XCartoT provides a user-friendly interface for cartographers
to automatically generate necessary XSL files for their intende d maps. The goal of this research is to develop a
major step towards the geospatial Web.
KEYWORDS
Technology; Preference for Quality; Vo lume of Trad e; Vertical Intra-Industry Trade
1. Introduction
The tendency towards geospatial services is incessantly
growing among people from all differ e n t walks of life
and becoming a non-de tachable p ar t of everyday life.
People do not need high skills to use an online map
whenever they enter a cit y fo r the fir s t t ime. Furthermore,
spatial mobile and Web services have raised the expecta-
tion of people. Thus, developing services to fulfil l the
require ments of all sorts of people from different back-
ground is an inevi ta b le requirement that should be taken
into account by geospatial specialists.
Based on high interest of the public to geospatial ser-
vices, many specialis ts, organizations and institutes have
developed various metho ds, practice s, sof t ware, data
formats, Web services, etc. in diffe rent fields of geospa-
tial sciences. To prevent this diversity leading to confu-
sion, standards play a pivotal ro le . The most dominant
standardizatio n o r ganizations and consortiums in the
field of geospatial Web services are International Organ-
ization of Standardizatio n (ISO), World Wide Web Con-
sortium (W3 C) and Open Geospatial Consortium (OGC).
On the other hand, Web has undergone many revolu-
tions compared to the existing one. The latest revolution
was introduction of “Web 2.0” as a new concept. Web
2.0 is associated with concepts such as data/information
sharing, intero p e r ability, user-centered design and colla-
boration. Prior to this revolutio n, users were limited to
use the available content, whereas Web 2.0 sites allowed
the users to interact and collaborate in social networks
with user-generated content.

S. H. PAZOKY, F. HAKIMPOUR
OPEN ACCESS JGIS
60
On this account, previously known standards such as
GML became more popular. GML is designed to trans-
port and sto re geo-referenced data [1]. It separates con-
tent from graphic presentation and does not contain any
information on how to visualize geo-referenced data.
Therefore, GML is not dire ctly suitable for ap p lic a tio ns
that need visualizatio n. Hence, it should be converted to
other forms based on the usage such as graphical visua-
lization, plain text or verbal output [2].
All the aforementioned possibilities can be impl e-
mented. However, graphical visualization is the most
prominent way of communicatio n. Geospatial science is
meant to show the spatial relationships between natural
features. Therefore, it is obvious that a graphical map is
far more useful than a textual or verbal one.
GML can be visualized using certain libraries like
Open Layers, certain GML viewer software, using XSLT
to convert GML to a presentation language like SVG or
X3D, etc. The focus of this research is on visualization of
GML by converting it to SVG by XSLT . XSLT is used
as the transformer of GML to SVG. Scalable Vector Gra-
phics, a W3C recommendation since 2001, is a markup
language for de scr ib ing two-dimensional graphics appli-
cations and i ma g es, and a set of related graphics scrip t
interfaces. SVG is an XML-based language and de-
scribes vector graphic both statically and dynamically.
As stated and discussed comprehensi vely in Peng &
Zhang [3], the future of Web maps depends on SVG,
GML and WFS. SVG has man y features that make it the
best choice for Web-maps including [4-7]:
 An open standard compatible with other Web stan-
dards such as CSS, XSLT, XLink, XPointer;
 Provid ing rich graphical visualization features such as
scalabilit y, vector disp lay, animation, interactivity,
transpar ency, graphic filter effects and special visual
effects such as shadows , lighting effects and easy
editing;
 Facilitatin g fast response time for interactive query
requests;
 Provid ing efficient data intero p er a b ility over the net-
works;
 Supporting small wireles s dev ices;
 Search ability.
SVG and GML are two complementary languages
whi ch are highly compatib le and can work in synergy.
Since GML plays a major rol e in geospatial Web, SVG is
currently the mos t promising format fo r vector graphics
displa y on the Internet [7,8].
Although th is tr ansfor mation is implemented several
times, the research has imp r oved it in the following
ways:
 The transfor mation process is completely shifted to
client-side.
 XSLT is a general-purpose tool to reorganize XML
files andit does not have any special feature for map-
making [9]. Imagine a cartographer intends to draw a
legend for the map . Working with this primiti ve tool
is more like dr awing wi th a vector drawing software
such as Auto Cad with the difference that user should
write some lines of codes instead of drawing with
drawing tools! In this researc h, XSLT is extended to
meet map maki ng requirements of a cartographer to
convert GM L to SVG. It is worth noting that the re-
search is not to produce a GML viewer, but an ad-
vanced tool for a cartographer to convert GML to
SVG.
 Since writi n g code in a somehow strange language
like XSLT ma y be bothersome for non-specialists, a
graphical user interface called XCartoT is designed
and implemented to facilitate ma p making process for
diffe re nt classes of users. Using XCart oT, carto-
graphers can set all the specifications of their desired
map. XCartoT then generates XSLT file using ex-
tended functions. Choosing the GML file as the out-
put, the transfor matio n process is run and the resul-
tant ma p in SVG f ormat is d isp layed both textually
and graphically.
Geospatial Web is a new term, emphasizing geo-re fe r-
enced data anywhere and anytime. Mobile devices and
the Internet are the major devices to accomplish this goal
[10]. Therefore, the ultimate goal of this paper is to illu-
strate the essentiality for standar d iz ation organizations
and institutes to forc e Web browsers to provide users
with embedded capabilities to visualize geo-referenced
data on the browsers both on computers and mobile de-
vices.
2. Automatic W eb Cartography
One of the major problems cartographers are facing to-
day is the enormous a mount of raw data. Thus, it is im-
possible to spend a long time working on every single
sheet to produce a well-designed map. On the other hand,
people are less likely to buy papermaps. The change in
people’s attitude from papermaps to digital maps is
somehow a revolution.Development of telecommunica-
tion infrastructure such as wireless communication net -
works, spatial positioning methods such as Global Posi-
tioning Systems (GPS), radio frequency identificatio n
(RFID), gyroscope, mobile computing systems such as
PDAs, ta b le ts and smart phones has been the mo tive of
this revolution [2]. Along with many other app lica tio ns
provided via telecommunication infrastructures and de-
vices, people expect much mor e from maps, including
availability and applica b ility in various devices anywhere
and anytime. According to the definition of ubiquitous
cartography, maps can be created and used anywhere and
anytime. Hence, it is not possible to have highly-s killed

S. H. PAZOKY, F. HAKIMPOUR
OPEN ACCESS JGIS
61
crafts people spend long hours to produce general pur-
pose maps, using traditional drawing methods like paint-
ing by hand [2]. Means of ubiquity are automatic and
Web cartography which are discussed in the next sectio n.
Automatic Web Cartography Techniques
Apart from technical issues, all Internet GIS services can
be divided into two d istinct categories based on the type
of data used. The initial category of services uses carto-
graphic data servers, while the other uses geodata serv-
ers.
Every Internet GIS service is constituted fr om data,
logic and presentation elements [11]. The first category
use data fro m a cartographic center, instead of raw geo-
data. Using this method, geodata is gathered, the map
features are selected and designed to form a seamless and
tiled map. Map providing procedure starts with a request
from a user. Then, the raster tiles related to the request
are searched and found in the cartographic database and
sent to the user. Therefore, there is no logic behind these
types of services. Although the method is very secure
and lightens the workload of the client; it has also some
serious disadvantages. The first disadvantage is that the
response time ma y grow very much due to heavy load on
the server. The second one is that the met hod needs high
netwo rk bandwidth because the data transmi tted via the
netwo rk is usually very bulky. The architecture can only
be implemented using server-side approach and is shown
in Figure 1(a).
On the other hand, there are some other services that
have direct access to geodata. Instead of previously-
prepared raster tiles, the map is generated from raw geo-
data based on cartographic instructions provided by a
specialist. These methods should be categorized into
server-side and client-side approaches.
Server-side approaches have been implemented by two
distinct technologies. The first technology is Common
Gateway Interface (CGI) which is an interface for run-
ning external programs, software or gateways indepen-
dent from platform. The most important bottleneck of this
method is that if several CGI programs are operating
simultaneously, it places considerable workload on the
server. In addition, w henever a client m akes any change to
inputs, the CGI program starts a new process thread,
consuming considerable computer resources [12]. The
CGI-based approach is thus not a suitable meth od for m ap
visualization on the Web [7]. Map Server is a software
package that uses this approach. There are some codes f or
map presentation in t he server-side. When the user sends a
request, the map is generated and sent to the user as im-
ages [13,14].
Another server-side approach is using Java Servlets
which is a program that runs on a Web server. Servlet
usually works much faster than CGI, since it stays resi-
dent in memory when running. Another advantage of
Java Servlet s is its porta bility bet ween operating sys tems
and also servers [7,13]. The architecture of server-side
methods is shown in Figure 1(b).
The other alternative is to transfer some of the respon-
sibilities of server to the clien t. There are t wo major me-
thods for this approach.
The initial method is Java applet. A Java applet is a
small program written in Java which runs on the client.
Java applets are platform independent similar to Java
Servlet. Running on the client side, developers can de-
sign user-friendly and interactive interfaces using Java
(a) (b)
Figure 1 . How server-side Internet GIS services using (a) Cartographic database; (b) Geodatabase work.

S. H. PAZOKY, F. HAKIMPOUR
OPEN ACCESS JGIS
62
applets. However , if the program and also the data are
large, applet may overload the client and even paralyze
the clie nt machine [7].
Another solutio n is using plug-ins to install in
client-side and add functionalitie s to the client’s Web
browser. Unlike Java products mentioned previously,
plug-ins are browser and platform dependent. They pro-
vide add itional abilities for the browser to display and
process spatial data, so that the server’s workload can be
reduced. Since every computation required by every re-
quest is done on the requester machine, clients’ interac-
tions with the server can usually take place frequently
and ef ficiently [7]. The architecture of the me thod is
shown in Figure 2.
3. Proposed Approa ch
What shapes the foundation of this paper is that X SLT is
not de signed to produce visual ma ps from GML. It is a
general-purpose language to reformat all types of XML
documents. Therefore, making a map with all the ingre-
dients using X S LT is very sophisticated. Fo r example, in
most cartography software, legend is generated automat-
ically. But if u s ers want to draw a complete legend on
their own, it wo uld be more similar to drawing in vector
environment such as AutoCad or CorelDRAW. The dif-
ference is that instead of dra wing tools provided in these
environments, the user should write XS LT or SVG codes,
whi ch are very complicated and time-consuming. What
make s the situat io n even worse is that since the graphical
result of writing codes is not provided real-time, the
process will become a trial and error proce ss. Extending
XSLT to meet cartographic requirements is the maj or
idea presented in this paper. The paper provides func-
tions, operators and ingredients for map cartography.
In this section, the investigator is to identify and de-
scribe the fundamental functionalities required to trans-
form geo-referenced data to a visualization format such
as SVG. In the next section, the functionalities are im-
Figure 2. How client-side Internet GIS services using geo-
datab ase work.
plemented using XS LT and it is clarified how Web car-
tography specialists can use them.
As discussed earlier, client-side computing has many
advantages over server-side computing. In this paper, the
process of converting GML to a presentation language
like SVG is transferred to client-sid e using plug-in tech-
nology. Advantages of server-sid e approach are as fol-
lows :
 Higher security;
 Higher concealment;
 No need for the technologie s to be widely approved.
On the other hand, advantages of client-side approach
can be listed as follows:
 Les s d ata is transferred on the net wor k .
 Les s frequently the d ata is transferred on the network.
 Higher level of interaction.
In addition, advantages of client-side app roach for the
discussed method are as follows:
 Separation of content fr om pre sentation;
 Reusabilit y of XSLT file generated by the server;
 Possibility to make per sonal p r o files fo r each client;
 Customizabil ity of the resultant ma p both content-
wise and graphically.
Another difference of this research with the previous
ones is that X SLT is extended to visualize GML maps
with SVG. Extending XSLT requires first to id entify
what needs to be added to current capabilities and then
implem en t t hem.
The mos t straight forwa rd way to extend XSLT is by
extension functions. As a consequence, a set of functions
with appropriate input and output are determined. The
areas where functions should be considered are as fol-
lows :
 Introducing spaces;
 Transforming fr om real space to monitor space;
 Calculating scale;
 Drawing geospatial features with appropriate sym-
bology and texts;
 Drawing outer map features.
The above-mentioned areas are necessary ones to ex-
tend XSLT in a way to be able to mak e an elementary,
but complete map.
3.1. Introducing Spaces
The page that a viewe r can see in a map is divided into
several parts including the following:
 browser space;
 user space;
 map space;
 geospatial features space;
 outer features space.
The hierarchy of the spaces is depicted in Figure 3.
Functions providing the user with different spaces are
mentioned bel ow:

S. H. PAZOKY, F. HAKIMPOUR
OPEN ACCESS JGIS
63
Figure 3. Map spaces hierarchy.
“public static String view box (coords, margin, b
Space Width, b Space Height, Precision)”
The above function is responsible for calculating the
minimum bounding box and receiving some global pa-
rameters fro m user with parameters as follows: coords:
the coordinates of all the sp atia l features on the map;
margin: browser space marg in; b Space Width: width of
the browser space; b Space Height: height of the browse r
space; and Preciosion: precision of all the numbers gen-
erated in the application.
“public static String border (margin)”
The above function creates the border of user space
where margin is user space mar gin .
“public static void margin Set (margin, Umargin)”
The function creates the marg in of map space using
the following parameters: margin: ma rgin between user
space and geospatial features space; where Umargin:
upper margin between user space and geospatial features
space.
Another useful function of this category is to draw
neatline. Neatline is a rectangle surrounding geospatial
features space. The function is as follows:
“public static String neatline (hShift, vShift)”
Where hShift is horizontal shift of the geospatial fea-
tures space; and vShift is vertical shift of the geospatial
feature space.
3.2. Tra nsforming Real Space to Monitor Space
There is a difference between coordinate system of real
space and monitor space as shown in Figure 4.
Afte r calculating the appropriate transformation para-
meters between the two spaces, the function to perform
the trans formation by using the above equation is as fol-
lows :
“private static String cords Change (coordPair)”
Where coordPair shows coordinate pairs to be trans-
formed fr om real space to monitor space.
3.3. Calculating Scale
To draw the map, the scale between real space and mon-
(a) (b)
Figure 4. Difference of coordinates systems of (a) Monitor
space ; and (b) Real space.
itor space should becalculated. In order to achieve the
goal, two elements are required: Space available on the
monitor and actual ground space that accommodates real
features. Space available on the screen as described
above is asked from the u se r through “view box” function.
Real space comprises of sets of nodes of all selected fea-
tures. Al l the nodes in the GML file, which are intended
to be drawn on the map, are al so introduced to the “view
box” function. Usin g maximum and minimum values of
northing and easting, scales in vertical and horizontal
directions are calculated using the following equations:
( )( )
horizontal scalemax min
w
XX
=−
( )( )
vertical scalemax min
h
YY
=−
where “w” is the width and “h” is the height of geospatial
features space.
Based on the geospatial features space, scales in the
two directio n s are d if fere nt. To preserve the map fro m
horizontal or vertical elongation, a unique scale should
be chosen for both directio ns. As the geospatial features
space introduced before cannot be exceeded, the mini-
mum value of scales is chosen as the eventual map scale.
An important point to mentio n is that choosing the min-
imu m value of the two scales causes the geospatial fea-
tures space to decrease in one direction. Thus, map de-
signer should be alert not to leave any e mpty space.
The function to calculate the scale based on aforemen-
tioned equations is as follows:
“private static double scale Detection (minE , maxE,
minN, maxN, gfsBounds)”
Parameters are as follows: minE: minimum easting;
maxE: maxim um easting; minN: mi nimum northing;
maxN: maximum northing; and gfsBounds: geospatial
feature space bounds.
3.4. Drawi ng Geospatial Features with
Appropriate S ymbology an d Text
Geospatial features are categorized into three groups:
points, polylines, and polygons. For each of the groups,

S. H. PAZOKY, F. HAKIMPOUR
OPEN ACCESS JGIS
64
drawing, labeling and symbology is different. Therefore,
diffe re nt functions should be considered for each cate-
gory.
 Points: Points are comprised of just two coordinate
values of easting and northing. Point symbols should
be defined in SVG file and the functio n refers to the
symbol. Furthermore, the size of the symbol is ad-
justab le using the function. The functio n to draw
points with appropriate symbology is as follows:
“public static String sty lePoint (coordPairs, sym,
fName, labelTag, symH, symW, labelSty le)”
Using the following parameters: coordPairs: coordi-
nate p air s rep r esenting a point; sym: reference to SVG
point symbol; fName: name of the feature group in
the legend; labelTag: tag to label features according-
ly; sym H: symbol height; symW: symbol width; and
labelSty le: label styling.
 Polylines: Polylines are comprised of two sets of co-
ordinates. As there is no way to d e fi n e linear symbols
in SVG, polyline symbols are implemented using
“style” which is a CSS r eserved keyword. The text of
a linear feature should be written on it several times
with a certain interval. The function for drawing po-
lylines wit h appropriate styling is as follows:
“public static String stylePolyline (coordPairs, fName,
labelTag, labelInt, styling, labelstyle)”
Parameters are as follows: coordPairs: sets of coor-
dinate pairs representing a line; fName: na me of the
feature group in the legend; labelTag: tag to label
features accordingly; labelInt: labels interval; styling:
defining linear symbols using CSS code; and label-
Style: label styling.
 Polygons: Polygo ns are also comprised of two sets of
coordinates. Like points, polygons can use externally
defined symbols. In addition, as polygons are sur-
rounded with lines, border lines can be styled by CSS
“style” keyword. Labels of polygons should be in the
middle of the polygon. The function for drawing po-
lygons is as follows:
“public static String stylePolygon (coordPairs, sym,
fName, labelTag, styling, labelStyle)”
With the following parameters: coordPairs: sets of
coordinate pairs representing a polygon; sym: r efe r-
ence to SVG polygon symbol; fName: na me of the
feature group in the legend; labelTag: tag to label
features accordingly; styling: defining linear symbols
using CSS code for polygon borders; and labelSty le:
label styling
3.5. Drawi ng Outer Map Features
Outer map features are those whic h help map users un-
derstand the map b ette r and include the followings:
 Map title: Map title is a short hugely-typed text on top
of a map to provide a clear indication on what the
map is displaying. Therefore, top of the map should
be left empty that is accomplished by setting different
margin value for top of the map when using “ma r-
ginSet” function. The function designed for produc-
ing map title should suggest the best p lace fo r title .
Also, two parameters are needed that if the suggeste d
position is not acceptable for the users, they can move
it in two direction s. The function which displays the
title is as follows:
“public static String title (text, hOffset, vOffset, styl-
ing)”
Parameters are as follows: text: title text; hOffset : ho-
rizontal o ffset of the title ; vOffse t: vertical offset of
the title; and styling: title text styling.
 Grid: Grid lines define locations on map using Carte-
sian coordinate system. Each grid line spe cifies one
coordinate horizontall y or vertically based on its di-
rection. The function is as follows:
public static String grid (startingE, startingN, hInt,
vInt, dist1, hOffText, vOffText, textStyle)
Using the follo wing parameters: startingE: the easting
of the first vertical grid line; startingN: the northing
of the first horizonta l grid line; hInt: interval between
horizontal grid lines; vInt: interval between vertical
grid lines; dist1: distance of grid line texts from grid
lines; hOffText: horizontal offs e t of texts; vOffText:
vertical offset of texts; textStyle : te xts styling.
Different parameters of grid function are depicted in
Figure 5(a).
 Legend: Legend is where all symbols used in the map
are gathered showing which f eature they re fer to. The
function declaration should be as mentioned bel ow:
“public static String drawLegend (pX, pY, width , title-
Style, textStyle , borderStyle)”
With the following parameters: pX: X coordinate of
the position of the legend in outer features space; pY:
Y coordinate of the position of the legend in outer
features space; width: legend width; titleStyle : styling
of the title s of the legend; textStyle: styling of the text
used in the legend; and borderStyle: styling of the
border of the legend.
Different Parameters of legend function is depicted in
Figure 5(b).
 Scalebar: Scalebar is a graphical representation of
scale that helps users measure distances on a map.
Since scalebar is more complicated than other outer
map features and has mor e distinct elements, para-
meters of this f u nctio n are mo re than previous ones.
The function declaration is as follows:
“public static String scaleBar (ty p e , div, divLength,
subDiv, pX, pY, dist1, dist2, height, titleStyle, head-
Style, oddStyle, evenStyle, titleHOff headHOff)”
Parameters are as follows: type: scalebar type; div:
number of divi si ons; divLength: d ivisio n length ;

S. H. PAZOKY, F. HAKIMPOUR
OPEN ACCESS JGIS
65

(a) (b)
(c)
Figure 5. Different parameters of (a) “grid”; (b) “drawLegend”; (c) “scal ebar” f unctions.
subDiv: number of subdivisi ons; pX: X coordinate of
the position of the scalebar in outer features space; pY:
Y coordinate of the position of the scalebar in outer
features space; dist1: distanc e of title from scalebar;
dist2: distance of heading from scalebar; height: sca-
lebar height; titleS ty le: ti tle styling; headStyle: head-
ing styling; oddStyle: scalebar styling odd parts;
evenStyle: scalebar styling even parts; titleHOff: title
horizontal off s et; and headHOff: heading horizontal
off set.
Different Parameters of scalebar function is depicted
in Figure 5(c).
 North arrow: North arrow type is defined by symbols
in SVG directly and referenced in the function. The
function is as follows:
“public static northArrow (pX, pY, sym)”
Using the follo wi ng parameters: pX: X coordinate of
the position of the north arrow in outer features space;
pY: Y coordinate of the position of the north arrow in
outer features space; and sym : reference to t he symbol.
 Map metadata: Every map should contain production
information, otherwis e it is not valid. The text is en-
tered by the user and ‘\n’ wil d card should be used to
go to next line. The function is as follows:
“public static metadata (pX, pY, text, textStyle)”
With the following parameters: pX: X coordinate of
the position of the north arrow in outer features space;
pY: Y coordinate of the position of the north arrow in
outer features space; text: metadata text; and textS ty le:
Text Styling.
4. Prototype Implemen tation
Required functions to extend general-purpose XML
Transformation language to a cartographic tool wer e in-
troduced in the previous section. In this section, most of
the functions are implemented to demonstrate how using
extension functions can facilitate GML to SVG conver-
sion on the client side with c o nditions described in pre-
vious sections. Furthermore, a graphical user interface
called XCarto T is designed to make the process more
user-friendly and also allow less professional users to

S. H. PAZOKY, F. HAKIMPOUR
OPEN ACCESS JGIS
66
produce well-designed maps using aforementioned tools.
4.1. Implementing Extension Functions
4.1.1. Data
The data used in the research consists of the followi n g:
 Polygon features: parcels of 6 municipal regions;
 Polyline features: streets of the same regions;
 Point features: petrol stations, police stations and hos-
pitals of the same regions.
4.1.2. XSLT File
The first line of code to talk about is the openi ng <svg>
tag that is as follo ws:
‘<svg height="" width=" " viewBox="" version="1.1"
preserveAspectRatio="none">’
In this line, 3 parameters should be set. The height and
the width of the page which specifies browser space
sho ul d be entered by the user. The value of the “viewBox”
attribute is a li st of fou r numbers <min-x>, <min-y>,
<wid th> and <height>, separated by whitespace and/or a
comma . This attribute determines a rectangle in user
space which s hould be mapped to the bounds of the
viewport established by the given element. It is notewor-
thy to mention that this attribu te is mandatory and cannot
be left emp ty [4]. “viewbox” function described in the
previous section is used to calculate the value of this
attribute. This line of code runs “viewbox” function and
sets the output to a “viewbox” variable:
‘<xsl:variable name="viewbox" select="carto:viewbox
(// gml :pos L is t, 5,1260,600, 2) " /> ’
Where ‘//gml:posList ’ is an XPath express i on input-
ting the coordinates of all spatial features.
After substituting val ues, SVG tag would be as follows:
‘<svg height="600" width="1260" viewBox= "{$view-
box}" version="1.1" preserveAspectRatio = “none”>’
Where “{$viewbox}” is the name of the variab le to
store the output of “viewbox” function.
Next step is to call the “border”, “marginSet” and
“neatline” functions to determine the coordinates of dif-
ferent spaces whi ch are depicted in Fig ure 6(a). The
functions may be called as follows:
‘<xsl:variable name="border" select="carto:border
(10 )" />’
‘<xsl:valu e -of select="carto:marginSet (20,50)" />’
‘<xsl:variable name="neatline" select="carto:neat-
line (270,0)" />’
The user is also able to draw map border and neatline.
To do so, the result of these functions should be used to
draw rectangles using t he SVG code lines b elow:
‘<polyline points="{$border}" style="fill:white;stroke:
black;stroke-width:2" />’
‘<polyline points="{$neatline}" style="fill:white;stroke:
black;stroke-width:1" />’
To draw geospatial features in the provided geospatial
feature space, different symbologies can be defined using
SVG capabilities whic h some samples are shown in Fig-
ures 6-8.
In the XSLT file, geospatial features are drawn one b y
one. Thus, drawing s hould be inside a loop.
(a) (b) (c)
Figure 6. S ample point symbols for (a) Hos pita l; (b) Police dep ar tment ; and (c) Petrol stations.
Figure 7. Sample linear symbols.
Figure 8. Sample polygon s ymbols.

S. H. PAZOKY, F. HAKIMPOUR
OPEN ACCESS JGIS
67
At this stage, outer map features are added to the map.
The ones which are imp lemen ted in this research are as
follows:
 map title
 grid
 legend
 scalebar
“title” functio n is called as fo llows:
‘<xsl:valu e -of select="carto:title('Sample Map',-350,
25,'font-family:Vernada;font-size:24p t' )"/>’
The following line of code is to produce grid lines:
‘<xsl:value-of select="carto:grid(536000,3948000,1000,
1000,5,'stroke:rgb(99,99,99);stroke-width:1','font-family
:Vernada;font-size:7pt' ,-15,-15)" / >’
The following line of code produces a legend:
‘<xsl:value-of select="carto:drawLegend(1050,50,130,
'font-family:Vernada;font-size:10pt','font-family:Vernad a
;font-size:7pt ' , 'fill :whit e ;stroke : black ;stro k e -width:1')" />’
And finally, the follo win g line of code is used to pro-
duce a legend:
‘<xsl:valu e -of select="carto:scaleBar(1,3,600,5,990,
70,20,5,8,'font-family:Vernada;font-size:12pt','font-famil
y:Vernada;font-size:7pt','fill:#C0C0C0;stroke:bl ack;st ro
ke- width:1','fill:#9ACD32;stroke:black;stroke-width:1',-
80,-2)" />’
The final result wit h all the map surroundings is as de-
picted in Figur e 9.
4.2. Developing a GUI for the Application
(XCartoT)
Using extension functions to facilitate map making from
geo-referenced data might confuse users unfamiliar with
geospatial and Web concepts. In other words, Web
car-tographers may find it difficult to learn and use
XSLT language as well as our extended functionalities.
To alleviate this problem and simplify map making
process, a user-friendly graphical user interface called
“XCartoT” is designed. XCartoT generates the necessary
Figure 9. Result map after adding geospatial features with
their symbology.
XSLT fi l e automatically according to the carto graphers’
requirements. In this section, XCartoT is introduced.
First view of XCartoT is shown in Figure 10.
XCartoT is made up of t wo parts: The menu bar and
some tabs. The hierarchy of the tab s is s h own in Figur e
11.
In ‘Map Generation Features’ tab, user should set all
the parameters required to produce a map. The parame-
ters are those described in Sections 5 and 6. For better
organization, these parameters are categorized into four
groups: Basic Parameters, Drawing Laye rs, Symbology
and Outer Map Features.
After setting all the para meters, XSLT file is produced
automaticall y using extension functions described in pre-
viou s sectio ns. Goi ng to “Code” ta b and cho osing X SLT
nested tab, the user can view automatically-generated
XSLT file.
“GML” tab shows GML file after being introduced to
the applicatio n. GML fileshould be added to the applica-
tion using the menu bar. Having GML and XSLT files,
SVG file is produced by choosing “Transform” menu
item. Then, it is visualized by ajava SVG visualization
library called Batik and can be viewed in “SVG View”
tab as shown in Figure 12. Finally, the whole procedure
can be summarized in the following flowchart (Figure
13).
Figure 1 0. First vi ew of the GUI.
Figure 1 1. T he hierarchy of XCartoT tabs.

S. H. PAZOKY, F. HAKIMPOUR
OPEN ACCESS JGIS
68
5. Literature Review
This section is dedicated to introduce and compare work
of various other researchers in this area. The first re-
search was done by Mansfield, P and Fuller, D. [15]. The
authors introduce the idea of converting XML to SVG
via XSLT. XML data used in the research is not geospa-
tial and there’s no examp l e of converting geospatial data
to SVG.
Another research is done by Taladoire, G. [16]. The au-
thor has explained the problem well and described all the
details. The input data used is GM L, but a complete
conversion from GML to SVG is not shown. The author
has used CSS for styling, but the resultant map is not
interactive.
Another research is done by Neumann, A. and Winte r,
A.M . [17]. The authors demonstrate that vector graphic
Figure 12. SVG view generated after producing SVG code
in “S VG Vi e w” tab.
Figure 13. The whole procedure of map production using
the propo sed metho d.
has higher quality than raster graphic. Then, languages
for vector graphics are introduced and compared. These
languages include: SVF, DWF, Flash, PDF, PGML,
WebCGM, HGML, DrawML, VML, Java2D and XML.
The conclusion of the comparison leads to the fact that
SVG is the best choice to present the maps on the Web.
The major ad vantage of this research is that the maps are
completel y interactive.
A very efficie n t conversion of GML to SVG is done
by Tennakoon, W. [18]. The author has converted a com-
plete GML file to SVG using XSLT code.
Another atte mpt is done by Spanaki et al. [19] in
Athens, Greece. The difference between this paper and
the previous atte mpts is that the conversion is done in the
internet browser of the client.
Bonati et al. [20] have also researched in this area .
Their approach is exactly similar to the previously cited
papers, but the generated map is completely interactive.
The user can pan, zoom, and change symbols and much
more.
A paper assembled by Ron in Galdos Systems Inc. is
somehow similar to the idea mentioned in this r esearch.
The difference between this research and previously cited
papers is that the author introduces the idea of extension
functions in XSLT. This function should be implemented
in the XSLT engine to work as is done in this research.
However, there is no implem e ntatio n of extension func-
tions in this research.
6. Conclusions
Emerging various methods, practices, software, etc has
caused standards to be the necessities of today’s life .
GML as a standard, which is recommended by OGC, is a
language to store and to transport geospatial data. Having
no informatio n on how to visualize the data graphically,
GML is a means to separate geospatial content from
graphical presentation. Therefore, there are several ways
to visualize the textual geo-referenced data. A straight-
forward method is to convert GML to a graphical lan-
guage like SVG, using a convertor like XSLT. Although
the process has been implemented several ti me s by dif-
ferent scientists, the research has improved the current
approaches inseveral aspects:
 Transformation process is completely transferred to
client-side. Using the proposed approach, the user has
access to geodata, as well as an appropriate visualiza -
tion of the data. Another advantage is that geodata
transferson the network much faster than raster im-
ages. Furthermore, geodata is transferred once and
can be visualized many times without any need to
connect to the server. Unlike server-side appro aches,
there is not much load on the server, since it just pre-
pares and sends geo-referenced data and sometimes
XSLT file needed for presentatio n. The next advan-

S. H. PAZOKY, F. HAKIMPOUR
OPEN ACCESS JGIS
69
tage is that there is no need to install any special
sof tware on the computer or mobile device except fo-
ra mere internet br owser of any vendor because the
required plug-ins are pre-installed on all ma jor inter-
net browsers, although the qualit y of the resultant
maps mig h t have slight differences in special condi-
tions such as animation.
 The next important contributio n of the pap er is that
XSLT as a general-purpose transformation language
is extended to meet cartographic requirements of
map-maki ng. Required functions are recognized, de-
signed and imple me nted . Although several functions
can be thought of to be added to XSLT, the research
focuses on the most i mportant ones.
 The final c o ntribution is developing a GUI called
XCartoT to further facilitate users in map-making
process through this method. XCartoT allows users to
set all the parameters of a map and the XSLT file is
generated automatically using extension functions.
Then, after introd uctio n of GML file, conversion is
executed and the resultant SVG file is available for
the use r both textually and graphically.
 Geospatial Web is a concept in information era to
provide access to maps anywhere and anytime using
the Internet and mobile devices. The goal of the re-
search is to prepare the required steps towards the
geospatial Web. Furthermore, the investigator sug-
gests that standardization organizations and consor-
tiums such as W3C ob lige Web browsers for both for
computers and mobile devices to support geospatial
services.
REFERENCES
[1] Open Geospatial Consortium (OGC), “Geograpy Markup
Language (GML),” 2007.
http://www.opengeospatial.org/standards/gml
[2] G. Gartner, D. A. Benn et and T. Moritta, ‘Towards Ubi -
quitous Cartography,” Cartography and Cartographic
Information Science, Vol. 34, No. 4, 2007, pp. 247-257.
http://dx.doi.org/10.1559/152304007782382963
[3] Z. Peng and C. Zhang, “The Roles of Geography Markup
Language (GML), Scalable Vector Graphic (SVG), and
Web F eature Servi ce (WFS) Specifications in th e Devel -
opment of Intern et Geographic Information Systems
(GIS),” Journal of Geographic Systems, Vol. 6, No. 2,
2004, pp. 95-116.
http://dx.doi.org/10.1007/s10109-004-0129-0
[4] Wo rld Wide Web Consortium (W3C) , “Scalable Vector
Graphics (SVG) 1.1 (Second Edition),” 2011.
http://www.w3.org/TR/SVG/
[5] A. Neumann and A. M. Winter, “Time for SVG—To-
wards High Quality Interactive Web-Map s,” Proceedings
of the 20th International Cartographic Conferen ce, Bei-
jing, 6-10 August 2001, pp. 2349-2362.
[6] B. Jenny, A. Terribilini, H. Jenny, R. Gogu, L. Hurni and
V. Dietrich, “Modular Web-Based Atlas Information Sys-
tems,” Cartographica, Vol. 41, No. 3, 2006, pp. 247-256.
http://dx.doi.org/10.3138/2773-Q553-0483-NP77
[7] X. Yao and L. Zou, “Interoperable Internet Mapping: An
Open Source Approach,” Cartography and Geographic
Information Science, Vol. 35, No. 4, 2008, pp. 279-293.
http://dx.doi.org/10.1559/152304008786140560
[8] M. Kramis, C. Gabathuler , S. I. Fabrikant and M. Wal-
dovogel, “An XML-Based Infrastructure to Enhan ce Col-
laborative Geographic Visual Analytics,” Cartography
and Geographic Information Science, Vol. 36, No. 3, 2009,
pp. 281-293.
http://dx.doi.org/10.1559/152304009788988305
[9] Wo rld Wide Web Consortium (W3C), “XSL Transforma-
tions (XSLT) Version 2.0,” 2007.
http://www.w3.org/TR/xslt20/
[10] A. Scharl and K. To chtermann, “The Geosp atial Web:
How Geobrowsers, Social Software and the Web 2.0 Are
Shaping the Network Societ y,” Springer, London, 2007.
http://dx.doi.org/10.1007/978-1-84628-827-2
[11] Z. R. Peng and M. H. Tsou, “Internet GIS,” Wiley, Ho-
boken, 2003.
[12] S. Gundavaram, “CGI Pro gr amming on th e World Wide
Web,” O’Reilly Associates, Sebastopol, 1996.
[13] B. Huang and M. F. Worboys, “Dyn amic Modelling and
Visualization on the Internet,” Transactions in GIS, Vol.
5, No. 2, 2001, pp. 131-139.
http://dx.doi.org/10.1111/1467-9671.00072
[14] B. Kropla, “Beginning MapServer: Open Source GIS De-
velopment,” Springer-Verlag, New York, 2005.
[15] P. Man s fiel d and D. Filler, “Graphical Stylesheets Using
XSLT to Generate SVG,” Proceedings of XML Confer-
ence.
[16] G. Taladoire, “Geospatial Data Intergration and Visuali -
sation Using Open Standar d,” 7th EC-GI & GIS Work-
shop, Potsdam, 13-15 June 2001.
[17] W. T. M. S. B. Tennakoon, “Visualization of GML Data
Using XSLT,” Diploma Thesis, International Institute for
Geo-Information Science and Earth Observation, En-
schede, 2003.
[18] M. Spanaki, B. Antoniou and L. Tsoulos, “Web Mapping
and XML Technologies: A Close Relationship,” 7th
AGILE Conference on Geographic Information Science
Heraklion, 29 April-1 May 2004.
[19] L. P. Bonati, L. Fortunati and G. Fresta, “SVG Explorer
of GML Data,” Proceedings of SVG Open, Vancouver,
13-18 July 2003.
[20] R. Lake, “Making Maps for the Web with GML,” Galdos
Systems, Inc.