Introduction
Scalable
Vector Graphics (SVG) is the emerging standard for the display of
two-dimensional vector graphics on the Web. It has been developed by the World
Wide Web Consortium (W3C) – the body responsible for Web standards such
as HTML. SVG displays three types of graphics: vector graphic shapes,
such as lines, arcs and polygons (including polygons with holes), text,
and raster images, which can be positioned relative to other features in
the image.
SVG
is a grammar in XML (eXtensible Markup Language), another W3C
specification. Through the use of
a scripting language (such as JavaScript), and access to the SVG Document
Object Model (DOM), images can be made both interactive and dynamic
within the Web browser.
An
SVG image can be made interactive through the assignment of event
handlers, such as “onclick” and “onmouseover”, to image elements. These
might be used, for example, to highlight a selected feature, show
attribute information, or display a “map tip”.
Through
the DOM, image elements and groups of elements may dynamically be given
new styles (color, etc), made visible or not, moved or modified. New
elements may even be added. All this can take place on the client machine
– without a “round trip” to the server.
SVG
is an ideal candidate for displaying GIS (Geographic Information Systems)
information in a Web browser. All typical GIS features can be readily
displayed (and manipulated), and data is transferred in a compact vector
(rather than raster) format. Since SVG is XML, it leverages and
integrates with other W3C standardization efforts. This means that
facilities already developed, such as Cascading Style Sheets (CSS2) and
Extensible Stylesheet Language Transformations (XSLT), can be readily
employed – they didn’t have to be “reinvented” for SVG. Also, since it is
XML, the SVG DOM plugs seamlessly into the DOM of browsers, such as those
from Microsoft and Netscape, and is easily accessed from DHTML (Dynamic
Hypertext Markup Language) pages. This facilitates easy to code,
efficient, responsive interaction with the user.
Status
Technically,
the W3C does not create standards – it publishes “Recommendations.” In the
Web community, however, a W3C recommendation is as close to a standard as
you’re likely to see. Currently, as of August 2, 2000, the SVG 1.0
specification has a status of “Candidate Recommendation.” This means that
developers are encouraged to create implementations and provide technical
feedback. The specification could be elevated to “Recommendation” status
at any time.
SVG
has the support of all the “big players”. These include Microsoft,
Netscape, IBM, and Sun Microsystems. SVG is being promoted by the major
graphics software vendors, such as Adobe and Corel. All of these
companies (and about twenty others) have been active contributors to the
standardization effort.
Once
SVG becomes a Recommendation, it is expected to become a built-in
supported document type for both Microsoft’s Internet Explorer and
Netscape’s Navigator. In other words, SVG will be supported natively, and
not require a “plug-in”.
In
the meantime – until SVG is natively supported in the major browsers –
plug-ins are available (at no cost) for rendering SVG images. The most
popular of these is from Adobe.
Advantages
of SVG
SVG
is XML. As such, any tool used in support XML can be used in support of
SVG. SVG can leverage other facilities developed to enhance XML – those
facilities don’t have to be “re-invented” specifically for SVG. SVG will
be the 2D vector graphics standard for the Web. Support should be broad
and universal – not confined to the GIS or technical communities.
SVG
is vectors. If produced intelligently, it can be more compact than
equivalent raster images, and more compact than many vector formats, as
well.
SVG
will be built-in. Currently, a plug-in is required to view SVG in a
browser, but this is likely to change shortly. Once SVG is supported
natively by the major browsers, not only will it not be necessary to
download and install a plug-in, you’ll never have to worry about upgrade
problems when changing to a new version of a browser.
How MRF Is
Using SVG
One
of the acclaimed advantages of SVG is the ability to pan and zoom an
image on the client side – since the image is based on vectors, it is
“resolution independent”, and you don’t see the choppiness you would if
you zoom in on a raster image. The problem with this as it relates to a
GIS image server is that, as you zoom in, you expect to see greater
detail. In order for that detail to be displayed, it would have to have
been in the image sent to the client. More detail means longer
transmission and rendering times. Panning presents a similar problem in that
the image would need to contain information you would not initially be
able to see. Carrying this to its logical conclusion, providing full
panning and zooming on the client would entail downloading the complete
feature sets from the server. Not a practical solution, in most cases.
The
approach taken with the MRF SVG Map Server is to send only the amount of
detail needed to render the image at the scale selected – panning and
zooming is disabled. Several techniques are used to produce images that
the orders of magnitude are smaller than they would be, if sent out at full
resolution. Each pan or zoom requested by the user requires a trip back
to the server for a new image, but the penalty is small, due to the
reduced image size.
Data Security
The “minimum
resolution” approach taken by MRF has a beneficial side-effect. Many data
vendors are concerned that their spatial data-sets not be published on
the Internet in such a way that they could be downloaded and put to
unauthorized use. The MRF approach to SVG delivery discourages this in
two ways:
- The points sent out are
in pixel positions, rather than coordinates. When zoomed out, the
resolution of these points will be very coarse (relative to the
original coordinates), and likely to be of little use. When zoomed
in, the point resolution will be better, but only a small portion of
the data-set will be included in the image. In order to extract a
significant amount of data with reasonably good point resolution, a
large number of queries would need to be made, and then the data
pieced together – a server could be programmed to detect this kind
of activity.
- It is not necessary to
include location, scale, or projection information in the image.
Without this reference information, the data extracted would be less
useful.
Online Demo
- Download plug in
Although we expect the
situation to change in the next year, SVG is currently not supported
natively in your browser. Adobe
has the Version 2 SVG plug in available for free download at the
following URL:
http://www.adobe.com/svg/viewer/install/
NETSCAPE USERS: please note that the current version of
the demo only operates on IE 5.0 and higher. Please contact
us for information on when the SVG demo will operate in Netscape.
2.
Running SVG map server demo
Please download and install
the SVG plug in before continuing with the online SVG demo at:
Basic Demo
Some Useful
Links
http://www.w3.org/Graphics/SVG/Overview.htm8
http://www.w3.org/TR/2000/CR-SVG-20001102/ (specification)
http://www.adobe.com/svg/ (good
tutorial)
http://wdvl.com/Authoring/Languages/XML/SVG/
(more links)
If you would like a live or online demo of our SVG
server, please click here and send
us your contact information or call 1-877-216-5515.
|
