Internet Mapping Sans Map Server - Scalable Vector Graphics

In last week’s discussion about the wonders of PostgreSQL and PostGIS, I mentioned I’d talk about serving maps without a map server (in the publishing world we call that a “teaser”). Alas, the PC is up to his eyeballs in work, so he didn’t get quite as far in to it as he would have liked, but I have enough to give you a sampling. So, with no further whining….SVG!

Scalable Vector Graphics (SVG) is an XML document standard for describing 2d vector graphics. It’s an open standard created by the W3C, those same nice folks that brought you the HTML and CSS standards. It describes features like lines, curves, polygons, raster images, and text, in plain ascii XML. This is then interpreted by the user’s browser to render vector features.

Take this snazzy map image for example. I loaded some layers into PostgreSQL, returned SVG for three layers, and displayed it all in a browser. From the database, to the web server, to the client. Do you notice and element missing in the above equation? NO MAP SERVER! The thing that is always the most likely to die a horrible technological death has been completely removed from the equation.

There are a vast number of advantages to this approach. As there is no map server to die (I’d say ~95% of all of our application woes stem from ArcIMS), it’s a vastly more stable solution. As it is a vector rather than a raster raster format, it can scale to any size without increased download size or decreased resolution. You can manipulate the XML the same way you can manipulate anything in the DOM – you can turn layers on and off without ever making a round trip back to the server. The vector features can have intelligence, so you can have mouse-over information based on feature attributes. It’s all open-standards, so if you code in something like PHP, your solution will be completely portable to Apache and/or Linux (or most anything else). The list goes on and on.

Let’s take a look at a typical SVG document.

<?xml version=“1.0” encoding=“iso-8859-1” standalone=“no”?>
<!DOCTYPE svg PUBLIC “–//W3C//DTD SVG 1.0//EN” “http://www.w3.org/TR/SVG/DTD/svg10.dtd”>
<svg viewBox=“0 0 270 400” xmlns=“http://www.w3.org/2000/svg”>
<g id=“mainlayer”>
<rect fill=“red” stroke=“black” x=“15” y=“15” width=“100” height=“50”/>
<g font-size=“20px”>
<text x=“44” y=“88”>rect</text>
</g>
</g>
</svg>


As you can see, it’s a fairly readable document type. After the general declarations, the <svg> tag denotes the actual SVG. Here, it’s drawing a simple rectangle and some text.

How does this help us? The key lies with PostGIS. PostGIS has a function called assvg which returns features as SVG. So, we can make a call like so:

select assvg(the_geom,0,1) as thesvg from voting_precincts

This returns SVG for the voting precincts in a field called thesvg, one record per feature. Then it’s a matter of putting it into an SVG document:

<g id=“baseprec”>
<?php
while (!$recordSet->EOF) {
echo ‘<path d=“’.$recordSet->fields[‘thesvg’].‘” style=“stroke: black; fill: white;” />’;
$recordSet->MoveNext();
}
?>
</g>


It loops through the recordset and makes the features, and you’re on your way to a map.

There are some notable downsides to SVG. Labeling line features is problematic without conflict detection. Nice features on the client side can require a lot of tricky Javascript and XML coding. You would end up making a lot of cartographic symbols from scratch. If you support OGC WMS servers, this won’t help you in the least. You have to be cognizant of download sizes and generally use zlib compression and simplify PostGIS functions, as with state plane coordinate being so large, the SVG file can get big fast (although as ascii, it compresses pretty well). But the biggest problem is browser support. SVG is in it’s infancy, so browser support is iffy. With Firefox 1.5 (out in November), SVG will be built in, but IE users will have to download a plugin from Adobe to view SVG, and neither one works exactly like the other.

For our purposes, this technology may need a little more time to incubate. At the very least, it would need to wait for Firefox 1.5 so more than IE with a plugin could handle it. But I think it still bears watching.

If you want to check out SVG, first you’ll either need to download Firefox 1.5 or get the Adobe SVG plugin for Internet Explorer (http://www.adobe.com/svg/viewer/install/main.html). Then go look at what the PC had time to squeak together: http://maps.co.mecklenburg.nc.us/website/svggis/testsvg.php . Things to note – zooming and turning layers on and off is all done at the client, and clicking on a precinct or polling location pops up information in a fantastically boring javascript alert box (again, the PC is really busy).

To see some really neat stuff people are doing with internet mapping and SVG, check out http://www.carto.net/papers/svg/samples/ . Be warned, however: some of the code in the examples makes the PC’s brain hurt.