Geometry Attributes

SafeGraph's Geometry Attributes provide detailed information about the size and shape of POIs in our Places dataset.

Contents

• Column Definitions
• Key Concepts

Helpful Links

• Places Data Schema
• Geometry Attributes Schema

Column Name Detailed Descriptions

Note: Geometry metadata not provided for Closed POIs.

geometry_type

This is the geometric shape associated with the POI where possible values are: "POLYGON" or "POINT." This is meant to distinguish traditional SafeGraph places which currently have Geometry or will eventually have Geometry ("POLYGON") from places that intentionally do not have Geometry ("POINT.") Some POIs have geometry_type = "POLYGON" but no corresponding WKT because we have not yet built our Geometry product in that region of the world. See our summary stats page for details on Geometry coverage.

polygon_wkt

• Spatial reference used: EPSG:4326
• WKT stands for Well-Known-Text. It’s a simple way to define a polygon/shape and is the standard format for polygons in SafeGraph Places.
• Other common geospatial file formats include Shapefile and GeoJSON. WKT can be easily converted to these formats, and a Google Colab notebook to assist with the conversion can be shared upon request.

polygon_class

The classification of the polygon: 1) OWNED_POLYGON: only one POI maps to this distinct polygon. 2) SHARED_POLYGON: at least two POIs share the same polygon. See Shared Polygons for more details.

is_synthetic

• We strive for precise polygons for nearly all of our places, but in some cases, we have not yet sourced an accurate polygon and will instead infer a synthetic polygon from an accurate centroid, category-based radius, and heuristics like avoiding overlap with roads. In these cases, is_synthetic = "true." For some categories, it does not make sense to provide a precise polygon. Those categories are listed below:
  • Cemeteries and Crematories (812220)

enclosed

If true, then this POI is completely enclosed indoors by its parent and is only accessible by entering the parent structure. Mobility data often is often noisier (higher horizontal accuracy) indoors, and extra care should be taken when attempting to perform visit attribution on enclosed POIs.

includes_parking_lot

• In some cases, our polygons intentionally include the parking lot (POIs with parent qualifying naics_codes and car dealerships). The value of the includes_parking_lot column is to make explicit to our customers when the polygon_wkt does or does not include the parking lot. There are three possible values true, false, and null (null when we are not sure whether a parking lot is included in the geometry).

wkt_area_sq_meters

The calculated area of the polygon_wkt in square meters. Note this will not account for any area associated with multi-tiered structures.

related_parking

• The related_parking column leverages our Parking Lots data to show the relationship between a given place and any surrounding parking lot(s).

Key Concepts

Spatial Hierarchy (parent_placekey)

Some POIs are characterized by a broader footprint and cannot be represented by the outline of a single building. These types of POIs often encompass smaller POIs within their borders, and we try to flag where these overlapping relationships exist in the real world by setting the parent_placekey of the smaller POI equal to the placekey of the larger, encompassing POI. We colloquially refer to the larger, containing POI as the "parent" and the smaller POI as the "child."

If a POI is not contained by an overlapping polygon, the parent_placekey will be null. Only POIs of particular categories can qualify as "parent" POIs with the exception of brands wholly containing other brands (ex: a Subway within Wal-Mart). Below is a table of all sub_categories and corresponding naics_codes that have the potential to be parents:

In rare cases, a parent POI can have a parent. Examples include:

• Starbucks > Airport terminal > Airport
• Subway > Walmart > Shopping center
• Physician's office > Outpatient care center > Regional medical campus

Shared Polygons

In dense environments, such as indoor malls or multi-story buildings, we may not be confident about a POI’s true shape, so we provide the overall structure polygon instead. This results in several POIs sharing the same polygon. In other cases, we simply may not have a unique polygon for each POI, so several POIs end up sharing the same polygon. In each of these cases, the POIs would be classified as "SHARED_POLYGON" in the polygon_class column.

If a single POI maps to a distinct polygon (excluding that POI's children), then the POI is classified as "OWNED_POLYGON" in the polygon_class column. We exclude children from influencing a POI's polygon_class because in cases where a unique polygon is not available for a child POI, the child POI most likely maps to the parent POI's polygon; however, that does not mean the polygon is not a good representation of the parent itself.

For example, a Nike store inside of a shopping mall. If we don't have a good polygon for the Nike store, then the Nike store may share the same polygon as the mall, but the polygon for the mall is still representative of the mall's shape and size. For more details on parent-child relationships, see the Spatial Hierarchy section above.

If you need to differentiate unique stores within a shared polygon, you should use the POI centroids (the latitude and longitude columns). Since user GPS signals often drift inside of large structures, for use cases such as determining places visited by a user, we have found that user distance to centroid is a good substitute for distance to polygon.