GISCollective

By Carl | Published November 23, 2012

Recently, Dr. Sarah Battersby from the University of South Carolina gave a talk on Web Mercator as the UW Geography Department’s weekly Yi-Fu Tuan lecture. Dr. Battersby broached an important concern–that Web Mercator could in fact be reshaping the way that young people picture the Earth, reverting society’s default mental image of the world to one that was held before geographers succeeded in making print publishers self-conscious of Greenland looking bigger than Africa. She further argued that Web Mercator is useful for placing markers on a map, but we are using it in ways that go way beyond what it was originally intended for (three words–Google Maps choropleths). Battersby’s talk actually clarified a question I have had in my mind for a while: why can’t we just make tile sets with other projections? The answer I’m sure is obvious to the experienced web GIS programmer or strongly mathematically-minded person, but my brain took months to process it, so no doubt there are other noobs like me who don’t quite get what all the fuss is about. Hence this blog entry, my attempt at a basic explanation of the problems faced in building a slippy map alternative to EPSG:900913. First, the problem. Your computer screen is flat. The world ain’t. A projection is how we get a picture of the round Earth onto a flat piece of paper or collection of pixels on a monitor. Every projection distorts sizes, angles, and/or distances. The projection that looks most like the real deal is of course a globe, such as found in Google Earth. But an interactive globe has a few problems. For one, it relies on WebGL technology, which isn’t quite mature yet. For another, it heavily distorts distances and angles. And if you want to see the whole surface of the planet at once, you’re going to need a 2-D projection. A Mercator projection—what Google Maps sort of uses (we’ll get to that “sort of” in a minute)—happens when you roll up a piece of paper around a globe, touching it along the whole length of the equator, and flatten the globe onto it. This is called a cylindrical projection, because when the paper is rolled up around the globe, it looks like a cylinder. Cylindrical projections have a key advantage in that all meridians (longitude lines) are straight. Mercator works really great if you’re, say, Ferdinand Magellan looking for a compass bearing that will take you around Cape Horn, because all of the latitude and longitude lines and angles in between lay out nice and straight on the map like we experience them in real life. It also works well if you’re Google and you want a map image that you can neatly slice up into little squares that your server sends to a customer’s browser. North is always up, your hometown doesn’t look squished or slanted when you zoom in to it, and everybody’s happy. Well, not everybody. The trade-off is that since the real earth curves in toward the polls, in order to get those straight lines, you have to stretch and distort the surface more and more as you get closer to penguins or polar bears. The poles themselves are impossible to see, because as you approach them, the distance between latitude lines stretches out toward infinity.

The downfall of Mercator is the old Greenland problem. It’s unfair to the Global South, making places that are mostly trees, snow, and better-off white people look huge, and the places where most of the world’s population lives look puny. This is especially a problem when you see a choropleth map that uses Mercator, because the picture you get of the data is distorted (it might look like a vast part of the world prefers hockey over soccer, but that’s just Mercator Canada messing with your head). And–here’s where it gets weird–in the case of Google Maps, the slippy map trendsetter, their Mercator projection isn’t even a real Mercator projection. “Real” Mercator projections use an ellipsoid to represent the surface of the earth, because as everyone who took high school Earth Science knows, the real earth is shaped slightly more like an egg than an apple. But to make their back-end calculations take up as little server power as possible, Google simplified the equation so that it just assumes the earth is a perfect sphere. This means that, according to Battersby, locations at high latitudes may be up to 50 kilometers off of where they would be on a more accurate ellipsoid Mercator map. So if Mercator sucks so much, why not just use a different projection? After all, there are hundreds. And, in fact, there is one other commonly used for slippy maps (although not by Google). OpenLayers is the longest-running maintained open-source slippy map code library, and for a long time was the open-source alternative of choice to Google (I would argue that torch has now passed to Leaflet). Its default projection is plate carrée, also called Lat/Lon or some variation by programmers (EPSG:4326). The simplest of all projections, this really isn’t a projection at all–it just takes the latitude and longitude of locations on Earth’s surface and sticks them as y and x coordinates on a cartesian plane. This is still a cyllindrical projection, but one that keeps all distances to the same scale, while distorting the angles on the map and distorting size horizontally at the poles.

Now that we’ve got all that housekeeping out of the way, back to the question at hand: why aren’t there more slippy map projections? So far, Mercator and plate carrée are the only two that have garnered significant use. As it turns out, this is for a very practical reason. Slippy maps are made up of static image tiles, usually 256×256 pixels, in png or jpeg image format. They are stored in a server cache or generated on the fly and sent to your browser as you need them. Whenever you zoom in or out or pan the map to a new spot, that tells the server you need more tiles, so it sends them to you automatically. This sure beats the old days when you had to click a button to do anything with the map and it would take from seconds to minutes to redraw everything. But the tiles need to either be pre-rendered or use a fast algorithm for rendering, which precludes reprojection, in order to make the map functionally usable. This is where the trouble starts. For projections, the upshot is that the map can’t be reprojected on the fly. If it could, the central meridian of the map could just be moved over to wherever the center of your screen happens to be after you move it, so you could use any projection you wanted. But since the projection on tiles is static, everything must be straight lines, or else things are going to look more and more distorted the farther away from the central meridian you get. Say that meridian was 180o—Chicago would look like Los Angeles, tilted on its side. Sure, you can cut up any map image into tiles, but unless you are using a cylindrical projection, you are only going to have one straight meridian, and the rest are going to curve, increasingly so the closer you get to the sides of the map. The map also won’t be able to pan continuously side to side.

There aren’t too many cylindrical projections other than Mercator and plate carrée. You could conceivably use a Miller Cylindrical, which is a compromise projection, or a cylindrical equal area projection like Gall-Peters, which lots of cartographers think is ugly. Google’s API actually supports these projections, so long as you supply the equation and your own tileset. But using a non-cylindrical projection is out-of-bounds if you want a continuous slippy map. It may be that we have reached a functional limit of tile-based slippy maps. With improved vector-rendering technologies such as the HTML 5 Canvas and WebGL, we could be approaching a “back to the future” moment when we will again make use of dynamic web maps generated on the fly per user request. An altogether amazing recent example is Bernhard Jenny’s adaptive composite map projection scheme (by christine). His demo application and paper smash the mental barrier that treats map projections as separate and unmixable equations. The continuous map warps and changes projection depending on the latitude and zoom level at which you are engaging it. Jenny bases his transformations on a USGS manual for selecting map projections based on the map use, written in 1987 by John P. Snyder. At a low-level zoom, he uses the Hammer and Lambert Azimuthal projections, two that don’t distort areas when you’re looking at the whole world. Zoom in more and the shape of the projection changes to one that distorts the shape of the earth’s surface as little as possible at the central latitude while remaining equal-area. High latitudes stay azimuthal, middle latitudes change to an Albers conic projection, and low latitudes use Lambert cylindrical. For the Albers projection, two standard parallels are dynamically moved to minimize the distortion you can see in the frame. Zoom in far enough, and the map transitions to Mercator using linear interpolation, finally jumping to a tile-based slippy map. You can still find some jumpy transitions and buggy spots if you play around with the demo long enough, but Jenny has made impressive findings in determining a scientifically optimal scheme for viewing the world from multiple scales and positions.

The responsiveness of Jenny’s tool is like Google Earth, but this is a map, not a globe. Not only does it correct our faulty Web Mercator view of the planet, it may even add entirely new perspectives. Allowing the map to be centered on any latitude, including the poles, makes it easy to view the continents in oblique ways that are rare to see on paper maps. Consider the implications of this given that global warming is increasing the geopolitical importance and possibility of future settlement of the earth’s polar regions. The application takes advantage of the HTML5 Canvas element, which provides fast client-side rendering and manipulation of vector data. According to Jenny, it could alternatively render as a raster image using WebGL, but rasterizing for Canvas currently takes too long, which means doing something more than a silhouette with this approach is still a challenge for the average browser. It’s all still experimental, and the programming somewhat opaque to anyone like me who isn’t a genius at complex piecewise geometry functions. It will take a complete redesign of existing web mapping infrastructure to make use of on a wide scale. Nonetheless, Jenny’s approach presents what could be a strong challenge to the dominance of the tile-based slippy map and the cartographic limitations that it comes with. Jenny’s map transforms depending on latitude and zoom level. This screenshot of the working demo is a Hammer projection at scale ~0.8 viewed from ~27o N. (The error in Antarctica is likely due to an incomplete polygon in the vector paths drawn on the map.) Jenny’s projection selection diagram shows how the map transitions between projections at different latitudes and scales. The parameters—including transition placements and the projection used for small scales—are adjustable via an interactive version of this graph dynamically linked to the map in the demo tool. From Jenny, 2012. References Jenny, Bernhard. 2012. Adaptive Composite Map Projections. IEEE Transactions on Visualization and Computer Graphics 18, 12: 2575-2582. Jenny’s proof-of-concept application: http://cartography.oregonstate.edu/demos/CompositeMapProjection Mercator projection. Wikipedia. http://en.wikipedia.org/wiki/Mercator_projection DiBiase, David et al. 2012. Geometric Properties Preserved and Distorted. The Nature of Geographic Information course. College of Earth and Mineral Sciences, PennsylvaniaStateUniversity. https://www.e-education.psu.edu/natureofgeoinfo/c2_p29.html Further reading from Sarah Battersby: Battersby, Sarah E. 2009. The Effect of Global-Scale Map Projection Knowledge on Perceived Land Area. Cartographica 44, 1: 33-44.

Slippy Map Projections Explained