Land Records National Parcel Dataset: Technical Specification

Updated July 28, 2025

The Land Records National Parcel Dataset is a comprehensive, standardized geospatial dataset aggregating parcel boundaries and associated land ownership and taxation attributes from various local jurisdictions across the United States. This document outlines the detailed description and technical specifications for this dataset.

2. Data Content

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

The public version of the schema definition is available on Github: https://github.com/land-record/parcel-standard.

Column	Type	Constraints	Description
landrecid	STRING	REQUIRED	Universally unique ID (UUID) assigned to each parcel assigned by the Land Record database.
parcelid	STRING	REQUIRED	Parcel id assigned by the local administrative authority. AKA parcel number, APN, AIN, PID, and PIN. The format will vary.
parcelid2	STRING	NULLABLE	Alternate parcel id assigned by the local or state administrative authority. May be the same as parcelid if no alternate given.
geoid	STRING	REQUIRED	The full combined FIPS code of the jurisdiction in which the parcel resides (state fips + county fips).
statefp	STRING	REQUIRED	State FIPS code.
countyfp	STRING	REQUIRED	County FIPS code.
parceltype	STRING	NULLABLE	Parcel type identifier or description.
acctnum	STRING	NULLABLE	The assigned tax account number associated with this parcel / owner.
taxyear	INT64	NULLABLE	The year for which the provided tax assessments are levied.
usecode	STRING	NULLABLE	Land use code.
usedesc	STRING	NULLABLE	Description of the land use associated with this parcel.
zoningcode	STRING	NULLABLE	Zoning code associated with this parcel. These will vary in format.
zoningdesc	STRING	NULLABLE	Zoning description associated with this parcel. These will vary in format and length.
numbldgs	STRING	NULLABLE	Number of buildings located on the parcel. This includes primary residence as well as any accessory dwellings, garages, sheds, etc.
numunits	STRING	NULLABLE	Number of living units located on the parcel.
yearbuilt	STRING	NULLABLE	The recorded year that the primary building was constructed.
numfloors	STRING	NULLABLE	Number of stories/floors/levels in the primary building according to the local authorities.
bldgsqft	STRING	NULLABLE	Assessed area in square feet of the primary building.
bedrooms	INT64	NULLABLE	Number of known and assessed bedrooms in the main building.
baths	STRING	NULLABLE	Number of known and assessed bathrooms in the main building.
imprvalue	INT64	NULLABLE	Assessed value of improvements; typically this is the value of any and all buildings located on the parcel.
landvalue	INT64	NULLABLE	Assessed value of the surface land only. Does not include value of buildings, agriculture, or subsurface minerals or water.
agvalue	INT64	NULLABLE	Assessed value of any agricutlure or agriculture rights.
totalvalue	INT64	NULLABLE	Total assessed value, i.e. landvalue + imprvalue + agvalue.
saleamt	INT64	NULLABLE	Transaction amount of the most recent recorded sale that this parcel was a part of. Usually the parcel comprises the entire sale, but occasionally the sale amount can include other parcels.
saledate	DATE	NULLABLE	Transaction date of the most recent recorded sale that this parcel was a part of.
ownername	STRING	NULLABLE	Name of the recorded owner.
owneraddr	STRING	NULLABLE	Mailing address of the recorded owner, if known.
parceladdr	STRING	NULLABLE	Mailing address of the parcel.
legaldesc	STRING	NULLABLE	Legal description of the parcel; this is usually described in terms of lot numbers, plat numbers, book numbers, etc.
township	STRING	NULLABLE	Public Land Survey System (PLSS) township identifier.
section	STRING	NULLABLE	Public Land Survey System (PLSS) section identifier.
qtrsection	STRING	NULLABLE	Public Land Survey System (PLSS) quarter-section identifier.
range	STRING	NULLABLE	Public Land Survey System (PLSS) range identifier.
plssdesc	STRING	NULLABLE	Public Land Survey System (PLSS) full description.
plat	STRING	NULLABLE	Plat number or identifier
book	STRING	NULLABLE	Plat book number or name.
page	STRING	NULLABLE	Plat book page number or name.
block	STRING	NULLABLE	Plat block identifier.
lot	STRING	NULLABLE	Plat lot identifier.
updated	DATE	REQUIRED	Date of last known update of the source data. If not specified by the source provider or if it is unknown, this field represents the date of most recent acquisition of source data.
centroidx	NUMERIC	REQUIRED	x-coordinate (longitude) of geographic center POINT of the parcel in EPSG 4326. In rare cases the center may lie outside the parcel shape itself in the case of a 'C' shaped parcel.
centroidy	NUMERIC	REQUIRED	y-coordinate (latitude) of geographic center POINT of the parcel in EPSG 4326. In rare cases the center may lie outside the parcel shape itself in the case of a 'C' shaped parcel.
surfpointx	NUMERIC	REQUIRED	x-coordinate (longitude) of centermost POINT that is guaranteed to lie within the parcel's surface in EPSG 4326. This point will never lie outside the parcel.
surfpointy	NUMERIC	REQUIRED	y-coordinate of centermost POINT that is guaranteed to lie within the parcel's surface in EPSG 4326. This point will never lie outside the parcel.
geom	GEOGRAPHY	REQUIRED	MULTIPOLYGON of the parcel lot line boundary in EPSG 4326.
unmapped	JSON	NULLABLE	A JSON object containing any remaining unmapped fields from the source data. This object is optional and may not be included for all sources, counties, or export formats.

2.2. Notes on particular schema attributes

2.2.1. landrecid

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 landrecid lineage across vintages, so that a particular parcel maintains the same landrecid 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. parceltype

Non-standard attribute that some localities include to describe special cases. For example, certain localities specify “underground” parcels which lie below Earth’s surface, or distinguish parcels with mineral rights from others. This field is often unset (NULL).

2.2.3. 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.4. 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.5. 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.6. 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 address assigned by the locality (if it exists).

Conversely, it is also the case that a single parcel can have many addresses, as in the case of an apartment building. In these cases, the address assigned is 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.7. 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 plat, block, and lot if available. The land record database does not discriminate between these two 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 will always be NULL.

2.2.8. unmapped

This object contains source fields that were not mapped into the Parcel Standard Schema. There are many reasons that the fields may not have been mapped: they are superseded by data from a more reliable or complete source, or perhaps their quality was judged to be insufficient. Nonetheless, there are good reasons to retain this data in the final output in case it is useful.

Note: Not all output formats support JSON fields. In cases where native JSON support is not available in the output format, it will be stored as a JSON string, or simply set to NULL.

2.3. 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.

Each quarterly release contains any new data sourced between the release date of the current quarter and that of the previous quarter.

Q1 2025: April 1, 2025
Q2 2025: July 1, 2025
Q3 2025: October 1, 2025
Q4 2025: January 5, 2026
Q1 2026: April 1, 2026
Q2 2026: July 1, 2026
Q3 2026: October 5, 2026
Q4 2026: January 4, 2027
Q1 2027: April 5, 2027
Q2 2027: July 5, 2027
Q3 2027: October 4, 2027
Q4 2027: January 3, 2028
Q1 2028: April 3, 2028
Q2 2028: July 10, 2028

3. Data Processing and Standardization

3.1. Data Ingestion and Processing

Parcel data is collected from various authoritative sources, primarily county and municipal tax assessor offices, planning departments, and GIS departments. Data formats and source accuracy and update frequency vary widely.

3.2. Data Harmonization and Standardization

As of October 2024, the land record database maintains a catalog of data sources for over 3,000 US counties and all 50 states plus the District of Columbia that consists of over 78,000 unique data fields among 2.3+ million total distinct data fields among 14,500 catalogued data sources. Each of these data sources are merged with others that represent the same county, and each of the combined table’s fields is mapped and typecasted onto the target schema described in Section 2.2.

3.3. Quality Control and Validation

Multiple quality control checks are performed:

Geometric Validation: Checks for topology errors (e.g., self-intersections, sliver polygons, gaps between adjacent parcels) and invalid geometries.
Attribute Validation: Checks for missing values in critical fields, data type conformity, and adherence to domain constraints.
Spatial Accuracy Assessment: Visual inspection and comparisons against high-resolution imagery and known reference points to identify significant spatial discrepancies.
Temporal Consistency: Monitoring changes in parcel data over time to ensure updates are captured accurately.

4. Data Distribution

4.1. 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.

4.2. Output Data Precision

The output dataset is snapped to a 1e-7 uniform grid, which results in a precision of around 1cm at the relevant 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 across 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.

4.3. Coordinate Reference System

The dataset geometries are always delivered is EPSG 4326 (SRID=4326). This maximizes compatibility with popular database engines, such as:

PostgreSQL (with PostGIS)
Google BigQuery
Snowflake
Amazon Athena
DuckDB
and other engines.

4.4. File Formats

The dataset can be delivered in one of many formats, so choose the one that best suits your database engine, use case, and other business and technical requirements. Supported delivery formats include:

Shapefile (zipped)
(Geo)Parquet
GeoJSON (newline-delimited)
GeoPackage

5. Usage Recommendations

The per-county datasets range in size from very small (~1MB) to large (hundreds of MB) based on the size of the county. Likewise, the state datasets vary in size. The national dataset is quite large and dense, and performance challenges can arise even on modern database engines and modern hardware (as of 2024) and Cloud VMs.

Careful consideration needs to be made depending on your use case for the dataset, and what performance requirements you have.

5.1. Analytics Use Cases

For analytics-heavy use cases, BigQuery, Athena, and Geospark are known to work well with this dataset.

At around ~150 million rows, the dataset is on the upper end of what you’d normally expect PostgreSQL to handle in an analytical usage mode, but it is known to work well with the right hardware.

No matter the use case, make sure the data is properly indexed / clustered on the statefp, countyfp, and geom columns at minimum.

5.2. Online serving use cases

For online map and query serving use cases, PostgreSQL and DuckDB are known to work well with this dataset.

If hosting on a single VM or physical server, the following hardware and database configurations are recommended:

Hardware:

At least a 4th gen Xeon or 4th gen Epyc processor with many cores
Even better: Xeon 6 with MRDIMMs and P-cores
At least 64GB of the fastest RAM supported by your system
A fast SSD. NVMe drives designed for CDN content-serving that have high read rates tend to work well.

PostgreSQL configuration:

Version 15+
Utilize partitioning where feasible, e.g. partition table by state or county.
Configure hugepages if supported by your OS

To partition by state:

create table lr_parcel ( … ) partition by list(statefp);

Partition by county:

create table lr_parcel ( … ) partition by list(geoid);