How the Parcel Atlas Is Built, Verified, and Maintained

This page describes how the UrbanKit Parcel Atlas is built, how endpoints get verified, and where the atlas falls short. It is a process statement, not a marketing page. If you are a planner, a GIS analyst, or a developer deciding whether to trust this data, the specifics below are what you need.

How a county enters the atlas

Every county in the atlas went through the same four-step process before its endpoint appeared on a page.

Discovery. The starting point is the county's ArcGIS REST services directory, usually reachable at a URL like https://gis.<countyname>.gov/arcgis/rest/services. For counties that publish through ArcGIS Hub or their state's open data portal, the Hub search for [County Name] parcels feature layer turns up hosted FeatureServer endpoints. For counties running their own ArcGIS Server, a Google search for "[county] arcgis rest services parcels" usually hits the services directory within the first two results. Some counties go through a county-by-county review of their GIS department's public-facing pages.

Endpoint identification. Once a parcel service is found, the layer URL gets resolved to a specific layer index, typically /FeatureServer/0 or /MapServer/0. The distinction matters; a URL ending in /FeatureServer without the layer index returns service metadata, not queryable features. The FeatureServer vs MapServer explainer covers this in detail. Both types work for attribute queries if the layer has supportsQuery: true; the atlas records which type each county uses.

Field schema capture. Appending ?f=json to the layer URL returns a fields array listing every attribute the county exposes. The atlas records the searchFields relevant to parcel lookups: the parcel identifier field (variously named PIN, PIN14, APN, PARCEL_NUMBER, PARID), the owner-equivalent field if present (TaxName, OWNER_NM, BILLNAME), and the situs address field. Not every county exposes all three. Kane County, IL exposes TaxName on its public REST layer; Cook County, IL does not expose owner names at all on the public layer.

Liveness probe and encoding. Before a county goes live, the endpoint gets a manual liveness check: HTTP status 200, response shape confirms features array, expected fields present. Passing counties are encoded as a single JSON record in public/data/atlas/<state>.json. The site-wide index.json is regenerated from all state files. That data lands in prerendered HTML via react-snap at build time; the atlas pages do not make runtime fetch requests to county servers.

How stale endpoints get caught

County GIS servers go down, reorganize their services directory, rename layers, or drop fields after a software upgrade. The atlas runs a GitHub Actions liveness check on a weekly schedule (every Monday at 13:00 UTC) to catch these regressions before they become silent failures on county detail pages.

The workflow, at .github/workflows/atlas-liveness.yml, fetches every endpoint in the atlas and checks three things: HTTP status 200, a valid JSON response body with a features or fields key, and the presence of the expected search fields recorded at intake. If any of those fail, the workflow opens a GitHub issue tagged atlas-liveness with the full report.

This surfaced real problems. In May 2026, a liveness run (issue #51, filed 2026-05-18) flagged six endpoints as unreachable. A re-run on 2026-05-24 resolved all six as transient outages. Earlier, a schema drift on Oregon's Multnomah County layer — the PROP_TYPE field disappeared after a county GIS update — was caught and corrected with a commit that removed the field from the atlas record. The GitHub repository is the public audit trail for these corrections.

Liveness checks catch HTTP-level failures and field disappearances. They do not catch data quality drift inside a field. An assessor's office that starts populating the owner field with legal entity names in a different format won't trip the liveness check. That kind of drift only surfaces through user reports.

How counties get added and corrected

New counties enter the atlas two ways: through ad-hoc discovery during research for articles or tools, and through the contact form when someone emails or messages with an endpoint they found. There is no automated crawler pulling county GIS directories in bulk. Discovery is manual, which is slower but catches the edge cases a bulk scraper misses. Some counties publish their parcels under a service named Assessor or TaxParcel rather than Parcels.

When an error gets reported (a wrong URL, a field name that changed, an endpoint that moved), corrections flow through a single source of truth: the atlas-data source files at public/data/atlas/<state>.json. A corrective commit to that file triggers the prebuild chain: sync-prerender-routes updates the react-snap include list, regen-atlas-sitemap regenerates sitemap.xml, generate-atlas-pdf rebuilds the lead-magnet PDF, and sync-indexnow queues the changed URLs for fast recrawl. Every downstream derived file updates automatically from the source correction. State hub pages, county detail pages, the @urbankitstudio/atlas npm package, and the sitemap all stay in sync.

The stance on endpoint quirks is to document them honestly. Cook County's public REST layer publishes blank owner names. The Illinois Judicial Privacy Act lets judges redact their home parcels from public records. Some California counties suppress owner names for parcels where the owner filed under Government Code section 6254.21. These facts appear on the relevant county pages, not papered over with vague "data quality may vary" disclaimers. The honesty is the methodology.

What the atlas does not do

The atlas is an index of county REST endpoints, not a parcel data product. Understanding the distinction prevents a specific category of frustration.

It is not an ownership lookup tool. The atlas documents where county parcel records live and which fields those endpoints expose. The Parcel Lookup tool queries those endpoints directly, but the query goes to the county's own server. For normalized, cross-county parcel data with consistent field names and reliable owner records, Regrid is the right product. They license and standardize assessor data; we index the raw endpoints.

It is not real-time. Each county's data freshness depends on that county's reassessment and republication cycle. Most Illinois collar counties reassess annually. Cook County reassesses on a triennial triad cycle, which means any given parcel's assessed value and owner-of-record can be one to three years stale depending on which triad the parcel sits in. No atlas entry claims to reflect today's ownership; it reflects the county's most recently published REST layer.

Coverage is not exhaustive. As of 2026-05-24, the atlas covers 117 counties across 39 populated states. Many smaller rural counties do not expose public REST layers. Their parcel data sits in Tyler Technologies' iasWorld or Devnet's hosted portal, behind a vendor authentication wall. Those counties are not in scope until they publish a public endpoint. The atlas covers the counties where finding the ArcGIS parcel layer URL yields a working public endpoint.

No PII is stored. The atlas indexes where county parcel records live, not the records themselves. No owner names, addresses, or parcel identifiers flow through or get stored on UrbanKit Studio's servers. When you use the Parcel Lookup tool, your query goes directly from your browser to the county's ArcGIS server. The response comes back to your browser. Nothing passes through or gets logged here.

Who is behind this

UrbanKit Studio is operated by Leo Yong. The atlas exists because no commercial product offers an honest open index of county REST endpoints with field-schema documentation. Regrid sells normalized parcel data, which is a different and more expensive product. The index of where the raw endpoints live, with field names documented and quirks noted, has no equivalent in the public GIS tooling space.

The frustration that produced this was specific: trying to do public notice work across multiple Illinois collar counties and spending an hour per county figuring out which ArcGIS service had the parcel layer, which field name the county used for the owner, and whether the endpoint returned owner data at all or gave back blanks. That hour-per-county friction applies to every planner, paralegal, and GIS contractor who touches parcel data. The atlas is the output of solving that problem for my own work and publishing the results.

Funding is AdSense plus, eventually, an optional paid tier that removes ads. No data-licensing arrangements, no county relationships, no affiliate links to county vendors. The AdSense application is currently in re-review after a "Low value content" rejection in May 2026. This methodology page is part of that response.

Where the atlas is going

The immediate roadmap is coverage. The current 117 counties across 39 states covers the major metro areas and the Illinois collar county cluster that drives most of the search traffic, but it misses most Tier-2 metros and nearly all rural counties that do have public REST layers. The next batches expand by state, starting with states where ArcGIS Hub publication is widespread and field schemas are consistent enough to document cleanly.

Field schema documentation will deepen. Right now the atlas records which fields exist; future entries will include sample query patterns, notes on field format quirks (the 14-digit Cook County PIN format versus 10-digit collar county variants, for example), and links to the county assessor's portal for data that the REST layer doesn't expose. The county owner-name query guide covers some of this already; the atlas itself will carry more of it county by county.

The @urbankitstudio/atlas npm package mirrors the website data in a structured format for developers building county tools. It is currently at v0.3.0 and bumps with each data batch. Pull requests for new counties and endpoint corrections are welcome at the GitHub repository.

Open to community contributions: if you know a county that publishes a public parcel REST endpoint that is not in the atlas, the contact form is the right place.

Contact and corrections

Found a wrong endpoint? A field name that changed? A county that should be in the atlas but isn't? Use the contact form. Corrections that verify out go into the atlas-data source and propagate through the full build chain within one deploy cycle.