Unstacking Bars

Overview

In his map of the 1854 cholera outbreak in London, John Snow uses stacks of bars to represent the number of fatalities at a given address. A location with one fatality is represented by a single, horizontal bar that lies parallel to road where the fatality occurred. A location with five fatalities is represented by five horizontally stacked bars:¹

In 1992, Rusty Dodson and Waldo Tobler digitized the map. Each bar and pump was assigned a unique x-y coordinate. Each road was translated into series of straight line segments, defined by their endpoints. While the original data are no longer available,² they are preserved in Michael Friendly’s ‘HistData’ package. The data are plotted below:

Despite the appeal of stacked bars, I would argue that they are visually and computationally problematic. The reason, simply put, is that not all bars are created equal. Even though they are identical in terms of their appearance and the only thing that appears to distinguish them is their position on the map, bars can actually play different roles.

Sometimes a bar represent the location of a fatality, sometimes it doesn’t. Standalone bars, a stack with a one single bar (i.e., an addresses with one fatality), or the bar at the base of a stack represent a location. However, bars above the base case do not. Their only purpose is to create the visual stacking effect to represent the number of fatalities at an address.

Within a map, this duality can be a problem. Because a map is a visual device that illustrates spatial relationships, it’s natural to assume that the position of an elements (e.g., a bar) reflects an actual, physical location. When we violate this assumption, we undermine the visual interpretation of the map and potentially handicap our analysis. This is particularly true given that 44% (257/578) of bars in Snow’s map fall into the second, geographically uninformative category.

To address these problems, I “unstack” Dodson and Tobler’s data. I do so in two ways. In the first, which is available in fatalities.unstacked, all cases in a stack (i.e., at the same “address”) are given the same x-y coordinate. In the second, which is available in fatalities.address, the unit of observation is the address rather than the the case: each address is a single observation with a single x-y coordinate, and the number of cases observed at that location becomes an attribute of the address.

Data details

To illustrate the differences between the two, first consider how the datasets treat the largest outlier on Snow’s map: the eighteen cases at 38 Broad Street.

## The 18 cases at 38 Broad Street ##

broad38 <- c(239, 12, 310, 398, 562, 397, 421, 190, 290, 61, 174, 547, 523,
             521, 138, 59, 340, 508)

# With fatalities, all members of the stack have different coordinates

fatalities[fatalities$case %in% broad38, ]
#>     case        x        y
#> 12    12 12.34107 11.48214
#> 59    59 12.58271 11.01057
#> 61    61 12.47289 11.21463
#> 138  138 12.56326 11.04593
#> 174  174 12.48731 11.17735
#> 190  190 12.44094 11.28124
#> 239  239 12.31552 11.51159
#> 290  290 12.45943 11.24890
#> 310  310 12.35546 11.44285
#> 340  340 12.59532 10.98533
#> 397  397 12.40901 11.34986
#> 398  398 12.36903 11.41560
#> 421  421 12.42551 11.31754
#> 508  508 12.61480 10.95197
#> 521  521 12.54972 11.07519
#> 523  523 12.53218 11.10452
#> 547  547 12.51176 11.14190
#> 562  562 12.39045 11.37820

# With fatalities.unstacked, all members of the stack have identical coordinates

fatalities.unstacked[fatalities.unstacked$case %in% broad38, ]
#>     case        x        y
#> 12    12 12.31552 11.51159
#> 59    59 12.31552 11.51159
#> 61    61 12.31552 11.51159
#> 138  138 12.31552 11.51159
#> 174  174 12.31552 11.51159
#> 190  190 12.31552 11.51159
#> 239  239 12.31552 11.51159
#> 290  290 12.31552 11.51159
#> 310  310 12.31552 11.51159
#> 340  340 12.31552 11.51159
#> 397  397 12.31552 11.51159
#> 398  398 12.31552 11.51159
#> 421  421 12.31552 11.51159
#> 508  508 12.31552 11.51159
#> 521  521 12.31552 11.51159
#> 523  523 12.31552 11.51159
#> 547  547 12.31552 11.51159
#> 562  562 12.31552 11.51159

With fatalities.address, the 18 cases are represented by a single observation, case 239, which serves as the “address”:

# The 18 cases at 38 Broad street are nominally represented by case 239

fatalities.address[136:140, ]
#>     anchor.case         x        y case.count
#> 236         237 15.775540 13.98787          2
#> 238         238 12.900190 10.33882          1
#> 239         239 12.315520 11.51159         18
#> 257         240  9.794394 11.77236          1
#> 258         242 12.677590 12.05460          1

Virtues of “unstacking”

To illustrate the virtues of “unstacked” data, consider the following.

Kernel density contours

The graphs below apply bivariate kernel density contours, of varying bandwidths, to the “stacked” and “unstacked” data. The contours help to illustrate the spatial distribution or topography of fatalities, and provides a way to estimate the location of the epicenter, if not the source, of the outbreak.

With the “stacked” data, fatalities, the contours are looser (more uncertainty) and the epicenter is further south than what we might expect given that the Broad Street pump (blue triangle)³ is the recognized source of the outbreak. The problem is that the “vertical” stack of 18 cases (west of the pump at 38 Broad Street) and the “horizontal” stack of 5 cases (south of the pump at 10 Cambridge Street) pull the fit downward in a southerly direction.

With fatalities.unstacked, the contours are “tighter” (less uncertainty) and the epicenter are located further north, nearer to the roads, the pump and to Broad Street:

“Unstacking” via classification

The main roadblock to “unstacking” is that there is no notion of an “address” in the data. Bars are merely points. Streets are merely line segments.⁴ Nothing links the points to segments. And nothing connects one bar in a stack to another. All elements exist independently of one another. The only reason why the map “works” is that the fatalities and roads data have overlapping x-y coordinates.

To “unstack” the data, we need to match each bar to a specific road (segment) and to a specific stack. To accomplish these tasks, I employ two different methods of classification.

Orthogonal projection

The first method works by orthogonal projection. For each bar, the algorithm draws a series of lines that pass through the bar and that are orthogonal to “nearby” road segment.⁵ If the projected line intersects or bisects a road segment, it becomes a candidate for the bar’s home segment. If there’s more than one candidate, the algorithm chooses the segment that is “closest” to the bar: the segment with the shortest orthogonal projector.

To illustrate, consider the following stylized example. For case 12, there are three possible “home” road segments: the solid blue, solid red and the solid green segments. Of the three, only red and green are viewed as candidates. The problem with blue is that its orthogonal projector (the blue arrow) does not intersect the solid blue segment. Of the two remaining candidates, red is chosen because it is closer to case 12 than green: the red arrow is shorter than the green one.

This procedure correctly classifies 515 of 578 of the cases, an error rate of 10.9%. Errors occur due to ambiguities surrounding a case’s “home” segment. Unlike Snow’s map where a bar’s “horizontal” orientation indicates its “home” road segment, Dodson and Tobler only record a case’s x-y coordinate. This can lead to problems at street intersections, where a point may be closer to the “wrong” segment, and at addresses with many cases.⁶ The problem with multiple cases is that stacking can push cases away from their “home” segment. Consider the figure below. Even though visual inspection (the alignment of the stack) should lead us to choose black, the algorithm chooses red. The reason for the error is that stacking pushes the case so far from black that it falls outside of the range of consideration. I corrected these errors by manually recoding cases.

Cluster analysis

To link a bar to a stack, I use hierarchical cluster analysis.⁷ To make this task easier, I use a bar’s orthogonal coordinates rather that its x-y coordinate . That is, I use the point where the the orthogonal projection from the bar intersects its “home” road segment. Doing so reduces the dimensionality of the problem (the algorithm only needs to compare positions of points along a line) and virtually eliminates any classification error.⁸

The figure below illustrates this approach. Using a case’s x-y coordinate, the graph plots the case’s numeric ID and draws the corresponding orthogonal projector to Broad Street. Matching a bar to a stack, which is equivalent to identifying a stack, means identifying distinct clusters of points along the road segment. For the case at hand, visual inspection leads us to expect that we should find 8 different clusters: 4 on the north side, 4 on the south.

One can be confirm the results by examining Snow’s map:⁹

The one fly in the ointment is that addresses directly opposite one another will have “identical” orthogonal points and will appear to belong to the same “address”. A simple solution to distinguish clusters on opposite sides of the street is to compute the sign of the arithmetic difference between a case’s x-y coordinate and its orthogonal coordinate.

For example, consider cases 321 and 239. They lie on opposite sides of Broad Street. In the figure below, 321’s coordinates are shown in blue while 239’s are shown in red. When we take the signs of the differences, we get (-, +) for 321 and (+, -) for 239. This distinguishes cases on the north side from those on the south side.

In general, for roads with positive slopes (e.g., Broad Street), the differences for cases on the north/west side will be (-, +) while those on the south/east side will be (+, -); for roads with negative slopes (e.g., Cambridge Street), the differences for cases on the north/east side will be (-, -) while those on the south/west side will be (+, +).¹⁰

With this information, I can use cluster analysis to identify stacks, or “addresses”, on each side of a candidate road segment. Since we expect the distances between cases in a stack or “address” to be small, I use an arbitrarily low but reasonable cutoff “height” of 0.05. The two dendrograms below represent the North and South sides of Broad Street. We can see that this procedure correctly classifies the 8 different groups or stacks that can be seen in the figure above and that can be verified by looking at Snow’s map.

The map was originally published in Snow’s 1855 book “On The Mode Of Communication Of Cholera”, which was reprinted as John Snow et. al., 1936. Snow on Cholera: Being a Reprint of Two Papers. New York: The Common Wealth Fund. You can also find the map online (a high resolution version is available at http://www.ph.ucla.edu/epi/snow/highressnowmap.html) and in many books, including Edward Tufte’s 1997 “Visual Explanations: Images and Quantities, Evidence and Narrative”.↩
http://www.ncgia.ucsb.edu/pubs/snow/snow.html ↩
The blue triangle is the “correct” location of the pump as included in the amended, second version of the map that appears in the Vestry report. The empty green triangle is the pump’s “wrong” location from the original map.↩
In Friendly’s HistData package, these data are called “Snow.deaths” and “Snow.streets”.↩
To reduce computation, I only consider road segments with at least one endpoint within approximately 50 meters of the bar (i.e., a distance of 0.5 on the map’s scale).↩
This is further exacerbated by the fact that the width of roads is not always taken into consideration. This creates instances where cases on one side of the street appear to be closer to the road than those on the other side. One particular case of note is Portland Mews. In Snow’s map, Portland Mews is a large yard or square. In Dodson and Tobler, Portland Mews simply a set of line segments, which possibly corresponds to the roadway through the location. As a result, given the orientation of the cases of Snow’s map and location of the cases in Dodson and Tobler, these three cases will appear to belong to a single cluster instead of two separate ones. I manually chose a more distant road segment on Portland Mews that better reflects the orientation of bars in Snow’s map.↩
Specifically, I use stats::hclust(), which is included with base R and which, by default, employs a “complete” method of agglomerative hierarchical clustering.↩
What makes this possible is that, by design, its “vertical” dispersion, the spread of x-y points along the orthogonal axis, is much greater than its “horizontal” dispersion, the spread of orthogonal points along the road’s line segment. In an ideal world, the “horizontal” dispersion would be zero and all points in a stack would be perfectly aligned. In practice, this is not the case.↩
In Snow’s map, one can see 5 addresses on the north side of the block of Broad Street between Dufours Place and Poland Street (the road running north-south just visible on the east or left side of the graph) but only 4 of those addresses fall on the street segment in Dodson and Tobler. The reason for the discrepancy is that intersections with other streets, regardless of which side of the road they may fall, define the end points of road segments. This is why the south side of this segment of Broad Street only includes 4 addresses: the endpoints are defined by Dufours Place on the left (west) and Cambridge Street on the right (east).↩
The two limiting cases occur when roads run either along the East-West axis (i.e., 0 degrees) or the North-South axis (i.e., 90 degrees). For the former, cases on the north side will be (0, +) while those on the south side will be (0, -); for the latter, cases on the east side will be (+, 0) while those on the west side will be (-, 0).↩

“Unstacking” Bars

lindbrook

2017-08-10