Iggy quantifies places using several approaches. For more detail on what happens behind the scenes, see the Spatial Compute Engine section.

Counts

Total number of things in boundaries, like grocery stores, or parks. Counts are useful because they summarize what’s around in a human-understandable way: the number of grocery stores nearby, or the number of public transportation options.

Count-based features have count appended to their name - for example poi_is_grocery_store_count.

Intersecting Area

For objects that have a real-world extent, such as parks or lakes, the area of overlap with a given boundary. Intersecting areas are useful to answer questions like “how much of the area around a place is parkland?”

In the example on the left, we see only the intersection of the park with the boundary. The example to the right shows yet another variant – the total area of any intersecting features.

Intersection features have units specified in their name: intersecting_area_in_sqkm (left picture) or total_area_of_intersecting_features_in_sqkm (right picture). For example parks_and_recreation_total_area_of_intersecting_features_in_sqkm.

Length

The total length of intersecting linear features - for example coastline. Length is useful when the boundary between two areas is important - for example to answer the question “is there a walk along the waterfront by this address?”.

Length features have units specified in their name: intersecting_length_in_km. For example coast_intersecting_length_in_km.

Distance

The distance between some point and the nearest instance of another object. Or the distance between some point of origin and a destination along an actual road network. Distance is the measure to use when answering questions like “how far is the nearest urgent care center?” or “how close is the nearest (noisy) airport?”

Distance features have the metric and units specified in their name: distance_in_m_to. For example distance_in_m_to_is_childcare.

Travel time

The time required to get from point A to B by walking or driving on roads or paths. Travel time is useful when you need to know real-world accessibility. For example, the driving time required to get to the nearest downtown area.

Travel time features have the mode and units specified in their name: drive_time_in_minutes_to. For example drive_time_in_minutes_to_airport.

Indicator variables

These features tell you whether some criterion is being met or not. In some cases, the count or distance to a particular POI is less important than simply knowing whether or not it is nearby or intersecting with a boundary. As an example, you may care whether there are more or less than 15 restaurants nearby, or whether or not water is reachable within a 10 minute walk.

Features that are indicator variables have names prefixed by label, like label_park_access_10m_walk. Alternately, names may be written in declarative form, e.g. coast_intersects.

Other attributes

For some Features, we summarize in ways that don’t fit neatly into categories like count, distance, etc. Typically this happens when a particular attribute of a POI is important - for example knowing the total megawattage of power plants nearby, or typical speed limit of nearby roads.

In these cases, we default to naming the Feature as descriptively as possible to make its value unambiguous.