New ideas in terrain mapping for cyclists

by Daniel on May 28, 2009

danielbio1

I live with a couple of cyclists, who spend many of their summer days out on the trails west and south of Madison. A few months ago, one of them asked me to make a bike map for him, pointing out what he felt was a shortcoming of the ones available to him: it’s hard to figure out where the hills are. This is particularly critical if you ride in places like the Driftless Area, as my roomates do. A map showing you where to turn and which roads have wide shoulders and low auto traffic is very useful, but it doesn’t tell you how rough the next hill is going to be.

Figure 1: The above is a draft of one of my first attempts, in this case depicting a particular ride that one of my roommates hopes to participate in this summer. click to see fullsize

Figure 1: The above is a draft of one of my first attempts, in this case depicting a particular ride that one of my roommates hopes to participate in this summer. click to see fullsize

So I set to work considering how best to show elevation changes along a route, and I came up with a relatively simple concept: encode the elevation of points along the route using line width.

The symbology here is, I think, fairly efficient. By varying the width I am encoding three pieces of information: the elevation of the path, the slope, and the aspect. The first is not particularly useful, but the other two are the critical pieces of information for the cyclist. Importantly, both need to be on the map together – knowing the slope of a hill is great, but you also have to know whether, as you head along the road, you’ll be climbing up that steep grade or coasting down. Getting all that information into one symbol is not necessarily that hard. Both slope and aspect are derived from elevation, so it’s really just a matter of producing a map which shows elevation in a way that makes it easy to see the pattern of how elevation changes. Show the one variable, and your brain fills in the other two. But, it works a lot better if the symbology makes it easier for your brain to figure out how elevation changes. Compare the two maps below:

Using the visual variables of lightness or size to encode data

Figure 2: Using the visual variables of lightness or size to encode data

One encodes elevation along the path by width, and the other by color value. In my opinion, slope is much easier to figure out when line width changes than when the color value does. The color at A is darker than the color at B – but can you quantify how much darker? And can you do it as easily as you can tell how much wider the line is it at A vs B? Speed and ease of understanding are, I think, particularly important given how the maps are to be used. I am told that these will be read by people who don’t even stop their bikes while reading the map (I don’t really know anything about biking – I’m not usually permitted outside the confines of the UW Cartography Lab). So, the map has to work when they’re not looking closely or long at it. The second advantage of line widths over something like color variations is that line widths are more robust – they won’t vary according to lighting conditions, as the users bike in and out of the shade of trees and in varying levels of cloud cover.

The map on the left (using lightness) does have a couple advantages of its own. A small one: by not changing line width, we don’t have to worry about lines getting too wide (causing crowding) or too narrow (and thus being hard to see). The other advantage is really more of a lack of a disadvantage – the highest elevations are not dominant. Look back at Figure One for a moment – notice how the south-center part of the map stands out the most. It’s at the highest elevation, so it has the widest lines. But it’s also mostly flat stretches, which means that it’s not a big deal to our cyclist – they want to know about the hills, about the changes. Encoding elevation by colors keeps the reader from focusing attention as much on the high elevations, which won’t stand out quite so badly.

Instead of encoding something the cyclist doesn’t care about (elevation) and letting them figure out the things they do want to know (slope and aspect), we could just encode the latter directly. Again, though, we need both for it to be useful, and so here’s where it gets tricky. Slope isn’t so bad – it’s just however many degrees the angle is, so that’s something we can pretty easily put into a color ramp, for example. But aspect is the hard part, since it depends on which way you’re going down the road. It’s uphill one way, and downhill the other. You could put little arrows or some other indicator next to the road to indicate which way is uphill. Or perhaps encode the aspect in color hue (red for north, blue for east, etc.) while changing the lightness of the color to indicate the grade. Or, you might try this:

The arrow points downhill, and larger arrows or darker ones indicate steeper slopes.

Figure 3: The arrow points downhill, and larger arrows or darker ones indicate steeper slopes.

There are more possibilities, obviously. But I am of the opinion that these solutions are somewhat weaker than simply showing elevation directly – the reader has to process two different symbols (or two properties of the same symbol) and extract two pieces of information. Maybe that’s still easier than processing the symbols to extract elevation, and then calculating slope and aspect internally. But I do not think so. If you present someone with a map they intend to use to figure out the lay of the land, they’re expecting to see the terrain – hills, valleys, etc. Figure 3 above is getting too abstract. It doesn’t feel like land anymore, and so it’s harder to interpret. This is why people like hillshading – mountains look like mountains, and that’s something we can understand without a lot of processing.

I imagine a reader could train themselves to interpret something like Figure 3 faster and easier, since it does show what they want to know with about the least amount of ink possible, and without showing anything extraneous. But that will take effort and learning. Right out of the gate, I think a map showing elevation is easier to understand, because it’s a lot easier to figure out what the landscape is going to look like.

Thinking about the landscape was, in fact, what led me to the initial technique of encoding elevation by line weight. I had simply thought of it in terms of looking down on the world from high up. Roads which are at a higher elevation would be closer to your eye, and so appear larger than those far down in valleys. Whether or not this particular concept is working in the back of people’s minds when they see these maps is another matter, but it at least provided the inspiration. The more academic analysis came later, much of it while I was writing this up.

While I appreciate any general feedback readers would be so kind as to provide, I’m particularly interested to know if anyone’s seen anything like this before. It’s not a terribly complicated symbology idea, so I imagine someone somewhere must have thought of this.

10 Comments

[Indiemapper] How indieprojector shaped the world

by David Heyman on May 26, 2009

added edge points

Looking for a more in-depth view into map projections and indieprojector? Head over to the indiemapper blog to read Andy’s post about working with geographic projections in ActionScript 3. There’s a basic round-up of getting geo-data into Flash with simple projection support and a more detailed discussion about some of the challenges encountered with re-centering and polygon splitting.

It’s a must-read if you’re thinking about rolling your own geographic projection-support in AS3!

Link: How indieprojector shaped the world (via indiemapper blog)

No Comments

[Indiemapper] Announcing: indieprojector

by David Heyman on May 12, 2009

Today, we are pleased to announce the release of our free geographic projection and data conversion tool: indieprojector.

For indieprojector, we took three core indiemapper features:

  1. SHP / KML import
  2. Geographic projections
  3. SVG export

… and combined them into a single stand-alone web application. Indieprojector lets you load multiple SHP or KML files, reproject them to one of 11 geographic projections and export them to SVG for use in a vector graphics editing program. We’ve also included lots of information on each projection plus filtering tools to help you select the best projection for your individual project.

We’re very excited to be offering a preview of indiemapper before it’s release at the end of the summer and we hope indieprojector is useful for your day-to-day mapping work. Check out the indieprojector screencast and please take some time to give us some feedback and let us know what you think. We look forward to hearing from you.

Enjoy indieprojector!

UPDATE: A new version of indieprojector has been released which includes support for NetworkLink tags in KML, layer re-ordering and various minor UI and bug fixes.

indieprojector

3 Comments

[Cartogrammar] Accidental map projections

by David Heyman on May 8, 2009

If you want to make an omelette, you’re going to have to break some eggs, and if you want to code geographic projections, you’re going to have to bend the world. Here’s a look at the Axis Maps blooper reel courtesy of Cartogrammar developer Andy Woodruff’s blog. Enjoy!

Link: Accidental map projections (via Cartogrammar)

Azimuthal Redux

3 Comments

ARRA funding map

by Ben Sheesley on April 30, 2009

ARRA Funding Map

Lots of maps are coming out that document when, where, and how stimulus money is being spent through the ARRA, like these at the Foundation Center. With all of the reporting, accountability, and transparency required of ARRA grant recipients, I’m sure we’ll only be seeing a lot more of these in the future. Recovery.gov directs traffic to states’ Web sites where some of this data is appearing. I’m looking forward to seeing more and more mash-ups and interactive maps and graphics as developers and designers get their hands on this stuff and data from other sources that track stimulus money.

Our Map

For now, we decided to get involved by putting together a static map that shows where our ARRA tax dollars are going for energy-related programs administered by the DOE. As underlying layers, the map shows states’ historical energy consumption trends and their projected trends required to meet consumption goals set for 2012.

I’m sure we could all talk about the politics around ARRA funding and energy consumption and how this might or might not be shaped by patterns that the map does or doesn’t show. But to me, a few of the most interesting things about this map are related to its design:

1) Encoding data in state boundaries

I’ve always been attracted to National Geographic political reference maps, with their countries each outlined in a different color. On those maps, outline color clearly helps distinguish one place from another. Plenty of other maps use enumeration unit outlines to represent data, too, like those that categorize administrative boundaries using line weight, dashes and dots, etc. I wondered what was to stop the application of this idea to a thematic map? Why not try to take it one step further and encode numerical data, as opposed to nominal data, in unit outlines? I haven’t seem many examples of this.

The main limitations here are line weight and unit size. Line weight has to be heavy enough so that color can be seen and read. For my map, this seemed to work best above around 4 pts. Only thing is, as enumeration units get smaller, the outline can eat up more interior space and obscure the presence of a second data set, which in this case is the historical energy consumption trend, encoded using unit fill color. So, I had to cheat a little bit with some small states and states with small pieces (e.g., Delaware and Maryland) and decrease the line weights a bit under 4 pts. I don’t see this approach working very well with really small enumeration units like US counties, unless the map scale is really huge.

2) Color selection

The challenge here was to select colors for three data sets (historical energy, projected energy, and ARRA money) that not only encoded data properly but were harmonious (i.e., not competing or ugly). The historical energy data set has a natural midpoint around zero, so it needed a diverging color scheme. On the other hand, the projected energy data, having no midpoint, required a sequential scheme (thanks to ColorBrewer 2.0 for both sets of specs). Proportional rings for ARRA money just needed to be readable and look nice on top of the other colors.

Here are some earlier attempts at getting color right. In my first try, I used a grayscale sequential ramp for the historical data (state fill color), matching the middle value to the map’s background for a pseudo-diverging ramp feel. But this seemed overly subtle and downplayed the importance of clearly distinguishing states with decreasing and increasing energy consumption trends.

First attempt at color.

First attempt at color.

So, my next try was to replace the grayscale ramp with a true diverging ramp. Yuck. The mix of red outlines and fill colors bothered me on an purely aesthetic level. Other diverging ramps with other hues in them produced similarly ugly results.

Second attempt at color

Second attempt at color.

The final colors for historical energy consumption trends (blue-white-red) seem to best emphasize the data’s midpoint, with red doing its part to connote “alarm” in the states with a poor track record. The projected energy consumption data set is now lower down in the visual hierarchy (shown using a grayscale color ramp on state outlines), but this seems to be acceptable compromise. Using gray prevents these two ramps from competing for attention or overlapping and confusing the map reader. From my perspective, at least, it also results in an (yes, subjective) improvement in overall color harmony.

Other thoughts about the ARRA funding map? Please add them to the comments.

6 Comments

Virtual Globes are a seriously bad idea for thematic mapping

by Mark Harrower on April 17, 2009

Google Earth is amazing. As we’ve commented here before, it continues to blow our minds and has also done wonders for the popularity of maps. And let’s be honest, it looks super cool. There is no doubt that Google Earth is much sexier than that boring old atlas collecting dust on your shelf: It’s interactive, seamlessly integrates distributed data sources, animates the surface of the earth over time, facilities virtual communities, can be customized by both developer and user, etc, etc. It’s hard to not be impressed.

So all of our maps should be in Google Earth, right?

Wrong.

In fact, despite recent efforts to create a suite of thematic mapping approaches, Google Earth is a terrible environment for presenting many kinds of thematic maps. I’d go so far as to say that the 3D prism maps and 3D graduated symbol maps we see popping up in Google Earth are pure chart junk, of the kind Tufte warned us about repeated for past 25 years.

3D prism map of population in Google Earth

3D prism map in Google Earth (blog.thematicmapping.org)

3D human figures as proportional symbols

3D human figures as proportional symbols (blog.thematicmapping.org)

CHART JUNK

Chart junk takes what should have been a simple-to-read graphic and makes extracting information (1) slower, (2) more difficult, and (3) more prone to reading errors, because of excessive ornamentation and unnecessary design additions—like adding a 3D effect that communicates nothing in and of itself but simply “looks cool.” This is not idle speculation: Research consistently shows chart junk and “redundant ink” hurt otherwise fine graphics.

Want to see for yourself? Download these two example KML/KMZ files from blog.thematicmapping.org and run them in Google Earth. While you’re looking at them try to extract numbers or compare places: KMZ File 1 |  KML File 2

“BUT THEY LOOK COOL”: A TECHNOLOGY IN SEARCH OF A PROBLEM

As Abraham Maslow said, “If the only tool you have is a hammer, you will see every problem as a nail.” This seems to be the case with virtual globes and the developers who love them and insist that any and all kinds of thematic data belong there. Instead, I’d challenge us to take a step back and ask,

WHY DO WE MAKE THEMATIC MAPS?

For a long time folks like Robinson, Dent, and MacEachren have been arguing that thematic maps exist to support two basic tasks: (1) the ability to extract numbers/facts about specific places (e.g., 15C in Paris) and (2) the ability to judge those values in geographic relation to other places (e.g., 5C warmer than London, about the same as Milan). In other words, we want both specific details and overall patterns to be obvious on our thematic maps. And we want all of that AT A GLANCE.

The problem with digital globes (as with all globes) is you can’t see half the planet and, due to curvature, really only about a 1/3 of the planet clearly at once. Which leaves us with a conundrum: If you’re only mapping a small place (e.g., a country), why do you need to have it on a globe? And if you have a global dataset, why would you allow your readers to only ever see ½ the data at once? They can rotate the globe (more on this later) but they’ll never be able to see the entire dataset at once. That makes understanding overall patterns very difficult, and asking folks to “remember” half of a global dataset while they spin the globe to the other side is far, far beyond the meager limits of our working memory. If you’re not convinced, just try it.

KNOW YOUR HISTORY

What makes these recent developments even more frustrating is that in the 70s and 80s, with the advent of digital map making, cartographers flirted with, and largely rejected, faux 3D prism maps and 3D graduated symbol maps (like the two examples above) since they suffered from several limits:

    1. visual occlusion (not all of the map can be seen at once since some places hide others)
    2. people suck at estimating volumes, especially of complex shapes (e.g., try estimating the size of moving van you’ll need for your home)
    3. mental rotation of complex shapes is extremely hard, so hard that it is often used as a measure of intelligence in IQ tests.

Many a thesis and dissertation was written in the past 40 years demonstrating these limits to human visual processing.

The nice thing about Virtual Earths is that you can rotate them, so the problem of visual occlusion is solved, right? Yes and no. Yes, interactivity and the ability to rotate the globe can help reveal hidden places, but no, these virtual globes introduce a significant extraneous cognitive load because the user must now think about controlling the globe (not always easy with a mouse) while also trying to focus on the thematic content. In fact, adding a complex task, like visually acquiring the Google Earth controls and then trying to figure out how to move/scale/reposition the globe between two other tasks effectively “flushes” short-term working memory. It’s a kind of mental sorbet, which is why giving folks something distracting to do is a common trick in memory tests (they lose their train of thought). Why would we deliberately do this to our map-readers?

BIG PROBLEM: INCONSISTENT SCALE

In the examples above it is really hard to judge relative sizes. Why? Because the scale of the symbols is constantly changing, and the ones closer to the viewer are much larger (and at a different scale) than the ones far away. Given that it has been long established in cartography that people are terrible at estimating sizes, and even worse at estimating volumes, it is utterly inane to compound this failure by drawing the symbols at different scales. Of course it is worse than this: Rotating the globe slides each symbol through its own scale transformation path, changing in size with every pixel the maps are moved.

This is an absolute rule: If you want to give people the best chance to judge the relative sizes of objects, they should all be drawn at the same scale.

STILL NOT CONVINCED? LET’S DO SOME USER TESTING

Judging height is critical to the success of this map, yet most heights are obscured

Judging height is critical to the success of this map, yet most heights are obscured

TASK #1: As quickly as you can, how does Nepal compare to Uzbekistan?
TASK #2:
As quickly as you can, find all of the other places on the map similar to Nepal? Which place is most similar? Which one least?

Hard, isn’t it? To be honest, it shouldn’t be: A regular 2D classed choropleth map or proportional symbol map would make short work of those questions. So what did we gain by extruding the countries up into space? Not much that I can see.

    1. The Lack of a zero-line referent makes it hard to judge absolute magnitudes.
    2. The “fish eye lens” effect mean each prism is viewed from a different angle than its neighbors, making comparison just a little bit harder as we have to mental account for these differences in our estimates.
    3. It is hard to judge the height of something when you are staring directly down at it. This matters because height is the visual variable that does the “work” in this graphic—it’s how the data are encoded visually. Why obscure the very thing map-readers need to make sense of the graphic (e.g., the side-view height of each polygon)?

SOLUTIONS?

I need to be convinced of two things: (1)  something is fundamentally wrong with our proven and highly efficient planimetric thematic maps, and (2) that reprojecting this data onto a virtual globe somehow solves those problems. Otherwise, we truly have a cool new technology in search of an application, and that’s just putting the cart before the horse.

Some suggestions: First, unless the 3rd dimension communicates something and isn’t merely redundant data already encoded in the colors, sizes, etc., do not include it (for all the reasons outlined above). Second, if you want folks to perform “analytical map reading tasks” such as estimating relative sizes, distances, or densities, keep scale constant. Third, do not obscure parts of the map behind other parts if that isn’t inherently relevant to the data (e.g., this is fine for terrain visualization). Fourth, and most importantly, do some user testing before presenting a new technique as the best thing ever: It’s how research works and why it is important.

So what things are Google Earth (and other Virtual Globes) good for? The consensus around here is (1) to engender, quite powerfully at times, a qualitative “sense of place” or “immersion”; (2) for virtual tourism (e.g., sit on top of Mt Everest) or virtual architecture/planning; and (3) to perform a kind of viewshed analysis and see what can and cannot be seen from locations (line-of-sight). All of those are inherently 3D-map reading tasks in which the immersive, 3D nature of the map is important. By comparison, population data (one number per country) is NOT inherently 3-dimensional and is only made to suffer when dressed-up in prism maps and 3D figurines.

Cartography, like all good design, is about communicating the maximum amount of information with the least amount of ink (or pixels). The world is just too complex and interesting to be wasting our ink/pixels on non-functioning ornamentation.

15 Comments

SXSW: Axis Maps Roadshow

by David Heyman on April 14, 2009

A couple weeks ago I was lucky enough to get invited to the SXSW Interactive conference to speak on a panel called Neocartography: Design and Usability Evolved. Here are some collected thoughts I had from running through the panel again in my head.

Do you need a cartography degree to make maps? As the only trained cartographer on the panel, they just couldn’t wait to ask me this question (could I really say that Stamen’s “non-cartographers” shouldn’t be making maps?). I gave the popular answer, “No,” but with a caveat: “You just need to care about cartographic design.” Elegant design and clear communication are universal to all aspects of design. Cartographers have a slight leg up in the map game because we’ve been using our design chops to get good at applying these universal concepts to maps, but concepts like subtle use of color, visual heirarchy and map / UI composition can directly be applied from graphic design to map design. Incidentally, this is the hardest stuff to teach to cartography students. However, there is a lot of cartographic design that is uniquely geographic. Issues like projections, thematic symbolization and generalization don’t exist outside of maps and largely exist because of the challenges of representing a complex world on a small, flat piece of paper. These same issues remain even moving from paper to the computer screen, but unfortunately they are largely ignored. On a preachy note, I think it is our responsibility as cartographers to CONSTRUCTIVELY engage ourselves with the new mapping discourse.

What’s with neocartography? Neocartography is a tricky definition (one that I think is changing every day) so take the coward’s way out and define it as:

You know… the Where2.0 crowd.

But “Where2.0″ covers it pretty well. Location (that’s the where) is EVERYTHING. It’s an on-demand (that’s the 2.0) reference-map world where apps need to know WHAT you’re looking for so they can tell you WHERE it is. A lot of cartographers (especially those educated in Geography) probably feel disengaged with the new movement because they are looking for “Why3.0.” We want to make thematic maps that explain the world instead of just locating a tiny part of it. And unbelievably, with two people on the panel who helped build it, we never showed off Geocommons Maker and its thematic mapping to the audience. We could have started the Why3.0 movement then and there!

What about the 9,000 lb Google shaped elephant in the room? Instead of listening to me prattle on about projections and choropleth classification schemes, it seemed like the audience would rather hear what Google, represented by Elizabeth, their Maps UX Designer, had to say about mapping. Me too. Even though we are both making maps on the Internet, our issues couldn’t be more different. Where we can agonize over cartographic and UI issues, Google constantly needs to consider issues of scalability. With their maps viewed by millions of people (horrible problem to have, right?), design decisions take on massive significance. The UI and interactivity set worldwide expectations on what an interactive map should be (look at panning / zooming controls on all the major map providers to see their influence). They’ve become masters of the universal elements of cartographic design but have not addressed (or have been constrained by) the uniquely cartographic issues. Because Google sets the tone for mapping on the web, the web-mapping community has believed that these issues cannot or should not be dealt with.

Anything else? Just a couple things:

  • Cloudmade and OpenStreetMap are going to be huge. They are going to improve the state of cartography on the web and engage both experts and the public with mapping in entirely new ways. 
  • GPS is coming to social networks. This is going to be MASSIVELY HUGE. In 3 years, “location-aware” won’t be a buzzword anymore, it will be an assumed feature. There is going to be insane amounts of spatial data and I, for one, cannot wait to face all of the display challenges it’s going to pose.
  • Stamen kicks ass and they’ve set the bar high for top-shelf online mapping. It’s hard to share a stage with Mike Migurski when he has such awesome maps and visualizations at his disposal. What a show-off.
  • It was great to meet Elizabeth and some of the Google Maps team. I wish I could have pried more Google secrets from them but they’re too tight-lipped.
  • Andrew Turner at FortiusOne is one of the most plugged-in, active people working in the neocartography field. Thanks to him for putting together a great panel and keeping us in line.
  • Everyone at SXSW had an iPhone.
  • Everyone communicated via Twitter.
  • Favorite quote: “The difference between unemployed and self-employed is only in your head.”
  • Favorite panel: How to Give Better Presentations – To unfairly summarize, be gimmicky to get people’s attention, play to their emotions, and don’t split their attention between what they see and what they hear.
  • I honestly cannot recommend this conference enough. Getting to be around the leaders in the technology field was an unbelievably energizing experience. I met some wonderful and inspiring people and I could feel the world changing over those five days.
No Comments

Spicing up Google Maps in Flash

by Andy Woodruff on February 25, 2009

Note from the future: the example in this post broke somewhere along the line, but this whole post is obsolete anyway now that the Google Maps API allows styled maps!

This isn’t news to everyone, but it’s worth pointing out the fun things one can do with maps using the ActionScript ColorMatrixFilter. Tired of the boring old yellow and orange Google map in the Flash API (or any other map in Flash/Flex)? Lay down a ColorMatrixFilter on that sucker!

The ColorMatrixFilter, if it needs to be pointed out, essentially allows you to mix up the red, green, blue, and alpha channels of vector or raster graphics to produce exciting new colors. Adobe has a nice little article explaining it, along with an interactive demo.

Here’s a little example of simple effects I threw together for Google Maps. Click the links at the bottom for different looks.

Get Adobe Flash player

I poked around the Google Maps Flash API to find exactly where to apply the filter. If you apply it directly to the Map instance, you’ll color everything, including the Google logo and whatever else floats on top of the map. One level deeper is better, but will still color makers and info windows. A second level deeper is the spot. It’s basically like this, where map is the Map instance:

var a:Sprite = map.getChildAt(1) as Sprite;
var b:Sprite = a.getChildAt(0) as Sprite;
b.filters = [new ColorMatrixFilter([ /* color matrix values */ ])];

In the example above, “Winter” takes the red and green input channels and distributes them equally across all channels, but the blue input remains blue on output. The result is an desaturated, icy-looking blue. “Inverted Grayscale” turns everything to grayscale, but additionally sets the map’s blendMode property to “subtract” and sets it against a white background. That inverts the grayscale image for a somewhat stylish effect.

Now, let’s face it: this is a quick and easy but very limited method for “customizing” a map. (And to be honest, I’m not sure how kosher it is according to the terms of service.) It can make a map look cool, but applying the effect to pre-made tiles means that you’re altering the colors of all features on the map. You can’t keep the official blue and red of interstate highway shields, for example.

So keep this little trick in mind, but be more excited about actual customization (and open data) with CloudMade.

4 Comments

Indiemapper

by David Heyman on February 20, 2009

Dear Map-Enthusiast,

We are very pleased to announce the launch of indiemapper.com. Indiemapper is a project that is very near and dear to our hearts. When we were starting as a company or even before that at the University of Wisconsin, we constantly talking about the tools available to us as cartographers. Talking might be putting it lightly… we were complaining.

The same things were coming up time and time again. Why is it so hard to make a simple map from digital data? Why did we need to keep PC’s around when all of our design work was done on Macs? Why was all the current software so expensive when we were only using 10% of its total functionality?

At the same time, we were building some great online tools built for cartography. Ben was building TypeBrewer to help map-makers understand and make better choices with typography. Mark had built ColorBrewer a few years earlier when he was back at Penn State. Dave was working on bringing usable UI controls to temporal and geographic visualization in BallotBank. These programs were built on expert content, usability and accessibility.  Why weren’t web-based tools like this available within a the map-making environment?

Flash forward to the spring of 2008. Indiemapper began as a proof-of-concept built by Andy and Zach Johnson during their free time. They wanted to see just how much of the cartographic capabilities of GIS could be moved online using Flash. As it turns out, quite a lot. Originally, we thought that this would be a great code repository from which we could draw ideas and code to build into maps we were making for clients. Then it all came together. Indiemapper was so close! Andy’s original work proved it could be done. We could finally build the application that we ourselves had been wanting for all these years!

Indiemapper is still in development and there’s a lot we’re still learning about the final product. We’re re-coding that original prototype from the ground up to make it robust enough for professional cartographers in a production environment. We’ve redesigned the UI and built in expert choices (colors from ColorBrewer, type from TypeBrewer, data classification, etc) to make it easy for novice map-makers to produce great looking maps quickly.

We know that there are lots of people like us who are frustrated by the current available tools because of their price or their functionality. We’re confident indiemapper is for you and will find a place in your mapping workflow.

Looking forward to making maps with you,

Axis Maps LLC

No Comments

Map Evolution

by Ben Sheesley on January 15, 2009


Recently, we took on a nice little print mapping project for a few hotels located in downtown Madison, Wisconsin. The project involved making a one-sided, page-sized map showing hotel locations and the locations of a few points of interest in the area. The idea was that hotel guests could use the map to find their way around downtown as well as get a sense for where they were staying in relation to the university, interstates, airport, etc. The map was to be printed in grayscale, plus 3 spot colors (red, yellow, and blue).

Before starting out, we discussed the possibility of sharing the project with those interested in seeing all the stuff that goes into designing a map like this. The map design process is notoriously difficult to articulate and we’re keen on the idea of making pieces of it more transparent, where possible. One option was to screen capture the hotel map as it appeared in the production software at regular time intervals from blank page to finished product. So, here is a sequence of 116 images, originally captured at 10-minute intervals, compiled to show the evolution of the hotel map in just under 2 minutes. Clearly, not all maps are made in the same way, but this should expose some of the kinds of design decisions made in a relatively simple project like this.

Watch the larger version of Map Evolution (990 x 766px) — best for seeing change in map details.

6 Comments