Chris Tweedie posted an interesting reply to my rant about GIS standards and took me to task for “WMS bashing” and why WMS is a useful Enterprise standard. Perhaps – except I clearly stated in my original article that I was only talking about standards used on the web and not in the Enterprise.

Nevertheless, Chris does a good job of pointing out the flaws of tiled mapping systems. Its the usual litany of suspects – they take a lot of disk space, aren’t standardized, don’t support arbitrary scales and don’t support customized styles.

Having spent four years of my life writing a WMS server, the Smallworld Internet Application Server (SIAS), I’m all too familiar with these issues. But in the end it all boils down to a fundamental conflict – map styling versus performance.

The Importance of Style

Even the slightest hint that you’re limiting styling options is enough to send customers into a rage. And no, I’m not kidding.

This is important stuff – so important that there are laws in Germany, and probably other countries, saying exactly how maps should be rendered. I remember long, agitated discussions with German customers about how SIAS rendered circles. Our circles weren’t perfect, they were off slightly off for reasons I no longer remember and in ways no one would ever notice. But it made our system non-compliant under German law, so had to be fixed.

Styling in Smallworld is totally customizable. It can vary based any number of things – here is just a small subset:

• Object type – interstates are blue, main roads are red
• Object attribute – Steel pipes are gray, copper pipes are yellow
• Scale – A pipe is a green at less than 1:10,000, blue for 1:10,000 and greater
• Area – Roads in England are not rendered the same as in the United States
• And of course the kicker – users could override the rendering methods themselves and do whatever they pleased.

Smallworld then adds the concept of “drawing applications” (yeah, horrible name), which basically means that an engineer wants to see one set of styles, while a customer service representative wants to see another.

So when building SIAS, one of the absolute, you must meet this requirement or not bother building a product, was faithfully reproducing the styles users had set up in their Smallworld databases.

The Importance of Performance

At the same time, producing a beautifully rendered map counts for diddly if users have to wait a minute for it to show up in their browser.

Now Smallworld’s rendering system is fast – after fifteen years of optimization it is the fastest GIS rendering system I’ve ever seen (its used to blow away ESRI, maybe it still does). And it had a clever caching system that made it possible to keep nearby geographic features in memory, making panning and zooming operations lighting fast for desktop clients.

This is really important – one of the things most people don’t appreciate is how much data it takes to render a map. For example, say you want to make a detailed map of Manhattan. It will include tens of thousands of street segments, parcels, buildings, etc. All of which have to be fetched from the database. Then you have to look up the styles for each feature, and finally, render the map. So local, in-memory, caching is key – even today.

But this system breaks down on the Intranet or Web. A SIAS server may support tens or hundreds of users – each interested in a different geographic area. Thus you’re almost guaranteed to break the cache, resulting in expensive queries back to the database.

One obvious solution is tying clients to servers based on their bounding box, but we never went down that route because we didn’t see a way of doing it in a generic manner that would work out of the box.

So to support arbitrary styles and scales, and have decent performance, requires a lot of hardware. A whole lot of hardware. And that introduces a whole host of other issues – managing the hardware, client sessions, updates, etc. All of which are solvable, but it still takes time to get right.

And the Twain Shall Meet

So is there a middle ground? I think so – if you’re willing to throw away arbitrarily scales and don’t mind using lots of diskspace.

From talking to customers over the years, I don’t think arbitrarily scales are as important as people think. What is important is what features are displayed at different scales and how they are styled. For examples, roads should be visible when the scale is less than 1:20,000 and be drawn in red.

In a typical Smallworld setup, users would create roughly 10 of these rules, which were called display scales. Other GIS systems have similar concepts. Thus, these display scales become the basis for your tiled zoom levels – although you would probably want to make sure you have 15 to 20 of them.

So what are the downsides? There are myriad:

• Users can’t change map styling on the fly (and if you really want this, then you’re a power user and should just install a desktop client)
• Updates to the database invalidate tiles, you need a process to determine which tiles have been invalidated and then regenerate them
• In versioned databases, like Smallworld, you can really only support one version (unless you have *lots* of diskspace and time, a typical Smallworld database would have hundreds or thousands of alternatives).

And the advantage? You move map rendering out of the main code path. For an Intranet or Web client, I think its a no-brainer, you have to do it if you want a scaleable system.

A Toy Standard

As you might have guessed by now, I think WMS is a fatally flawed standard. Its a “toy” standard – its great if you have a few users but its extremely difficult to scale – whether you are on the Web or in the Enterprise.

Its difficult to scale because it doesn’t constrain the problem. It imagines a world of instant map rendering where any client can request any bounding box, any scale, any coordinate system and any styling. Such a world does not exist today. Maybe it will in five or ten years, but that’s doesn’t help us now.

The obvious solution is to constrain the problem. If this seems like a horrible thing to do then just think of the Web. There is only one way to address things (URIs), there are only a few actions you can perform (HTTP has a handful of verbs), there is no central authority (and thus you get broken links), etc.

In the map rendering world, the constraints are fairly clear – fixed scales, fixed bounding boxes (ie, tiles) and fixed styling via pre-defined style groups. If you’re willing to make those three simplifications, then you can create a Web Mapping Standard that really works.