At Wet Dog Weather, we have our own web and mobile display technology called Terrier. It’s crazy good, and we love it! However, we understand that sometimes you need to support the old way of doing things, which is why we also support traditional web mapping services like WMS and WMTS.

When a customer asks for WMS or WMTS support, we figure out how to do it. But that doesn’t mean we don’t have opinions about these web mapping services. We have such opinions!

Web Map Service

Born in the late nineties, WMS is a straightforward standard for fetching a chunk of a rendered map, one of the original web mapping services. This was a time when servers were smart, and clients were dumb. Web browsers were improving, but AJAX wouldn’t appear for another half-decade, and mobile was still very simple.

WMS works in two parts, though most people skip the first part.

1. Ask the server for Capabilities. That is, what it has to offer.

2. Ask the server to construct an image at a given resolution for a given area.

Credit: OpenStreetMap

Pretty simple to use, but it’s got some significant downsides.

• The user spends a lot of time waiting for an image to appear.
• Server work scales by the number of active users.
• It defies modern caching techniques.

Web Map Tile Service

A newer standard, WMTS, is halfway decent for web mapping services. With WMTS, the client can request individual tiles in a tile stack.

Credit: OpenStreetMap

99% of the time, these tiles are presented in a pyramid and are in Web Mercator. They can be in other coordinate systems, which is a strength, but they usually are not.

Best of all, WMTS works nicely with modern caching. Image pyramids are broken into predictable sizes and can be fetched as needed by a client and cached in your CDN.

Tile paging can also be done outside a TMS pyramid. This is more problematic and leads to the core problem with WMTS.

The Problem with Capabilities in Web Mapping Services

Both WMTS and WMS nominally have this GetCapabilities step. The client is supposed to ask the server what data is available, parse through the return, and then start fetching tiles from the given locations.

In most cases, the developer makes the GetCapabilities call, stares at the XML return (yes, XML), and then hardwires the URLs they find buried in that document. Most web map display libraries could do a better job parsing Capabilities, so developers tend to do this manually.

For time series data, like weather, there are some extra problems. Capabilities have a fine way to encode data slices, but not explicitly time, so you must circumvent this to work with your users.

The real problem with Capabilities in web mapping services is scale. By default, a service is supposed to return everything it has. This was designed in the era where one server had a few things, and another server had another few things, and so on. It wasn’t designed with the sorts of monster services we build now.

An obvious answer is to add query parameters to the GetCapabilities call and narrow things down that way. By default the client app usually wants to list everything, which can be expensive.

Standards are Good, We Prefer Different Ones

With the advent of the iframe and Canvas, the web has been moving steadily away from a static representational model for web mapping services. There are some downsides to that, but the upside is more control over how data is displayed to a user.

What we love about the web is Javascript and WebAssembly. We can give you a precise, low-latency, and nimble interactive weather map display with those.

On the other hand, if you need WMS and WMTS, that’s fine. We have our Static Tile Service option for Boxer and are happy to charge for it.