The hardest questions about a parcel dataset are often about the space between parcels. Do neighboring boundaries meet? Does one parcel cut into another? Is a thin overlap a real property interest, or a stray edge left by digitization? At LandRecords, answering those questions across a nationwide parcel layer is part of building data people can trust. It is also why we built postgis-cuda, an open-source way to run large spatial joins on a GPU from PostgreSQL.
Quality lives in the relationships
A parcel can be a valid polygon on its own and still be wrong in context. A boundary can overshoot the next lot and create a sliver of overlap. Two edges meant to coincide can leave a narrow gap. A stray vertex can turn a straight line into a spike that cuts across a neighbor. Conversely, a condominium may have multiple legitimate records on the same footprint. A useful quality check has to look at pairs of parcels and distinguish those cases, not simply count invalid shapes.
That means asking millions or billions of geometric questions: which parcels intersect, by how much, whether they only touch at a boundary, and which near neighbors fail to meet at all. The answers give our quality-control process a tractable list of candidates. A small positive intersection area can flag a sliver; an unexpected topological relationship can reveal an overshoot; a distance check can surface edges that nearly meet. We can then compare the flagged geometry with its source, neighboring records and imagery, fix stray edges introduced during processing, resolve a clear digitization error when the source evidence supports it, and rerun the checks. Where the evidence is inconclusive, we leave the boundary unchanged and flag it for review.
Put the expensive work where it belongs
Our CUDA engine keeps loaded geometry layers in GPU memory. A lightweight PostgreSQL extension sends SQL requests to a GPU daemon, which narrows candidate pairs with a spatial index and refines them with double-precision geometry calculations. The result is familiar spatial work in the database: intersection pairs and areas, point-in-polygon matches, topological relations, clustering, and distance joins.
We built it for our actual hardware and workload. In the published October 2026 benchmarks, one NVIDIA H200 NVL held 162 million U.S. parcels and 161 million address points in about 70 GB of GPU memory. With the layers resident, a nationwide five-meter parcel-to-parcel distance join examined roughly 1.3 billion matching pairs in 13.2 seconds in stats mode. Loading the full parcel layer takes minutes, so the advantage grows when the same resident geometry supports repeated checks.
The county-scale measurements show what that means for the spatial joins behind parcel QA and enrichment:
| Los Angeles County workload | Matching pairs | PostGIS | GPU | Speedup |
|---|---|---|---|---|
| Parcels × counties, intersection area | 2.42 million | 17.7 s | 7.7 ms | ~2,300× |
| Parcels × parcels, intersection area | 23.23 million | 61.5 s | 297 ms | ~207× |
| Addresses × parcels, point in polygon | 14.08 million | 13.3 s | 6.5 ms | ~2,000× |
These published October 2026 benchmarks compare PostGIS using 48 connections with computation on one NVIDIA H200 NVL after the GPU layers are loaded. GPU times exclude that one-time load and delivery of result rows through SQL; for example, loading the 2.4 million Los Angeles parcels took 2.38 seconds. The table reports measured workloads, not a promise that every query runs at those speeds.
We do things differently
Parcel vendors often look similar when compared by coverage alone. Our edge is what we can do with the geometry behind that coverage, and the efficiency with which we are able to produce our product. We can examine parcel relationships at the scale of a whole county or the country, vary a tolerance, inspect the exceptions, apply justified corrections, and check the result again. That is a stronger quality workflow than relying only on isolated polygon validity tests or occasional spot checks. It also helps with enrichment: the same spatial machinery can relate parcels to addresses, counties and other layers.
The GPU is one part of a larger system. Our processing pipeline acquires data from more than 3,200 jurisdictions, harmonizes their different schemas, merges and cleans geometry, enriches parcels with related data, and runs automated and human review before publication. We retain the source context and reviewable mapping logic because a fast spatial answer is only useful if we can explain and act on it. Our advantage is the combination of source-aware data work, high-memory GPU hardware, purpose-built spatial software and repeated quality checks at national scale.
No tool can make an uncertain source boundary survey-grade. But better tools let us find more of the suspicious geometry, investigate it faster, and verify corrections across the surrounding parcel fabric. That is the engineering behind a more dependable nationwide parcel dataset. Explore the code and benchmarks, or get in touch if you are building on parcel data.