indiemapper is free

by David Heyman on January 5, 2012

With the start of 2012, we’ve decided to make indiemapper free to use. Since indiemapper launched in 2010, our business has grown and changed to where supporting and maintaining indiemapper is no longer a major part of what we do at Axis Maps every day. We’re making indiemapper free so that it can continue to exist as a useful tool for map-makers while freeing us up to be as awesome as possible at our custom cartography business.

To allow us to give it away for free, we’re scaling back what indiemapper does. We’ve removed all account-based online functionality including usernames / passwords, cloud storage, and map sharing. Everything else, we’ve left as is. The map-making process is still the same except you don’t have to log in AND you need to export your map before you close your browser. We’re also moving our support operations over to GetSatisfaction to let the community of indiemapper users share their knowledge amongst themselves.

We’re really happy about this change and we hope you are too. If you have any questions about the new direction of indiemapper, please let us know in the comments.

Launch indiemapper

10 Comments

“But hasn’t everything already been mapped?”

by Andy Woodruff on December 15, 2011

In a recent post I remarked on the common reaction people have when I say that I’m a cartographer. In my experience people are usually mildly astounded and fascinated by this exotic profession (and just like that we are new best pals), and as the conversation progresses they ask if that means something like Google Maps. But sometimes it’s the most dreaded, annoying question that every cartographer has heard: “hasn’t everything already been mapped?”

There is of course a real answer to that question (perhaps it’s something like, “everywhere, but not everything” or perhaps it’s “there’s actually this one spot in Idaho we haven’t hit yet”), but it’s more amusing to dwell on the things we cartographers hear from our new acquaintances than on what we say in reply. In that spirit, a week or two ago I posed the following on Twitter:

Survey time. Cartographers, fill in the blank based on your experience. Person: “What do you do?” You: “I’m a cartographer.” Person: ______

It generated some excellent replies. If you’re not a cartographer, when you meet one remember that these are things we’ve all heard. If you are a cartographer, please comment to share your experiences too!

@stefanie_gray has heard several good ones.

“You’re a cartographer? But isn’t the map done?!” (Yes, there is only one map! Ever! And it’s DONE!)

“Why would you study cartography if every place has been discovered?” (Uh, did I say I was in ‘conquistador studies’?)

“Hahaha making maps? On the computer? There’s already Google Maps, no need for anything else!”

@wallacetim‘s neighbor doesn’t like his prospects.

“Where’s the money in that?”

@kg_geomapper seems to hang around a mix of high-tech and low-tech map users.

Person: [response always involves mention of either a road atlas or google maps!]

I also get “oh yea, I love old historical maps”

@mapgeek reports a modern twist on the old “hasn’t everything been mapped” bit. Google did it!

“But hasn’t everywhere already been mapped by google?” aargh

She has also, much to my horror, encountered someone who is less than impressed with cartography. And from a geologist at that!

I also got a “god, how boring” response once!

I think he may have been something to do with geology! oh the irony!

@fgcartographix has also found uninterested people (which is too bad, because I usually count on cartography for an easy conversation topic) but also the usual Googlers.

Person: and then changing the subject.

Person: There’s still area to map with Google Earth? (got that one twice…)

@desjardins meets people who have a passing familiarity with a dictionary.

“um, so what does a cartographer do?” or “that’s maps or something, right?”

@NadiiaGorash knows a similar crowd.

Person: WHO?!? Me: …. Person: I see. Mapmaker!

But @nichom finds people a step behind.

Person: < blink> (mental search for what ‘cartographer’ means) Me: I make maps. Person: Cool! (let fun conversation ensue)

@vtcraghead points out that those with good taste (my judgment, not necessarily his) may know about cartography because of Arrested Development.

We are living in the shadow of Buster: http://www.youtube.com/watch?v=tj7RlQdF25A

@clubjosh has figured out a good reply to the standard line.

usually get the “hasn’t everything been mapped” line which gets my “Yeah, but some moron keeps changing things” retort

@g_fiske talks to the good ones. The ones who appreciate us.

Person: “Oh, I love maps!”

And @musingbouche is not a cartographer, but knows what to say if she meets one.

cool!

Did I miss any? Comment on this post with any other good ones you’ve heard!

15 Comments

Web cartography… that’s like Google Maps, right?

by Andy Woodruff on December 5, 2011

A few weeks ago I was graciously invited by Jeff Howarth to speak to cartography and geography students and faculty at Middlebury College, Dave’s alma mater. I showed some of the work we do at Axis Maps, described our processes, and offered my perspective on what web cartography is all about. The topics were mostly aimed at undergraduate cartography students who may be considering a career path like ours. (While we’re at it, check out some of the student maps.) This post is not at all verbatim but more or less sums up what I said.

The “what do you do?” exchange is always fun for me when meeting new people. When I tell people I’m a cartographer, two reactions usually occur. The first is something like “wow, that’s so cool! I’ve never met a cartographer!” (Lesson: maps make you popular at parties.) Then follows something along the lines of “so what does that mean, like Google Maps?” I then attempt to explain succinctly that yes, sometimes it is kind of like that, but no, it really isn’t.

It’s a little amazing that it’s only taken six or so years for the popular conception of a map—or at least a web map—to become so strongly tied to one type of map, and one exemplar at that. It’s both a blessing and a curse for a practice like ours at Axis Maps, in ways that I hope will be evident as I summarize the way we approach interactive web cartography.

THOROUGHLY DELIBERATE, PURPOSEFUL DESIGN

I made a bad map a couple of weeks ago. It showed 24 hours of bus GPS tracks in Boston, colored according to speed.

MBTA bus speed map

Cartographers, trained in their science, would tell me it’s a bad map. It’s a totally inappropriate color scheme for numerical data. It doesn’t generate any clear insights. But the map’s intended audience—the people for whom it was designed—speak differently. It’s eye-catching and novel, it’s reasonably popular, and most importantly it prompts interest and discussion on the state of transit in Boston. Rules and conventions shouldn’t be ignored to the point of misleading or misinforming map users, but just as with wholly “correct” and “useful” maps (which we also try to make!), this particular map successfully accomplished its purpose.

The point is something that seems to define our work and, I think, modern web cartography beyond the general practice of “making maps”: it’s all about purposeful design. Cartographic design is more than visuals and aesthetics; there’s room for the cartographer’s design decisions at every step between the initial earthly phenomenon and the end map user’s behavior.

Daniel Huffman has argued for the human element in cartography with regard to the discipline’s artistic side, and the more I think about it, the more it seems that this is not just about art in cartography; it’s part of what makes a Cartographer something more than a mapmaker. Cartography is about the careful thought behind the design of a map, not just any work (automated or otherwise) that results in a map.

DATA → DESIGN → CODE

So how does cartographic design play out at Axis Maps? We like to think of a project as three-stage process. We begin by finding out what the client wants mapped and for whom, and then assessing and obtaining the necessary data. Next we develop designs for the map, user interface, and interaction based on the known goals, assets, and restrictions. Finally, in a stage that is labor-intensive but conceptually trivial, we write code to build the map as designed. Without getting too far into the boring details of how we work, I want to mention a few notes on each stage.

Data

Anyone who has tried to make a map, chart, or anything like that will know that working with data is an easily underestimated task. Data come in a million formats and are often messy. Jeremy White, graphics editor and cartographer at the New York Times, has said that when people ask his advice on what software to know for his line of work, to their surprise he answers Excel. It takes at least passing familiarity with a variety of formats and scripts and tools to be prepared. And getting data onto a map isn’t just a matter of using ArcGIS anymore. I haven’t used ArcGIS even once in the past four years.

I’ll say two specific things about data. First, we always take care to obtain a data inventory from the client and to develop a data model early on. The data inventory (a list of everything that needs to be shown on the map) is an important first step before we begin designing anything, because obviously we need to have complete knowledge of the requirements in order to come up with a good design. Similarly, the data model (the way the data are organized, basically) will be necessary to know how to write code that loads and processes the data later on.

Second, all of that matters because complexity of the data and map can vary a lot, and it can’t be unknown when we go to design an interface. The chart below, from a paper by Robert Roth and Mark Harrower (PDF), explains why complexity matters. (It’s talking about interface complexity rather than data complexity, but we find them to be related.) We need to know about complexity and the map’s audience in order to execute a successful design.

Interface complexity vs user motivation (Roth and Harrower)

Design

If there is one clear thing I can say about our design process, it’s that it works like this: mock up EVERYTHING. Everything! We try not to leave anything to imagination. We generate mockups for every interface state, every map view, and every interaction. This usually means a couple dozen screens in the end, showing a step-by-step simulation of a user interacting with the map. We think that locking down all these designs before writing a single line of code is crucial to smooth development and good design. Otherwise we run the risk of cobbling together designs on the fly while writing code, resulting in a messier product.

We’ll always miss a few things, but with enough thinking and discussion we manage to identify most problems before encountering them during development. Our design process, like most I’m sure, is very iterative and involves a lot of attempts and review. Ben, our main Design Guy, draws on experience, conventions, constraints, user feedback, a keen sense of aesthetics, and, I assume, magic to turn ideas into great-looking and smoothly functioning designs. (Maybe he’ll have a chance to describe his methods here sometime.) He notes that there are always a zillion ways to attack a design problem, and for every alternative there is always a better one. We discuss to death possibilities for every little detail until the optimal solution is achieved. Ben’s idea of improvement in design skill is being quicker and requiring fewer attempts to arrive at the best solution to a problem.

FInding the design solution

Code

Writing code takes up the bulk of our time, but in concept it’s almost a formality to us. It’s all about choosing the right tools for the job (Flash, OpenLayers, Polymaps, jQuery, and so on) and then building what we’ve already so carefully designed. We don’t do this work in order to do interesting or novel technological things; we do it to make good maps. If cool technological developments come out of it, all the better, but it’s almost never the main purpose. In my own invented definition of cartography, cartographers are not the ones whose drive is to develop mapmaking technologies. Another related community does that, spending less energy on designing actual maps. It all works well as long as the groups exchange knowledge and each knows what the other is doing.

Our coding process goes something like this. 1) Load the data. 2) Make things work. 3) Make things pretty. Like I mentioned before, having everything designed ahead of time is vital. We can start with something rough but functional without worrying about design, because we already know how it will look and behave in the end. It also lets us know when we’re finished; interactive projects have a way of never ending if there are no clear goals at the outset.

Our coding steps for the London Low Life map

After hearing from enough of my cartography peers whose hatred of programming burns with the fire of a thousand suns, I must say this: yes, coding sucks. I write code all the time, and it often makes me want to punch the computer in the face. But it’s worth it. Totally worth it. It only takes a little skill to produce awesome things. A willingness to write some code opens a lot of doors, and it doesn’t require devoting a lifetime to becoming a master programmer. It doesn’t even require being a good programmer. It’s just another skill, not so different from, say, drawing Bézier curves in Illustrator for static work. Nathan Yau’s tale (and his Visualize This book) is a good one to learn from for those who have resisted getting into programming.

WHERE DOES DESIGN BEGIN?

After describing the design we do, it’s worth noting that visuals and user experience design are only one part of the overall process of designing a map. Kirk Goldsberry, visiting scholar at Harvard and professor at Michigan State University, recently impressed upon me that design in a cartographic context—broadly meaning the decisions that go into map—is not merely figuring out the visuals, but rather exists in the entire mapping process, something I touched on earlier. Leaving out map use for now, consider the progression from phenomenon to graphic. At one end is the actual thing that is happening, at the other end is the map that represents it. In the middle are data, meaningless in isolation and not to be confused with the phenomenon itself.

Design in cartography

Above are some activities that exemplify the progressions from phenomenon to data, from data to graphic, and the whole thing from phenomenon to graphic. Ideally a cartographer designs the entire process: what data are collected, how they are collected, how they’re organized, how they’re represented, how the map looks, how interaction works, &c. Dr. Goldsberry gave the example of old-timey explorers. They went places, recorded the data themselves for the purpose of making a map, and then they crafted the map itself. They designed everything. Sometimes a cartographer can still own the whole processes, but it’s rare these days, especially in web mapping. Realistically I think most activity falls either between phenomenon-to-data or data-to-graphic, with most of us who call ourselves cartographers existing in the latter category. We work with the data we have, but it’s worth bearing in mind that we’re doing something (i.e., making a map) that the data may not have been meant for, and this can affect our user experience design decisions.

WEB MAPPING, or PUTTING THINGS ON TOP OF OTHER THINGS

Returning to Google Maps, it has defined not only the layperson’s idea of a web map but also the web mapper’s idea of a web map, it seems. Ever since the early days of Google Maps mashups, the trend in web maps has been basemap + stuff on top. There’s almost always this strict separation of layers—layers that often were not designed to go together, although that part is gradually on the decline. We’ve advanced to the point where pretty good cartography is possible and easy in this framework (thanks to tools like TileMill), but it remains the case that web cartography usually means designing around the tiled Mercator slippy map system, and often using someone else’s tiles, instead of seeking the ideal solution. We all do what’s feasible within technological and time constraints, of course. At Axis Maps we take advantage of the built-in capabilities and user familiarity with standard tiled web maps all the time. But I do sense a risk that “web map” is coming to mean only one type of map, the “things on top of other things” map.

So perhaps my purpose today is to remind us all that there’s more than one kind of web map. Cartography is not Google Maps. It’s not OpenStreetMap. It’s not mashing up geotagged data from various APIs. It’s not rendering tiles. It’s not “geo” (“geo” is a stupid non-word and I wish it would die). It’s not GIS. Cartography is in the thoughtful design of maps, no matter how they are built or delivered.

8 Comments

New letterpress maps of San Francisco and Manhattan

by Andy Woodruff on August 11, 2011

San Francisco letterpress

Just a quick note to say that we’ve released several new limited edition letterpress prints in our typographic maps store. Check them out, and as always thanks to everyone for the feedback and encouragement in recent months!

San Francisco 2nd edition: This is a new design of the San Francisco letterpress map we made earlier this year, featuring waterlines for a new coastal style. Available in blue or black ink.

Manhattan: This is divided into two maps. A Lower and Midtown Manhattan shows the island from its southern end to 61st St, and Upper Manhattan features Central Park in an extent from 57th to 159th Street. Available in blue or black ink, and individually or paired together.

1 Comment

Representing ‘No Data’ on Interactive Maps

by Ben Sheesley on June 13, 2011

We spend a lot of time determining the best way to represent data given to us by our clients. Whether in the user interface or on the map itself, it’s at the core of what we do. In contrast, I’ve been surprised recently by the amount of time we’ve spent thinking about how to best represent data we do NOT have. Here, I’m talking about places where data was either not collected or not reported. Needless to say, discovering empty cells in a spreadsheet is not at all uncommon, albeit frustrating at times. This is the nature of data collected in the real world. But what is the best way to represent “no data”? It only takes a single missing value to raise the question and present this rather unique design problem.

Below are a few of the ways we’ve chosen to represent ‘no data’ in recent projects when interpolation or other means of smoothing out and covering up missing values was not an option. We feel that instances of ‘no data’ are nothing to hide from or ignore. In fact, in some cases, I’d argue that representing ‘no data’ can be a good thing and actually help to tell a more complete and truthful story about a mapped phenomenon that wouldn’t otherwise be seen.

 

Proportional Point Symbols

In the Jewish Life in America project for Adam Matthew Digital (project description), we mapped immigration, education, and population data at a number of countries, states, and cities over time to show how change took place. However, not every city has data available at every time slice. For those years when cities had no data, we mapped empty proportional point circles, sized according to the last year in which recorded data was available. For example, in the figures below the map shows that around 1890 Chicago had a Jewish population of 50,000. No data is available for St. Louis for this year, but in 1850–the last year in which data was recorded–we can see there was a Jewish population of 600 people.

Jewish population in Chicago, c1890

Jewish population in St. Louis is not available at c1890. The value at the last available time slice, c1850, is given instead.

Mapping hollow circles at years with no data can be helpful in a few different ways. First, it allows comparisons to be made between every city, albeit across years in some cases. Second, it reduces the distracting “pop-corn” effect of city points appearing and disappearing with each click of the timeline. Third, it shows the spatial distribution of all cities having some jewish population across time. Finally, and perhaps most simply, it makes for a less empty-looking and data-starved map.

 

Choropleth

For the Children’s Environmental Health Initiative Interactive Map Dashboard, we mapped a range of health, demographic and program data. In the figure below, late pre-term births at the census tract level in Durham, NC are shown. Features with ‘no data’ are represented by a gray fill color, a common technique found on choropleth maps. They can be hidden from the display via a checkbox in the user interface where the number of features without data is also shown.

Tracts with no data are represented using a gray fill color. An interface control counts and hides them.

The same map, but with ‘no data’ features hidden from display.

Places with ‘unstable rates’, although not exactly instances of ‘no data’, do not have big enough sample sizes to make meaningful inferences (as well as having some privacy concerns related to the small sample). Like features with no data, unstable rates can be hidden from the map display and ignored when necessary. However, unlike ‘no data’ these places are included in the map classification and are color-coded (i.e., not grayed-out). By treating each independently, users can refine how they want to display this more empty end of the data spectrum.

The same map, but with ‘unstable rates’ hidden from the display.

Assigning the color gray to ‘no data’ might seem like an obvious and easy choice, however, we’ve had to be somewhat careful in the past. Gray tends to recede and lie lower in the visual hierarchy than other colors on the map, and from a design perspective this can be advantageous in a number of ways. At the same time, this makes it especially important that the different meanings for “gray” are clear to the end user and that it be used consistently across the map and user interface.

While working on designs for the Illinois Public Health Community Map in collaboration with IDPH and IPRO, for example, we found that multiple uses for gray would be needed. In fact, a county on the map could be assigned one of three different gray values, and it was possible that counties representing each type could appear coincidentally. They could be gray 1) because a user zoomed in to a particular sub-region of the state, 2) because a user focused data around certain percentiles with the provided histogram control, and 3) because no data was available in the database. In addition, the health data we were mapping was calculated in several ways (e.g., “Rate of discharge” and “Deviation form Statewide Benchmark”), each requiring a different map color-scheme. In the mockup below of the Western IL health region, out-of-region counties are shown in light gray, out-of-focus counties in medium gray, and a single county with no data is shown in dark gray. To be safe, we chose sequential, diverging, and bivariate color schemes that didn’t include gray so as to avoid any potential confusion.

Mockup of the Western IL health region showing out-of-region counties in light gray, out-of-focus counties in medium gray, and a single county with no data in dark gray.

Basemap

One feature of the London Low Life Map we produced for Adam Matthew Digital (project description) involves the overlay of historical maps on a modern basemap of London so that both images can be seen together using an opacity control. However, not all of the historical maps were scanned at the same resolution, meaning the extent that zooming is possible can change from map to map. As a simple means of handling maps with ‘no data’ at the higher resolutions, we disable part of the zoom widget when the handle reaches a certain point. Zoom levels that are not available for a selected map are shown, but not clickable. This is similar to what Google Maps does when switching over to terrain from the roads map, although in that case the zoom widget is shortened instead of disabled.

In this map, the zoom track is disabled to represent the limits of available base map data.

3 Comments

Cantabrigian Namesakes

by David Heyman on June 3, 2011

Andy’s made a great looking map of small-multiples showing the breakdown of how streets were named in Cambridge, MA. Those of you familiar with the area will have fun trying to recognize the highlighted streets. Everyone else can marvel at how useful the small-multiple technique is at making easy comparisons across a complex dataset.

Cantabrigian Namesakes

No Comments

The Furniture District

by David Heyman on May 6, 2011

Over on the Bostonography Blog, Andy is muses about the spatial arrangement of humorous retailers in Cambridge. It’s inspired by The Simpsons and has some great looking maps (like the above) from GeoCommons.

The Furniture District

No Comments

London Low Life

by David Heyman on May 5, 2011

This week, we’re happy to begin a 30-day preview of one of our most distinctive interactive mapping projects: The London Low Life Map. This map was produced for Adam Matthew Digital, a digital publishing company based in the UK. Adam Matthew produces digitized archives of historic primary source documents, collected around a central theme, for higher education institutions. This map was built as part of their London Low Life collection that explores the seedy underbelly of Victorian London. It examines the documents of sex, drinking, gambling, and the institutions that sprang up to combat those very vices. As the map is integrated into Adam Matthew’s collection, we will only be able to grant access to our readers for 30-days. I encourage you to explore the map and enjoy Adam Matthew’s fantastic collection of historic maps and images. Since we’ve pulled the map out of the collection, I wanted to give you some context on what is included.

View the map >>

London Low Life-2-2

Historic Basemaps

The full London Lowlife project gives users access to a mountain of primary source documents from Victorian London, so it only makes sense that we start with maps made of greater London during this era. We’ve included some metadata with each of these maps (author, date, publisher) to give historical context and placed them on top of a custom Cloudmade basemap (with adjustable opacity) to give some modern context as well.

London Low Life-3-2

Taking these historical maps from raw image to geographically accurate overlay was an incredibly intricate procedure. While some maps existed as single, contiguous images, others were scanned in their current forms as pages, separated by fraying canvas. Before we could rubbersheet the maps to OpenStreetMap data (with the help of the UW Cart Lab), we had to manually remove the seams and align the resulting image fragments to one another. Furthermore, because these maps were at different sizes and scales, we had to build a system that would identify maps with limited resolutions and restrict the zoom levels available on the fly.

standford1884.tif-1-2

It’s fascinating to view the changes in the street maps over time, especially which streets were given primary status then and now.

Tallis Streetviews

In the mid-nineteenth century, John Tallis drew detailed views of the fronts and façades of buildings along Central London’s streets. Originally designed as a “visual yellow-pages” (businesses would pay to have their shops labeled), his 88 plates now survive as a first-person perspective into the streets of Victorian London.

London Low Life-4-2

We wanted to make these plates as immersive as possible. With the help of AMD’s editorial staff, we took Tallis’ original image and added some color to sharpen the images, shadows to depth, and a blue-sky background to increase the realism of the images. Finally, the images were run through Google Sketchup to create the perspective views that place you in Victorian London and allow you to look down either side of the street.

Be sure to click the “view original” button to see the original plates to view the intricate detail surrounding the street images.

Thematic Data

While the historic basemaps and Tallis Streetviews of the London Lowlife map attempt to provide insight into the qualitative aspects of Victorian London geography, we also wanted to explore the changing character of the population through quantitative thematic mapping. Simple demographic measures like population and density can provide a major insight into the nature of a city. However, we believe the most telling indicator of life in Victorian London, and certainly true to the name “low life” ascribed to this project, is the explosion in social services that sprung up throughout the city to deal with the new urban population.

London Low Life-5-2

By dragging the timeline to view an animation of the entire century, you can watch population increase in various sections of the city and then the services emerge to try and meet the need.

Victorian London

The final section of the map gives a taste of the larger London Lowlife project by placing a selection of the primary source documents on the map. It’s an engaging way to explore city by viewing some fantastic records of the landscape and people of Victorian London.

London Low Life-6-2

Mouse over a category point on the legend list to quickly highlight all corresponding points.

View the map >>

1 Comment

New typographic maps of Washington DC and New York

by Andy Woodruff on April 26, 2011

DC and NYC typographic maps

Earlier this month we launched our new store with two new typographic maps we had been working on since last autumn: Washington, DC and New York City (Manhattan). These 24×36 inch posters, along with the existing line of cities, are now done in super sharp detail as offset prints, and all are now found at the new store.

In addition to the new cities, we also released limited edition letterpress prints of San Francisco, which managed to sell out almost immediately. We’re now looking into future letterpress editions of this and other cities.

So if you haven’t checked it out yet, have a look at our typographic maps store and all five cities for sale:

As always, thanks to everyone for all the encouragement and support we’ve received for this project!

2 Comments

Video Demonstration: Illinois Public Health Map

by Mark Harrower on March 9, 2011

We’re very happy to be able to show-off our collaboration with the Illinois Department of Public Health and IPRO. This map makes information about the quality of health in communities available to the public, highlighting socioeconomic disparities that may exist. When combined with our indiemapper platform as well as linked graphs and charts, the clinical data in the map can be used to examine the health needs of a community, county or region for better policy and planning.

Above is a quick demonstration video showing the basic functionality. After watching the video, check-out the map itself.

No Comments