1. Introduction

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

Column	Type	Constraints	Description
`lrid`	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.
`taxacctnum`	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`	INTEGER	NULLABLE	Number of known and assessed bedrooms in the main building.
`halfbaths`	INTEGER	NULLABLE	Number of known and assessed half bathrooms in the main building.
`fullbaths`	INTEGER	NULLABLE	Number of known and assessed full bathrooms in the main building.
`imprvalue`	BIGINTEGER	NULLABLE	Assessed value of improvements; typically this is the value of any and all buildings located on the parcel.
`landvalue`	BIGINTEGER	NULLABLE	Assessed value of the surface land only. Does not include value of buildings, agriculture, or subsurface minerals or water.
`agvalue`	BIGINTERGER	NULLABLE	Assessed value of any agricutlure or agriculture rights.
`totalvalue`	BIGINTEGER	NULLABLE	Total assessed value, i.e. landvalue + imprvalue + agvalue.
`assdacres`	FLOAT	NULLABLE	Assessor-specified acreage under assessment. May be different the calculated area.
`calcarea`	FLOAT	REQUIRED	Calculated area of the parcel geometry in square meters.
`saleamt`	BIGINTEGER	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 street address of the recorded owner.
`ownercity`	STRING	NULLABLE	Mailing address city of the recorded owner.
`ownerstate`	STRING	NULLABLE	Mailing address state of the recorded owner
`ownerzip`	STRING	NULLABLE	Mailing address postal code of the recorded owner.
`parceladdr`	STRING	NULLABLE	Physical street address of the parcel.
`parcelcity`	STRING	NULLABLE	City in which the parcel is located.
`parcelstate`	STRING	REQUIRED	State in which the parcel is located.
`parcelzip`	STRING	NULLABLE	Postal code 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.
`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.
`lrversion`	STRING	REQUIRED	Version of this dataset in the form YEAR.QUARTER, e.g. 2025.1 for the first quarter of 2025.
`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`	GEOMETRY	REQUIRED	MULTIPOLYGON of the parcel lot line boundary in EPSG 4326.

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.3. Versioning and Updates

2.3.1. Update Schedule

The National Parcel dataset is updated quarterly on the first monday of each third month beginning January. 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.

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 December 2025, the land record database maintains a catalog of data sources for over 3,200 US counties and all 50 states plus the District of Columbia and Puerto Rico. 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.

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. (This is where we use our human eyeballs and point them toward QGIS to see if anything looks “off”).
Temporal Consistency: Monitoring changes in parcel data over time to ensure updates are captured accurately.
Statistical Congruence: Many corrections are made based on statistical analyses of the datasets and the patterns of individual attributes and attribute categories.

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

4.3. Coordinate Reference System

The dataset geometries are always delivered in 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. Published 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.

4.4.1 Instant Downloads

The following formats are produced automatically with quarterly releases and are available for download immediately after purchase:

Shapefile (zipped)
GeoPackage

4.4.2. Custom Downloads

The following formats can be produced upon request:

GeoJSON (newline-delimited)
Geodatabase
pg_dump file

4.5. Published Web Services

The dataset is also made available to customers as OGC (WMS, WFS, etc) web services.

Fun fact: this is the same service that powers our data explorer! It is a MapLibre source configured like so:

yourAuthToken = ...;
map.current = new mapboxgl.Map({
    style: {
        version: 8,
        sources: {
            parcel_us: {
                type: 'raster',
                scheme: 'tms',
                tiles: ['https://api.landrecords.us/pro/gwc/service/tms/1.0.0/pro:parcel_us@EPSG:3857x2@pbf/{z}/{x}/{y}.pbf'],
                tileSize: 512
            }
        }
    },
    transformRequest: (url, resourceType) => {
        if (resourceType === 'Tile' && url.startsWith('https://api.landrecords')) {
            return {
                url: url,
                headers: { 'Authorization': 'Bearer ' + yourAuthToken }
            }
        }
    }
});

4.5.1. Parcel Coverage Map Service

We publish our coverage map as a web service for use in your applications. This is the same service that powers our public website at http://landrecords.us/products. It contains information about parcel coverage, as well as coverage for selected attributes.

County Coverages: https://api.landrecords.us/pro/gwc/service/tms/1.0.0/pro:county_coverage@EPSG:3857x2@pbf/{z}/{x}/{y}.pbf?token=<TOKEN>
State Coverages: https://api.landrecords.us/pro/gwc/service/tms/1.0.0/pro:state_coverage@EPSG:3857x2@pbf/{z}/{x}/{y}.pbf?token=<TOKEN>

4.5.2. QGIS: Configure in a WMS/WMTS Connection

You can easily load the Nationwide Parcel layer into QGIS.

First, Create a New WMS/WMTS Connection.

Then configure the new connection by pointing to the Landrecords API endpoint (api.landrecords.us), and setting the Authorization token provided after signup:

https://api.landrecords.us/pro/gwc/service/wmts

https://api.landrecords.us/pro/wms

Now you will see all the layers available to you in the Browser:

4.5.3. QGIS: Configure in an XYZ Tile Layer Connection

Create a new XYZ Connection:

Configure the connection with the Landrecords API endpoint.

Note the {-y} parameter. This is required for proper functionality in QGIS.

This example connects to the EPSG:3857 projection. You can use EPSG:4326 as well.

https://api.landrecords.us/pro/gwc/service/tms/1.0.0/pro:parcel_us@EPSG:3857x2@png8/{z}/{x}/{-y}.png8

https://api.landrecords.us/pro/gwc/service/tms/1.0.0/pro:parcel_us@EPSG:4326x2@png8/{z}/{x}/{-y}.png8

Set the Authorization header to include the API key that was provided to you after signing up for the hosted web service.

Click Save, and now you’re ready to add this layer to your project.

4.5.4. Secure Parcel Layer Web Services

Visit https://landrecords.us/enterprise-web-service to learn more.

5. Bulk file usage Recommendations

The per-county datasets range in size from very small (a few MB) to large (several GB) based on the size of the county and the number of attributes available. Likewise, the state datasets vary in size. The national dataset is quite large (100GB+ compressed, 250GB+ on disk), and performance challenges can arise even on modern database engines and modern hardware (as of 2026) 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, DuckDB PostgreSQL + PostGIS are known to work well with this dataset. The more RAM you have the better: we recommend 128GB minimum.

At 155+ million rows, the dataset is on the upper end of what you’d normally expect a standard PostgreSQL installation to handle in an analytical usage mode, but it is known to work well with the right hardware and postgresql.conf settings.

No matter the use case, make sure the data is properly indexed / clustered on the geoid and geom columns.

5.2. Online serving use cases

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

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

5.2.1. Hardware Recommendations

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

5.2.2. Cloud VMs

Take special care to provision sufficient disk IOPS for usage of this dataset. This may require provisioning a larger-capacity drive than strictly necessary for data storage.
SSD persistent disk is strongly recommended.
Likewise for the hardware recommendations, at least 64GB of RAM is recommended for best performance for most use cases.

5.2.3. PostgreSQL configuration

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

Partition by state/county:

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

Frequently Asked Questions

How quickly is the parcel dataset download delivered?

For state and county dataset purchases, you will get access to the file download immediately after purchase.

For the nationwide dataset, you will receive an email with access instructions within 24 hours after your purchase.

What data formats do you support?

We support instant downloads for Parquet and Geopackage. If you need a different format, let us know! We’ve delivered everything from EWKT+CSV files to raw postgres data dumps. We’re here to support you.

Do you offer additional data layers other than Land Parcels?

We believe there’s power in focusing on doing one thing, and doing it well. We do not offer any other data layers at this time, but if there’s something you’d like to see added to the current dataset, please contact us and let us know.

Documentation