A Case Study

Once I digitally recreated the original Squares of Washington City, I wanted to quickly map something that I hadn’t seen before . . . that nobody had seen before. I typically map history by linking tables of historical data with historical geographic features, such as Squares, Lots, or building footprints. In this case I needed data associated with the old Squares, or the Squares as they were prior to Urban Renewal and other Square-distorting developments. Before I drew the old Squares, I could not accurately map historical data associated with them.

I decided to map the 1874 Faehtz & Pratt assessment, which has been available as a table in the Building Permits Database for over a decade. That assessment is available on microfilm at Washingtoniana and probably elsewhere. Owner’s names are not included, unfortunately, but otherwise it is by far the most user-friendly assessment of the Old City of Washington. The assessment includes a map of each Square showing the lot configuration at that time, but not “improvements,” which are buildings.

1873 Faehtz & Pratt Assessment
A snip of the table representing the 1873 Faehtz & Pratt assessment of the City of Washington.

Wording within the document indicates that it is a snapshot of what existed in September 1873, so I use that year for this data. The records/rows in the assessment naturally represent taxable lots. I have started to draw the original lots, but I am a long way from being able to map every lot in the Old City. I quickly made a new table of aggregated data by Square. That is what I will map.

1873 Assessment Aggregated by Square
Snip of the 1873 Assessment Aggregated by Square

This assessment covers only the Old City of Washington (Squares 0001 to 1170). The city must have just formally disappeared at that time due to the Organic Act of 1871 but was still treated differently than the rest of the District.

In order to link the table to the map features you need a unique “key” value that matches one record/row in the table with one map feature. The Square and Suffix together provide that. I created a new column/attribute for each Square on the map that contains the two values concatenated. When I made the table of the assessment many years ago I identified each Square with the square and suffix values already together. I need to link those two values together in the mapping work environment.

I expected some pushback from the software in joining via these two values, like maybe it would choke because the length of the fields did not match or trailing blanks were not consistent. It seems like simple things are never simple and I often have a wrestling match with ArcMap to do basic things, but this time it just worked so I have time to write about it.

There are four values in the assessment that I can map for each Square: the numbers of brick, frame, and “other” buildings and the total value of assessments. Dot density is the “best practice” for symbolizing quantities by variably-sized polygons. Dots representing a number in the table are placed randomly within the associated polygon/Square. When you zoom out to the scale I will use, the randomness becomes visually irrelevant.

I mapped bricks (brick buildings) first, making them brick red. ArcMap software wants to show dots at a 10:1 ratio. That is, there is one dot in a square for every 10 buildings. It appeared very sparse, as if little development had happened in the city. Out of curiosity I went to 1:1. That was way too thick, especially when the other building types were included. I settled on 5:1, one dot for every five buildings of that type.

1873 Assessment, all Bricks
Bricks represented at 1:1. When I add frame and other buildings, the map will be too crowded.

The map needs to easily and instantly orient the reader to the contexts of time and place. For maps showing the last hundred years or so I use the Districts ample waterways and parklands as the visually outstanding features. For data this old, those features would deceive and/or confuse, so I’ll try a period map.

I have the 1861 Boschke map on hand and for this unpaid project it is good enough. All of the privately owned Squares in the Old City are represented by my original Squares, rendered in a neutral color to make a nice background for the representative dots that are the focus of the map. Below the Squares I layered the original streets (also recently drawn by me) as a 4.5-point gray line to further reduce noise from the Boschke Map within the Old City.

1873 Assessment
A presentable version of the map, with bricks, frames, and other buildings (purple) represented at 5 per dot.

“Other” buildings, represented in purple, include stone buildings, carriage houses, churches, warehouses, etc. The many that can be seen in the SW quadrant are shanties, small, cheap dwellings valued at $50 to $100. The undesirable and previously unused low lying ground around James Creek became home to many freed slaves after the Civil War.

I symbolized the total value of the improvements on each Square with a graduated circle. This method skews by Square size, as a smaller Square simply cannot hold as many improvements/buildings. Nonetheless, this symbology shows exactly and absolutely where the money has been invested.

1873 Assessment
Total value of improvements, per Square.

Frankly, it didn’t occur to me to put legends on any of these maps. With these last three maps, the point is not the values that the symbols represent, which mean little today and are best seen on a report anyway. The point is to see where the improvements and the money were. A legend would distract.

In an attempt to see where the most expensive buildings were, I wanted to normalize that value by the total number of buildings on the Square. So I went back into Microsoft Access and added that field to the table. There’s probably a way to normalize by a sum right in ArcMap, but my naive solution was easy.

1873 Assessment
Total Improvements per Square, normalized by the total number of buildings on that Square.

This map is very similar to the previous, total improvements, but the dots that represent many improvements are relatively shrunken and those that represent more expensive buildings are swollen.

Then I figured it’d be more straightforward to divide total improvements by total buildings per Square, so I went back into the data table one more time to add that. In mapping it, I selected Squares with more than 6 buildings so as to eliminate outlying expensive buildings and focus on clusters and groupings. Turns out this is exactly what I had already done by normalizing the graduated symbols. I’m still learning!

Assessment 1873
The green normalized-improvements dots are matched perfectly by my naive attempt at the same, represented by the black-around-orange dots. The maximum sizes are set different to compare the two.

Did I waste my time? Not at all! What had been — to me — an abstract, behind the scenes process has been made perfectly clear in the most tangible way. This map did for me what I hope my maps do for readers. That is, it instantly crystalized an idea in my mind that was previously not entirely clear.

One last thing: mapping is a great way to QC (quality control) your data. I noticed that Square 0110, near the northwest edge of the Old City, had a ton of brick buildings. It was an eye-catching outlier. Turns out my table had 300 brick buildings on one lot there that, according to the 1887 Hopkins map, probably had no actual brick buildings. By mapping the data I was able to fix a whopper of an error that had been in my data table all along. There may be other data errors in the table, but surely none so egregious.