Updates from indiemapper.com

by David Heyman on November 20, 2009

If you’ve been wondering why our blog has been a little quieter as of late, let me present to you the reason: Indiemapper. It’s our web-based mapping application built to help you make great looking maps from digital data FAST. It’s not quite ready for release yet but I did want to share with you a 3 minute overview screencast and 3 sweet looking maps made using indiemapper. As always, check out http://indiemapper.com for more details and information.

PS – Thanks to everyone who came out to our NACIS session and PCD demo. Your feedback and enthusiasm has been invaluable!

Indiemapper Overview Screencast

30-day Precipitation Totals

Idiemapper - Precipitation

Europe at Night

Indiemapper - Europe at Night

2008 Election Results by County Population

Bivariate Election

No Comments

Ed Parsons dislikes cartographers, “more than anyone in the world”

by Mark Harrower on November 5, 2009

The title was one of the opening statements made by Google’s “technology evangelist” Ed Parsons in a recent talk for the British Computer Society. In the talk he argues traditional street maps are bad (all of them) because they fail to engender a sense of place and because they abstract the world using map symbols. He goes on to say Streetview is good and doesn’t suffer any of these problems. So is Google Earth. The take-home message is that 2D is bad! Maps symbols are bad! Photos are good! And paper is bad! [subtext: Google doesn't make paper, but if we did, we might soften our stance].

Here is my concern: I’m not aware of any research to support such simplistic claims. Merely saying them, repeatedly, doesn’t make them true. The wayfinding research that I have seen shows that for some users, for some map reading tasks, yes, absolutely Streetview and Virtual Earths and geo-tagged photos can help. And for some users and some situations paper is better than pixels. And for some users, and some kinds of data, 2D is better than 3D. But none of those statements is a blanket truth and by outright rejecting all traditional maps in his talk–even if just for wayfinding on mobile devices–an otherwise solid argument is overshadowed by hyperbole.

If drug companies made arguments like these they might try to convince us by saying “Aspirin is bad. Aspirin may make your arms fall off. But our new drug has none of these problems. Use our new drug.” The difference is drug companies are legally obligated to back-up their claims. It is perhaps the reason they don’t employ “evangelists.”

The deeper, more troubling message that we hear again and again is that cartography is little more than making street maps.  And the flip side of that coin is the only reason we use maps is for wayfinding. Streetview is very cool (it really is), but it is also pretty specialized in its uses and the advent of it does not in fact “kill cartography.”

Cartography is more than taking photographs of a street. It’s a shame that someone with this level of influence at Google has such a limited view of why we map.

8 Comments

Visualizing Indieprojector

by Mark Harrower on August 20, 2009

In case you haven’t seen it over on the indiemapper blog, this is a composite view of all the data loaded into indieprojector since it was launched earlier this summer.

IndieProjector_Poster_small

No Comments

[Cartogrammar] Simple shapefile drawing in ActionScript 3

by David Heyman on July 17, 2009

Need a quick and easy way to get shapefiles into your AS3 project? Fear not! Over on his blog, Andy has posted a set of supplemental classes to Edwin van Rijkom’s SHP code library. It’s a simple solution that will help you get from data to interactive map faster than ever.

Link: Simple shapefile drawing in ActionScript 3 (via Cartogrammar)

No Comments

Data Probing and Info Window Design on Web-based Maps

by Ben Sheesley on July 13, 2009

Info windows are the familiar pop-up balloons that often appear when interacting with features on a map. This activity is generally called data probing. For example, click on a Google Maps marker and up comes a little bubble with information about the place. The uses for data probing are seemingly limitless, ranging from the retrieval of map-based comments, annotations, and descriptions of ‘what’s here?’, to map stats and info graphics, to map use instructions (e.g., “get directions”), explanations (e.g., “group of 3 markers”), and controls (e.g., “zoom here”), to alternate map views (e.g., an historical map). All of this, of course, can come through in the form of text, photos, audio, and video.

Data probing is essential. In one sense, its needed because we’ve got tons of data about the world, but just small, low-resolution computer screens to view it all on. Like a drop-down list or an accordion menu on a Web page, data probing is a design compromise that can save space on maps. In another sense, however, data probing is an important design decision that can help direct map readers’ attention and understanding from the general to the specific by offering details on demand. Without data probing, we’d either have crazy-cluttered maps or watered-down maps not taking advantage of all of that rich data out there.

Of course, data probing is everywhere outside of mapping as well; on charts, graphs and all sorts of other info graphics. But here I focus on Web maps, specifically on info window design, and outline some major design considerations and provide a few examples that could help inspire your next effort.

Design Considerations
1) Size
Large footprint info windows hold lots of data but end up obscuring much of the map itself. Often, it’s the geographical context and the distribution of data around a probed location that’s helpful for a more complete understanding of a place. When an info window obscures the map, the missing section must be held temporarily in a user’s working memory until the window is closed. For this reason, it’s usually worth minimizing this kind of cognitive load and coming up with ways to make info windows more compact.

Compactness depends a lot on the volume of data that will wind up in the info window. Tiny, “tool tip”-sized window are great for small amounts of data, like a summary statistic, geographical feature name or ID, or a line of text. Larger windows, holding multiline text, images, etc., typically range between 250-350px wide and 100-400px tall. On some maps, both sizes can be used in tandem to good effect, like in the University of Wisconsin Campus Map (below).

University of Wisconsin, Campus Map

University of Wisconsin Campus Map, showing large and small info windows.

Instead of expanding much beyond the larger size mentioned, its worth considering ways of organizing info window content to keep the footprint compact. One solution we really like is the idea of using tabs to categorize content and/or mini-slideshows for previewing distinct chunks of material. EveryBlock’s city maps and Stamen Design’s London 2012 map are good examples:

EveryBlock city map

EveryBlock info window, showing mini-slideshow content.

London 2012 map

London 2012 info window, showing tabbed content.

We also like the idea of info windows that re-size dynamically (within limits) to best fit their content. When content is just a bit larger than a probe window, this can prevent the need for a scroll bar, which just creates extra work for the map user. Conversely, when content is small, the window shrinks to fit, avoiding big blank spaces that unnecessarily obscure the map. Really large amounts of content, like a full news article, are probably best presented on a new page or somewhere off the map and retrieved via hypertext links (e.g., “full text”).

Avoid too much empty space

Avoid too much empty space.

2) Position
If we apply what we learn from Eduard Imhof’s work on label positioning, the preferred place for an info window attached to points and other small objects would be to the right and somewhat above it. In contrast, left and in-line positioning would be less desirable, although Imhof acknowledges that any placement is permissible and sometimes even necessary. Compared to positioning map labels, however, info windows are somewhat of a unique challenge. This is partly because they tend to be larger in size and partly because of our interest in keeping them on screen when opened near the edges of a map or application window.

Avoid cutting-off info windows.

Avoid cutting-off info windows.

Perhaps the most common approach to keeping info windows on the screen is to auto-pan the map. This works especially well if the map extent is limitless in all directions, because there’s no concern about auto-panning off the edge. Too much auto panning, however, can be disorienting, especially when the action itself is unexpected or the distance and speed of panning are too great. Auto panning can also be disrupting to users, due to a change in the map extent, which can alter the location or visibility of markers and data layers previously in view.

One ‘smart’ info window that I really like repositions itself left/right/top/bottom around a probed location to stay on screen AND minimize the amount of auto-panning. There’s a working example and source code for this by Dmitir Abramov. Maybe, a ‘super-smart’ info window would also be aware of related geo-data (e.g., map markers) and reposition itself to minimize contact with that, as well?

3) Stem
The info window stem is the visual link that connects it to a probed location. The problem of obscuring map context in the immediate spatial neighborhood can be solved by lengthening and/or shifting the stem along the window’s edge. It’s often the immediate geographical context that we’re most interested in, anyway. The question, ‘what’s near here?’ can be as interesting, if not more interesting than ‘what’s here?’. So, generally speaking, we prefer longish tails, but can think of cases where a short tail would be preferred (e.g., like on cell phone maps or other tiny map windows).

Longer stems can reveal neighboring map content.

Longer stems can reveal neighboring map content.

Another option is to go without a stem at all, which keeps the area around a probed location totally open. The strong connection between location and info window is lost, but this can be restored to some degree with a highlighting technique, like in the The New York Times map, Geography of a Recession, below. Here, the highlight (black outline) gives users positive feedback and helps link it to the info window, which appears/disappears on mouse-over/off. For stemless windows that are persistent, (i.e., require a click to open and/or close) highlighting becomes even more important to maintain this visual connection.

New York Times, Geography of a Recession.

New York Times info window without a stem.

4) Open/Close
Opening and closing an info window should be immediately obvious to users. The advantage of mouse-over windows, like in the NYTimes example above, is that they appear with almost no effort at all and can’t easily be missed. However, this ‘always on’ nature can make if feel ‘in the way’ sometimes, especially if finding non-probable map or window space takes work.

A really obvious “X” button in the upper right corner is maybe the most immediately obvious way to close a probe. Clicking ‘away’ from the info window itself can also be effective, as long as other uses for a mouse click are also considered. In other words, should an info window close upon click+drag map panning? (Probably not.) Should it close when another location is probed via mouse click? (Probably, yes.)

One option that I don’t see too much of is that for opening multiple info windows simultaneously. Two or more open windows is very basic, yet invaluable, way of comparing details across locations. Universal Mind’s LaunchPad demo (below) allows users to open multiple info windows and then drag-and-drop them anywhere on the map. A similar approach might give users the option of “pinning” info windows to the map at their stem points, thus maintaining stronger visual linkages to locations. Perhaps, the windows could also be repositioned, with stems changing in length and direction.

Universal Mind, LaunchPad

Universal Mind's LaunchPad, showing multiple info windows.

5) Look and Feel

  • Drop Shadow. Drop shadows helps focus attention on info windows, elevating them above other map content and setting them apart from visually complex map backgrounds.
  • Window Corners. Choice of square or rounded corners is mostly a stylistic decision. If rounded, make sure that the corner radius stays constant when scaling dynamically (9-slice scaling works well for this).
  • Title. Window titles should help users answer basic questions like, ‘what are we looking at here?’, or ‘what is the name / address of this probed location?’
  • Graphic Styles. Good use of type styles and colors, background color, and/or subtle divider lines can help organize content and go along way in making it faster and easier to read.
  • Stem Position and Angle. Stems positioned too closely to a corner can appear somewhat unstable. An angled stem, as opposed to a stem that extends perpendicularly from a side, can add a bit of visual interest, but too sharp of an angle can appear awkward, as shown below. Corner-anchored stems, although more uncommon, distance a window farther from its location than side-anchored stems, assuming equal lengths. They seem to appear most stable when extending at about 45 degrees (see below).
Stems at steep angles or near corners appear less stable

Stems at steep angles or near corners appear less stable.

Corner stems appear most stable at a 45-degree angle.

Corner stems appear most stable at a 45-degree angle.

Alternatives to Info Windows
There are plenty of examples in which data probing doesn’t bring up an info window at all. Rather, data is presented in some other part of the page or user interface. Although obscuring map surface area can be avoided this way, one issue to consider is split attention. This can weaken linkages and create more work for the user, whose attention has to be in multiple places–and potentially across large distances–on screen. OpenStreetMap and Flickr’s Yahoo! Maps mashup are both good examples of this alternative.

OpenStreetMap.

OpenStreetMap splits apart a probed location (blue outline) and its related info.

Flickr map

Flickr's map splits apart a probed location (white star outline) and its info.

Other Examples of Info Windows
1) Bing Maps
Mouse over/off to open/close. Dynamic window and stem positioning. No auto-panning. Short stem. Dynamic scaling.

Bing Maps

Bing Maps

2) Google Maps
Click to open/close. Window and stem are fixed position. Auto-pan to stay on screen. Long stem. Dynamic scaling.

Google Maps

Google Maps

3) Stamen Design, Oakland Crimespotting
Click to open/close. Scrolling content. Fixed size and position. Short stem. Slight semi-transparent background.

Stamen Design, Oakland Crimespotting

Stamen Design, Oakland Crimespotting

4) Washington post, Time-Space: World
Modified Google info window. Click to open/close (small info window on mouse-over). Blue scroll buttons move between points in the cluster for a unique way of organizing content.

Washington Post, Time-Space: World

Washington Post, Time-Space: World

5) Yahoo! Maps
Click to open/close (small info window on mouse-over). Window and stem are fixed position. Auto-pan to stay on screen. Short, almost non-existent, stem. Dynamic scaling.

Yahoo! Maps

Yahoo! Maps

2 Comments

ColorBrewer2.org

by Mark Harrower on June 23, 2009

I’m pleased to announce we’ve launched ColorBrewer2.org! After 8 years, which is about 80 in web years, it was time to update and overhaul the much-loved ColorBrewer. I was lucky to be a co-designer on the original and with the Flex development talents of Andy Woodruff we were finally able to implement ideas that had been kicking around. This remains totally free and adds some new features that’ll make using this easier and faster.

cb2

New Features include:

1. EXPORT: We never really had this before and now you have four ways to get colors out of ColorBrewer: export Adobe ASE color swatches directly into Illustrator or Photoshop, copy and paste color specs, download an Excel file of specs, or even run ColorBrewer right inside ArcGIS (thanks to the folks at the NCS).

2. MILLIONS OF SPOT/ACCENT COLORS: You can now check any spot color against the schemes, not just the pre-defined 8 we use to include. For example, you can now see how well your specific company colors work against any scheme – just type in the hex/rgb/cmyk values and take them for a test drive.

3. FILTERING: You can now narrow your search and find what you’re looking for much faster using filtering by colorblind-safe, print friendly, and photocopy-able check boxes.

4. TRANSPARENCY: This one was much requested, especially by folks who wanted to preview how well the color schemes worked on mash-up tiles and terrain/hillshading. This one was tough becuase the quality guarantee (and testing) behind the schemes was done with fully opaque colors and white backgrounds. So be carefully not to assume that the schemes will work as well once you start changing their opacity and merge them with other map layers, but if you are cautious (e.g., 3 or 4 colors) it may work for your needs.

One of our core ideas of our company is that we can and should donate some a portion of our time to fun side projects. Updating ColorBrewer was just such a labor of love and we believe, deeply, in the need for tools to support the on-going democratization of cartography and also the need for good design in the world. Cheers!




11 Comments

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