|     Introduction     |     Digitizing     |     Metadata     |     Results     |

Final Lesson: Digitizing Sanborn Maps of Charlottesville, Virginia

Jim Kompanek

Introduction:

Between the late eighteenth and late nineteenth centuries, the Sanborn Map Company produced highly detailed insurance maps for hundreds of urban areas across the United States. These historic maps have proved to be an important resource in the fields of "urban geography, architectural history and preservation, urban planning, ethnic studies, urban archaeology" (Sloan 2007) and many more. The purpose of this project was to digitize these maps for a fictional proposal for the Albemarle Charlottesville (Virginia) Historical Society (ACHS). The goal is to provide a framework for (Sloan 2007):

• Land use change studies;

• Genealogical research;

• City visualization.

This report is broken into four sections, the introduction, the digitizing process, the metadata for each layer, and the final results. Each section can be navigated through with the above toolbar.

Database Design:

Structure

The basic structure of the database included data organized into five spatial layers.  Each layer played an important role in the  development and implementation of the geodatabase. Primarily, these included (Table 1):

• DRG: This dataset was provided by the client. This layer augmented the DOQ as a reference aid for the georeferencing of Sanborn maps.
• DOQ: This dataset was also provided by client. Although the DOQ was projected, the projection was not defined and had to be determined.
• Sanborn maps: These maps were provided by the client. They were subsequently georeferenced and served as the basis for the polygon and line features.
• Polygon feature class (Structures): This class was used to outline the structures indicated on the Sanborn maps.
• Line feature class (Roads): This class represented the streets in Charlottesville and were used as the basis for potential future geocoding.
• Point feature class (Struc_Add): This class represented the location of individual addresses and was generated using code to determine the center of polygons.
• Tables (Struc_Year): This table was used to store attribute information, such as number of stories, year, and land use.

Table 1. Summary of layers used for the geodatabase design. 

Database Design:

Design

Feature attributes were dependent on the feature type and are discussed below. Each feature class was projected in UTM Zone 17 (NAD 83) to match that of the DOQ.

Structures Polygon Feature Class:

As mentioned above, the Structures polygon outlined all of the buildings on the Sanborn map. The only field assigned to this class was Struc_ID. This field identified each structure both geographically and temporally. Because this field acted as an identifier and not a number (used for statistics), it was a text field. Presumably, between decades most structures will remain intact, identifying each unique structure will cut down on redundancy versus having almost identical features between decades (i.e., a structure indicated on multiple maps will have the same Struc_ID). This feature class will relate to Struc_Year tables based on this field.

Struc_Year Feature Class:

As previously mentioned, the Struc_Year table contained a unique entry for each Struc_ID and decade for each individual structure which appeared on the Sanborn maps. For example, if a unique structure remained in place from 1900 through 1990, there will be 10 entries for it. To minimize storage space, a coded domain was used for the year attribute field. All of the recorded attribute information for each information was also stored in this table (see Tables 2-4). Coded domains were used to minimize the chances of data entry error. It was ultimately decided to keep this table separate from the geographic layers, as it will also allow data entry from within Microsoft Access, with minimal chances for file corruption. When necessary, this table can be related to the other layers.

                              Table 2. Summary of the Struc_Year feature class. 

Code	Description
1	1900
2	1910
3	1920
4	1930
5	1940
6	1950
7	1960
8	1970
9	1980
10	1990

Code	Description
NE	North East
NW	North West
SE	South East
SW	South West
N	North
S	South
E	East
W	West

 

 

Table 3 and 4. Coded Domains for the Struc_Year feature class.

Struc_Add Feature Class:

The Struc_Add point feature class identified the position of each unique address. To simplify querying, each address was broken into four separate fields: 101 NE Main St was converted into 101, NE, Main, Street. All of the data was stored in text fields, because each attribute (even the number) identifies a data identifier and is not used for math or statistics (Table 5). As with the previous feature class, coded domains were used to simplify the data entry process (Table 6).

            Struc_Add Point Feature Class

                          Table 5. Summary of the Struc_Add feature class.   

Table 6. Coded Domain for the Struc_Add feature class.

 

Roads Line Feature Class:

The Roads line class consisted of segments of each road that were used for the purpose of address geocoding. Its fields were very similar to the Struc_Add class, minus the St_Numb fields. It also contained LeftFrom/To and RightFrom/To fields. These were used to indicate address number ranges (Table 7).

Table 7. Summary of the Roads feature class.

 

Year Designation and Domains:

Designation of 1920

From year to year, it is unlikely there will be many changes in the Structures polygon. To minimize redundancy, this polygon feature class contained only unique structures from each decade. Specific information regarding these structures was contained in data tables, which were related as needed, to the polygon. The Struc_Year table used coded domains to code for each year, where 1920 will be coded as “3” to minimize storage space. Each structure was then listed for each decade it was present on the map. It is  likely than land use will change for a significant percent of structures between decades, therefore this attribute was stored in the Struc_Year table.

X/Y Domain Info

The X/Y Domain extent was defined by the approximate coordinates (in UTM NAD 83) of the city center +/- 10 km in each direction (Table 8). This allowed enough area to cover the entire city and allow the geodatabase to grow with the city in the future.

 Table 8. X/Y Domain Extent for feature classes.

---

References Cited:

Sloan, Jim

2007 Lesson 7/8/9/10: Final Project.  The Pennsylvania State University World Campus Certificate Program in GIS. Accessed 15 March 2007.

---

This document is published in fulfillment of an assignment by a student enrolled in an educational offering of The Pennsylvania State University. The student, named above, retains all rights to the document and responsibility for its accuracy and originality.