Delft University of Technology,
Department of Geodesy, Section
GIS-technology
Thijsseweg 11, 2629 JA Delft, The Netherlands
Tel (+31) 15 2784268
Fax (+31) 15 2782745
Email: m.e.devries@geo.tudelft.nl
SVG has a lot of potential
for the publishing of geographic (or "spatial") content on the Web. Many
examples exist of user friendly, interactive interfaces based on a combination
of SVG, HTML and JavaScript. Basic functionality like "pan", "zoom", "identify"
and visibility control (switching on and off of map layers) is not a problem.
If there are bottlenecks these are mostly in the field of performance (loading
time) or they concern differences between (versions of) browser software that
have to be handled.
At this moment SVG seems
especially suitable for sites that show the more or less pre-defined content of
one provider. It also helps when file (or stream) sizes are not too large. For
other Web Mapping situations (retrieving data of more than one provider,
analyzing and editing) more work has to be done. Important issues are:
1 Ways to reduce loading time (as perceived by the
user). A strategy could be to store the SVG path or shape elements in the
database. Synchronization with the real (geographic) data can be enforced by
stored procedures etc. Loading time will be reduced because the on the fly
transformation of feature instances into SVG can be skipped.
2 Better possibilities to change the rendering order
of SVG elements (or element groups). There are ways to do this, but some
methods have consequences for event handling (grouping and referencing with
<defs> and <use>), or they
involve DOM actions for all individual elements of a group ("removeChild",
"insertBefore", "appendChild"). Maybe the "z-index" construct should be added
to the SVG specification after all.
3 Better support by plug-in software for inbound
linking into SVG (addressing SVG fragments by their id). At this moment
(January 2002) only Apache"s Batik seems to be able to handle this. This could
also be a solution for the rendering order issue.
SVG is "only" the graphic
format. The geographic information itself is stored in proprietary GIS or CAD
file formats or in object relational databases (Oracle Spatial, Informix
Spatial etc.). This raises the question of the transformation from the data
itself into SVG. This can be done as a batch process or "on the fly" with SVG
data and (dynamic) HTML pages as a result.
At the TU Delft we are
experimenting with the transformation of GML into SVG. GML (= Geography Markup
Language) is an important initiative of the OpenGIS Consortium. It is a domain
specific XML vocabulary meant for the storage and exchange of spatial data.
The OpenGIS GML
specification is basically a set of XML Schema documents with element
declarations and type definitions plus a hierarchical structure for the relationships
between types. In this way the specification offers a framework that can be
used by organizations to make the application specific XML Schema(s) for their
own GML implementation. User organizations do this by extending the basic GML
object types as defined in the specification.
GML can play a part in
geographic data exchange in a number of ways:
-
as an "offline"
exchange format (downloadable files or on CD)
-
as an "online" format
for retrieving and maybe even updating spatial data. Another OpenGIS initiative
is important here: the Web Feature Server specification. The Web server outputs
GML as response to a client request.
We chose XSLT for the
transformation of GML into SVG. Some components of the GML viewer were hard
coded: the rendering order of the map layers and the styling parameters (color,
fill, line width). For the "identify" operation the original GML data is
queried with the help of a unique id.
The next step will be
to make a viewer that will consist of a generic 'core' in combination with some
interactive modules that make it possible for users to change the rendering
order of the map layers, and to change the classification and/or styling
attributes for feature sets.
It proved not "trivial"
to write transformation software that can transform GML into SVG regardless of
its data structure. This is because of the fact that feature and attribute
names are not fixed, but vary from organization to organization. Also the
hierarchical structure (nesting of features and feature collections) is not the
same for every GML implementation.
The XML application
schema(s) that describe the structure of the GML play a crucial role in this
respect: the transformation software will have to read the implementation
specific XML Schema document or documents first, before it can 'understand' and
transform the GML data.