maps.stamen: Some Known Bugs, What’s To Do

Thanks to our handy bug reporting form, and perhaps spending a little too much time surfing around the world in watercolor at the studio, we’ve isolated a couple of bugs which we’d like to update you on.

The background is, even though the watercolor map has been online for some weeks now, viewers haven’t yet looked at every place at every zoom level. Since it would take aaaages to make all the map tiles for all the zoom levels available, we’ve been creating new tile areas based on people’s viewing activity, and then working to cache tiles for popular areas. (See Jeff’s Log Maps post on for more information about this.)

This means there are parts of the world haven’t had their watercolor map made. What we’re finding too, is that some of the tiles that have already been made have been generated incorrectly, and will have to be re-made.

As you click around watercolor world, you might come across maps that look like this:

We’ve been calling this the “Underwater” bug. It seems like it happens in the tile-making process if the machine that constructs the tiles is running too hot. It freaks out at coastlines, and ends up literally flooding the land area with the water texture.

You may also have seen a preponderance of grey while you browse around too, like:

Thanks to our superstar efficiency buddy, Aaron Huslage, we think we’ve tracked down the overall issue to machine I/O, the servers’ ability to process inputs, and issue outputs. If the I/O is flooded, the software to generate tiles on the fly baulks, and gets more and more underwater. So, to try to reduce that chance of flooding, we need to reduce and simplify the inputs we’re sending through to create new tiles. Step 1 is to try to “simplify the world.”

The theory is that we’re sending a more complicated Make request than we need to. CTO, Mike Migurski likens this to killing a whole chicken in order to make a McNuggetTM. We’re experimenting with ways to reduce the size of OpenStreetMap data ahead of time, for the whole world, because Watercolor in particular is such simplified cartography that is doesn’t need the whole chicken. If we just give Cascadenik only what it needs (instead of the whole chicken), that might reduce the machine I/O. Then, we’ll see what happens next…

We’ll post an update to let you know if that worked, or not. Any advice that springs to mind, feel free to post a comment!

2 thoughts on “maps.stamen: Some Known Bugs, What’s To Do

  1. I don’t know how this meshes with your mission, but have you considered using someone else’s hosting and tile delivery infrastructure to deliver Stamen tiles? MapBox springs to mind. Not sure if that is even possible, but they seem to have solved a lot of the issues related to satisfying tile requests …

  2. Hi John,

    Good golly, this a late reply, but… here goes.

    I think the main important difference between and a service like MapBox is that shows the entire planet, at every zoom level. You’ll notice if you click around the maps on MapBox that they’re all bounded in some way, either by level of detail as you zoom around, or a bounding box, like the City of Toronto or similar.

    We’d prefer to make sure the system we’ve built is robust, with a view to adding more styles of the entire world into it.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>