The dataset consists of geometric features representing parcel boundaries and a set of attributes that describe each parcel. Polygons representing the boundaries of individual land parcels for purposes of tax assessment for the jurisdiction in which they reside. These geometries are derived from digitized cadastral maps, surveys, recorded deeds, and legal descriptions of the parcel.

2.1. Schema Definition

2.2. Notes on particular attributes

2.2.1. lrid

This column is guaranteed to be universally unique across the entire nationwide dataset, including within counties. It is an RFC 4122 UUID type that uniquely identifies each parcel across space, but not time.

Efforts are made in the landrecords database to maintain lrid lineage across vintages, so that a particular parcel maintains the same lrid over time as new versions of the dataset are produced. While this process is reliable, it is not perfect. Moreover, parcels regularly change shape as new digitization methods are used by assessors, and parcels are occasionally subdivided or joined to form entirely different parcels, and the lineage to the ancestor parcels is not always ascertainable.

2.2.2. usecode / usedesc

Localities define their own land use codes, but in most cases, these attributes are mapped to the LBCS (Land-based Classification Standards). In cases where the locality defines their own standard that does not align with LBCS, or the data is unavailable, usecode and usedesc may deviate from the LBCS.

2.2.3. zoningcode / zoningdesc

Like usecode, zoningcode is locality-specific. Unlike usecode, there is no nationally agreed-upon standard that all zoning codes and descriptions can be mapped to. Since specific zoning codes only have semantic value within the borders of a particular county (or city or other jurisdiction), zoning codes are kept in the format provided by the county, to the degree they are provided.

2.2.4. numunits / numfloors

This data is lifted directly from the source data when it is available, but it is often missing from source datasets. As a result, they are often estimated.

numunits is often estimated based on the number of mailing addresses associated with a parcel, provided there is at least one building on the parcel. Likewise, numfloors is rarely available in the source data, but can occasionally be estimated based on the known or modeled height of the main building. (The “main” building is whichever building on the parcel has the largest internal usable area measured in square feet).

For example if the building footprint is 1000sqft on the surface, has a total usable area of 1800sqft, a height of 21 feet, and is zoned residential, a reasonable conclusion is that this is a 2-story building, i.e. numfloors=2. The land records database will derive these data in circumstances such as this when there is a high degree of confidence.

2.2.5. parceladdr

Usually, the primary parcel address is that which, when written on the front of an envelope, would reach a mailbox located on the parcel grounds. But this is not always the case. Many localities assign addresses to parcels that no letter can ever reach. In these cases, the land records database prefers the physical address assigned by the local authority if it is made available.

Conversely, it is also the case that a single parcel can have many addresses, as in the case of an apartment building or commercial strip mall. In these cases, the address assigned is either 1) provided by the taxation or appraisal authority that has jurisdiction over the parcel, or 2) that which is closest to the centroid of the parcel, and in most cases, any unit number will be removed. The number of addresses associated with a parcel is shown indirectly in the numunits column of the parcel record.

2.2.6. legaldesc / plssdesc

A core historic function of the “county” unit of government is to record deeds and collect property taxes. Deeds are recorded by the county to indicate ownership of parcels, and as part of the deed is a “legal description” of the parcel in question.

Some counties publish the full physical legal description, which involves using the PLSS (Public Land Survey System) to describe the exact boundary and location of the parcel. Others describe simply the parcel’s filing location in the book of deeds, e.g. BOOK A2 PAGE 97 and its components will be stored in the columns book and page. Additionally, these recorded pages may have a map attached, and will be designated by block, and lot if available. The land record database does not discriminate between these various approaches, and will record the provided “legal description” in the legaldesc column, irrespective of the format.

On the other hand, the plssdesc will always contain a standardized PLSS description when it is available. 30 states utilize PLSS to describe the location and bounds of parcels, and its components separated into the columns for section, quarter section, range, and township. In the 20 states where PLSS is not used, plssdesc, range, section, and qtrsection will always be NULL.

2.2.7 cooling, heating, and heatfuel

Heating, heatfuel, and cooling values will fall into one of the following enumerated values.

heatfuel — primary fuel source for the heating system:

heating — heat-distribution / system type:

cooling — cooling / air-conditioning system type:

2.2.8 accesstype, parceltype, and ownertype

accesstype and parceltype are most informative for protected lands, parks, and other publicly-managed parcels — privately-owned residential and commercial parcels generally fall through to PRIVATE / UNKNOWN. ownertype is populated for every parcel and describes the legal nature of the entity recorded on ownername, independent of the parcel's jurisdiction.

accesstype — public physical access to the parcel:

parceltype — ownership / management category of the parcel:

ownertype — legal nature of the entity recorded on ownername:

2.3. Versioning and Updates

2.3.1. Update Schedule

The National Parcel dataset is updated quarterly. Not all counties publish their source data at this interval, but all are checked by the land records database to pull, harmonize, and a merge updates if there are any.

2.3.2. Versioning

Each dataset includes the column lrversion which is set for each parcel and indicates the landrecords dataset release version. This is distinct and separate from the updated column which indicates the date of last source update or acquisition.

2.4. Source Data Precision

Geometric precision varies based on the original source data (e.g., surveyed vs. digitized from aerial imagery). There is no standardized or reliable way of ascertaining data accuracy from a particular source – the data provided by a county serves as the authoritative source of parcel/tax information for that county, and Land Records does not attempt to improve upon the county’s own methods of data collection and digitization.

2.5. Output Data Precision

The output dataset is snapped to a 1e-7 uniform grid, which results in a precision of around 1cm at most North American latitudes. Each vertex is snapped to the grid point which is closest to the underlying source data while preserving topology of the original geometry.

A large proportion of source data in the United States was collected and subsequently digitized against the NAD83 datum. The output datum however, is WGS 84. The typical, off-the-shelf transformation tools utilized by Land Records to transform geometries between these datums are usually accurate within a meter or so, but this varies by latitude.

100% accuracy in transforming between NAD83 and WGS84 would require taking into account the exact time at which the original data was collected, the methods used, and the subsequent tectonic plate drift that has occurred in the meantime. If this is a requirement for your use case, more details are available in this paper: Transformations between NAD83 and WGS84. See also this open-source implementation in C++: https://github.com/SonicScholar/trans4d-cpp.