When analyzing a potential new location to open a new store, new restaurant, or new coffee shop, it is often useful to analyze the potential catchment area for the selected location.
A typical approach here is to calculate a given catchment area for the new location. This could be a drive time zone or in a larger city walking time zone may be more appropriate. This often depends on the type of store you are looking to open - and where.
Below you can see such walking time zones around two locations in San Francisco. The zones below are 10-minute walking zones.
In this article, we will investigate how you can calculate proportional values between these walk time zones, or any other catchment areas, and demographic or population data that often is stored on boundary datasets.
Happy #MapInfoMonday
As you can see in the image above, the walking zones each overlap several block group polygons: Some block groups are completely covered by the walking zones. Others are only partially covered.
To calculate the proportional population for each of these block groups, we need to calculate what percentage of each block is covered by the walking zones. When we have this percentage, we can also estimate the number of people covered by these walking zones. We assume that the population is spread equally across the block groups.
To walk you through the principles of this method, we will start by calculating the proportional overlap between each walking zone and all the block groups that intersect these. We will use the PropertionOverlap function to calculate overlapping percentages.
Once the percentage has been calculated, we can multiply this by any variable that we can consider evenly spread across the block groups to calculate the value inside the walking zone.
In the expression below, you can see how I calculate the proportional overlap in the second line. Keep in mind that the order of the parameters is essential. It will help if you know that the proportional overlap is calculated using this formula: AreaOverlap( object1, object2 ) / Area( object1).
In order case, the first parameter is the walking zones and the second parameter is the block group.
In the fourth line, I calculate the proportional population by multiplying the population by the proportional overlap.
Select wt.Name, gv.areaname, gv.code
, ProportionOverlap(gv.Obj, wt.obj) As "PropOverlap"
, gv.popcy
, gv.popcy * ProportionOverlap(gv.Obj, wt.obj) As "PropPop"
From NewLocations_WT as "wt"
, gv_usa_updateprofile_bg as "gv"
Where wt.obj Intersects gv.Obj
Into Selection
The above query will give you the details of each intersection between a walking zone and a block group that intersects. This gives you a good picture of the neighborhood's coverage and allows you to double-check your query. Do the numbers look ok? Does it look correct that this block group overlaps the walking zone by 12%? Those kind of questions.
But what you really are after are the summarized values. How many people live within my new store's catchment area (walking zone)? To get to these values, we will modify the query slightly.
We will remove most of the columns to return as we only need the name of the location and the summed proportional population. And, we will group the result by the name of the location to get a value for each of the two potential new locations.
Select wt.Name
, Sum(gv.popcy * ProportionOverlap(gv.Obj, wt.obj)) As "PropPop"
From NewLocations_WT as "wt"
, gv_usa_updateprofile_bg as "gv"
Where wt.obj Intersects gv.Obj
Group By wt.Name
Into Selection
As you can see below, we now only get two records back: One for each of the two locations. And in our example, we only get one value for each record: the proportional population.
You can of course calculate multiple values if the table you compare the walking zones against holds multiple variables that you are interested in. For the GroundView data, we could also have considered using the estimated population in 5 years or the population for some of the specific age groups.
We want to bring the calculated value back to the locations so that these values get stored with the potential locations. To do this, we will use the Update Column dialog.
Below, you can see how I have configured the Update Column dialog, to update the Pop_10m on the NewLocations table with the values from the PropPop column from the Query7 query. For the join, I specified that the values in the Name columns in the two tables should be identical.
------------------------------
Peter Horsbøll Møller
Principal Presales Consultant | Distinguished Engineer
Precisely | Trust in Data
------------------------------