The New Jersey Historic Preservation Office maintains and reviews information on the location, qualities, history, and regulatory history of Historical and Archaeological sites in New Jersey. In order to locate and use relevant information in NJHPO files for review of a specific location/area, two to five paper maps, and six or more file locations must be consulted. We have designed a GIS, using ArcView and Microsoft Access, that consolidates and overlays mapped site and report information, and stores the most current attribute information available, including regulatory review history, for the sites. Pilot conversion data entry has been completed for Gloucester County, and a pilot Planning Survey, including direct electronic delivery of data, is underway for Salem County.
Acquiring and maintaining knowledge about the historic architectural structures, landscapes and archaeological sites in a state is important in preserving our cultural resources. Since this knowledge has a strong spatial component, GIS provides an ideal framework for acquiring, maintaining and accessing this information. Collecting such information is one of the roles of Historic Preservation Offices in the various states. This paper describes a GIS pilot project for the New Jersey Historic Preservation Office (HPO).
The GIS pilot was funded by the New Jersey Department of Transportation with ISTEA funding. The GIS pilot was designed for geospatial data about two major categories of resources: 1) historic architecture and landscape, and 2) archaeological sites. In addition, the GIS design incorporated a project logging and tracking system to help HPO staff members manage their work flow, and a Report Catalog to assist in archiving and retrieving detailed information contained in reports. This paper focuses on the GIS design of the project.
The scope of work for the GIS Pilot included a requirements analysis, system design, data development, and hardware and software recommendations. The GIS Pilot was completed by a project team composed of members from Rutgers University, a consulting firm specializing in historic architecture, and the staff of HPO. Data development was completed in two phases: 1) a conversion of legacy data for Gloucester County (Rutgers team members), and 2) acquisition of new data for Salem County (architectural history consulting firm). The staff of HPO assisted throughout the project, particularly in the requirements analysis and system design phases.
The software used to complete the GIS Pilot includes ArcView 3.2, ArcGIS 8.1, ArcIMS, and Microsoft Access. Street files from GDT are used for address matching. Hardware acquired for HPO included Dell workstations, backup systems, an 11x17 format HP color laser printer and field data collection kits (digital cameras, laptops, Trimble GPS units).
Following the completion of the needs assessment and requirements analysis for HPO, the data structure was designed. The design reflects information requirements for Federal and NJ state regulatory review of cultural resources, and the work flow of project tracking within the Office. The design also reflects the need to bring in and store both: 1) converted legacy data from HPO files, and 2) new attribute data from new surveys and submittals. Some of the new information will be accompanied by GPS and shapefile data and some will not.
The overall design consists of separate database structures for Historic Architecture, Archaeology, Logging and Tracking, and Report Catalog. Spatial features are linked by primary key to those records. The details of the structure evolved through multiple design iterations over the course of converting legacy data (for Gloucester County). A few additional changes may be made upon feedback from the consultants doing a new planning survey (for Salem County).
We began with the structure for Historic Architecture. This has the most complex table relational structure of the four database structures. Figure 2 shows the conceptual GIS data model for Historic Architecture. The fundamental unit for historic architecture is the Property, which is the first type of feature described in a historic architectural survey. In our scheme it is the unit of historic ownership and/or function (this is a slightly different, more-restricted usage of the term "property" than in the National Register). Some examples are a residential lot (with its house and garage); a farm (with its farmhouse, barn, additional outbuildings, and associated fields); an industrial complex (with its buildings and railroad connection); a church lot (with its sanctuary building, yard, and associated cemetery). Information about the Property as a whole is stored in a Property table, with the Property ID auto-generated by Access and used as the primary key. This is used to link child subtables for location, bibliographic references, survey history, detailed Farm information (if applicable) and Eligibility assessment (for NJ and National Registers).
Each historic Property is mapped as a polygon wherever the available geographic information is sufficient to estimate boundaries within a few tens of feet. The Property ID from the Property table is used as the foreign key to join to the property attributes. In a few cases one Property may be represented by a multi-part polygon because areas that are related by ownership and function are not contiguous. A Property for which boundaries have not yet been defined is mapped as a point; either at the approximate location of the primary Element (common for legacy data), address-matched and offset a few feet from the street centerline (also common for legacy data), or at the intersection of the driveway with the street right-of-way (new GPS points). For legacy data, address-matches to street intersections are also used if other point information is not available. If location information is insufficient to map the Property as either a polygon or a point, it is assigned to a municipality polygon, or, if applicable, to a Historic District boundary polygon (see below). There are thus three separate shapefiles for Properties; Property polygon, Property point, and "Municipality" polygon. All shapefiles in the entire system carry a field coded for source of the feature, enabling the user to assess the quality of the location information.
Historic Properties contain Elements, which consist of Buildings, Structures (such as water towers, highways, canals), Objects (such as statues and fountains), Bridges, Industries (industrial buildings), or Landscapes (such as cemeteries, designed gardens), in our scheme. Reconnaissance surveys describe the property as a whole with brief notes about its included elements. Intensive level surveys include detailed descriptions of individual elements; and additional information for the property as a whole, especially if it is a farm. Intensive level information about Elements is stored in a complicated arrangement of a child table, with Property ID as the foreign key relating it to the Property table; and a series of grandchild tables. This arrangement allows the generation and storage of a unique Element ID and name(s) for each Element to be associated with a property (in the child table); and six different grandchild tables that store the attributes for each type of Element. There are additional grandchild tables that store information on people associated with the construction or rebuilding of the Element (designers, engineers, etc.), and on alteration dates of the Element. The Element ID is used as the foreign key to relate all of these records to the appropriate Element in the child table.
Elements are mapped as points if location information is available, or as polygons if sufficient mapping information is available. Thus there are two shapefiles for Elements, one for points and one for polygons. Element ID is used as the foreign key to join the records to Element attributes. Each shapefile record is also coded to reflect what type of Element it represents (Building, Structure, Object, etc.) In some legacy records, locations for Elements are available, but there are no Element IDs because the attributes do not include intensive level information and no Element records have been created. In these cases the Property ID is used as the foreign key to join to the Property attribute record. For legacy data it is common to have only location information or no spatial information for an Element. The goal for future data is to have surveyors map Elements, using a combination of field inspection and information from the Digital Orthophoto Quarter Quadrangle base maps. In most cases an approximate polygon should be achievable. More detail site maps, such as CAD drawings, where available, can be linked by file name to the attribute record for the Property.
After historic Properties have been surveyed, where appropriate, a Historic District may be defined. In our scheme, a Historic District is a collection of Properties (i.e., more than one property). The Historic District has its own boundary, which may coincide with Property boundaries in some places but not in others. Most Historic Districts, especially those based on concentration, linkage, or continuity of Properties will be represented by a single polygon. Districts based on association or function may be represented by multi-part polygon. Attribute information about the District as a whole is stored in the District table, and in child tables for location, bibliographic references, dates of Significance, survey work history, and Eligibility assessment. District ID is the auto-generated primary key for the District table and the foreign key for the child tables. It is also the foreign key to join the District polygon shapefile and the District attribute records. After a Historic District is defined, it is related to the attributes of its included Properties by the addition of the District ID foreign key to each Property attribute record.
The data entry forms for historic architecture are illustrated in Figures 3-5. Figure 3 shows the overall look of the interface for the set of forms. Figure 4 shows a portion of the form for Properties. Figure 5 shows a portion of the form for Elements.
The overall GIS structure for Archaeology is simpler than for Architecture, although the number of attribute tables is larger. Figure 6 illustrates the general scheme for Archaeology. Our "Property" and "District" terminology is similar to that above, but applies slightly differently. In the discussion below we use the word "site" to apply to any area of Archaeological interest. In our terminology for the GIS, an Archaeological Property is a single area that qualifies or could qualify as an Archaeological Historic Property under National Park Service guidelines. It contains or contained artifacts and/or features of significant Archaeological interest. At Phase I (reconnaissance) level of survey, basic attribute information about the Property is stored in the Archaeological Property table with a field for an auto-generated Archaeological Property ID as the primary key. Additional attribute information about the Property as a whole is stored in child tables for legal location, bounding coordinates, threats to the site, bibliographic references, different types of diagnostic artifacts, survey work history, and artifact collections from the site. Some of this information may only be available after more-intensive survey. One Property may have more than one type of diagnostic artifact recorded at an early stage of survey.
The scheme for storing survey work history for Archaeological Properties consists of a table for records of instances of survey of the Property (related to the Property table as its parent by Archaeological Property ID); and a grandchild table that stores information about individual survey workers. More elaborate information is gathered and stored concerning survey work on Archaeological Properties than for work on architectural Historic Properties because, in most cases, survey work on Archaeological sites has a direct effect of altering the site permanently in some way.
An Archaeological Property is mapped by either a point or a polygon, depending on the size of the site and the quality of assessment and location information. The point and polygon shapefile records are joined with the attribute records by using the Archaeological Property ID as a foreign key. The Smithsonian system identifier is a secondary ID. Because at least one point in Universal Transverse Mercator coordinates is required in order to obtain a Smithsonian system identifier for a site from the New Jersey State Archaeologist (New Jersey State Museum), most sites will have enough information reported to establish a point. However not every site involved in a regulatory process has had this identifier obtained for it, resulting in some sites with attribute information but vague or non-existent location information. From legacy data we also have some mapped Archaeological Properties with no attribute data.
If a site is surveyed at a more intensive level, and/or has extensive data recovery work performed on it (Generally Phase II or Phase III survey), the additional information about it goes into the Archaeological Property table and child tables listed above; and into one of three child Site Type tables, for Native American sites, Historic/Industrial sites, or Shipwrecks. Each Site Type table has grandchild tables related to it that store specific site information whose records are in many-to-one relationship to the Site Type table record. For example, the Historic/Industrial Site table has a grandchild table for types of materials found at the site.
At the more-intensive levels of survey, an Archaeological Property must be defined as only one Site Type. If a given area has significant artifacts and/or features of more than one Site Type, a second Archaeological Property must be defined. Its boundaries will overlap with those of the first Property, obviously, but in most cases will not be coincident. Both Properties should have defined boundaries and be represented in the Archaeological Property polygon shapefile. Each will have its own Archeological Property attribute record (and Archaeological Property ID).
After the description of Archaeological Properties in an area, an Archaeological District may be defined, if warranted. Definition of an Archaeological District is done in roughly analogous fashion to the definition of an architectural Historic District as described above (however, defined Archaeological Districts are rarer than architectural Historic Districts). Attribute information for the Archaeological District as a whole is stored in the Archaeological District table, with primary key Archaeological District ID; and in related child tables for legal location, bounding coordinates, bibliographic references, period(s) of significance of the District, and survey work history.
Individual Archaeological properties are included in the Archaeological District by entry of the Archaeological District ID into the appropriate field in the Archaeological Property table for each included Property. There is also a field in the Archaeological Property table for a Historic District ID, so that relationship can be recorded if the site falls within and is related to an architectural Historic District.
Archaeological Districts are mapped in the Archaeological District polygon shapefile, and individual records related by Archaeological District ID. In order to allow wider use of Archaeological site presence/absence information without compromising the security of sensitive sites, a quarter-mile presence/absence grid is constructed from the Archaeological Property shapefiles and Archaeological District shapefile.
The Historic Preservation Office also needs to track in-progress work according to geography, because work on the same area may be done by different people and/or companies for different agencies. In the past there has not been any straightforward way to relate these efforts to one another. There also has not been a simple way to report on upcoming statutory deadlines by project and worker. A Logging and Tracking GIS structure was designed to provide for these functions, as well as to store information and generate other reports required by the National Park Service, or others to whom NJ HPO is responsible, about review efforts by HPO. The general scheme for Logging and Tracking is shown in Figure 7.
When the first submission for a Project arrives at HPO, basic information about the Project is stored in the Project Attributes table, with an auto-generated Project ID as the primary key, and the Project is mapped as a point in a point shapefile with records related to the Project by Project ID. For each ostensibly-new Project, the process of mapping the Project location provides a check on whether the work is really part of a pre-existing Project at the same location. The Project table has two child tables, related to it by Project ID, that store many-to-one records of Agencies related to the Project and legal location of the Project.
As more information about a Project is developed, additional information is entered in the Project Attributes table, and the Project mapped in the Project polygon shapefile when a boundary can be defined. This additional information is generally developed in the course of one or more Project Actions.
The Project Actions table, with auto-generated primary key Action ID, is also in a child relationship to the Project Attributes table, with Project ID as the foreign key. Records of all Project Actions are stored in one table; however data entry is done via different interfaces depending on the Review type involved. Review type refers to the statute, regulation, or program under which the work falls. For example, all regulatory review work related to the involvement of Federal agencies or Federal funding in a Project that may affect historic cultural resources, is termed "Section 106 Reviews." The different Review type interfaces allow for a simplified, customized data entry format for each Review type; for automated entry of Review type code for each Project Actions record; and for easy viewing of sequential Project Actions for one Review type even if more than one Review type takes place on one Project (a common occurrence for big projects).
Each Review type has its own set of Action types, which are stored in a different lookup table for each Review type. The lookup tables are used to present choices for Action type entry in the appropriate Review type interface (and the Action-type-field entry in the Project Actions record). For each Action type record in each lookup table, there is a code, a verbal description of the Action type, and several other fields are also stored. The field for Action kind notes whether the particular Action is a submittal/response by HPO, an internal HPO process, an external process that HPO needs to track, or a submittal by HPO to an external person or group and the subsequent response. In addition to Action kind, each Action type record also has fields for statutory review periods, and possible outcomes of the Action. When an Action type is chosen via the Review type interface, the lookup table information is presented to the user, thus giving a prompt to the user for filling out deadline fields, for noting what work is required for the Review at any stage, and what additional information should be entered for the Project Actions record when the work is done. Because of the complexity of possible outcomes, and the frequency of changes in statutes and programs, this approach was deemed more practical than trying to automate more of the entries (deadlines, for example).
Related to the Project Actions table by Action ID are two grandchild tables, in many-to-one relationship to Project Actions on Action ID. These are the Project Documents table, which records any outgoing HPO documents related to a particular action; and the Project Conditions table, which records any restrictions HPO imposes as a condition to approval for a particular Project step. A great-grandchild table, Project Monitor Dates, relates to the Project Conditions table on Condition ID. Project Monitor Dates entries are used to track ongoing monitoring activity for Conditions that require it.
The final part of the table structure for the Project Logging and Tracking database is the Chrono table. This is an electronic replacement for the Log book kept by HPO to record all outgoing correspondence.
The Historic Preservation Office stores a large number of reports, most submitted as part of a regulatory review process for a particular Project. The final part of the GIS design stores information about these reports. Figure 7 shows a simplification of the design and relationships to Project Logging and Tracking.
A Report Catalog was constructed by Historic Preservation Office staff, in a separate effort from the rest of the GIS, and in consultation with the Endex project of the Department of Environmental Protection. The Endex project, an effort by DEP to construct a GIS-based catalog of environmentally-related gray literature for the state, is in process in partnership with the Rutgers University Library System.
For newly-mapped reports, each report is represented as a polygon in the Report Polygon shapefile. The polygon is related to the Report attributes by either the Report ID or the Shelf Code, depending on the needs of the user (bibliographic information or physical location of the paper copy, respectively). The polygon may be established by direct digitizing, by copying a Project Polygon, or it may be derived as a buffer around a linear Project entity such as a road or a pipeline. For the latter, the linear feature is also stored, in a Report Line polygon. For legacy data, these same shapefiles are used. However some legacy data is insufficient to establish a polygon, so a Report Point shapefile is used to map those reports.
Legacy data for one county (Gloucester County) was converted as part of the GIS Pilot. Conversion of data for 2700 architectural property records, 103 archaeological properties and 59 historic districts was completed by the Rutgers University team members. This section briefly describes the conversion steps for the spatial information.
The locational information for the legacy data have historically been recorded by HPO staff on paper USGS quad sheets (for Listed properties and districts, and those deemed Eligible for listing as a result of formal review). Property identifications (ID numbers and text description) are written in the margin of the sheets and locations are drawn directly on the sheets as points or polygons. Figure 8 illustrates the marginal notation of property identifications and Figure 9 illustrates the locational information drawn on the existing paper quad sheets. Historic sites described as part of a planning survey have varying location information; some are mapped on paper topo quads by the surveyor, some not. Additional sketch map information showing site details for specific properties and elements is contained in some of the submissions to HPO. Although these sketches often lack basic cartographic information, some were useful in identifying particular structures on a site. An example of a sketch map is shown in Figure 10. Some survey records include no map information.
The data conversion process for the legacy spatial data consisted of scanning and geo-referencing the existing paper quad sheets, heads-up digitizing of the properties and districts, and then refining the digitizing using Digital Orthophoto Quarter Quads (DOQQs), and in some cases, verbal descriptions or auxiliary map information. The polygons showing areas covered by regulatory survey reports were also digitized using scans of HPO-maintained paper maps and report information. An example of a digitized historic district, properties, and elements is shown in Figure 11.
Data development of new survey data for architectural and landscape resources is currently underway for Salem County. Consultants are completing field data collection using the new Access database collection forms and GPS units. The geographic features are then digitized and organized in conformance with the new GIS data model. The opening screen of the survey database is shown in Figure 12.
This paper has described the design of a GIS data model for historic preservation, the use of the data model in the conversion of legacy data, the acquisition of new survey data, and in the daily logging and tracking of projects within the HPO. Work is currently ongoing on two applications for HPO staff. One is a simple ArcView application for project intake information (see Figure 13). Another is an ArcIMS application that will allow staff to search by project name and location. Plans for continued data development include conversion of legacy data for listed properties and more new survey data collection.
