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

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.

New letterpress maps of San Francisco and Manhattan

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.

Representing ‘No Data’ on Interactive Maps

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.

Cantabrigian Namesakes

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

London Low Life

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 >>

New typographic maps of Washington DC and New York

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!

Video Demonstration: Illinois Public Health Map

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.

Collecting Data from Non-Mapmakers

A few months back, we partnered with the UW Cart Lab to build a map for the University of Wisconsin Arboretum. We wanted to create a map that was populated with content generated by users and experts, built on top of free existing web-services, easy to maintain and great-looking. The map itself is relatively accessible so I’ll let you explore it on your own, however, I did want to talk a little bit about a major piece of functionality that is completely transparent to the end-user. First, a little background…

The University of Wisconsin Arboretum is easily the fourth best thing about living in Madison, WI after the Memorial Union Terrace, The Farmer’s Market, and being able to bike to anywhere (coming in fifth: that bonkers taxidermy museum). It’s a relatively vast piece of natural land on the near-West side of town. In just a 5-minute bike ride from downtown, you can feel like you are in the middle of the wilderness. Residents and researchers alike use the Arboretum for everything from running and biking to invasive species research, from snow-shoeing and hiking to painting and nature writing. This piece of land is very meaningful in many different ways to many different people.

Credit: University of Wisconsin Arboretum

That diversity of experience was the main challenge we faced coming into this project. There were lots of voices that wanted to be heard and have their perspective on the Arboretum reflected on the map. How do we engage these researchers, volunteers and nature enthusiasts without having to train each of them on the minutiae of collecting and preparing geographic data?

After looking around for a service that was already doing something similar, we landed on Google My Maps (since it was Google, we didn’t have to look very far). We had already planned on using Flickr to allow users to place their own photos on the map so this didn’t seem like to far of a conceptual jump. My Maps is a simple way for users to edit maps, adding vector points, lines and polygons just by drawing on a Google Map. Best of all, it outputs to KML, the format of the data already included in the map.

After adding their feature and attribute data to My Maps, all the user would need to do is send the URL of the KML file to the map administrator and it would be added to the map. Done? Nope. This is where things get cool.

While the input methods for Google My Maps are fantastically easy and well done, the symbology needed some work to fit in with our map. We didn’t want to have to sacrifice our cartography just for ease of input. We wanted to have full control over the colors and the point icons used by this incoming data.

Changing point styles is relatively simple. We built the map to use a lengthy XML file that the map administrator at the Arboretum uses to configure the map. Through this file, the administrator has a large amount of control over the data included in the map and can change it to instantly meet the Arboretum’s needs. It allows the admin to specify:

  1. The location and title of each layer
  2. Where the layers appear within the categories of the map
  3. What control users have over the layers (which show up in the legend, which start visible, which remain on)
  4. The available basemaps for each category
  5. All text content in the map
  6. If a layer’s feature contains photos or a slideshow
  7. Which layers are grouped into map animations and their corresponding date

The last thing the admin can do, is override the default point style by defining the URL to a PNG stored on the server. This icon will replace the default Google pushpin. We’ve designed a few of the default icons currently shown but with a little Photoshop work, any image can be used as a point symbol.

arbMap_icons.jpg 1150×900 pixels

Changing the stroke and fill color of a line or area symbol was a little trickier. Google offers a choice of 70 different colors for use on My Maps. Not every single one of those colors is going to look good on our basemaps, displayed with the other layers. To solve this, we created a color compatibility chart. Every single color on the Google My Maps selection corresponds to a color deemed compatible with our map. When a My Maps KML is loaded into the map, it automatically adjusts the colors based on the chart below. It is not a 1:1 relationship, as we’ve had to limit our palette to less than 70 colors. However, it gives the user the expected control over color and makes the finished product more visually pleasing.

myMapsArbMapColors

 

This solution is not 100% perfect and there were some sacrifices that had to be made to get this compatibility. Firstly, the data-model we used for each feature was limited. Google allows just one name and one description per feature. This eliminated the possibility of doing quantitative mapping and classification on the fly. (For data created outside of Google My Maps, we enabled categorical mapping using standard KML styles and including the name of the category as the name of the style).

Secondly, KML is not known for its friendly file sizes and the data used in this map is HUGE. We’ve tried to optimize it as much as possible but have resorted to inserting loading screens with informational content about the Arboretum to make those download times seem much shorter.

Hopefully this gives you a clear picture of what’s going on behind the scenes of the Arboretum map. The flexibility we’ve given to the map administrator to configure the map as well as the power we’ve given to the stakeholders to add their own data was new for us at the time, but is something we’ve continued to add to our more recent projects, albeit to a lesser degree. The UW Arboretum map still feels young and in its infancy. The map is a “living document” of the UW Arboretum. As more Arboretum volunteers and researchers get involved and add their considerable expertise to the map, we’re looking forward to watching it grow and change in the future.

San Francisco Typographic Map

HOORAY! The San Francisco typographic map is finally finished and is ready for purchase today. I made a big push to get this map ready for the holidays (with some help from Andy and Ben) and we’re really happy with the way this turned out. More images.

I went a bit overboard and decided to map the *entire* city; The amount of fine detail in this map is pretty astonishing. To fit the entire city onto a poster, of course, means the type itself has to be much smaller to fit it all in. In fact, the street text is half the size of the Chicago map (6 pt surface streets versus 12 pt) so there’s lots of detail for your eyes to enjoy.

GO BIG: Given the crazy density of streets I strongly recommend you get one in poster size (23×34 or up) so you can best see all of the parks, water features, and twisty streets the city is famous for.

WHAT’S THIS ABOUT LETTERPRESS?! Great news, we’ll be offering limited edition, gorgeous letterpress prints on rich cotton paper in the first half of 2011. While we love Zazzle (their prints rock), many of you asked (and begged!) for us to do these as hand-made, limited edition art prints and we thought that was a great idea. Want to be the first to know when they go on sale? Go here.

WHAT’S NEXT? We have New York City (Andy) and Washington DC (Ben) coming up shortly. They look sweet.