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 content.stamen.com 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!