Rendering With Style

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.

  1. Chris Tweedie
    July 12, 2007

    I dont disagree that to scale in an enterprise sense, tiled schemes is the best by far but i was just trying to highlight that WMS isnt as bad as everyone seems to make out.

    If you are able to “constrain” your mapping project to a distinct number of layers, styles, clients, projection and scales then congratulations, i wish all my mapping projects were that easy!

    Certainly taking a bit from both baskets would be to use something like Openlayers to utilise both Tiled schemes as well as dynamic WMS as overlays. Of course the problem then is the lack of interoperability *between* tiling systems. But thats another story 🙂

    One-size doesnt fit all and i dont think Tiled systems are going to replace WMS. They serve different niches and should really coexist together.

    Reply
  2. Charlie Savage –
    July 12, 2007

    Hi Chris,

    Thanks for the comment. I think a hybrid solution is definitely a good idea. Standards would certainly be nice – but that’s obviously more of a political issue than a technical one. If enough customers want a standard, OGC, or someone else, will be happy to oblige.

    I also agree that one size doesn’t fit all, and there is a place for the extreme flexibility of WMS.

    I am curious though – you don’t think there is any place for some simplifications in most mapping applications (trying to hit the 80/20 rule here I suppose)?

    Reply
  3. Chris Tweedie
    July 12, 2007

    Oh definately there is room to move. But its probably too hard to generalise down to a specific set of criteria unless we had some examples to work with

    All food for thought anyway.

    Reply
  4. Sean Gillies
    July 12, 2007

    I think the usefulness of toggling any and all map feature layers is overblown. Of course a GIS analyst needs this feature in their desktop application, but a lay-user is relying on us to use our expertise, overlay layers properly, and give them a map that’s both informative and usable. A street map, for example (G/Y/M): the roads, waterways, parks, places of interest, all go together and don’t have much meaning without the others.

    Reply
  5. Charlie
    July 12, 2007

    I’m with Sean. With SIAS we had an HTML client which had a super fancy layer control. It was done as a tree – for example it might look like this:

    Transportation
    Road Network
    Interstates
    Main Roads
    Railways
    Land
    Parcels

    Etc. 95% of web users had no idea what it meant – the most they wanted was 2 or 3 checkboxes to turn groups of things on or off (roads for example).

    Anyways, layers are amenable to tiles – each layer gets it own set of tiles. A browser can then put them back together by overlaying the transparent tiles (just as WMS works today).

    Reply
  6. Chris Tweedie
    July 13, 2007

    If you can restrict your project down to a set number of distinct layers then i am all for it. But from my experience, where a project contains many layers/groups/themes/whatever, users enjoy the flexibility of seeing “more” or just seeing “what they want”.

    G/Y/M in comparison does not have many data layers but the number of users who immediately want to drape their own data over the tiles should show that people *do* want customisation. Of course, this flexibility should not come at the expense of a nicely compiled base map and this is where G/Y/M shines.

    Reply
  7. George Marrows
    July 13, 2007

    We did some of this stuff in the latest SIAS 4.1 release. As Steve Bell mentioned in some earlier comments, 4.1 was a complete reimplementation – we switched to a J2EE app server, redid the client using dynamic JSF etc.

    One thing we introduced was cached/tiled maps with layering, pretty much as you describe above. The native 4.1 mapping service is clever enough to switch between cached map tiles and dynamic maps if the user does want to change style, but we tried to design the UI to ‘keep users in the cache’.

    Another much more minor enhancement addresses your comment about the complexity of theme trees for users – there’s a customisation switch to hide all but the top level, so the theme control then becomes a series of on/off switches. We felt we had to maintain the option of the full tree – like Chris, we have customers who want their maps just so, even in a web app.

    Nice blog btw – I’ve been mailing some of your GIS articles round the office (though not the Ruby-ish ones – I keep those for myself :-).

    Reply
  8. Charlie Savage –
    July 20, 2007

    Hi George,

    Thanks for the SIAS update. Sounds like a nice system you’ve implemented. Curious how J2EE and Magik communicate. Did you use the embedded HTTP server in Magik? Or is it via tics or some such mechanism? Or via the magik-java bridge we built?

    Reply

Leave a Reply

Your email address will not be published.

Top