A provider's headline refresh frequency is only a starting point.

Parcel data does not have one universal date. Local sources update on different schedules, individual attributes may represent different reporting periods, and matched or enriched datasets may have their own update cycles.

Ask:

• • • When was data for the geographies we care about last refreshed?
    • What does that refresh date actually represent?
    • Do important attributes have their own dates or reporting periods?
    • Are matched or enriched datasets refreshed separately?
    • How are differences in currency represented in the data?

For example, fields such as tax year or transaction dates can provide time context that a county-level refresh date alone does not.

What matters is whether the specific information your workflow depends on is current enough for the decisions you need to make.

🔗 Learn more: How should you evaluate parcel-data currency?

Geographic coverage and attribute coverage are different.

A provider may have parcel boundaries across your entire target geography while important fields such as ownership, mailing address or land-use information vary significantly between jurisdictions.

Ask:

• • • Are parcel boundaries available everywhere we need them?
    • How well are our critical fields populated in those places?
    • Are gaps concentrated in particular counties, states or markets?
    • Why do those gaps exist?
    • Would they materially affect our workflow?

Coverage gaps can result from local collection practices, public-record restrictions or redaction requirements. A low fill rate therefore does not automatically indicate poor-quality data.

🔗 Learn more: Why does parcel-data coverage vary, and what should buyers look for?

A field appearing in a schema does not mean it is meaningful for every parcel.

Both high and low fill rates can require context.

In a rural area where many parcels contain no structures, a building-related field may naturally have a low fill rate.

At the other extreme, a source may populate a field with sentinel values or meaningless placeholders, producing a high fill rate without providing useful information.

Ask:

• • • How is fill rate calculated?
    • Why might values legitimately be absent?
    • Are placeholders or sentinel values treated as populated data?
    • Can we inspect representative records behind the percentage?
    • Can we inspect the underlying values to understand what the fill-rate percentage actually represents?

Completeness should be evaluated alongside the meaning of the field, the source and the characteristics of the geography.

Provenance helps you understand what a value represents and what happened to it before it reached you.

Ask whether you can distinguish between:

• • • information supplied by an authoritative source;
    • information standardized by the provider;
    • information calculated or created by the provider; and
    • information matched from another dataset.

The provider should also document the source and processing status of important fields.

This matters because two similarly named fields can serve different purposes. A locally sourced value may preserve jurisdiction-specific meaning, while a standardized value may be better suited to comparison across many jurisdictions.

A provider should make it possible to understand not only where a value came from, but whether it has been preserved from the source, standardized, calculated or linked from another dataset before you decide how to use it.

Nationwide parcel data originates in thousands of local systems that were not designed around a single national schema.

A provider therefore has to decide what can be mapped into a common structure, what can be standardized and what source information should be retained.

Ask:

• • • Is the schema clearly documented?
    • Are field names and definitions consistent?
    • Can we distinguish source values from standardized values?
    • Are local values retained where they remain useful?
    • Does the documentation explain when different fields should be used?
    • Does the provider retain source values where standardization would remove useful local context?

For technical enterprise buyers, schema design becomes particularly important when parcel data needs to support recurring analytics, applications or integrations across many jurisdictions.

Ownership is a good example of why field names alone are not enough.

Local sources do not always structure owner information consistently. A government source may provide an owner name as one unstructured value rather than separate first- and last-name fields, making further parsing difficult without introducing assumptions.

Different ownership fields and datasets can also reflect different underlying records. For example, assessor ownership and recorder or deed ownership may update through different processes and answer different questions.

Ask:

• • • What source does the primary owner field come from?
    • Is the original source value preserved?
    • Has owner-name parsing or standardization been applied?
    • How well populated is ownership in our target geography?
    • How frequently is the underlying ownership source updated?
    • If more recent ownership information matters, does the provider offer recorder- or deed-based ownership in addition to assessor ownership, and does that dataset expose its own currency information?

🔗 Learn more: How should you evaluate parcel ownership data?

Geometry needs to be evaluated differently from ordinary attributes.

Most parcel boundaries originate with local government sources, and their positional characteristics can vary.

Aerial imagery should also be interpreted carefully. Both parcel geometry and imagery can contain spatial error, so visible misalignment does not establish which dataset is wrong.

Ask:

• • • Who created or maintains the underlying parcel geometry?
    • What validation is performed?
    • How are invalid polygons handled?
    • What happens when a larger shift, skew, rotation or other spatial issue is identified?
    • Does the provider reposition authoritative geometry simply to match imagery or another basemap?
    • Is the geometry appropriate for the precision our workflow requires?
    • What happens when a larger shift, skew, rotation or other spatial issue is identified?

GIS parcel data should not be treated as survey-quality data. Where exact legal boundary location matters, the appropriate survey or authoritative process should be used.

🔗 Learn more: How should you evaluate parcel boundary quality?

Property and public-record requirements vary between jurisdictions and can change over time.

A provider should be able to explain how it monitors those requirements and how changes are reflected in its products and processes.

Ask:

• • • What is your documented process for handling redaction requests or requirements?
    • How do you monitor changes to applicable local, state, federal or national laws?
    • How are newly enacted requirements incorporated into your products?
    • Where permission is required to use public-record data, how is that handled?
      
    • Can compliance requirements change which fields or datasets the provider makes available in a particular jurisdiction?

Compliance can directly affect product scope, not just internal legal processes.

The strongest data-quality claims are ones you can investigate.

Ask whether the provider makes available:

• • • field-level coverage information;
    • geography-level refresh information;
    • a documented schema;
    • source and lineage information;
    • processing methodology;
    • representative sample data; and
    • clear explanations of known limitations.
    • evaluation data delivered through the access method your production workflow is likely to use.

Sample data is particularly valuable because it allows your team to test the fields, structure and geographies that matter before making a broader commitment.

For a more technical Enterprise evaluation, also ask whether the provider can supply evaluation data through the delivery method you expect to use in production. Testing a downloadable file can tell you a lot about the data itself, but it does not necessarily tell you how an API, Feature Service or recurring bulk-data workflow will fit into your systems.

A transparent provider should make it possible to evaluate fit, rather than simply asking you to accept a generic claim of high-quality data.

Data quality is only part of the buying decision.

Once the dataset itself meets your requirements, consider how well the provider fits your technical and operational environment.

Ask:

• • • Can the data be delivered in the way our workflow needs, for example through bulk files, API, Feature Service or another appropriate method?
    • Does the provider support the scale and update model we need?
    • How flexible is the provider when requirements differ from a standard package?
    • What support is available during evaluation, implementation and ongoing use?
    • Is the documentation good enough for technical teams to work independently?
    • Does the commercial model make sense for the value and scale we need?
    • Can we evaluate the provider using the same type of access method we expect to use after purchase?

The best dataset on paper is of limited value if it is difficult to integrate, difficult to maintain or poorly supported once it reaches your organization.

Vendor comparisons become much more useful when every provider is assessed against the same requirements.

Start with your own workflow rather than each vendor's strongest marketing claim. Define what matters, request evidence and compare the answers consistently.

A practical evaluation should leave you able to answer:

• • • Does the provider have the information we need?
    • Is it available in the places we need it?
    • Do we understand where it came from and how it has been processed?
    • Is it current, complete and precise enough for our workflow?
    • Is it handled in accordance with the requirements that apply?
    • Can we verify the provider's claims ourselves?
    • Can we work effectively with both the data and the organization behind it?

Taken together, these criteria give you a much stronger basis for choosing a provider because the comparison reflects the data, workflow and operational requirements your organization actually needs to support.

That is also how real enterprise evaluations tend to work. Burns & McDonnell evaluated multiple parcel-data providers against criteria including coverage, accessibility and legal risk. Regrid ultimately fit its needs because the dataset combined nationwide coverage, consistent formatting, regular updates, flexible delivery options and alignment with its Esri environment.

You don't have to rely only on our claims when evaluating Regrid. We make many of the inputs in this guide available for you to inspect directly.

Check coverage and currency

Use our Coverage Explorer to review parcel coverage, refresh dates and field-level completeness in the counties that matter to your workflow.

🔗 Explore Regrid parcel-data coverage

Review the schema

Our parcel-schema documentation explains what individual fields mean, where they come from, how they have been standardized and when related fields may be more appropriate.

🔗 Explore the Regrid parcel schema

Inspect sample data

If you want to explore the dataset independently, our Data Store includes downloadable full-county samples in multiple formats. These include the Regrid Premium Schema, allowing you to inspect the fields, structure and values before committing to a broader evaluation.

🔗 Explore Regrid sample data

Review our methodology

Our documentation also explains how we source, standardize, refresh and process parcel data, including the steps we use to clean parcel geometry.

🔗 Explore our parcel-data methodology

Test the way you expect to work

For an Enterprise evaluation, start with the way you expect to use the data. Our team can provide relevant evaluation data through the delivery method that makes sense for your workflow — whether that's bulk files, Feature Service, API or another option.

That lets you evaluate not only the parcel records themselves, but how the data fits into the tools, pipelines, maps or applications your team expects to use in production.

🔗 Explore Regrid's enterprise delivery methods