Is polygon POI always better than centroid-plus-radius?

For dense retail, multi-tenant buildings, and mixed-use blocks — yes, polygon is strictly better because it doesn't bleed visits between neighboring merchants. For isolated big-box retail with large parking lots, centroid-plus-radius is acceptable and much cheaper to source. GSDSI's POI & Geofencing product ships polygon-primary with centroid fallback so buyers can choose per use-case.

How often should a POI file be refreshed?

Monthly at minimum. US retail establishment churn runs at ~8–10% per year per Census Business Dynamics Statistics, so a file refreshed annually will have 8–10% stale records within 12 months — enough to materially distort foot-traffic reads. Every record should carry opening/closing-date provenance so buyers can filter stale records at query time.

How does POI quality affect foot-traffic analytics?

POI quality is the hidden determinant. Most foot-traffic accuracy failures are POI failures, not panel failures. A store with a misplaced centroid will misread parking-lot traffic; a multi-tenant building without tenant-level cut-outs will mix customer categories; a stale file will count visits to closed stores. See why POI data quality makes or breaks foot-traffic analytics for the upstream framing.

What is the "same address, different business" problem?

When multiple merchants operate at the same street address (a coffee shop and a dental practice in the same mixed-use tower, for example), an address-level POI file collapses them into one record. Downstream foot-traffic reads then mix customer categories and become unusable. The fix: tenant-level polygon cut-outs plus NAICS primary codes per tenant — but that requires field-survey-quality POI sourcing, which is expensive to build and maintain.

POI Data Quality: Polygons, Centroids, Multi-Tenant

Most foot-traffic accuracy failures are not panel failures — they are POI failures. Buyers instrument a mobility vendor, run a foot-traffic read on a chain, and the number comes back wrong. Nine times out of ten the mobility signal is fine; the POI record that defined the geofence was wrong. This piece is the working diagnostic — what high-quality POI data actually looks like, where the failure modes hide, and which procurement questions surface them before you sign. For the upstream framing, see why POI data quality makes or breaks foot-traffic analytics, and for the panel-side companion, foot-traffic panel sizing.

Key Takeaways

Polygon fidelity beats centroid-plus-radius for any store in a multi-tenant building, strip mall, or dense urban block — radius-only geofences silently bleed visits between neighboring merchants.
Centroid placement errors are the single largest source of false-positive visits — a centroid placed on a building rooftop rather than at the retail footprint will misread parking-lot traffic as store visits.
The "same address, different business" problem (two businesses at 123 Main St) requires NAICS classification + tenant-level polygon cut-outs — address-level POI files cannot resolve it.
POI refresh cadence matters: US retail closures track Census Business Dynamics Statistics at roughly 8–10% of establishments per year — a stale POI file will count visits to closed stores.
Buyers should ask vendors for polygon area in square meters, centroid coordinates, NAICS primary code, and opening/closing provenance on every record — if any of those are missing, the file is legacy-quality.

Polygon Fidelity vs Centroid-Plus-Radius

The foundational POI architecture choice is polygon versus centroid. A polygon is a closed geographic shape (usually a GeoJSON `Polygon` or `MultiPolygon`) that traces the actual building or leasehold footprint. A centroid is a single lat/long point paired with a radius (typically 50–150m) to form a circular geofence. Polygons are strictly better for accuracy: they trace the real footprint, they handle non-rectangular buildings, and they don't bleed across property lines. Centroid-plus-radius is cheaper to source, easier to maintain, and fine for isolated stores with large parking lots — but it breaks in three common contexts: multi-tenant buildings, strip malls with shared parking, and urban blocks where adjacent buildings house different merchants. GSDSI's POI & Geofencing product ships polygon-primary records with centroid fallback, so buyers can choose resolution per use-case.

Where Centroid Placement Errors Hide

Even polygon-primary POI files carry centroids — and those centroids are used when a downstream tool needs a single representative point (a pin on a map, a distance-to-nearest-competitor calculation, a radius-based fallback). The failure mode: centroids placed at the geometric center of the building footprint can land on a rooftop rather than at the customer-facing entrance. For big-box retail, that's fine. For a strip-mall tenant whose entrance faces the parking lot while the geometric center of the building falls on the opposite side, the centroid is 30–50m away from where the customer actually enters — and every mobility signal captured in the parking lot gets attributed to the wrong neighbor. The right architecture: centroids placed at the customer-facing entrance (when resolvable) with polygon override for the full visit check. Ask vendors how they generate centroids — building-footprint center, entrance location, or parcel center — and push back on anything that isn't entrance-aware.

The "Same Address, Different Business" Problem

This is the hardest POI problem in dense retail. A mixed-use tower at 123 Main Street houses a coffee shop on the ground floor, a dental practice on the second floor, and offices on floors 3–12. An address-level POI file collapses all of these into one record ("123 Main Street, Anytown"). A foot-traffic read against that single record mixes coffee-shop customers, dental patients, and office workers — useless. The fix requires two things:

Tenant-level polygon cut-outs that trace each storefront footprint within the building (coffee shop polygon covers only the ground-floor retail footprint; dental polygon covers only the second-floor suite; office polygons cover everything else).
NAICS primary code per tenant so downstream tools can filter by category — coffee-shop visits (NAICS 722515) are not office visits (NAICS 523930).

This level of resolution requires field-survey-quality POI sourcing or cross-references to building management / Census NAICS + tax-parcel datasets. It is expensive to build and maintain. Buyers paying for foot-traffic on urban or mixed-use retail should verify tenant-level resolution before signing — and if the vendor cannot demonstrate it, the reads will be unusable in dense-retail contexts.

Refresh Cadence and the Closure Problem

POI quality is a function of recency as well as resolution. US retail establishment churn runs at roughly 8–10% per year per Census Business Dynamics Statistics — meaning a POI file refreshed annually will have 8–10% stale records within 12 months, growing to 15–20% within 24 months. Stale records create two failure modes: false-positive visits (foot traffic counted at a closed store) and missed visits (new stores not in the file). The right architecture: monthly refresh cadence at minimum, with opening/closing-date provenance on every record so buyers can filter stale records at query time. GSDSI's POI & Geofencing product carries opening/closing-date fields and a rolling monthly refresh; GSDSI's Real Estate Data product provides the commercial-property layer that anchors POI governance.

POI Procurement Diagnostics

A short working checklist buyers should run before licensing any POI file:

What percent of records are polygon-primary (GeoJSON Polygon/MultiPolygon) versus centroid-plus-radius? Anything below 70% polygon-primary is legacy-quality for dense retail.
Where are centroids placed — building-footprint center, customer-facing entrance, or parcel center? Entrance-aware centroids are the right answer.
How are multi-tenant buildings handled — tenant-level polygon cut-outs or single-address collapse? Single-address collapse is unusable for mixed-use contexts.
What is the refresh cadence and what opening/closing-date provenance is on each record? Monthly-or-better with date provenance is the right answer.
What is the NAICS coverage rate — what percent of records carry a primary NAICS code? NAICS coverage below 95% means significant categorical filtering gaps downstream.

Buyers who run this checklist routinely discover that POI files marketed as "comprehensive" are actually address-level, centroid-only, with annual refresh — legacy-grade for most modern use-cases. The checklist is cheap to run and cheap to score; vendors should welcome it.

Frequently Asked Questions

Is polygon POI always better than centroid-plus-radius?: For dense retail, multi-tenant buildings, and mixed-use blocks — yes, polygon is strictly better because it doesn't bleed visits between neighboring merchants. For isolated big-box retail with large parking lots, centroid-plus-radius is acceptable and much cheaper to source. GSDSI's POI & Geofencing product ships polygon-primary with centroid fallback so buyers can choose per use-case.
How often should a POI file be refreshed?: Monthly at minimum. US retail establishment churn runs at ~8–10% per year per Census Business Dynamics Statistics, so a file refreshed annually will have 8–10% stale records within 12 months — enough to materially distort foot-traffic reads. Every record should carry opening/closing-date provenance so buyers can filter stale records at query time.
How does POI quality affect foot-traffic analytics?: POI quality is the hidden determinant. Most foot-traffic accuracy failures are POI failures, not panel failures. A store with a misplaced centroid will misread parking-lot traffic; a multi-tenant building without tenant-level cut-outs will mix customer categories; a stale file will count visits to closed stores. See why POI data quality makes or breaks foot-traffic analytics for the upstream framing.
What is the "same address, different business" problem?: When multiple merchants operate at the same street address (a coffee shop and a dental practice in the same mixed-use tower, for example), an address-level POI file collapses them into one record. Downstream foot-traffic reads then mix customer categories and become unusable. The fix: tenant-level polygon cut-outs plus NAICS primary codes per tenant — but that requires field-survey-quality POI sourcing, which is expensive to build and maintain.