TL;DR

Try out the new CensusMapper, it’s great!

History

Here we focus on what’s new in this CensusMapper update, we refer those interested in how CensusMapper started and how we got here to posts chronicling the motivation and history of CensusMapper. (von Bergmann 2015b, 2015a, 2016b, 2016a, 2017a, 2019, 2020b, 2020a, 2021; von Bergmann and Cervantes 2015b, 2015a)

The new CensusMapper

After putting off revamping CensusMapper for many years in early 2025 the stars aligned. Just as Jens was mapping out what it would take to modernize CensusMapper Leia, a UBC Computer Science student, approached Jens for an internship opportunity. After some discussions to make sure skills and interested aligned we decided to take the plunge. With both of us having other main responsibilities it took some time, but we have been slowly hacking away at it and are finally ready to roll it out.

Changed user experience

How do these technology choices translate to the user experience? We want to highlight a couple of the impacts of these changes.

Visual impact

The changes in mapping stack and refinements in map representation discussed above change the visual impact of the maps as illustrated in the comparisons below. We believe this significantly improves the user experience and the readability of the maps.

claude mcp add --transport http censusmapper https://censusmapper.ca/mcp

claude mcp add --transport http --scope user censusmapper \                                                               
    https://censusmapper.ca/mcp \
    --header "X-Api-Key: YOUR_API_KEY"

❯ what is the average income in vancouver?    

⏺ Let me search for income variables and the Vancouver region in parallel.
  Called censusmapper 2 times (ctrl+o to expand)
⏺ Now let me fetch the income data for both the Vancouver CMA and City of Vancouver.
  Called censusmapper 3 times (ctrl+o to expand)
⏺ Here's what the 2021 Census (2020 income data) shows for Vancouver:

  City of Vancouver 
  
  ┌───────────────────────────────────────────────────────────────────┬──────────┐
  │                              Measure                              │  Amount  │
  ├───────────────────────────────────────────────────────────────────┼──────────┤
  │ Average household income                                          │ $114,900 │
  ├───────────────────────────────────────────────────────────────────┼──────────┤
  │ Average economic family income                                    │ $151,000 │
  ├───────────────────────────────────────────────────────────────────┼──────────┤
  │ Average individual income (persons 15+, not in economic families) │ $55,850  │
  ├───────────────────────────────────────────────────────────────────┼──────────┤
  │ — Male                                                            │ $58,500  │
  ├───────────────────────────────────────────────────────────────────┼──────────┤
  │ — Female                                                          │ $53,350  │
  └───────────────────────────────────────────────────────────────────┴──────────┘
  
  Vancouver Metro Area (CMA)
  
  ┌───────────────────────────────────────────────────────────────────┬──────────┐      
  │                              Measure                              │  Amount  │
  ├───────────────────────────────────────────────────────────────────┼──────────┤
  │ Average household income                                          │ $117,300 │
  ├───────────────────────────────────────────────────────────────────┼──────────┤
  │ Average economic family income                                    │ $141,000 │
  ├───────────────────────────────────────────────────────────────────┼──────────┤
  │ Average individual income (persons 15+, not in economic families) │ $52,650  │
  ├───────────────────────────────────────────────────────────────────┼──────────┤
  │ — Male                                                            │ $55,400  │
  ├───────────────────────────────────────────────────────────────────┼──────────┤                                                
  │ — Female                                                          │ $50,040  │
  └───────────────────────────────────────────────────────────────────┴──────────┘                                                

  Source: Statistics Canada, 2021 Census of Population (25% sample data, income year 2020).
  
  A few notes on interpreting these:
  
  - Household income is the most commonly cited figure — $114,900–$117,300 across city/metro.
  - Economic family income is higher because it pools multiple earners in the same family unit.
  - Individual income (~$53–56K) covers people 15+ who are not part of an economic family (e.g., single adults living alone).
  - The gender gap is ~$5,000–$5,400 (male > female) across both geographies.

claude mcp remove censusmapper

The future

There are lots of things that did not make it into this release of CensusMapper, but are in some form or another in the planning pipeline. In the near term we will be focused on ironing out quirks and little issue as we collect user feedback. But medium to longer term we got more exciting things in the pipeline.

Upshot

We got a new and shiny CensusMapper, try it out, browse maps others have made, go back to maps you made previously and spiff them up, and make new maps!

There likely are still a number of quirks and issues, if you come across any ping us on any of our contact channels so we can fix it.

Why now?

The main reason I haven’t done this before is that it takes time. But this that has fundamentally changed over the last year or so. This kind of web-app is a fairly simple and straight-forward application using standard javascript frameworks and StatCan APIs. And LLMs, in particular Claude Code, can do most of the work for this kind of thing with only a little hand-holding, dramatically accelerating development of such an app. Taking it from a week (estimated) of full time work to just a couple of (longish) train rides with most of the time spent reading while the LLM is noodling away writing code, only requiring intermittent intervention, updated instructions, and occasional hand holding and reading of code when it gets stuck to give more pinpointed instructions to guide it back on track. Plus some light manual editing at the end for fine-tuning.

Building the app

There is nothing special about the process, LLMs, and in particular Claude Code, have found wide adoption in the industry and this is a fairly standard workflow. But many outsiders don’t have a view into how LLMs are rapidly changing processes in the industry and there probably is value to quickly sketch the process of creating this kind of web app aimed at a broader audience.

Two years ago the way such an app would have gotten created is by someone with strong familiarity of front end web frameworks to collaborate with someone familiar with StatCan data and how people use data to sketch out and develop the app. Or a single person combining those skills, but that is rare. Just a year ago half of the front-end work would have been shortcut by asking an LLM to write a bare-bones template to get things started, cutting the front-end work in half. Today all that’s required is a bit of superficial knowledge of front-end web frameworks to guide the process at a high level, trouble-shoot, and at the end manually refine things a bit.

How does it work? Pretty simple. To get it started I dropped into the Claude Code console, selected Sonnet 4.5 as the model¹, enter plan mode and instructed Claude to plan a static web app leveraging StatCan API using react and observable plot for graphing. It should allow browsing StatCan tables, browse and select dimensions and members from specific tables, and fetch the corresponding data and metadata and plot the result.

Claude took some time to browse the StatCan API specifications, did some web searches, and presented me with a detailed implementation plan. I asked it to make some tweaks and then gave it the go ahead to build the app. Claude noodled along and came back 20 minutes later with a somewhat functional bare-bones implementation. Some more back and forth pointing it to various problems in the app, and I had a basic app. All in all it took maybe an hour and half to get there, much of the time on my side was spent making coffee and preparing breakfast while Claude was doing work in the background.

That’s when the bulk of the work started. This bare-bones version was usable, but barely so. What was needed is to help Claude design (and rearrange) the UI elements to make them more intuitive and informative, to properly access and parse the metadata and integrate it so users understand what they are doing. At this point it also required to also check through the code and tell Claude to redesign some parts. Partially because I have changed my mind on some UI choices and workflows half way, and partially with an eye toward future extensions. And to fit my idiosyncratic preferences.

Then came a phase to optimize the caching and API calls to minimize loading time for users and drag on StatCan APIs. This again required some hand-holding and quite specific instructions.

The last phase was a bit more tedious the goal was to fine-tune the user flows through the app and add styling. This involved a mixture of instructions to Claude and light manual editing of code. Some of this would probably have gone faster if I had taken full control and made all edits myself, but offloading a bunch of that to Claude gave me more time to read and was a net positive in terms of my time. That’s pretty much it.

I should add that while this sounds (and was) stupendously easy to do, it does require some expertise to give the right directions to Claude. Expertise both in terns of a detailed understanding the data and StatCan APIs, as well as user needs and common use cases. And expertise in front-end web frameworks to give clear instructions on how to implement the app and to effectively troubleshoot when Claude manoeuvred itself into a corner. Claude will get better at the some of this, in particular the last part. Already at this point one can probably trade lack of expertise in front-end development for more annoying back and forth with Claude to get things working. It’s a gradient of being super-effective in instructions and needing more back and forth with Claude to resolve issues, and I was definitely not always all that effective and wasted some time (and tokens) in the process.

There were also some quintessential LLM moments. Proper handling of dates and time zones was one such example where Claude Code struggled. Which goes back to the nature of LLMs, and the fact that there is an awful lot of code out there that does not handle dates and time zones properly and LLMs lack the ability to independently reason out the correct algorithm. This could have probably been resolved by repeatedly pointing out to Claude that some results were incorrect, with Claude repeatedly trying to fix it and probably succeeding at some point. But I decided to shortcut the process and just intervene manually to fix it. When one gets to non-standard tasks, or tasks that have often gotten implemented poorly in the wild, LLMs struggle and manual intervention is often easier.

The app

The app itself is quite straight-forward, it has three pages, one for data discovery, one for selecting time series, and one for plotting.

Next steps

This is a basic version of the app I had in mind, there are lots of ways to expand it and make it more useful:

• Most importantly bringing in different data sources, for example integrating CMHC data, Bank of Canada data which I have already done for R users.
• Allow for more advanced plotting options, including custom functions to allow combining of several time series.
• Add ways to save several views/user states so that users can build up and share a repertoire of graphs they can revisit as data updates.
• Provide more stable data access, some StatCan APIs can be unavailable for some time between midnight and 8:30am eastern, and every now and then the StatCan APIs go down during daytime too. These are quite annoying design failures of the StatCan API, it’s hard to understand how in this day and age StatCan designed a system with this much planned downtime (and high propensity for unplanned downtime).
• Add functionality for selecting different dimensions for the x-axis, not just time.
• Add functionality for visualizing data on a map, at least for high level geographies.
• See where users take this and learn about use cases I have not thought about and continue to improve user experience.
• Add in ways to display uncertainty (when available) and information on resolution/rounding of data.
• Be more principled about units. That includes better handling of log scale depending on the data type (e.g. percentage or index data, and making log scale the default for some data types), and warning users if they plot the different data types on the same graph.
• Be more principled about aggregating data depending on the data type, for example use geometric and arithmetic mean as appropriate
• Add functionality for showing year over year change or month over month change.

Some of these can be implemented within the current standalone web app framework, others require setting up a dedicated server that can store user information. And possibly setting up a separate database server to improve data availability and stability.

Solid demographic models

We can see the answer to when Surrey will surpass the population of Vancouver in recently released StatCan population projections at the municipal (census subdivision) level. StatCan’s method, in a nutshell, treats people as solid, aging them forward in place (within CSDs) via a crude approximation from past trends and made to sum into earlier calculated projections across the broader region (CD). Past net migration enters into past trends by age group and becomes extrapolated into the future. In trying to avoid running into absurd scenarios like negative population or unrealistically large growth scenarios in select areas and subgroups they crudely extrapolate areas and age groups that historically have been growing linearly and those that have been declining exponentially (while using language that would make any high school math teacher tear their hair out, but never mind that). More holistically this could be dealt with by a mechanism that implements regression to the mean over time.

We can see a slightly different answer to when Surrey will surpass the population of Vancouver in more standard provincial projections released by BC Stats in British Columbia. BC Stats also treats people as solids, but applies more refined methods to projecting age cohorts forward based upon distinct components of change (fertility, mortality, and migration) estimated from the past with some adjustments for current policies and future expectations, especially concerning immigration.

Figure 1 shows both of these projections, for BC Stats, the cross-over where Surrey surpasses Vancouver is imminent, happening sometime just after the Census, by the end of 2026. For StatCan, it looks like it’s one year further away, happening by the end of 2027.

<code>

metro_van_cities <- list_census_regions("2021") |>
  filter(level=="CSD",CMA_UID=="59933") |>
  add_unique_names_to_region_list() |>
  mutate(Name=fct_reorder(Name,-coalesce(pop,0))) |>
  select(GeoUID=region,Name)

bc_projections <- read_csv(here::here("data/Population_Projections_metro_van.csv"),skip=6) |>
  pivot_longer(matches("_\\d{4}$"),names_pattern=c("(.+)_(\\d{4})"),names_to=c("Series","Year"),values_to="Population") |>
  mutate(Name=gsub(", District Municipality", " (DM)",Municipality) |>
           gsub(", City of", " (CY)", x=_)) |>
  mutate(Date=as.Date(paste0(Year,"-01-01"))) |>
  select(Date,Municipality,Name,Series,Population) |>
  left_join(metro_van_cities,by="Name") |>
  select(-Name) |>
  left_join(metro_van_cities,by="GeoUID") |>
  mutate(Series=recode(Series,"Estimate"="Estimates",
                       "Projection"="Projections"))

csd_estimates <- get_cansim_connection("17-10-0155", refresh="auto") |>
  filter(substr(GeoUID,1,4) == "5915",
         nchar(GeoUID)==7) |>
    collect_and_normalize(default_month = "01") |>
  left_join(metro_van_cities,by="GeoUID") 

csd_projections <- get_cansim_connection("17-10-0162", refresh="auto") |>
    filter(Gender=="Total - gender",
           `Age group`=="All ages",
           `Projection scenario`=="Projection scenario M1: medium-growth",
            substr(GeoUID,1,4) == "5915",
            nchar(GeoUID)==7) |>
    collect_and_normalize(default_month = "01") |>
  left_join(metro_van_cities,by="GeoUID") 


all_data <- bind_rows(
    csd_projections |> mutate(Series="StatCan projections"),
    csd_estimates |> mutate(Series="Statcan estimates")
  ) |>
  mutate(Source="StatCan") |>
  rename(Population=val_norm) |>
  bind_rows(bc_projections |> mutate(Source="BC Stats") |> filter(Series=="Projections"|Date=="2024-01-01") |>
              mutate(Series="BC Stats projections")) |>
  mutate(Series=factor(Series,levels=c("Statcan estimates","StatCan projections","BC Stats projections")))

all_data_cleaned  <- all_data %>%
  filter(Name %in% ((.) |> count(Name,Series) |> count(Name) |> filter(n==3) |> pull(Name))) 

line_types <- setNames(c("solid","dashed","dotted"),
                           c("Statcan estimates","StatCan projections","BC Stats projections"))
source_colours <- setNames(sanzo::trios$c157,
                           c("Statcan estimates","StatCan projections","BC Stats projections"))

all_data_cleaned |>
  filter(Name %in% c("Vancouver","Surrey")) |>
  filter(Date>="2015-01-01",Date<="2035-01-01") |>
ggplot(aes(x=Date, y=Population, color=Series,linetype=Name)) +
    geom_line(linewidth = 1) +
    geom_point(shape=21) +
  scale_colour_manual(values=source_colours) +
  scale_x_date(date_breaks = "5 years", date_labels = "Jul %Y") +
  scale_y_continuous(labels=\(x)scales::comma(x,scale=10^-3,suffix="k"),
                     trans="log", breaks=seq(500,900,50)*1000) +
    labs(title="Population Estimates and Projections for Vancouver and Surrey",
         x=NULL,
         y="Population",
         linetype="Muncipality",
         colour="Source") 

We can see the cross-over between Vancouver and Surrey is heavily driven by the projected decline in Vancouver’s population. This is striking. Where does it come from? As it turns out, temporary residents arriving in the metro area of Vancouver have more often landed in the City of Vancouver than the City of Surrey. Recent rollbacks in temporary residents due to Canadian immigration policy have been extrapolated forward, and have been built into the solid population models of both StatCan and BC Stats, where they enter in just slightly different ways. The assumption is that if you turn off this conveyor belt of temporary residents, then the City of Vancouver’s population will decline more than the City of Surrey’s. But is this correct? We could work with different assumptions. Let’s think about our conveyor belt as more like a stream, one of many feeding the pond of our metropolitan area. What happens to the deepest part of the pond - our central city - if this particular stream gets diverted?

Liquid demography

Where will people sloshing around Metro Vancouver land? As it turns out, they land mostly where there’s housing to contain them. If we believe this, then projecting in the future should be based mostly on where housing is likely to land rather than our cohort projections. To make this more concrete, let’s think about housing growth.

Overall, both Vancouver and Surrey have been adding housing in recent years. To better match housing to population we would want to look more broadly at housing services provided, not just number of housing units. We don’t have open data on square footage or number of bedrooms added, but we can use dwelling types, combined with household size estimates for each dwelling type, to derive a rough and imperfect measure of growth in housing capacity and relate the to population growth. We show the household size by type estimates derived from the 2021 census in Table 1.

dwelling_types <- c("Single", "Semi-Detached", "Row", "Apartment")

hhsize_data <- get_cansim_connection("98-10-0240") |>
  filter(GeoUID %in% c("5915022","5915","5915004"),
         `Household size (8)` %in% c("Average household size","Total - Household size"),
         `Number of bedrooms (6)`=="Total - Number of bedrooms",
         `Statistics (3C)`=="Number of private households") |>
  collect_and_normalize() |>
  filter(`Tenure (4)`=="Total - Tenure") |>
  select(GeoUID,value=VALUE,`Dwelling Type`=`Structural type of dwelling (10)`,name=`Household size (8)`) |>
  pivot_wider(names_from=name,values_from=value) |>
  filter(`Dwelling Type` !="Total - Structural type of dwelling") |>
  mutate(`Dwelling Type`=recode(`Dwelling Type`,
                                "Single-detached house"="Single",
                                "Semi-detached house"="Semi-Detached",
                                "Row house"="Row",
                                "Apartment in a building that has fewer than five storeys"="Apartment",
                                "Apartment in a building that has five or more storeys"="Apartment")) |>
  summarise(hhsize=weighted.mean(`Average household size`,`Total - Household size`),.by=c(GeoUID,`Dwelling Type`)) |>
  filter(`Dwelling Type` %in% dwelling_types) |>
  mutate(`Dwelling Type`=factor(`Dwelling Type`,levels=dwelling_types))

hhsize_data |>
  left_join(metro_van_cities, by="GeoUID") |>
  mutate(Name=coalesce(Name,"Metro Vancouver")) |>
  select(-GeoUID) |>
  arrange(`Dwelling Type`) |>
  mutate(hhsize=round(hhsize,1)) |>
  pivot_wider(names_from=`Dwelling Type`,values_from=hhsize) |>
tinytable::tt()

Dwellings of most types tend to contain more people in Surrey than in Vancouver. This likely reflects roomier dwellings in Surrey, indicating greater housing services being provided on average per dwelling, though it’s possible differences are also picking up other patterns, like more doubling up. Overall, our basic assumption is that on average dwellings produced in Surrey will probably contain slightly more of our liquid people than in the City of Vancouver. Multiplying these figures with our data on recent completions (with a minor adjustment for demolitions), we can roughly estimate the net housing capacity recently added per year in Vancouver and Surrey. The resulting estimated housing capacity growth is shown next to StatCan estimated population growth in Figure 2.

<code>

summarize_annual_by_type <- function(data){
  data |>
    filter(`Dwelling Type`!="All") |>
    mutate(Year=strftime(Date %m+% months(6),"%Y")) |>
    summarize(Total=sum(Value,na.rm=TRUE),
              months=n(),.by=c(`Dwelling Type`,Year)) |>
    filter(months==12) |>
    select(-months)
}

van_completions <- cmhc::get_cmhc(survey = "Scss", series = "Completions", dimension = "Dwelling Type", breakdown = "Historical Time Periods", geo_uid = "5915022") |>
  summarize_annual_by_type()

surrey_completions <- cmhc::get_cmhc(survey = "Scss", series = "Completions", dimension = "Dwelling Type", breakdown = "Historical Time Periods", geo_uid = "5915004") |>
  summarize_annual_by_type()

yvr_completions <- cmhc::get_cmhc(survey = "Scss", series = "Completions", dimension = "Dwelling Type", breakdown = "Historical Time Periods", geo_uid = "59933") |>
  summarize_annual_by_type()
  


demolition_fudge <- 0.93

completions_combined <- bind_rows(
  van_completions |> mutate(GeoUID="5915022"),
  surrey_completions |> mutate(GeoUID="5915004"),
  yvr_completions |> mutate(GeoUID="5915")
) |>
  left_join(hhsize_data,by=c("GeoUID","Dwelling Type")) |>
  summarize(change=sum(Total*demolition_fudge*hhsize),.by=c(GeoUID,Year)) |>
  mutate(Metric="Housing capacity growth")
  
pop_combined <- bind_rows(
  get_cansim_connection("17-10-0155", refresh="auto") |>
    filter(GeoUID %in% c("5915022","5915004")) |>
    collect_and_normalize(default_month = "01"),
  get_cansim_connection("17-10-0152", refresh="auto") |>
    filter(GeoUID %in% c("5915"),
           `Age group`=="All ages",
           Gender=="Total - gender") |>
    collect_and_normalize(default_month = "01")
  )|>
  select(Year=REF_DATE,GeoUID,Population=val_norm) |>
  mutate(change=Population - lag(Population, order_by = Year),.by=GeoUID) |>
  select(-Population) |>
  mutate(Metric="Population growth") |>
  filter(!is.na(change))


bind_rows(pop_combined,
          completions_combined,) |>
  filter(Year>=2002) |>
ggplot(aes(x=as.integer(Year), y=change, color=Metric)) +
  geom_line() +
  facet_wrap(~GeoUID,scales="free_y",
             labeller=as_labeller(c("5915"="Metro Vancouver","5915022"="City of Vancouver",
                                    "5915004"="City of Surrey"))) +
  geom_point(shape=21) +
  scale_color_manual(values=sanzo::duos$c085) +
  theme(legend.position = "bottom") +
  scale_y_continuous(labels=\(x)scales::comma(x)) +
    labs(title="Population vs Housing Capacity Growth",
         x=NULL,
         y="Number of people",
         color=NULL,
         caption="CMHC Scss and StatCan Tables 17-10-0152, 17-10-0155, 98-10-0240")

The relationship is spiky and imperfect, reflecting in part the crudeness of our estimation as well as the compressibility of liquid demographics exhibiting short term adjustments in household formation and doubling up to smooth out mismatches. But generally as we add more housing, we also add more population. This relationship holds up pretty well until COVID hits in 2020. By 2021, the population of the City of Vancouver dropped in spite of additions to housing. Multiple issues account for this shift: immigrants stopped arriving, universities and workplaces went remote, and people increasingly valued more room at home (for work-from-home offices) relative to proximity to downtown. This last factor likely accounts for some of suburban Surrey’s resilience. Bigger homes and fewer commutes changed the landscape of demand. But people are liquid, and slosh, slosh, you’ll never guess what happened next. Lots of people sloshed back again!

This sloshing is important. Like a tsunami, the rollback in the City of Vancouver was temporary, to be followed by an inundation that completely erased the previous year’s loss in population in the City. What limited the City of Vancouver’s growth at that point? Housing. There was only so much available. People could double up (and they did!), exceeding the growth rate in housing capacity. But otherwise people would have to find room in the suburbs, which they also did. We can see from Surrey’s population that it also boomed. Surrey also saw lots of doubling up, but the boom there was further facilitated by a stronger underlying boost to housing capacity than we saw in the City of Vancouver.

Which brings us back to the differences between liquid and solid demographics. In a liquid demography, people will slosh around, but eventually make their way toward settling in the housing that’s available in the places they want to live. There are limits to how many people can be added, but we have a rough idea where they want to be. Accordingly, we need to pay attention mostly to how much supply has been created to meet the landscape of demand. And we don’t want to take housing for granted! In a solid demography, especially one where we don’t even put people in households but just focus on age cohorts, housing and its constraints are effectively ignored.

Ideally we want to bring liquid and solid treatments of people together. Both population dynamics and housing constraints matter. (Mulder 2006) Because it is the case that housing doesn’t always get filled up. Just like housing doesn’t magically appear in response to population change, people don’t suddenly appear in response to additions to housing supply. But ignoring housing constraints is especially problematic when we’re using population projections to estimate how much housing we need. More on that below!

Vancouver vs. Surrey in a Liquid World

Let’s get back to the horse race between Vancouver and Surrey. In terms of projecting when (or if) Surrey will overtake Vancouver in population, the liquid demography asks first, who is building more housing? Then, how is the landscape of demand changing? And finally, just as a check, are there any good reasons to believe we’ll see housing left empty even when people want to live there?

Figure 3 provides information on who is building more housing. Here “completions” refer to what’s just been added, with “starts” and “under construction” telling us what’s coming down the pipeline. In general, we’d expect completions to lag starts, but note the rise in “under construction” visible in both cities, which reflects increasingly lengthy construction timelines, reducing the predictability for when things will finish. (von Bergmann 2017b)

<code>

van_sur_completions <- metro_van_cities |>
  filter(grepl("^Vancouver|Surrey",Name)) |>
  pull(GeoUID) |>
  map_dfr(\(geo) {
    c("Starts","Completions") |>
      map_dfr(\(series) {
        cmhc::get_cmhc(survey = "Scss", series = series, dimension = "Dwelling Type", 
                       breakdown = "Historical Time Periods", geo_uid = geo) |>
      summarize_annual_by_type() |>
      mutate(Series=series)
      }) |> 
      bind_rows(
               cmhc::get_cmhc(survey = "Scss", series = "Under Construction", dimension = "Dwelling Type", 
                       breakdown = "Historical Time Periods", geo_uid = geo) |>
                 filter(strftime(Date,"%m")=="07") |>
                 mutate(Year=strftime(Date,"%Y"),
                        Series="Under Construction") |>
                 select(`Dwelling Type`, Year , Total=Value, Series, GeoUID)
      ) |>
      mutate(GeoUID=geo)
  }) |>
  left_join(metro_van_cities,by="GeoUID")

van_sur_completions |>
  ggplot(aes(x=as.integer(Year),y=Total,fill=fct_rev(`Dwelling Type`))) +
  geom_col(position="stack") +
  facet_grid(Series~Name, scales="free_y") +
  scale_y_continuous(labels=scales::comma) +
  theme(legend.position = "bottom") +
  #scale_fill_manual(values=sanzo::duos$c114, guide="none") +
  labs(title="Housing construction in Vancouver and Surrey",
       x=NULL,
       y="Number of units",
       fill=NULL,
       caption="CMHC Scss")

We can see 2025 was a very good year for Surrey completions. But historically Vancouver has been building more dwelling units, and its pipeline looks much more robust. Still, as we have noted Vancouver’s dwellings have generally been smaller. We don’t have good historical open data on number of bedrooms, but we can continue to proxy for that by breaking data out by dwelling type. Importantly, Surrey is starting to run out of room for greenfield development due to the Agricultural Land Reserve, and it’s increasingly building rowhouses and apartments instead. New single-family detached dwellings built in Surrey are going to look increasingly like those built in Vancouver - either replacing a tear-down, in which case they don’t contribute much to supply, or laneway homes, which generally accommodate fewer people.

At the same time the City of Vancouver has several planning initiatives that look at loosening up regulation to allow more apartments in several key areas; the Broadway Corridor, Heather Lands, Jericho Lands, the Villages initiative and others. This includes plans to densify around Skytrain stations. Of course, this also applies to Surrey, but demand is much higher in the City of Vancouver, as can be seen by looking at the modelled price surface for multiplexes from our report on the provincial SSMUH and TOA initiatives. (von Bergmann et al. 2023)

The price surface in Figure 4 provides a glimpse at the underlying landscape of desire. Residential space in Surrey is painted in blue and green, at much lower price points than the same space in Vancouver, neatly split between the red of Westside and orange of Eastside. People seem to generally want to move toward downtown Vancouver. What holds them back? Primarily the lack of housing. Similarly, CMHC’s report on supply constraints highlights spatial differential in unmet demand for housing within Metro Vancouver. (CMHC 2018) This kind of landscape suggests to a liquid demographer that if you divert one set of streams toward downtown Vancouver, like non-permanent resident inflows, they’re most likely going to be replaced by other streams that were also headed in that direction, but got backed up to places like Surrey by the competition for limited container space.

Figure 5 gives another view into this by showing workers by whether they commute within our outside of their city of residence on their way to work.

<code>

commute_data <- get_census("2021",regions=list(CMA="59933"), level="DA",
                           vectors=c(workers="v_CA21_7617",same_csd="v_CA21_7620"),
                           geo_format="sf") |>
  mutate(different_csd=pmax(0,workers - same_csd)) |>
  mutate(van_sur=CSD_UID %in% c("5915022","5915004")) |>
  mutate(across(c(different_csd,same_csd), ~replace_na(.,0))) 


random_round <- function(x) {
    v <- as.integer(x)
    r <- x-v
    test <- stats::runif(length(r), 0.0, 1.0)
    add=rep(as.integer(0),length(r))
    add[r>test] <- 1L
    value <- v+add
    value <- ifelse(is.na(value) | value<0,0,value)
    return(value)
}


scale <- 50
commute_data <- commute_data %>%
      dplyr::mutate(across(c(different_csd,same_csd),~(./scale))) %>%
      dplyr::mutate(across(c(different_csd,same_csd),random_round))

all_data <- c("same_csd","different_csd") |>
  lapply(\(cat) {
    dd <- commute_data |>
      filter(!!as.name(cat)>0)
    st_sample(dd,size=dd |> pull(cat),
              warn_if_not_integer=FALSE) |>
      st_as_sf() |>
      mutate(Type=cat)
  }) |>
  bind_rows() %>%
  slice_sample(.,n=nrow(.), replace = FALSE) |>
  mutate(Type=recode(Type,
                     "same_csd"="Same city",
                     "different_csd"="Different city"))

cov_sur_geo <- get_census("2021",regions=list(CSD=c("5915022","5915004")),geo_format="sf")

ggplot(all_data) +
  geom_water() +
  #geom_roads() +
  geom_sf(aes(colour=Type),size=0.5, alpha=0.5) +
  geom_sf(data=cov_sur_geo,fill=NA,linewidth=1) +
  coord_bbox(metro_van_bbox("tight")) +
  theme(legend.position="bottom") +
  guides(colour=guide_legend(override.aes=list(size=2,alpha=1))) +
  scale_colour_manual(values=sanzo::duos$c079) +
  annotate("text",x=-123.25,y=49.3,label="Vancouver",size=4,color="black") +
  annotate("curve",x=-123.25,xend=-123.12,y=49.29,yend=49.25,
           curvature=0.2,linewidth=0.75,
           arrow=arrow(length=unit(0.3,"cm")),color="black") +
  annotate("text",x=-122.95,y=49.05,label="Surrey",size=4,color="black") +
  annotate("curve",x=-122.95,xend=-122.82,y=49.06,yend=49.13,
           curvature=0.2, linewidth=0.75,
           arrow=arrow(length=unit(0.3,"cm")),color="black") +
  labs(title="Place of work status in Metro Vancouver",
       colour="Place of work",
       x=NULL,y=NULL,
       caption="StatCan census 2021")

commute_flow_lookup <- get_cansim_connection("98-10-0459") |>
  filter(substr(GeoUID,1,4) == "5915",
         nchar(GeoUID)==7) |>
  select(GeoUID,GEO) |>
  distinct() |>
  collect()

metro_names <- list_census_regions("2021") |>
  filter(level=="CSD",CMA_UID=="59933") |>
  add_unique_names_to_region_list() |>
  select(GeoUID=region,Name)

por_lookup <- get_cansim_column_categories("98-10-0459","Place of residence") |>
  mutate(id=Hierarchy,UID=gsub("\\[|\\]","",`Classification Code`)) |>
  select(id,UID)

pow_lookup <- get_cansim_column_categories("98-10-0459","Place of work") |>
  select(id=`Member ID`,Name=`Member Name`) |>
  left_join(por_lookup, by=c("id"="id"))

yvr_sur_por <- pow_lookup |>
  filter(UID %in% c("5915022","5915004"))

workers <- get_cansim_connection("98-10-0459") |>
  filter(GeoUID %in% c("5915022","5915004")) |>
  collect_and_normalize() |>
  filter(`Gender (3)`=="Total - Gender") |>
  summarize(Workers=sum(VALUE),.by=c(GeoUID)) |>
  left_join(metro_names, by="GeoUID")

jobs <- get_cansim_connection("98-10-0459") |>
  filter(`Place of work` %in% yvr_sur_por$Name) |>
  collect_and_normalize() |>
  filter(`Gender (3)`=="Total - Gender") |>
  summarize(Workers=sum(VALUE),.by=c(`Place of work`)) |>
  left_join(yvr_sur_por, by=c("Place of work"="Name")) |>
  left_join(metro_names, by=c("UID"="GeoUID"))

flows <- get_cansim_connection("98-10-0459") |>
  filter(GeoUID %in% c("5915022","5915004")) |>
  filter(`Place of work` %in% yvr_sur_por$Name) |>
  collect_and_normalize() |>
  filter(`Gender (3)`=="Total - Gender") |>
  left_join(metro_names |> select(Origin=Name,GeoUID), by=c("GeoUID")) |>
  left_join(yvr_sur_por |> select(`Place of work`=Name,UID), by="Place of work") |>
  left_join(metro_names |> select(Destination=Name,UID=GeoUID), by="UID") |>
  select(Origin,Destination,Value=VALUE)

van_sur_commuters <- flows |> 
  filter(Origin=="Vancouver",Destination=="Surrey") |> pull(Value) 
sur_van_commuters <- flows |> 
  filter(Origin=="Surrey",Destination=="Vancouver") |> pull(Value) 

van_workers <- workers |> 
  filter(Name=="Vancouver") |> 
  pull(Workers)
sur_workers <- workers |> 
  filter(Name=="Surrey") |> 
  pull(Workers)

van_jobs <- jobs |> 
  filter(Name=="Vancouver") |> 
  pull(Workers)
sur_jobs <- jobs |> 
  filter(Name=="Surrey") |> 
  pull(Workers)

This shows the mismatch of work and commute location stacking the deck against Surrey. The 2021 census recorded that Vancouver had 16% more jobs than workers, while Surrey had 28% fewer jobs than workers.¹ This is consistent with data from previous censuses. (von Bergmann 2017a, 2019a)

People are, as we keep pointing out, also sloshing around and compressing within containers, where people double up in existing housing when there isn’t enough housing to go around. This is an important mechanism for how housing systems adjust in the short term to demand shocks, but doubling up can also become a long term persistent feature of a housing market. The more people are doubling up all across the metro area, the larger the reservoir of people ready to decompress and fill up new containers wherever they may land, but especially if they land in the most desirable places. Figure 6 shows how people double up by age in Metro Vancouver, and for comparison purposes in select other Canadian metro areas. (Lauster and von Bergmann 2024)

This type of liquidity in housing demographics renders solid demographic models particularly problematic when applied to the sub-metro level, as we explain in more detail below. Where there’s a landscape of desire together with a ready reservoir of demand, we have every reason to expect that where we add new containers will largely determine where people land. Will there still be some empty homes? Sure. But probably not many (von Bergmann and Lauster 2022b), especially when we’ve layered several taxes on to most long-term vacancies. These kinds of taxes can add pressure for sellers and landlords to adjust their prices and rents until people flow into the new containers they control.

In short, don’t count Vancouver out. Short-term sloshing aside, our liquid demography suggests it’s got a decent chance of staying ahead of Surrey. But even in a liquid world, Vancouver may not win! It really depends upon how much housing gets built. Surrey could continue to scale up housing production via more apartments while major investments like SFU’s new medical school could tip the landscape of desire further toward Surrey’s direction. Furthermore, if current policy constraints to more greenfield development, like the Agricultural Land Reserve, come under assault, all bets are off - Surrey’s got a lot more land under ALR protection than the City of Vancouver. But those possibilities aside, in a liquid world there are plenty of reasons to believe that Vancouver will continue to battle off Surrey for the title of most populous municipality in the Metro area. Mostly it just has to keep building more.

The danger of solid projections in a liquid world

City level demographic projections are good in theory, especially if they are done well - ideally by combining our liquid and solid models. But it’s important to understand what they are useful for, and for what purposes they are not well-suited. The solid model pretty much ignores housing. The liquid model strongly emphasizes that in high demand supply-constrained areas, housing determines growth. What we can take away from both is that municipal population projections should not be used for planning around housing needs. Unfortunately, that is exactly what StatCan expects will be done with them:

These projections provide impartial, evidence-based insights to all levels of government, infrastructure owners, operators and investors to improve infrastructure planning and decision-making across Canada. The data is also expected to inform land use and urban planning, housing needs, transportation and communications.

The positioning of the projections as “impartial, evidence-based insights” is a frighteningly naive attempt to cast the assumptions and decisions embedded in the projections as value-free. Treating something that’s mostly liquid and compressible as mostly solid is neither “impartial” nor “evidence-based”. Worse, the notion that projections are expected to “inform land use planning” and “housing needs” is likely to do harm.

Further down StatCan does acknowledge the limitation that “modifications in land zoning” and “local development objectives” can have a big impact on municipal level population growth (“induce rapid fluctuations” in their language). This gets to the key tension: StatCan needs to pick a lane. If local demographics are liquid so land use planning can have significant impact on the projections, then that significantly limits the usefulness of projections that treats local demographics as a solid for land use planning. You can’t have it both ways.

So far we have focused on the M1 projection, StatCan offers a range of population projection scenarios where they vary underlying growth and inter-provincial migration assumptions. This can offer a range of scenarios and planners should not focus on just one of them, but the problem remains that all of these treat local demographics as solids rather than liquids. In Figure 7 we show the full range of scenarios for the City of Vancouver.

<code>

van_scenarios <- get_cansim_connection("17-10-0162", refresh="auto") |>
    filter(Gender=="Total - gender",
           `Age group`=="All ages",
           GeoUID=="5915022") |>
    collect_and_normalize(default_month = "01") |>
  left_join(metro_van_cities,by="GeoUID")

rank_data <- get_cansim_connection("17-10-0162", refresh="auto") |>
    filter(Gender=="Total - gender",
           `Age group`=="All ages",
           `Projection scenario`=="Projection scenario M1: medium-growth",
           nchar(GeoUID)==7,
           REF_DATE=="2024") |>
  slice_max(n=10,order_by=VALUE,with_ties = FALSE) |>
  arrange(-VALUE) |>
  collect_and_normalize(default_month = "01") |>
  left_join(metro_van_cities,by="GeoUID") |>
  mutate(n=rank(-val_norm)) |>
  select(GeoUID,Name,val_norm,n) |>
  filter(!is.na(Name))

van_scenarios |>
  filter(Date>="2015-01-01",Date<="2035-01-01") %>%
  mutate(`Projection scenario`=fct_reorder(`Projection scenario`,-val_norm)) |>
  ggplot(aes(x=Date, y=val_norm, color=`Projection scenario`)) +
  geom_line() +
  geom_point(shape=21) +
  scale_linetype_manual(values=line_types) +
  scale_y_continuous(labels=\(x)scales::comma(x,scale=10^-3,suffix="k"),
                     trans="log", breaks=seq(500,900,25)*1000) +
    labs(title="Population Projection Scenarios for the City of Vancouver",
         x=NULL,
         y="Population",
         color=NULL) 

Most of these scenarios are utterly unreasonable. The two highest growth scenarios, the high-growth and slow aging scenarios see Vancouver’s population still increasing in 2025, but then decreasing and only coming up above 2025 levels sometime late 2028.

Of course in the very short term, on the order of a year or maybe two, population could decline. We know there’s sloshing and adjustments that get made even in a liquid world. We’ll get a frozen glimpse at where things stand through the 2026 Census. We have seen such declines before, as during COVID where a multitude of factors came together all at once, as we explained above. But should we really expect one now?

We do know that non-permanent residents consume on average less housing than Canadian born residents, and similarly immigrants consume less housing than those Canadian born (despite what a recent StatCan study claims (von Bergmann and Lauster 2025)). So a reduction in non-permanent residents (and in immigration) may lead to housing being used less intensively, even while people slosh around to fill vacancies. In this sense, we would expect population to go down if the housing stock remained fixed. At the same time, and directly as a consequence of sloshing, we are seeing a softening of the rental market along with a temporary rise in vacancy rate and an increase in properties listed for sale. Altogether these patterns suggest that slightly fewer homes are being lived in until prices adjust to rebalance.

van_stock <- cancensus::get_census("2021", regions=list(CSD="5915022"))$Dwellings

van_current_under_construction <- cmhc::get_cmhc("Scss", series="Under Construction", 
                                                 dimension="Dwelling Type", 
                                                 breakdown="Historical Time Periods", geo_uid="5915022") |>
  filter(Date=="2025-10-01",`Dwelling Type`=="All") |>
  pull(Value)

van_length_of_construction <- cmhc::get_cmhc("Scss", series="Length of Construction", 
                                                 dimension="Dwelling Type", 
                                                 breakdown="Historical Time Periods", geo_uid="5915022") |>
  filter(Date=="2025-10-01",`Dwelling Type`=="All") |>
  pull(Value)

But the notion that Vancouver would see sustained population decline while still adding housing is difficult to reconcile with what we know about housing demand in Metro Vancouver. Vancouver has 17,065 units currently under construction alone with an average length of completion of about 21 months, a roughly 5% increase in housing stock that’s already baked in. Will the owners of those units really pay Empty Homes and Speculation and Vacancy Taxes to keep them vacant for long?

Liquids and Solids

As we noted at the outset, we think people are both liquids and solids. Ultimately we need demographic projections that combine these two forms. But we can go a little further to note that scale matters. At the national level, treating people as solids tends to work out ok. Immigration is subject to controls that really do make people look more like they’re coming off an assembly line. But once people land in Canada, the Charter works to preserve their ability to move freely. As a consequence, people become much more liquid as they move internally. This is mirrored in the reasons people give for moving. Immigrants don’t tend to make the move across borders for reasons like better housing affordability, but within metropolitan areas, housing drives the majority of local moves. Correspondingly, when we get below the metropolitan level, we really need to take into account how people are likely to move in response to where housing is being constructed. In short, at the local level, liquid demographics is the name of the game.

For the race between the City of Vancouver and Surrey that means that it’s mostly up to Vancouver who wins. Demand to live in Vancouver is much higher, if Vancouver allows more housing people will flow toward Vancouver and Surrey will have a very hard time catching up. If Vancouver swings back and cuts down their development pipeline, following Metro guidance, then Surrey will likely overtake Vancouver sometime in the next decade or two. As laid out by Uytae Lee, Surrey seems ready to try.

As usual, the code for this post is available on GitHub for anyone to reproduce or adapt for their own purposes.

## datetime
Sys.time()

[1] "2025-12-08 00:30:33 PST"

## repository
git2r::repository()

Local:    main /Users/jens/R/mountain_doodles
Remote:   main @ origin (https://github.com/mountainMath/mountain_doodles.git)
Head:     [efd3bd5] 2025-12-08: widgets

## Session info 
sessionInfo()

R version 4.5.2 (2025-10-31)
Platform: aarch64-apple-darwin20
Running under: macOS Tahoe 26.1

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.12.1

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/Vancouver
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] mountainmathHelpers_0.1.4 sf_1.0-22                
 [3] dotdensity_0.1.0          rlang_1.1.6              
 [5] cancensus_0.5.11          cansim_0.4.4             
 [7] lubridate_1.9.4           forcats_1.0.1            
 [9] stringr_1.5.2             dplyr_1.1.4              
[11] purrr_1.1.0               readr_2.1.5              
[13] tidyr_1.3.1               tibble_3.3.0             
[15] ggplot2_4.0.0             tidyverse_2.0.0          

loaded via a namespace (and not attached):
 [1] gtable_0.3.6       xfun_0.53          htmlwidgets_1.6.4  tzdb_0.5.0        
 [5] vctrs_0.6.5        tools_4.5.2        generics_0.1.4     curl_7.0.0        
 [9] proxy_0.4-27       fansi_1.0.6        pkgconfig_2.0.3    KernSmooth_2.23-26
[13] tinytable_0.13.0   RColorBrewer_1.1-3 S7_0.2.0           assertthat_0.2.1  
[17] lifecycle_1.0.4    git2r_0.36.2       compiler_4.5.2     farver_2.1.2      
[21] litedown_0.7       htmltools_0.5.8.1  class_7.3-23       yaml_2.3.10       
[25] pillar_1.11.1      classInt_0.4-11    tidyselect_1.2.1   digest_0.6.37     
[29] stringi_1.8.7      arrow_21.0.0.1     fastmap_1.2.0      grid_4.5.2        
[33] cli_3.6.5          magrittr_2.0.4     e1071_1.7-16       withr_3.0.2       
[37] scales_1.4.0       bit64_4.6.0-1      timechange_0.3.0   rmarkdown_2.30    
[41] httr_1.4.7         bit_4.6.0          hms_1.1.4          evaluate_1.0.5    
[45] knitr_1.50         Rcpp_1.1.0         glue_1.8.0         DBI_1.2.3         
[49] rstudioapi_0.17.1  jsonlite_2.0.0     R6_2.6.1           units_1.0-0       

New Metric!

We are suckers for experimenting with new metrics to understand housing pressures and got nerd-sniped by figures on shelter cost per square meter of floorspace in the UK put out by the Resolution Foundation, in particular the breakdown of shelter cost per square meter by age groups as flagged by Ant Breach on Bluesky, and referenced by Deny Sullivan asking for Canadian stats.

Room

In Canada we don’t know of a good data source on square footage and shelter costs by age breakdown, but we can achieve something similar by looking at shelter cost per room. Of note for current Census definitions, number of rooms includes “kitchens, bedrooms and finished rooms in the attic or basement” but excludes “bathrooms, halls, vestibules and rooms used solely for business purposes,” with specific judgments otherwise left to the respondent. As a specific example, consider a studio apartment where the kitchen was partially behind a wall. The number of rooms might be listed as one or two, depending upon the respondent. This kind of ambiguity is built into the rooms measure. But we have looked at number of rooms as a metric for household tightness before (von Bergmann and Lauster 2023), and while it is far from perfect (with sizes of rooms, as well as how we divide homes into rooms, changing over time and likely differing across regions in addition to inherent ambiguity), we believe it still offers a somewhat decent proxy for the size of homes.

get_combined_pumf_data <- function() {
  
  inflation <- mountainmathHelpers::simpleCache(
    get_cansim_vector("v41693271") |>
      mutate(Year=as.integer(strftime(Date,"%Y"))) |>
      mutate(CPI=val_norm / val_norm[Year==2021]) |>
      select(Year,CPI), 
    "inflation_annual_oct_2025.rds",path=here::here("data"))
  

  years <- seq(1991,2021,5)
 
  pumf_list <- years |>
    lapply(\(year) get_pumf("Census",year) |>
             label_pumf_data(rename_columns = FALSE) |>
             mutate(Year=year)) |>
  setNames(years)
  
  year_age_to_age_group <- function(age_column) {
    cut(as.numeric(na_if(age_column,"Not available")),breaks=c(-Inf,15,18,seq(20,85,by=5),Inf),
        labels=c("0 to 14 years","15 to 17 years","18 to 19 years",
                 "20 to 24 years","25 to 29 years",
                 "30 to 34 years","35 to 39 years","40 to 44 years",
                 "45 to 49 years","50 to 54 years","55 to 59 years",
                 "60 to 64 years","65 to 69 years","70 to 74 years",
                 "75 to 79 years","80 to 84 years","85 years and over"),
        right=FALSE)
  }

  select_columns_r <- c("ROOM","AGEGRP","PRIHM","SHELCO","WEIGHT","CMA","MOB1","TENUR","VALUE")
  
  pumf_all_r <- bind_rows(
    pumf_list[["2021"]] |> 
      select(all_of(select_columns_r)) |> 
      mutate(VALUE=as.integer(VALUE)) |>
      mutate(Year=2021),
    pumf_list[["2016"]] |> 
      mutate(ROOM=ROOMS) |> 
      select(all_of(select_columns_r)) |> 
      mutate(VALUE=as.integer(VALUE) |> na_if(99999999)|> na_if(88888888)) |>
      mutate(Year=2016),
    pumf_list[["2011"]] |> 
      mutate(SHELCO=coalesce(na_if(OMP,"9999") |> na_if("8888"),
                             na_if(GROSRT,"9999") |> na_if("8888")) |>
               as.numeric()) |>
      select(all_of(select_columns_r)) |> 
      mutate(VALUE=as.integer(VALUE) |> na_if(9999999)|> na_if(8888888)) |>
      mutate(Year=2011),
    pumf_list[["2006"]] |> mutate(SHELCO=coalesce(na_if(OMP,"9999") |> na_if("8888"),
                                                  na_if(GROSRT,"9999") |> na_if("8888")) |>
                                    as.numeric()) |>
      select(all_of(select_columns_r)) |> 
      mutate(VALUE=as.integer(VALUE) |> na_if(9999999)|> na_if(8888888)) |>
      mutate(Year=2006),
    pumf_list[["2001"]] |> mutate(SHELCO=coalesce(na_if(OMPP,"9999") |> na_if("8888")|> na_if("Not applicable"),
                                                  na_if(GROSRTP,"9999") |> na_if("8888")|> na_if("Not applicable")) |>
                                    as.numeric()) |>
      rename(ROOM=ROOMP,PRIHM=PRMAINP,WEIGHT=WEIGHTP,CMA=CMAP,MOB1=MOB1P,TENUR=TENURP,VALUE=VALUEP) |>
      mutate(AGEGRP=year_age_to_age_group(AGEP)) |>
      select(all_of(select_columns_r)) |> 
      mutate(VALUE=as.integer(na_if(VALUE,"Not applicable"))) |>
      mutate(Year=2001),
    pumf_list[["1996"]] |> mutate(SHELCO=coalesce(na_if(OMPP,"9999") |> na_if("8888")|> na_if("Not applicable"),
                                                  na_if(GROSRTP,"9999") |> na_if("8888")|> na_if("Not applicable")) |>
                                    as.numeric()) |>
      rename(ROOM=ROOMP,PRIHM=PRMAINP,WEIGHT=WEIGHTP,CMA=CMAPUMFP,MOB1=MOB1P,TENUR=TENURP,VALUE=VALUEP) |>
      mutate(AGEGRP=year_age_to_age_group(AGEP)) |>
      select(all_of(select_columns_r)) |> 
      mutate(VALUE=as.integer(VALUE) |> na_if(999999)|> na_if(888888)) |>
      mutate(Year=1996),
    pumf_list[["1991"]] |> mutate(SHELCO=coalesce(na_if(OMPP,"9999") |> na_if("8888") |> na_if("Not applicable"),
                                                  na_if(GROSRTP,"9999") |> na_if("8888") |> na_if("Not applicable")) |>
                                    as.numeric()) |>
      rename(ROOM=ROOMP,PRIHM=PRMAINP,WEIGHT=WEIGHTP,CMA=CMAPUMFP,MOB1=MOB1P,TENUR=TENURP,VALUE=VALUEP) |>
      mutate(AGEGRP=year_age_to_age_group(AGEP)) |>
      select(all_of(select_columns_r)) |> 
      mutate(VALUE=as.integer(na_if(VALUE,"Not applicable"))) |>
      mutate(Year=1991),
  ) |>
    left_join(inflation, by="Year") |>
    mutate(SHELCO_real = SHELCO/CPI) |>
    mutate(rooms=case_when(ROOM=="Not available" ~ NA,
                           ROOM=="NOT APPLICABLE" ~ NA,
                           ROOM=="Not applicable" ~ NA,
                           ROOM=="One room" ~ "1",
                           ROOM=="Two rooms" ~ "2",
                           ROOM=="Three rooms" ~ "3",
                           ROOM=="Four rooms" ~ "4",
                           ROOM=="Five rooms" ~ "5",
                           ROOM=="Six rooms" ~ "6",
                           ROOM=="Seven rooms" ~ "7",
                           ROOM=="Eight rooms" ~ "8",
                           ROOM=="Nine rooms" ~ "9",
                           ROOM=="Ten rooms" ~ "10",
                           ROOM=="Ten or more rooms" ~ "10",
                           ROOM=="Ten or >rooms"~"10",
                           ROOM=="Eleven rooms or more" ~ "11",
                           ROOM=="Eleven or more rooms" ~ "11",
                           TRUE ~ substr(ROOM,1,2))) |>
    mutate(rooms=as.numeric(rooms)) |>
    mutate(CMA=recode(CMA,"Regina - 705 and Saskatoon - 725"="Regina – Saskatoon",
                      "Regina(705) + Saskatoon(725)"="Regina – Saskatoon",
                      "Regina/Saskatoon"="Regina – Saskatoon",
                      "Ottawa-Hull"="Ottawa – Gatineau",
                      "Ottawa Hull"="Ottawa – Gatineau",
                      "Quebec"="Québec",
                      "Montreal"="Montréal")) |>
    mutate(TENUR=recode(TENUR,
                        "Renter or Dwelling provided by the local government, First Nation or Indian band"="Renter",
                        "Owned by a member of the household"="Owner",
                        "Rented or Band housing"="Renter",
                        "Owned (with or without mortgage)"="Owner",
                        "Rented (for cash, other) or Band housing"="Renter",
                        "Owned - with or without mortgage"="Owner",
                        "Rented - for cash, other or Band housing"="Renter",
                        "OwndWithWoutMortgage"="Owner",
                        "Rented Band Housing"="Renter",
                        "Owned (with or without mort.)"="Owner",
                        "Rented-cash/other or band hsg."="Renter")) %>%
    mutate(CMA=factor(CMA,levels= summarize(.,people=sum(WEIGHT),.by=CMA) |> arrange(-people) |> pull(CMA)))
  
  pumf_all_r
}

pumf_all_r <- mountainmathHelpers::simpleCache(get_combined_pumf_data(),"combined_pumf_data.rds")

Shelter costs per room

Shelter costs, as measured in the census, capture how much households are directly paying on an ongoing monthly basis to maintain their shelter, including utilities, condominium fees, and property taxes. This differs from measuring the value of housing services consumed, a more theoretical quantity. For example an owner household in a fully paid-off home may have very low ongoing shelter costs, but the value of the housing services they consume is much higher, which we estimate by imputing the rent they pay themselves. Shelter costs can be thought of as capturing how much people feel directly pressured by the housing market rather than measuring the value of their housing services.

To make shelter cost more comparable across homes we normalize it by the number of rooms in the home as a proxy for the size of the home. One could also normalize by the number of bedrooms, but that data is only available for the 2011 through 2021 censuses and we are interested in longer timelines for this post.

pd_all <- pumf_all_r |>
  filter(PRIHM %in% c("Person is primary maintainer","Primary household maintainer",
                      "PrimaryHhldMaintainr")) |>
  filter(!is.na(rooms)) |>
  mutate(rooms=pmin(rooms,10)) |>
  summarize(
    avg_shelco_per_room = weighted.mean(SHELCO_real/rooms, w = WEIGHT, na.rm=TRUE),
    people=sum(WEIGHT),
    .by = c(CMA,Year)
  ) 

One decision we have to make is over what universe we are estimating this metric. There are two natural choices; we can estimate this over people or over households. With an eye to the rest of the post we choose to estimate this over households.

Figure 1 shows the shelter cost per room across time for several large Canadian metro areas.

<code>

filter_metros <- function(data) {
  data |>
    filter(grepl("Toron|Vancou|Calga|Montré|Ottaw|Québ|Edom|Halifax|Victor|Hamil",CMA))
}

pd_all |>
  filter_metros() %>%
  mutate(CMA=factor(CMA,levels=filter(.,Year==2021) |> arrange(-avg_shelco_per_room) |> pull(CMA))) |>
  #filter(AGEGRP != "18 to 19 years") |>
  ggplot(aes(x=Year, y=avg_shelco_per_room, colour=CMA)) +
  geom_line() +
  scale_x_continuous(breaks=seq(1991,2021,by=5)) +
  scale_y_continuous(labels=scales::dollar_format(prefix="$")) +
  theme(axis.text.x = element_text(angle=45, hjust=1)) +
  labs(title="Running shelter costs per room in Canada",
       colour="Metro area",
       y="Monthly shelter cost per room (2021 dollars)",
       x=NULL,
       caption="StatCan Census 1991 through 2021 PUMF (individuals)") 

As one might expect, Vancouver and Toronto stand out with particularly high shelter costs per room, and also strong growth in the metric since 1991. At the other end of the spectrum, Québec City metro area shows low and fairly flat shelter cost per room.

Economies of Scale and Location Tradeoffs

Importantly, we shouldn’t expect shelter cost per room to linearly scale up with the size of a dwelling overall. After all, we already know that the room metric excludes things like bathrooms - and sometimes even kitchens - which are needed to support a dwelling, but not on a per room basis. So there should be economies of scale with respect to dwellings where having more rooms becomes cheaper on a per room basis. We illustrate this with Figure 2.

<code>

shelter_cost_per_room <- pumf_all_r |>
  filter(PRIHM %in% c("Person is primary maintainer","Primary household maintainer",
                      "PrimaryHhldMaintainr")) |>
  filter(!is.na(rooms)) |>
  mutate(rooms=pmin(rooms,10)) |>
  #filter(AGEGRP != "15 to 17 years") |>
  summarize(
    avg_shelco_per_room = weighted.mean(SHELCO_real/rooms, w = WEIGHT, na.rm=TRUE),
    avg_shelco_per_room2 = weighted.mean(SHELCO_real/sqrt(rooms), w = WEIGHT, na.rm=TRUE),
    .by = c(rooms,CMA,Year)
  ) 


shelter_cost_per_room |>
  mutate(name=paste0(rooms," rooms") |> recode("10 rooms"="10+ rooms") |> fct_reorder(rooms)) |>
  filter_metros() |>
  ggplot(aes(x=Year, y=avg_shelco_per_room,colour=CMA)) +
  geom_line() +
  scale_x_continuous(breaks=seq(1991,2021,by=5)) +
  scale_y_continuous(labels=scales::dollar_format(prefix="$")) +
  theme(axis.text.x = element_text(angle=45, hjust=1),
        legend.position = "bottom") +
  labs(title="Shelter cost per room by number of rooms reported",
       colour="Metropolitan Area",
       y="Monthly shelter cost per room (2021 dollars)",
       x=NULL,
       caption="StatCan Census 2021 PUMF (individuals)") +
  facet_grid(~name)

Importantly, we’re also probably picking up some within metro area location effects here. That is, more central locations tend to have more studio and 1BR apartments, while locations further out toward the suburbs tend to have larger detached houses. So proximity to jobs and amenities may be folded into our estimates of costs per room as well, and also help explain why they vary over number of rooms. This helps set up our discussion of age effects.

In this context it’s also useful to understand how the distribution of the number of rooms per home has changed over time and differs across geographies, as shown in Figure 3.

<code>

room_over_time <- pumf_all_r |>
  filter(PRIHM %in% c("Person is primary maintainer","Primary household maintainer",
                      "PrimaryHhldMaintainr")) |>
  filter(!is.na(rooms)) |>
  mutate(rooms=pmin(rooms,10)) |>
  #filter(AGEGRP != "15 to 17 years") |>
  summarize(
    count = sum(WEIGHT),
    .by = c(rooms,CMA,Year)
  )


room_over_time |>
  mutate(name=paste0(rooms," rooms") |> recode("10 rooms"="10+ rooms") |> fct_reorder(rooms)) |>
  filter_metros() |>
  ggplot(aes(x=Year, y=count,fill=name)) +
  geom_col(position="fill") +
  scale_x_continuous(breaks=seq(1991,2021,by=5)) +
  scale_y_continuous(labels=scales::percent) +
  theme(axis.text.x = element_text(angle=45, hjust=1),
        legend.position = "bottom") +
  labs(title="Distribution of number of rooms per home",
       fill="# rooms",
       y="Share of homes",
       x=NULL,
       caption="StatCan Census 2021 PUMF (individuals)") +
  facet_grid(~CMA)

The low share of especially 1-room homes in some regions explains the volatility in the shelter cost per room metric for 1-room homes. We also note that the share of low-room count homes increases especially in regions with growing housing shortages, which likely contributes to the increase in shelter cost per room over time. This is consistent with the explanation that the increase in the number of low-room homes is driven by people’s desire for privacy of their own home, and being forced to economize on size where they face less competition from people economizing by doubling up.

This suggests that adjusting for the changing distribution of the number of rooms per home across geographies and time might be useful to account for the economies of scale relating overall floor space to the number of rooms, while at the same time cautioning against doing this because of higher rent/sf for smaller units and variations in the distribution of the number of rooms being driven by housing shortages. For the rest of the post we will keep it simple and not adjust for the number of rooms, but Figure 4 shows the shelter cost per room adjusted for the changing distribution of the number of rooms per home to help gauge the potential impacts of doing such adjustment to our baseline Figure 1.

<code>

pd_all_adj <- pumf_all_r |>
  filter(PRIHM %in% c("Person is primary maintainer","Primary household maintainer",
                      "PrimaryHhldMaintainr")) |>
  filter(!is.na(rooms)) |>
  mutate(rooms=pmin(rooms,10)) |>
  summarize(
    avg_shelco_per_room = weighted.mean(SHELCO_real/rooms, w = WEIGHT, na.rm=TRUE),
    people=sum(WEIGHT),
    .by = c(CMA,Year,rooms)
  ) |>
  left_join(
    room_over_time |>
      filter_metros() |>
      summarise(total_rooms = sum(count), .by = c(rooms)),
    by=c("rooms")
  ) |>
  summarize(
    avg_shelco_per_room = weighted.mean(avg_shelco_per_room, w = total_rooms),
    .by = c(CMA,Year)
  )


pd_all_adj |>
  filter_metros() %>%
  mutate(CMA=factor(CMA,levels=filter(.,Year==2021) |> arrange(-avg_shelco_per_room) |> pull(CMA))) |>
  #filter(AGEGRP != "18 to 19 years") |>
  ggplot(aes(x=Year, y=avg_shelco_per_room, colour=CMA)) +
  geom_line() +
  scale_x_continuous(breaks=seq(1991,2021,by=5)) +
  scale_y_continuous(labels=scales::dollar_format(prefix="$")) +
  theme(axis.text.x = element_text(angle=45, hjust=1)) +
  labs(title="Running shelter costs per room in Canada  (adjusted by number of rooms)",
       colour="Metro area",
       y="Monthly shelter cost per room (2021 dollars)",
       x=NULL,
       caption="StatCan Census 2021 PUMF (individuals)") 

As one would expect, adjusting for the distribution of number of rooms dampens the growth in shelter cost per room for Toronto and Vancouver, which saw the largest increases in the share of low-room count homes, and increases the relative position of Calgary, which has a large share of high-room count homes. But the overall patterns remain similar to the unadjusted results.

If one wanted to refine the results of this post one could take a more principled approach and choose a more structured way to adjust for the changing distribution of the number of rooms, similar to what we did when constructing first-time buyer Lorentz curves. (Stewart and von Bergmann 2020, 2024)

pd_all_r <- pumf_all_r |>
  filter(PRIHM %in% c("Person is primary maintainer","Primary household maintainer",
                      "PrimaryHhldMaintainr")) |>
  filter(!is.na(rooms),
         AGEGRP != "Not available") |>
  mutate(rooms=pmin(rooms,10)) |>
  summarize(
    avg_shelco_per_room = weighted.mean(SHELCO_real/rooms, w = WEIGHT, na.rm=TRUE),
    people=sum(WEIGHT),
    .by = c(AGEGRP,CMA,Year)
  )  

Age

We were drawn into this because of the age disparity in the UK data, and we want to understand the shelter cost per room by age. How do running shelter costs per room differ for people in different age groups? Here we first need to revisit the question of the universe over which we are estimating this metric. For example, for 25 to 29 year olds, do we mostly care about the experience of those who formed independent households or do we also want to consider the experience of those living with their parents? We expect these two groups to face very different shelter cost pressures. In this post we mostly care about the former, so we again look at the household level and code the age group based on the age of the primary household maintainer, with the breakdown shown in Figure 5.

<code>

pd_all_r |>
  filter_metros() |>
  filter(AGEGRP != "15 to 17 years") |>
  #filter(AGEGRP != "18 to 19 years") |>
  ggplot(aes(x=Year, y=avg_shelco_per_room,colour=AGEGRP)) +
  geom_line() +
  scale_x_continuous(breaks=seq(1991,2021,by=5)) +
  scale_y_continuous(labels=scales::dollar_format(prefix="$")) +
  theme(axis.text.x = element_text(angle=45, hjust=1)) +
  labs(title="Running shelter costs per room in Canada",
       colour="Age of primary\nhousehold maintainer",
       y="Monthly shelter cost per room (2021 dollars)",
       x=NULL,
       caption="StatCan Census 2021 PUMF (individuals)") +
  facet_wrap(~CMA)

This shows a fairly consistent pattern with younger people having higher shelter costs per room, and shelter costs per room declining as we move upward through the age groups. There is variance in the size of the spread, as well as how it increased over time. And the sample gets thin for some age groups in some regions, in particular the 18 to 19 year old bracket, leading to some noise. The Québec City metro area again stands out with it’s low spread and fairly flat development over time. Toronto and Vancouver again show the largest spread and largest increase.

Following the lead of how the UK data was sliced, Figure 6 arranges the information into coarser age groups for easier readability.

<code>

recode_broad_age_groups <- function(data){
  data |>
    mutate(AGEGRP=recode(AGEGRP,
           "15 to 17 years"="15 to 29 years",
           "18 to 19 years"="15 to 29 years",
           "20 to 24 years"="15 to 29 years",
           "25 to 29 years"="15 to 29 years",
           "30 to 34 years"="30 to 44 years",
           "35 to 39 years"="30 to 44 years",
           "40 to 44 years"="30 to 44 years",
           "45 to 49 years"="45 to 64 years",
           "50 to 54 years"="45 to 64 years",
           "55 to 59 years"="45 to 64 years",
           "60 to 64 years"="45 to 64 years",
           "65 to 69 years"="65 years and over",
           "70 to 74 years"="65 years and over", 
           "75 to 79 years"="65 years and over",
           "80 to 84 years"="65 years and over",
           "85 years and over"="65 years and over",
           "0 to 4 years" = "0 to 14 years",
           "5 to 6 years" = "0 to 14 years",
           "7 to 9 years" = "0 to 14 years",
           "10 to 11 years"  = "0 to 14 years",   
           "12 to 14 years" = "0 to 14 years")
  )
}

grouped_age_data <- pumf_all_r |>
  filter(PRIHM %in% c("Person is primary maintainer","Primary household maintainer",
                      "PrimaryHhldMaintainr")) |>
  filter(!is.na(rooms),
         AGEGRP != "Not available") |>
  mutate(rooms=pmin(rooms,10)) |>
  #filter(AGEGRP != "15 to 17 years") |>
  recode_broad_age_groups() |>
    summarize(
    avg_shelco_per_room = weighted.mean(SHELCO_real/rooms, w = WEIGHT, na.rm=TRUE),
    rooms=sum(rooms*WEIGHT),
    people=sum(WEIGHT),
    .by = c(AGEGRP,CMA,Year)
  ) 

coarse_age_colours <- setNames(RColorBrewer::brewer.pal(5,"Dark2"),
                               c("0 to 14 years","15 to 29 years","30 to 44 years",
                                 "45 to 64 years","65 years and over"))

grouped_age_data |>
  filter_metros() |>
  ggplot(aes(x=Year, y=avg_shelco_per_room,colour=AGEGRP)) +
  geom_line() +
  scale_color_manual(values=coarse_age_colours) +
  scale_x_continuous(breaks=seq(1991,2021,by=5)) +
  scale_y_continuous(labels=scales::dollar_format(prefix="$")) +
  theme(axis.text.x = element_text(angle=45, hjust=1)) +
  labs(title="Running shelter costs per room in Canada",
       colour="Age of primary\nhousehold maintainer",
       y="Monthly shelter cost per room (2021 dollars)",
       x=NULL,
       caption="StatCan Census 2021 PUMF (individuals)") +
  facet_wrap(~CMA)

This is a good time to pause and think about how one might interpret this information. Increases in cost over time track fairly well with our understanding of housing shortages, with Québec City demonstrating very little shortage and Vancouver and Toronto demonstrating a lot. (Lauster and von Bergmann 2024) The differences by age are more difficult to interpret, they could be due to older people having been able to lock in housing costs in the past, having bought a home quite some time ago or benefiting from rent control after renting for a long time. But it could also be that older people tend to live in roomier places in the suburbs, benefiting from economies of scale, while younger people choose to live in more central locations, near more amenities, or in higher quality homes, which tend to have higher rents and prices. To disentangle this we can condition on renters, which removes the effects of e.g. people having low shelter costs because they have paid down their mortgage. We can also condition on recent movers to remove most of the effect of rent control. Figure 7 shows how this group fares over time.

<code>

movers_cats <- c("Non-migrants", "Different CSD, same census division", "Different CD, same province", "Interprovincial migrants", "External migrants", "Movers: Non-migrants", "Movers: Migrants: Internal migrants: Intraprovincial migrants: Different CSD, same census division - CD", "Movers: Migrants: Internal migrants: Intraprovincial migrants: Different CD, same province", "Movers: Migrants: Internal migrants: Interprovincial migrants", "Movers: Migrants: External migrants", "MoversNonmigrant", "DifferentCSDSameCD", "DifferentCDSameProv", "InterprovinclMigrant", "External Migrants", "Intraprovincial movers", "Interprovincial movers")

grouped_age_data_movers <- pumf_all_r |>
  filter(PRIHM %in% c("Person is primary maintainer","Primary household maintainer",
                      "PrimaryHhldMaintainr")) |>
  filter(MOB1 %in% movers_cats) |>
  filter(TENUR=="Renter") |>
  filter(!is.na(rooms),
         AGEGRP != "Not available") |>
  mutate(rooms=pmin(rooms,10)) |>
  #filter(AGEGRP != "15 to 17 years") |>
  recode_broad_age_groups() |>
    summarize(
    avg_shelco_per_room = weighted.mean(SHELCO_real/rooms, w = WEIGHT, na.rm=TRUE),
    rooms=sum(rooms*WEIGHT),
    people=sum(WEIGHT),
    cases=n(),
    .by = c(AGEGRP,CMA,Year)
  ) 

grouped_age_data_movers |>
  filter_metros() |>
  ggplot(aes(x=Year, y=avg_shelco_per_room,colour=AGEGRP)) +
  geom_line() +
  scale_color_manual(values=coarse_age_colours) +
  scale_x_continuous(breaks=seq(1991,2021,by=5)) +
  scale_y_continuous(labels=scales::dollar_format(prefix="$")) +
  theme(axis.text.x = element_text(angle=45, hjust=1)) +
  labs(title="Running shelter costs per room of renters who moved in the preceding year",
       colour="Age of primary\nhousehold maintainer",
       y="Monthly shelter cost per room (2021 dollars)",
       x=NULL,
       caption="StatCan Census 2021 PUMF (individuals)") +
  facet_wrap(~CMA)

This considerably narrows the spread across age groups. Data on recent renter movers in the senior age bracket should be interpreted with some caution due to the low number of cases in our sample, but overall trends indicated an interesting reversal for the senior age bracket which now shows up on top in many metro areas. Given our selection, it’s possible that in some cases shelter costs here might be picking up on ways that seniors newly moving into retirement communities and assisted living facilities see the costs of extra services bundled into their rents. Nevertheless, Toronto and Vancouver still show younger age groups with higher shelter costs per room, which is consistent with the hypothesis that some of the spread could be due to different preferences in location and roominess tradeoffs.

But there are some other factors that might play into this too. Household formation and tenure choice are both downstream of housing pressures, so conditioning on them can lead to collider bias, as we have previously explained. (von Bergmann and Lauster 2023; Lauster and Bergmann 2025; Lauster and von Bergmann 2024). We have proposed two measures of housing frustration based on household formation and tenure choice that can help quantify these pressures (von Bergmann and Lauster 2024), as shown in Figure 8 that we include here again for convenience. The housing frustration metric shows very high levels of suppressed household formation especially in Vancouver and Toronto that could explain some of the age patterns we see here via selection of richer folks into independent households among younger age groups. The question about tenure choice is more complicated and the relationship to the different spreads between age groups is less clear.

We can dig down a little deeper by examining how owners and renters differ in their ability to lock in lower shelter costs over time. Figure 9 splits the data by tenure, for a smaller selection of metro areas to keep things simple.

<code>

tenure_age_data <- pumf_all_r |>
  filter(PRIHM %in% c("Person is primary maintainer","Primary household maintainer",
                      "PrimaryHhldMaintainr")) |>
  filter(!is.na(rooms),
         AGEGRP != "Not available") |>
  filter(TENUR %in% c("Renter","Owner")) |>
  mutate(rooms=pmin(rooms,10)) |>
  #filter(AGEGRP != "15 to 17 years") |>
  recode_broad_age_groups() |>
    summarize(
    avg_shelco_per_room = weighted.mean(SHELCO_real/rooms, w = WEIGHT, na.rm=TRUE),
    rooms=sum(rooms*WEIGHT),
    people=sum(WEIGHT),
    .by = c(AGEGRP,CMA,Year,TENUR)
  ) 


tenure_age_data |>
  filter_metros() |>
  filter(grepl("Toronto|Vancouver|Calgary|Montr",CMA)) |>
  ggplot(aes(x=Year, y=avg_shelco_per_room,colour=AGEGRP)) +
  geom_line() +
  scale_color_manual(values=coarse_age_colours) +
  scale_x_continuous(breaks=seq(1991,2021,by=5)) +
  scale_y_continuous(labels=scales::dollar_format(prefix="$")) +
  theme(axis.text.x = element_text(angle=45, hjust=1)) +
  labs(title="Running shelter costs per room in Canada",
       colour="Age of primary\nhousehold maintainer",
       y="Monthly shelter cost per room (2021 dollars)",
       x=NULL,
       caption="StatCan Census 2021 PUMF (individuals)") +
  facet_grid(CMA~TENUR)

Here we see how owners diverge more than renters. Some of this divergence may reflect the effects of the roominess-location tradeoff and economies of scale, insofar as households tend to move toward the suburbs as they age. But it’s also the case that older owners are especially likely to have locked in lower shelter costs by buying increasingly expensive properties earlier in time than in younger owners, and they’ve also had longer to pay down their mortgages. For renters, by contrast, both young and old are relatively more exposed to the current housing market. Nevertheless, comparing back to Figure 7 it does appear that older renters in Toronto and Vancouver may still be benefiting from a cushion due to rent control interacting with longer term tenancies.

Figure 10 offers another way to look at age variation for owners. As noted earlier, actual shelter costs are distinct from housing services consumed, with the latter incorporating a measure of rent that owner-occupiers are understood to be paying to themselves. Here we compare the value of housing services consumed, as measured by imputed rent - which we estimate by applying a 4% CAP rate to the reported value of each home - to the reported running shelter costs that we have been using so far.

<code>

imputed_rent_age_data <- pumf_all_r |>
  filter(PRIHM %in% c("Person is primary maintainer","Primary household maintainer",
                      "PrimaryHhldMaintainr")) |>
  filter(!is.na(rooms),
         AGEGRP != "Not available") |>
  filter(TENUR %in% c("Owner")) |>
  mutate(rooms=pmin(rooms,10)) |>
  #filter(AGEGRP != "15 to 17 years") |>
  recode_broad_age_groups() |>
    summarize(
    avg_shelco_per_room = weighted.mean(SHELCO_real/rooms, w = WEIGHT, na.rm=TRUE),
    avg_imputed_rent_per_room= weighted.mean((VALUE/CPI*0.04/12)/rooms, w = WEIGHT, na.rm=TRUE),
    rooms=sum(rooms*WEIGHT),
    people=sum(WEIGHT),
    .by = c(AGEGRP,CMA,Year,TENUR)
  ) 


imputed_rent_age_data |>
  pivot_longer(matches("avg_")) |>
  mutate(name=recode(name,
                       "avg_shelco_per_room"="Reported shelter cost per room",
                       "avg_imputed_rent_per_room"="Imputed rent per room")) |>
  filter_metros() |>
  filter(grepl("Toronto|Vancouver|Calgary|Montr",CMA)) |>
  ggplot(aes(x=Year, y=value,colour=AGEGRP)) +
  geom_line() +
  scale_color_manual(values=coarse_age_colours) +
  scale_x_continuous(breaks=seq(1991,2021,by=5)) +
  scale_y_continuous(labels=scales::dollar_format(prefix="$")) +
  theme(axis.text.x = element_text(angle=45, hjust=1)) +
  labs(title="Running imputed rent to shelter costs per room in Canada for owner-occupiers",
       colour="Age of primary\nhousehold maintainer",
       y="Monthly shelter cost per room (2021 dollars)",
       x=NULL,
       caption="StatCan Census 2021 PUMF (individuals)") +
  facet_grid(CMA~name)

The age divergence mostly disappears when we look at housing services consumed by owners. This underscores the takeaway from Figure 7 that the main driver of the spread between age groups is not a preference effect, but rather how renters tend to gradually become owners and longer term owners are able to lock in lower shelter costs over time. Savings, including building up equity, can also help older owners cash out when they move and put up large downpayments on new homes. So even if older owners are theoretically paying themselves high rents as owner-occupiers of their new homes, the mortgage payments contributing directly to their shelter costs stay lower than for younger homeowners.

Upshot

What does all of this mean for our understanding of housing pressures faced by different age groups in Canada? We know from a lot of our previous work, and as shown in Figure 8, that younger people are forming households at successively lower rates in areas with growing housing shortages. At the same time, we see that young people increasingly face higher shelter costs per room compared to their older compatriots. Figure 7 leads us to believe that this cannot be simply explained by changing preferences of younger people. Instead, the divergence shown in Figure 5 and Figure 6 seems mostly due to older people having on average lived in their homes longer and having locked in lower shelter costs in the past, often while transitioning from renter to homeowner. This means that older people are, on average, still somewhat insulated from current pressures in the housing market, and younger people, on average, face the brunt of the current housing shortage in Canada. Worth noting that these averages, of course, still hide a great deal of variability within each age group.

Household formation and housing costs are connected. Rising housing costs depress household formation, and in turn shortages that mechanically lead to depressed household formation also heighten competition for any housing coming to market. These are two sides of the same coin, as evidenced when directly comparing housing costs to household formation. (von Bergmann and Lauster 2025)

At the same time it’s important to recognize that this is not a Canada-wide problem. The Québec City metro area has managed to avoid housing shortages, and real prices per room have remained fairly flat. Rising incomes in Québec City have allowed households to form at increasing rates, with the result being improved housing outcomes. This may in part be due to the Québec City metro area not facing the same population pressures as some of the other regions. But we can also see that Calgary, the metro area with the highest population growth among our sample, has done a much better job at keeping up with demand and mitigating housing shortages than some of the lower growth regions.

As usual, the code for this post is available on GitHub for anyone to reproduce or adapt for their own purposes.

## datetime
Sys.time()

[1] "2025-10-25 21:34:42 PDT"

## repository
git2r::repository()

Local:    main /Users/jens/R/mountain_doodles
Remote:   main @ origin (https://github.com/mountainMath/mountain_doodles.git)
Head:     [841cf37] 2025-10-26: key image for extra school tax calculator post

## Session info 
sessionInfo()

R version 4.5.1 (2025-06-13)
Platform: aarch64-apple-darwin20
Running under: macOS Tahoe 26.0.1

Matrix products: default
BLAS:   /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRblas.0.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.12.1

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/Vancouver
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
 [1] vctrs_0.6.5               cli_3.6.5                
 [3] knitr_1.50                rlang_1.1.6              
 [5] xfun_0.53                 generics_0.1.4           
 [7] S7_0.2.0                  jsonlite_2.0.0           
 [9] glue_1.8.0                git2r_0.36.2             
[11] htmltools_0.5.8.1         mountainmathHelpers_0.1.4
[13] scales_1.4.0              rmarkdown_2.30           
[15] grid_4.5.1                evaluate_1.0.5           
[17] tibble_3.3.0              fastmap_1.2.0            
[19] yaml_2.3.10               lifecycle_1.0.4          
[21] compiler_4.5.1            dplyr_1.1.4              
[23] RColorBrewer_1.1-3        htmlwidgets_1.6.4        
[25] pkgconfig_2.0.3           rstudioapi_0.17.1        
[27] farver_2.1.2              digest_0.6.37            
[29] R6_2.6.1                  tidyselect_1.2.1         
[31] pillar_1.11.1             magrittr_2.0.4           
[33] tools_4.5.1               gtable_0.3.6             
[35] ggplot2_4.0.0            

Vancouver multiplexes

The province drew upon our research in formulating its Small Scale Multi Unit Housing (SSMUH) reforms, mandating all municipalities allow multiplex on previously single-family lots (as of November 2023). The City of Vancouver was working on its own multiplex reform, and snuck under the wire by passing a bylaw that reclassified single-family lots to multiplex in October of 2023, just before the lots at issue would have come under provincial regulation.¹ We take this as an occasion to take stock of how Vancouver multiplexes have fared so far. We don’t have enough data to do a thorough analysis like we did for Kelowna and Coquitlam, but there is enough to take a preliminary look.

Prior to the multiplex legislation Vancouver allowed three units on most single family lots at 0.85 FSR under single ownership or up to four units structured as two strata lots with a main unit and a lock-off suite each for a combined 0.7 FSR. The multiplex legislation allowed for more freedom on how to configure units and increased the allowable density to 1 FSR. However, going beyond duplex and additions to floor space both remained conditional uses rather than outright, requiring contributions of various sorts to the City and close planner review. Contributions to the City were subjected to value capture analysis intended to balance out construction of multiplex with single detached and duplex. Subsequently the bylaw has been amended to allow up to six units in frequent transit areas as well as an expansion of the area that allows for multiplex as required by provincial SSMUH legislation. Of note, the density requirements remain far below the provincial guidelines of an implicit 1.5 to 1.6 FSR despite being in one of the the highest demand areas in the province.

get_plpos_data_for_range <- function(start_date,end_date,cache_path=tempdir(),permit_type=NULL, refresh=FALSE) {
  
  url <- "https://plposweb.vancouver.ca/Public/Default.aspx?PossePresentation=PermitSearchByDate"
  hash <- digest::digest(paste0(url,"-",start_date,"-",end_date,"-",permit_type))
  cache_file <- file.path(cache_path,paste0("pplos_",hash,".rds"))
  if (file.exists(cache_file) && !refresh) {
    return(read_rds(cache_file))
  }
 
  datachanges <- paste0("'AP0pCEcP9fH5dRPaDCclXjvW/RWG6DuU1GJqdoYCJdeMEyQgezIdkf31vuOO6FHEH8/cUCRQrVyF1WbfAGq8Y/T9t4QFxQutWcQbJVh9WHzZCVQ7Zpc6O75JEskEPmBFKDdtN0yeAWQB0yz6jVU1Yc8hGYZMN/whBxaSFWd5K6Zxe7JaoDMkr7AMmQw58VwFKYfL2AI7D4EPpAw98aeD/JCbWPGBB2DrVpwBAnIK6UTqiFwKdpteDDJp54Xpxn6dY3U2WldqXWhkTkpvRlhlYQ%3D%3D'",",",
                        "('C','S0',972146,'",start_date," 00:00:00')",",",
                        "('C','S0',984849,'",end_date," 00:00:00')",",")
  if (!is.null(permit_type)) {
    datachanges <- paste0(datachanges,"('C','S0',1039023,'",permit_type,"')",",")
  }
  datachanges <- paste0(datachanges,
                        "('C','S0',972146,'",start_date," 00:00:00')",",",
                        "('C','S0',984849,'",end_date," 00:00:00')",",",
                        "('F','ext-gen1009',0,0)")
  
  result <- httr::POST(url, body = list(datachanges = datachanges,
                                        currentpaneid= 1018439, 
                                        functiondef= 5,
                                        comesfrom= "posse",
                                        sortcolumns= "{}",
                                        paneid= 987904),
                       encode = "form")
  
  if (result$status_code != 200) {
    stop("Failed to fetch data")
  }
  
  content <- httr::content(result)
  
  # data <- html_table(content, fill = TRUE)[[1]]
  
  table <- content |> 
    rvest::html_node("table")
  
  header <- table|> html_nodes("th.possegrid") |>
    html_text()
  
  if (length(header)==0) {
    message("No data found: ",start_date," - ",end_date)
    return (NULL)
  }
  
  header[1]="X"
  
  data <- table |>
    html_nodes("tbody") |>
    map_df(\(tb){
      d<-tb |> html_nodes("td.possegrid") |>
        html_text() |>
        as.character() |> 
        setNames(header) |> 
        enframe() |> 
        pivot_wider() |>
        mutate(url=tb |> html_nodes("a") |> html_attr("href"))
    })  |>
    mutate(across(matches("Date"),\(x)gsub(".+\\n","",x) |> 
                    as.Date(format="%B %d, %Y"))) |>
    select(-X)
  
  write_rds(data,cache_file)
  data
}

get_detail_plpos_data <- function(url,cache_path=tempdir(),refresh=FALSE) {
  hash <- digest::digest(url)
  cache_file <- file.path(cache_path,paste0("pplos_",hash,".rds"))
  if (file.exists(cache_file) && !refresh) {
    return(read_rds(cache_file))
  }
  html<-read_html(url)
  
  tables <- html_table(html)

  zoning_table <- map_df(tables, \(tb){
    r <- NULL
    if (ncol(tb)>=2 && nrow(tb)>=1 && !is.na(tb[1,2]) && tb[1,2]=="Zoning Code") {
      r <- tb |> select(-1) |> 
        setNames(c("name","value")) |> 
        filter(name!="") |> 
        filter(!duplicated(name,value)) |>
        pivot_wider()
    }
    r
  })
  
  # sanity check
  if ("Zoning Code" %in% names(zoning_table) && is.list(zoning_table$`Zoning Code`)) {
    print(url)
  }
   
  details <- html |> html_nodes("span.possedetail")
  detailsg <- html |> html_nodes("span.possegrid")
  
  wd <- which(grepl("WorkDescription",details |> html_attr("id")))
  wt <- which(grepl("TypeOfWork",details |> html_attr("id")))
  wpid <- which(grepl("ParcelID",detailsg |> html_attr("id")))
  wfolio <- which(grepl("FormattedAccountNumber",details |> html_attr("id")))
  
  # permit_status <- html |> html_nodes("div.permitStatusDisplay") |> html_text()
  
  dd<-tibble(`Work Description`=details[wd] |> html_text(),
         `Type of Work`=details[wt] |> html_text(),
         PID=paste0(detailsg[wpid] |> html_text(),collapse = ", "),
         Folio=paste0(detailsg[wpid] |> html_text(),collapse = ", ")) 
  if (nrow(zoning_table)>0) {
    dd <- dd |> bind_cols(zoning_table)
  }

  dd<- dd |>  mutate(url=url)
  write_rds(dd,cache_file)
  dd
}


start_date <- as.Date("2023-10-01") # date permit data seems to start in the system
end_date <- as.Date("2025-08-27") # Sys.Date()

dp_data <- seq(start_date,end_date,by="1 month") |>
  map_dfr(\(d){
    get_plpos_data_for_range(start_date=d,
                             end_date=d %m+% months(1),
                             cache_path = pplos_cache_path,
                             permit_type="Development Permit")
  }) |>
  unique()

bp_data <- seq(start_date,end_date,by="1 month") |>
  map_dfr(\(d){
    #if (strftime(d,"%m")=="01") print(paste0("Starting ",d))
    get_plpos_data_for_range(start_date=d,
                             end_date=d %m+% months(1),
                             cache_path = pplos_cache_path,
                             permit_type="Building Permit")
  }) |>
  unique()

recent_dp_details <- dp_data |> 
  filter(`Created Date`>=as.Date('2023-10-17')) %>%
  left_join(.$url |> map_df(\(x){
    get_detail_plpos_data(x,cache_path=pplos_cache_path)
  },.progress=TRUE), by="url")

recent_bp_details <- bp_data |>
  filter(`Created Date`>=as.Date('2023-10-17')) %>%
  left_join(.$url |> map_df(\(x){
    get_detail_plpos_data(x,cache_path=pplos_cache_path)
  },.progress=TRUE), by="url")

multiplexes_dp <- recent_dp_details |>
  filter(grepl("multiplex",`Work Description`,ignore.case = TRUE),
         `Zoning Code`=="R1-1",
         `Type of Work`=="New Building") 
multiplexes_bp <- recent_bp_details |> 
  filter(grepl("multiplex",`Work Description`,ignore.case = TRUE),
         #`Zoning Code`=="R1-1",
         `Type of Work`=="New Building") 

status_levels <- c("Created","In Review","Preparing Recommendation",
                   "Response to Conditions","Approved Subject to Conditions",
                   "Stop Work",
                   "Ready For Issue","Issued", "Completed")

pd <- multiplexes_dp |>
  bind_rows(multiplexes_bp |> 
              filter(PID %in% multiplexes_dp$PID)) %>%
  mutate(PID=factor(PID,levels=filter(.,Type=="Development Permit") |> 
                      arrange(`Created Date`) |> pull(PID) |> unique())) |>
  mutate(min_date=min(`Created Date`),
         max_date=pmax(max(`Created Date`),
                       max(`Issue Date`,na.rm=TRUE),
                       max(`Completed Date`,na.rm=TRUE)),
         .by=PID) |>
  mutate(Status=factor(Status,levels=status_levels))
  
permit_colours <- setNames(RColorBrewer::brewer.pal(9,"Set1") |> rev(),status_levels)

status_counts <- pd |> 
  select(Type,Status,PID) |>
  distinct() |>
  count(Type,Status) 

So far in Vancouver there have been 429 development permit applications for multiplexes, of which 143 have been issued (or completed) and subsequently 123 building permits have been issued (or completed).² Table Table 1 table gives a more detailed breakdown.

status_counts |>
  rename(`Number of multiplexes`=n) |>
  arrange(desc(Type)) |>
  tinytable::tt()

Our data does not come with clean unit counts, a scan of permit detail descriptions indicates that a little below half of multiplex applications are for fourplexes, with the next popular configuration being triplexes at around 30%.

Figure 2 shows how multiplex applications have been progressing.

<code>

fit.dp <- lm(rank ~ `Created Date`, data= pd |>
  filter(Type=="Development Permit") |>
  arrange("Created Date") |>
  mutate(rank=row_number()))

slope.dp <- coefficients(fit.dp)[2] |> as.numeric()

eligible_zones <- c("R1-1","RT-7","RT-9","FSD")
eligible_parcels <- aggregate_cov_data("property-tax-report",
                                       where="tax_assessment_year='2025'",
                                       group_by='zoning_district') |>
  filter(zoning_district %in% c(eligible_zones)) |>
  pull(count) |>
  sum()

pd |>
  ggplot(aes(y=PID,shape=Type,colour=Status)) +
  geom_point(data=~mutate(.,Status=if_else(is.na(`Issue Date`),"Created",Status)) |>
               mutate(Status=factor(Status,levels=status_levels)),
             aes(x=`Created Date`)) +
  geom_point(data=~filter(.,!is.na(`Issue Date`)) |> mutate(Status = recode(Status, "Completed"="Issued")), 
                          aes(x=`Issue Date`)) +
  geom_point(data=~filter(.,!is.na(`Completed Date`)),aes(x=`Completed Date`)) +
  geom_segment(aes(x=min_date,xend=max_date,yend=PID),linewidth =0.25,linetype="dashed",colour="black") +
  theme(axis.text.y = element_blank(),
        panel.grid.major.y = element_blank(),
        panel.grid.minor.y = element_blank(),
        axis.ticks.y = element_blank()) +
  scale_colour_manual(values=permit_colours,breaks=names(permit_colours) |> rev()) +
  scale_shape_manual(values=c(21,16),breaks=c("Development Permit","Building Permit")) +
  scale_x_date(date_breaks = "1 month",date_labels = "%b") +
  labs(y=NULL,x=NULL,title="Multiplex Development Permits in the City of Vancouver",
       caption="Data: PLPOS")

Starting the clock in November of 2023, development permit applications are coming in at an average pace of 23 per month so far, or about 273 per year, almost double of the 150 applications a year that Vancouver staff originally projected. Translated into a redevelopment rate of the roughly 69,000 eligible single family parcels in Vancouver this means that at the current rate each parcel has about a 0.4% percent chance of redevelopment each year, about double what Coquitlam saw after their upzoning but less than a tenth Kelowna’s outcomes.

permit_tmielines <- pd %>%
  filter(PID %in% filter(.,Type=="Building Permit",
                         Status %in% c("Issued","Completed"))$PID) |>
  filter(Status %in% c("Issued","Complted")) |>
  summarize(start=first(`Created Date`),end=last(`Issue Date`),.by=PID) |>
  mutate(diff=end-start) 

Figure 3 shows the distribution of permitting timelines, from creating of the development permit to issuance of building permit, conditioning on having an issued building permit. The right-censored nature of the data makes it difficult to give definitive statements about permit times, a strong lower bound on permit times derived from is 350 days, with a wide distribution ranging from very fast permit times of 200 days at the low end and over 500 days at the high end so far.

<code>

permit_tmielines |>
  ggplot(aes(x=diff)) +
  geom_histogram(bins=30) +
  geom_vline(aes(xintercept=mean(diff)),colour="red") +
  theme(axis.text.y=element_blank()) +
  labs(title="City of Vancouver R1-1 multiplex permit time",
       y=NULL,
       x="Number of days (DP submission to BP issued)")

Figure 4 shows permit timelines ordered by creation data, with blank lines where building permits have not yet been issued.

<code>

permit_levels <- c("Development permit","Development permit (Pending)","Parallel development/building permit","Application gap","Building permit","Building permit (Pending)")

pd |>
  summarize(`Created Date`=first(`Created Date`),`Issue Date`=last(`Issue Date`),
            last_type=first(Type,order_by=Type),
            .by=c(PID)) |>
  mutate(PID=fct_reorder(PID,`Created Date`)) |>
  mutate(Days=`Issue Date`-`Created Date`) |>
  mutate(Days=ifelse(last_type=="Development Permit",NA,Days)) |>
  ggplot(aes(y=PID,x=Days)) +
  geom_bar(stat="identity",data=~mutate(.,Days=coalesce(Days,0))) +
  theme(axis.text.y = element_blank(),
        panel.grid.major.y = element_blank(),
        panel.grid.minor.y = element_blank(),
        axis.ticks.y = element_blank()) +
  geom_vline(aes(xintercept=mean(Days,na.rm=TRUE)),colour="red") +
  labs(title="Permit time for multiplexes",
       y=NULL,
       x="Number of days from DP application created in the system until BP issued",
       caption="Data: PLPOS")

A naive interpretation might suggest that permit times are decreasing, but it would be foolish to conclude that from this graph. The blank spaces of projects that have not yet received a building permit highlight the right-censored nature of the data and signal projects with outstanding permits that, once they get issues, will necessarily have longer permit times than nearby (in terms of creation date) permit applications that have already been issued building permits. Vancouver council’s 3-3-3-1 Permit Approval Framework, which suggests that multiplex permits should be given in 3 weeks, is clearly not working yet, and there is no strong indication of improvement in multiplex permitting timelines.

Figure 5 offers a view into the landscape of low-density development in the R1-1, RT-7, RT-9, and FSD zones that legalized multiplexes by tracking issued building permits for single family, duplex, and multiplexes by year the permit was issued.

<code>

zoning <- get_cov_data("zoning-districts-and-labels")
zoning_mask <- zoning |> filter(zoning_district %in% eligible_zones)
building_permits <- get_cov_data("issued-building-permits",
                                 where="typeofwork='New Building' AND propertyuse = 'Dwelling Uses'") |>
  sf::st_filter(zoning_mask) |>
  filter(issuedate <= as.Date("2025-08-28")) # pin end date

processed_permits_raw <- building_permits |>
  filter(permitcategory %in% c('New Build - Low Density Housing','New Build - Standalone Laneway') |
           permitnumber %in% multiplexes_bp$Number) |>
  mutate(use=case_when(permitnumber %in% multiplexes_bp$Number ~ "Multiplex",
                       specificusecategory %in% c("Laneway House","Duplex") ~ specificusecategory,
                       specificusecategory %in% c("Single Detached House w/Sec Suite","1FD w/ Family Suite","Principal Dwelling Unit w/Lock Off","Secondary Suite,Single Detached House w/Sec Suite","Single Detached House w/Sec Suite,Single Detached House") ~ "SFH w/Sec Suite",
                       specificusecategory %in% c("Single Detached House") ~ "SFH",
                       specificusecategory %in% c("Duplex w/Secondary Suite","Duplex w/Secondary Suite,Secondary Suite","Duplex,Lock -off Unit","Secondary Suite,Duplex w/Secondary Suite","Duplex,Secondary Suite","Lock -off Unit,Duplex","Lock -off Unit,Duplex w/Secondary Suite","Duplex w/Secondary Suite,Lock -off Unit","Duplex,Lock -off Unit,Secondary Suite") ~ "Duplex w/Sec Suite",
                       TRUE ~ "Other")) %>%
  sf::st_transform(mountainmathHelpers::lambert_conformal_conic_at(.))

processed_permits <- processed_permits_raw |>
  filter(use != "Laneway House") |>
  sf::st_join(processed_permits_raw |>
                filter(use == "Laneway House") |>
                select(LW_issueyear=issueyear) |>
                sf::st_buffer(5)) |>
  mutate(wLW=!is.na(LW_issueyear) & as.integer(issueyear)-as.integer(LW_issueyear) <=2 & as.integer(issueyear)-as.integer(LW_issueyear) >=0) |>
  mutate(use=case_when(wLW & use=="SFH" ~ "SFH w/LWH",
                       wLW & use=="SFH w/Sec Suite" ~ "SFH w/Sec Suite & LWH",
                       TRUE ~ use)) |>
  mutate(use=factor(use,levels=c("SFH","SFH w/Sec Suite","SFH w/LWH","SFH w/Sec Suite & LWH","Duplex","Duplex w/Sec Suite","Multiplex","Other")))

processed_permits |>
  filter(use!="Other") |>
  mutate(issueyear=recode(issueyear,"2025"="2025\n(up to Aug)")) |>
  ggplot(aes(x=issueyear,fill=fct_rev(use))) +
  geom_bar() +
  scale_fill_brewer(palette="Dark2") +
  labs(title = "Building permits for new buildings in area eligible for multiplexes since Oct 2023",
       x="Year permit was issued",y="Number of issued building permits",
       fill="Project type",
       caption="Data: CoV Open Data")

We see the shift away from almost exclusive single family housing (though often suited and some with laneway houses³) towards more duplexes and multiplexes, but the overall number of low-density building permits has not increased substantially. The multiplex reform has – by design – not led to a significant increase in the overall rate of redevelopment of low-density lots.

So far results from Vancouver’s multiplex reform appear to fall somewhere between Kelowna’s and Coquitlam’s. To be sure, new multiplex have entered the pipeline, but their progress has been stalled by permitting review. Developers continue to fall back on dwelling types (single-family house and duplex) offering less relief for housing shortages but enabled by outright approval processes, as well as those including secondary suites requiring conditional approval processes, but where developers have more experience and certainty working through permitting processes.

It’s worth noting that Vancouver’s overall density of 1 FSR is higher than both Kelowna and Coquitlam, but the base density allowed for existing single family use, including secondary suites and laneway houses, is also higher in Vancouver. Nevertheless, both remain lower than provincial guidelines for SSMUH. Moreover, demand to live in the area is higher in Vancouver, so it’s not clear how differences in density allowances translates.

Apart from differences in demand and existing vs updated density allowances, value capture efforts may be holding back some of the reform’s potential. The reform handicapped higher density multiplex options with amenity contributions to the City and/or other limitations (secured rental or “affordable ownership” units) put in place intentionally to keep land values low. Importantly, though the equity concerns go unrecognized by the City, this tips the scales to the benefit of the most expensive form of housing - single-family detached - and against prospective buyers willing to share land across multiple households. Nevertheless small-scale developers are proving more willing to try out the new forms on offer than anticipated by planning staff, perhaps in hopes that they can scale up multiplex in the future or otherwise better prepare themselves for future reforms.

A more successful multiplex reform would see the City actively encouraging multiplex instead of just conditionally permitting them under value capture conditions. Expediting permits for pre-approved forms of multiplex, as was done for Kelowna, would help! Of note, there have been moves in this direction. A OneCity proposal Streamlining the Provision of Duplex and Multiplex Housing in R1-1 Zoning exploring further reforms was put forward as a motion by Councillor Lucy Maloney in July and was unanimously approved by Council ahead of a forthcoming review of R1-1 zoning being prepared by staff. If, as we suggest, the devil is in the details for multiplex reform, there’s a still a chance to get him out!

More broadly, stepping out of the multiplex fixation, more successful housing reforms would see the City asking what form of housing would match demand to live in different parts of the city and generally work to enable those forms to get built. (von Bergmann and Lauster 2025) By contrast, the provincial SSMUH initiative just sets a new baseline for zoning, stepping up from single-family detached. The Transit-Oriented Area (TOA) initiative does the same by specifying new baselines near major transit investments. Cities can go beyond these minimums by allowing more people to share land for housing everywhere, and they can get an idea of what the outcomes will be by looking to current demand and proactively planning to let developers build to that demand. That doesn’t mean everywhere will look alike (indeed, its often planning constraints that reinforce cookie-cutter designs). Instead, providing greater flexibility for builders is likely to result in more diverse urban landscapes. Working through the implications for that kind of reform would return urban planning to a forward looking activity recognizing the value of city life for everyone rather than a backward looking activity reducing land values to protect the privileges of the select few who can still afford a full lot of their own.

As usual, the code for this post is available on GitHub for anyone to reproduce or adapt for their own purposes.

## datetime
Sys.time()

[1] "2025-10-25 21:35:06 PDT"

## repository
git2r::repository()

Local:    main /Users/jens/R/mountain_doodles
Remote:   main @ origin (https://github.com/mountainMath/mountain_doodles.git)
Head:     [841cf37] 2025-10-26: key image for extra school tax calculator post

## Session info 
sessionInfo()

R version 4.5.1 (2025-06-13)
Platform: aarch64-apple-darwin20
Running under: macOS Tahoe 26.0.1

Matrix products: default
BLAS:   /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRblas.0.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.12.1

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/Vancouver
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] VancouvR_0.1.9  rvest_1.0.5     httr_1.4.7      lubridate_1.9.4
 [5] forcats_1.0.1   stringr_1.5.2   dplyr_1.1.4     purrr_1.1.0    
 [9] readr_2.1.5     tidyr_1.3.1     tibble_3.3.0    ggplot2_4.0.0  
[13] tidyverse_2.0.0

loaded via a namespace (and not attached):
 [1] gtable_0.3.6              xfun_0.53                
 [3] htmlwidgets_1.6.4         websocket_1.4.4          
 [5] processx_3.8.6            tzdb_0.5.0               
 [7] vctrs_0.6.5               tools_4.5.1              
 [9] ps_1.9.1                  generics_0.1.4           
[11] proxy_0.4-27              pkgconfig_2.0.3          
[13] KernSmooth_2.23-26        RColorBrewer_1.1-3       
[15] S7_0.2.0                  lifecycle_1.0.4          
[17] git2r_0.36.2              compiler_4.5.1           
[19] farver_2.1.2              chromote_0.5.1           
[21] mountainmathHelpers_0.1.4 htmltools_0.5.8.1        
[23] class_7.3-23              yaml_2.3.10              
[25] later_1.4.4               pillar_1.11.1            
[27] classInt_0.4-11           tidyselect_1.2.1         
[29] digest_0.6.37             stringi_1.8.7            
[31] sf_1.0-21                 rprojroot_2.1.1          
[33] fastmap_1.2.0             grid_4.5.1               
[35] here_1.0.2                cli_3.6.5                
[37] magrittr_2.0.4            triebeard_0.4.1          
[39] e1071_1.7-16              withr_3.0.2              
[41] scales_1.4.0              promises_1.4.0           
[43] timechange_0.3.0          rmarkdown_2.30           
[45] otel_0.2.0                hms_1.1.4                
[47] evaluate_1.0.5            knitr_1.50               
[49] rlang_1.1.6               urltools_1.7.3.1         
[51] Rcpp_1.1.0                glue_1.8.0               
[53] DBI_1.2.3                 xml2_1.4.0               
[55] rstudioapi_0.17.1         jsonlite_2.0.0           
[57] R6_2.6.1                  units_1.0-0              

Low-density zoning

We can simplify away a lot of these complications by just looking at low-density zoning. There are still some concerns, for example the city made building multiplexes on the west side more expensive in order to preserve some west-side exclusivity. More importantly minimum lot sizes and frontages vary substantially and have the effect of suppressing land values to subsidize mansions and foster exclusion in some parts of town. But just looking at low-density zoning gives a more level playing field. For this we take R1-1 zoning (formerly mostly RS zoning), RT zoning, and Shaughnessy (FSD) zoning as “low-density”, with results shown in Figure 2.

<code>

plot_data2 <- plot_data |>
  mutate(FSR_floor =case_when(zoning_district %in% c("R1-1","FSD") |grepl("^RT-",zoning_district) ~ FSR_floor,
                                TRUE ~ NA)) |>
  mutate(FSR_floor_d=pretty_cut(FSR_floor, c(0.1,1,1.5,2,2.5,3,4,Inf), include.lowest=TRUE))

fsr_colours2 <- setNames(c(viridis::magma(7)),plot_data2$FSR_floor_d |> levels())

ggplot(plot_data2) +
  geom_sf(aes(fill=FSR_floor_d),color=NA) +
  scale_fill_manual(values=fsr_colours2,na.value="darkgrey") +
  geom_water() +
  labs(title="Naive demand-based FSR in low density zoning",
       subtitle="(assuming $900/sqft construction cost and 20% land share)",
       fill="Demand based FSR\n(lower bound)",caption="CoV Open Data") +
  coord_sf(datum=NA)

Focusing in on low-density zoning helps, but a new constraint emerges. The effect of minimum lot sizes is very visible, with e.g. sharp gradients around First Shaughnessy and across Blanca Street in the north-west part of Point Grey, where the city’s effort to force, and at the same time subsidize large mansion estates for those who can afford them is very visible.

Lot size adjustment

<code>

beta <- 0.544
standard_lot = 120*33

We have looked at the effect of minimum lot sizes previously and estimated the subsidy to estate mansion owners, or equivalently the loss of opportunity to Vancouverites due to the City preventing them from sharing land. (von Bergmann and Lauster 2021) We can leverage that to adjust for the effect of varying the size of (non-subdividable) lots. In that post we fit the random (grouped at the block level) intercept model

where is the land value, is the lot area, is a constant depending on the group of parcels, and is the scaling exponent that describes the attenuation of land values based on restrictive zoning. We estimated for Vancouver, which allows us to scale land values across the city to a standard East Vancouver 33’ x 120’ lot of area , the modal lot size in Vancouver. More precisely, we estimate an adjusted land value for each parcel that normalizes for the lot size effect via

which we then normalize per square foot of standard lot size for consistency with the work above and map in Figure 3.

<code>

plot_data3 <- plot_data2 |>
  mutate(lv_adjusted = current_land_value * (standard_lot / area) ^ beta / standard_lot) |>
  mutate(FSR_floor_adjusted=(lv_adjusted/ls-lv_adjusted)/construction_cost) |>
  mutate(FSR_floor_adjusted =case_when(!is.na(FSR_floor) ~ FSR_floor_adjusted, TRUE ~ NA)) |>
  mutate(FSR_floor_adjusted_d=pretty_cut(FSR_floor_adjusted, c(0.1,1,1.5,2,2.5,3,4,Inf), include.lowest=TRUE))


ggplot(plot_data3) +
  geom_sf(aes(fill=FSR_floor_adjusted_d),color=NA) +
  scale_fill_manual(values=fsr_colours2,na.value="darkgrey") +
  geom_water() +
  labs(title="Lot size adjusted demand-based FSR in low-density zoning",
       subtitle="(assuming $900/sqft construction cost and 20% land share)",
       fill="Demand based FSR\n(lower bound)",caption="CoV Open Data") +
  coord_sf(datum=NA)

We can take that adjustment and mix it in with the estimates from Figure 1 to get a more complete picture of the demand-based FSR across the city, as shown in Figure 4.

<code>

plot_data4 <- plot_data |>
  mutate(lv_adjusted = current_land_value * (standard_lot / area) ^ beta / standard_lot) |>
  mutate(FSR_floor_adjusted=(lv_adjusted/ls-lv_adjusted)/construction_cost) |>
  mutate(FSR_floor_adjusted =case_when(zoning_district %in% c("R1-1","FSD") |grepl("^RT-",zoning_district) ~
                                         FSR_floor_adjusted,
                                       TRUE ~ FSR_floor)) |>
  mutate(FSR_floor_adjusted =case_when(!is.na(FSR_floor) ~ FSR_floor_adjusted, TRUE ~ NA)) |>
  mutate(FSR_floor_adjusted_d=pretty_cut(FSR_floor_adjusted, c(0.1,1,1.5,2,2.5,3,4,Inf), include.lowest=TRUE))


ggplot(plot_data4) +
  geom_sf(aes(fill=FSR_floor_adjusted_d),color=NA) +
  scale_fill_manual(values=fsr_colours2,na.value="darkgrey") +
  geom_water() +
  labs(title="Demand-based FSR",
       subtitle="(assuming $900/sqft construction cost and 20% land share, lot size adjusted in low-density areas)",
       fill="Demand based FSR\n(lower bound)",caption="CoV Open Data") +
  coord_sf(datum=NA)

Having adjusted for low-density residential zoning, the map starts to look much more like we might expect, with job agglomeration and amenity effects driving demand more continuously around downtown and westward along the beachfront of Kitsilano, extending all the way to the border with the UBC Endowment Lands. At the same time, many of the remaining purple blotches on the map now highlight the zoning protections placed around industrial lands, here potentially blended with the disamenity effects of being surrounded by industrial uses. But it’s worth noting that even aside from industry, there are still some major issues with our integrated map.

We can clearly see the mixed-commercial zoning along many stretches of arterial roads that has higher (conditional) density limits forming a steep gradient to the lower density off-arterial areas. This gradient might indicate that our lower demand-based FSR estimates are too conservatives, but we also point out that upzoning broadly off-arterial, and thus greatly increasing land zoned for apartments, will decrease the value of the land along arterials that is currently one of the few places zoned for higher density.

Conversely we see parcels with unexpectedly low estimated demand along False Creek and Champlain Heights (likely related to leasehold status) as well as in multi-family zoned areas like the West End. The latter likely stems from how the very low density caps in most RM zones depress land values just like the minimum lot sizes in our low-density zones do. Unfortunately it gets harder to account for these effects given how area plans and (somewhat risky) upzoning expectations are layered on top of zoning. So our estimates are rather conservative outside of the low-density areas. On the other hand, a degree of conservatism might also be good insofar as adding a lot more high density multifamily zoning might be expected to reduce the price pressures on the existing high density multifamily zoning (as noted above). Aside from this, we also skip estimates for both parks and many other especially large properties that are either in the process of being developed (hello Jericho Lands!) or maybe should be (hello big empty golf courses!) Overall, while the adjustment we made for low-density zoning help (i.e. where limits on subdividing are strongly binding and impact land values), we’re stopping here for now, and we do not fully adjust for the effects of varying density and use limits across all zones.

Zoning for Resilience

The best case for zoning is that we should be putting it to work in planning for the future rather than as a straitjacket tying us to the past. In Vancouver we generally expect demand to grow, so zoning should be more generous than current demand estimates, providing us the flexibility we need to adapt. Zoning enforcing low-density or low-rise forms should be more strongly justified in terms of costs to the future. Allowing taller “out of scale” buildings has several advantages. If builders are willing to provide more housing on a given site, that’s generally a good thing. Allowing more housing boosts supply and current supply elasticity. But also, allowing taller “out of scale” buildings boosts future supply elasticity by leaving more land for future (re-)development with minimal contribution to the teardown cycle. We see some of this kind of benefit today when we get infill development on sites containing with large setbacks around towers built during the late 60s and early 70s (a zoning requirement for the tower form at the time). Over the past 50 years Vancouver planning has had a high emphasis on uniformity and scaling down to meet existing context, but this backward looking zoning comes at a high cost to not just contemporary but also future supply elasticity. This is a direct cause of current and future unaffordability, and these trade-offs have mostly gone unacknowledged.

Forward looking zoning should take the costs of both exclusion and teardowns into account. We should be looking to increase resilience by allowing for a wide variety of uses and accommodating a broad range of building heights and forms in order to make it easier to adapt to future changes in demand.

Upshot

It’s useful to develop counterfactuals for existing floor space development, both to highlight underlying demand and illustrate the negative effects of zoning constraints. Ideally we would want to build a model that is less sensitive to minimum lot sizes as well as density and unit limits to draw out a price-sensitive demand surface, as we did in our report on the provincial SSMUH and TOA legislation as visualized there in Figure 29. This approach can be extended to estimate economically optimal densities, with the additional benefit of being able to do away with the somewhat crude 20% land value share assumption.

Even though many complications remain to refined modelling, given both our provincial models and the crude estimates here, it’s safe to say that current zoning for residential floor space in the City of Vancouver is still far below demand in most parts of the city. Fundamentally that means official city policy is weighted against allowing people to share land for housing and toward forcing them to compete for it. It is unfortunate that when discussing reforms like multiplex zoning, demand estimates tend to either enter as a force to be countered (e.g. purposefully reducing potential land value to slow redevelopment), or never enter the discussion at all.

Planning necessitates accounting for an uncertain future. We believe that critically involves supporting people to live the lives they choose, without excluding future generations from doing the same. With respect to zoning, that means we should take current demand for housing (and other uses) seriously, and explicitly include it in planning discussions and tradeoffs. We need zoning that is resilient enough to adapt to changes and allow future demand growth to be met. And part of that resilience means taking a hard look at the climate impact of under-zoning, driving carbon emissions through the teardown cycle.

As usual, the code for this post is available on GitHub for anyone to reproduce or adapt for their own purposes.

## datetime
Sys.time()

[1] "2025-08-04 18:18:55 PDT"

## repository
git2r::repository()

Local:    main /Users/jens/R/mountain_doodles
Remote:   main @ origin (https://github.com/mountainMath/mountain_doodles.git)
Head:     [b18fe97] 2025-08-05: demand based zoning

## Session info 
sessionInfo()

R version 4.5.1 (2025-06-13)
Platform: aarch64-apple-darwin20
Running under: macOS Sequoia 15.6

Matrix products: default
BLAS:   /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRblas.0.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.12.1

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/Vancouver
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
 [1] vctrs_0.6.5               cli_3.6.5                
 [3] knitr_1.50                rlang_1.1.6              
 [5] xfun_0.52                 generics_0.1.4           
 [7] jsonlite_2.0.0            glue_1.8.0               
 [9] git2r_0.36.2              htmltools_0.5.8.1        
[11] mountainmathHelpers_0.1.4 scales_1.4.0             
[13] rmarkdown_2.29            grid_4.5.1               
[15] evaluate_1.0.4            tibble_3.3.0             
[17] fastmap_1.2.0             yaml_2.3.10              
[19] lifecycle_1.0.4           compiler_4.5.1           
[21] dplyr_1.1.4               RColorBrewer_1.1-3       
[23] htmlwidgets_1.6.4         pkgconfig_2.0.3          
[25] rstudioapi_0.17.1         farver_2.1.2             
[27] digest_0.6.37             R6_2.6.1                 
[29] tidyselect_1.2.1          pillar_1.11.0            
[31] magrittr_2.0.3            tools_4.5.1              
[33] gtable_0.3.6              ggplot2_3.5.2            

A hypothetical example

Maybe the best way to understand the problem is to take an extreme example that addresses all of the common arguments against supply being the main problem. Let’s assume, by some mechanism, we could socialize the entire housing supply overnight. That eliminates any forms of financialization, individual investors, greed or profit motive, and government could set rents to eliminate any affordability concerns. What could housing in Canada look like under that scenario?

Allocation

The first question is how would housing get allocated under such a system? In real life, we’ve seen a few examples, for instance in China (Forrest and Izuhara 2012) and Russia (Zavisca 2008), where after a period of initial upheaval housing was generally allocated by work unit. But these systems famously didn’t last. For simplicity let’s assume that on the day the housing stock got nationalized everyone happened to want to move - but only locally (perhaps imagine something like China’s hukou system preventing interregional migration and set aside the Charter Right violations entailed). Let’s also imagine government gets to allocate housing for everyone. Ignoring problems of how to allocate housing of different quality and location, government might want to allocate each family unit a home according to their needs, at a minimum by number of bedrooms.

But right off the bat this runs into a major problem: In most metro areas there are already a lot more family units than homes. Some families or unattached individuals will have to share homes and government will have to decide who and how. Some may enjoy sharing a home and one might imagine government setting up a system where people can volunteer to share a home rather than to get one of their own, but that probably requires giving out some perks (or exercising some coercion). To understand how this would play out we first need an estimate how many homes we are short and how many would have to share.

Fortunately that’s an easy question to answer since we have worked this out in the past, although the answer depends a bit on what kind of sharing we think is acceptable as a baseline. Our current rules in how we allocate non-market housing might give some guidance to that question. Non-market housing providers generally won’t issue lease agreements to doubled-up households and tenants who do share their non-market home with others run the risk of losing their benefits. One exception here is adult children who often are allowed in the parent’s household. To get a rough idea how we might distribute housing, we offer two metrics: a) the number of housing units required to avoid all doubling up (with some allowances for college-aged kids) shown in Figure 1, (Lauster and von Bergmann 2024) and b) the number of homes needed so that every family unit can have their own home, with more generous allowances of adult children living with parents shown in Figure 2.¹ (von Bergmann and Lauster 2024b)

No matter which metric we pick, we end up with a significant number of families and individuals who would have to share homes, and in some metro areas that number is excessively high - to the level that it would require very strong government incentives to get enough people to share homes in order to make the numbers work. Some doubling up is voluntary, and metro regions at the lower end of the spectrum put some rough bounds on how much that might be given our general economic conditions in Canada. Of note, during the eras of state and work unit allocation in China and Russia, doubled up families remained strikingly common, with lengthy queues for young adults to achieve apartments of their own (Forrest and Izuhara 2012; Zavisca 2008). For instance, as Zavisca notes, “In 1985, the Soviet government estimated that 40 million new housing units, or a doubling of the housing stock, would be needed to provide separate dwellings for all families.” Dispensing with the trappings of capitalism did not, in fact, solve housing shortage.

Back to our current system

In our current system it’s not government giving out incentives to share housing, it’s the market generating high rents for a scarce resource. We can see the relationship directly by plotting prevailing rents against the number of homes needed to avoid all doubling up in Figure 3. (Lauster and von Bergmann 2024)

Prevailing rents and prevalence of doubling up are tightly linked. People double up to pool income and make rent work. Rents, in turn, are mostly set by the wealthiest and most desperate person (or couple) who wants to escape their doubled-up living situation and form their own household. Doubling up is the main mechanism by which people adapt to a housing shortage, and in a (mostly) market driven housing system rents and prices adjust to sort people into minimal household units and doubled-up households.

No free lunch

The bottom line is that there is no free lunch. Rents are high because we don’t have enough housing. If all housing were socialized overnight the shortage would still be there and government would have to resort to coercion, queuing, or provision of high incentives to find enough people to double up in the existing housing stock. There is no way to solve this problem without building more housing. As government built more housing, use of line-ups, force, and incentives could drop. This, of course, is not so different from the relationship between rents and doubled-up households in our current market system. Rents, and people’s living situations, adapt to shortages and rents will fall as fewer people are forced to double up.² There are some other factors that matter too, income and wealth of the population as well as some cultural preferences for sharing, but that does not materially change this relationship. (Lauster and Bergmann 2025)

A History of Progress Interrupted

Figure 3 directly links rents to how people manage to live. A theory about housing that can’t, or does not even attempt to explain why so many people remain doubled up in some markets, is simply not a serious theory about housing. This problem can sneak into analysis through taking existing households and their sizes for granted as reflecting people’s differing preferences to live together rather than differing constraints on their ability to live alone. Failing to note the flexibility of households in accommodating slack in our housing markets can lead to denial about our underlying housing shortages.

At an individual level we mostly experience housing as an affordability problem. When we say that housing in a specific region is unaffordable we may not mean that the housing we live in right now is unaffordable. For example, a 30 year old child living with parents likely lives in housing their (combined) household can easily afford. What we mean is that the housing outcomes we aspire to, the same outcomes that our peers in other parts of the country achieve, are out of reach in the region we live in. And while there may be good reasons why housing is somewhat more expensive in some parts of the country, there is no good reason why rents and prices have to vary as dramatically as they do.

At the systems level we see that collectively these housing aspirations can only be fulfilled if we have enough housing. We suggest making doubling up a primary target for housing policy. This lens avoids a lot of the pitfalls when using other metrics like Core Housing Need that are plagued by collider bias and lose sensitivity once our housing shortage is large enough. (von Bergmann and Lauster 2023b) What’s more, reducing doubled up households ties back to a history of housing progress. The rapid rise in household formation in post-war Canada until the early 1980s was seen as a great success for Canadian housing. (Wargon 1979; Miron 1988; Miron 1989) Through the 1980s, however, these improvements were reversed in much of Canada, with household formation slipping in all metro areas outside of Quebec after 1981 as shown in Figure 4. This happened despite real incomes continuing to rise.

<code>

hmr_all <- simpleCache(get_phm_timeline(),"hmr_data_all.rds",path=here::here("data"),refresh=FALSE)

cma_colours <- c(setNames(RColorBrewer::brewer.pal(8,"Dark2"),
                          c("Toronto","Montréal","Vancouver","Ottawa – Gatineau",
                            "Calgary","Edmonton","Québec City")),
                          c("Canada"="black"))

hmr_all %>%
  bind_rows(summarize(.,Count=sum(Count),.by=c(AGEGRP,PRIHM,Year)) |>
              mutate(CMA="Canada")) %>%
  bind_rows(summarize(.,Count=sum(Count),.by=c(PR,AGEGRP,PRIHM,Year)) |>
              rename(CMA=PR)) |>
  mutate(hmr=Count/sum(Count),.by=c(CMA,AGEGRP,Year)) %>%
  left_join(filter(.,PRIHM,CMA=="Canada",Year=="1981") |> select(AGEGRP,base_hmr=hmr),by="AGEGRP") |>
  mutate(Households=ifelse(PRIHM,Count,0),
         AEHH=base_hmr*Count) |>
  summarize(across(c(Households,AEHH),\(x)sum(x,na.rm=TRUE)),.by=c(Year,CMA)) |>
  mutate(Source="PUMF") |>
  bind_rows(get_1941_1976_aehh_hh() |> 
              mutate(Source="Summary tapes\nPrinted tables")) |>
  filter(CMA %in% c("Toronto","Montréal","Vancouver","Ottawa – Gatineau",
                    "Calgary","Edmonton","Canada","Québec","Alberta","Quebec")) |>
  mutate(CMA = recode(CMA,"Québec"="Québec City", "Quebec"="Quebec (PR)","Alberta"="Alberta (PR)")) |>
  filter(!grepl("PR",CMA)) |>
  mutate(ratio=Households/AEHH) %>%
  mutate(CMA=factor(CMA,levels=filter(.,Year=="2021") |> arrange(-ratio) |> pull(CMA))) |>
  mutate(fudge=ratio/lag(ratio,order_by = Source),.by=c(Year,CMA)) |>
  mutate(fudge=mean(fudge,na.rm=TRUE),.by=Year) |>
  arrange(Year) |>
  fill(fudge,.direction="up") |>
  mutate(fudge=ifelse(Source=="PUMF",NA,fudge)) |>
  mutate(fudge=coalesce(fudge,1)) |>
  mutate(fudge=ifelse(Year=="1976",fudge,1)) |> # only fudge 1976
  ggplot(aes(x=as.integer(Year),y=ratio/fudge,colour=CMA)) +
  geom_point(aes(shape=Source)) +
  scale_shape_manual(values=c("PUMF"=21,"Summary tapes\nPrinted tables"=16)) +
  geom_line(aes(group=interaction(CMA,Source))) +
  geom_line(data=~filter(.,Year %in% c("1976","1981")) |> mutate(n=n(),.by=CMA) |> filter(n==2), linetype="dashed") +
  scale_color_manual(values=cma_colours) +
  scale_y_continuous(breaks=seq(0.1,2,0.1),trans="log") +
  scale_x_continuous(breaks=seq(1921,2021,5)) +
  labs(title="Ratio of Actual to Age-expected households (occupied (private) dwellings)",
       x=NULL,
       colour="Region/metro",
       y="Occupied housing units / age-expected households\n(based on 1981 Canadian household maintainer rates, log scale)",
       caption="StatCan Census 1941-1976, 1971-2021 PUMF (individuals)")

Age-expected households are the number of households one would expect to see if age-specific household formation rates were equal to those in a fixed year, in our case 1981 when household formation peaked in Canada. The ratio of actual observed households to age-expected households based on the 1981 standard for Canada demonstrates where we’ve seen substantial backsliding since. Toronto and Vancouver really stand out! But really everywhere outside of Quebec (except for metropolitan Ottawa, which of course is partly in Quebec) has seen interruption to their progress in household formation since 1981.

To dive a bit further into the technicalities of assembling this figure, we split the time series into parts where the data was derived from the PUMF and that derived from published census tables and electronic summary tapes, these data series are not strictly comparable because the PUMF data allows for filtering on the population in private households, whereas the older data looks at the total population which is not quite the right metric to use here. In cases where the time series don’t overlap we connect them via dashed lines. Moreover, in older censuses the households concept was somewhat floating in definition as well as how enumerators coded this. (Wargon 1979; Harris 1994). Misalignment is small if age data as well as households counts are for the entire population, including households in collective dwellings, but larger discrepancies emerge if e.g. ages are reported for the entire population but household counts are only reported for private households, as is the case in the 1976 summary tapes. We adjusted the 1976 ratio to roughly account for this discrepancy. Some of the fields in the 1961 and 1966 summary tape data have coding issues, we replaced some of the data with manually entered data from the printed tables as appropriate. Consistency of reporting for older censuses is less clear and actual values may differ somewhat from the values we report in the graph, discrepancies because of inconsistencies in the consideration of private vs collective dwellings can result in a roughly 3% deviation from our reported ratios. Our time series for Canada exhibits a large kink in 1941, corresponding to a severe housing shortage caused by the great depression, triggering the government to directly participate in housing construction via the crown corporation Wartime Housing Limited it created for this purpose. (Wade 1986) The concept of Metropolitan areas (or “greater cities”) was introduced in 1941 and is not available prior to that. Metropolitan area boundaries adjust over time.

Age-expected households were previously suggested as input for econometric modelling (DiPasquale and Wheaton 1994) to avoid collider bias when modelling housing demand elasticities, although unfortunately this insight seems to have become forgotten in much of the more recent economics literature, where people too often assume households as fixed and unresponsive to prices and rents, or household formation elasticities are under-estimated. Given the large changes in household formation over time and across metro areas shown in Figure 4 misspecifying structural equation models by ignoring or under-estimating household formation leads to substantial collider bias.

The decline in household formation since 1981 cannot be explained by changes in cultural makeup. Cultural factors do play some small role, but these trends also hold when only looking at the non-immigrant non-visible minority sub-population in Canada and there is strong evidence that the main cause is increasing housing scarcity and, with it, increasing housing costs. (Lauster and Bergmann 2025)

Doubling Up as a Metric

We are not alone in pointing out that our standard household-based measures we use in Canada to monitor housing, like Core Housing Need, are insufficient, and calling for also tracking household living arrangements. This is particularly clear when looking at the period from 1941 to 1981 when Canada made a lot of progress in improving housing outcomes, while standard affordability measures did not change much. In 1989 John Miron observed:

The analysis of affordability problems should not focus exclusively on the ratio of shelter cost to income. To do so is to view the outcome of the past forty years unduly harshly. Affordability measures should focus on how the opportunities for alternative housing have been improved over time. A nonfamily individual who now spends 40% of her income on a housing unit may feel much better off than her predecessor who had spent less on housing but shared her dwelling with others or lodged elsewhere. While not denying that this may still constitute an affordability problem, we should recognize that an important kind of progress has been made here. (Miron 1989)

The key insight here is that the utility function commonly used for housing outcomes that only looks at household income and shelter costs, is discontinuous across household formation, and more importantly, carries the opposite sign from how individuals experience their change in overall housing outcomes when un-doubling.

Miron continues:

To focus exclusively on shelter-cost-to-income ratios as an indicator of affordable housing is thus too narrow. Those who point to the declining affordability of housing to the “average” household miss an important point. Given the large income and price elasticities of household formation among nonfamily individuals, each new program to improve affordability may well have the effect merely of increasing the number of newly-forming low-income households paying a high percentage of their income on housing.

We note that people who see their shelter costs to income ratio go up when un-doubling generally form their own household because they feel it improves their overall housing outcomes despite reducing their affordability. Facilitating un-doubling is thus a worthy goal in its own right and leads to material improvement, albeit one that is not captured by commonly used metrics.

The last sentence of Miron’s paper is still very relevant today:

Especially in light of the household formation elasticities, what exactly are the benefits to be gained by further improving affordability, and how are they best measured? What are the costs involved, and are present tools to improve affordability the most cost-effective way of achieving the gains? Unfortunately, there has been little careful analysis of these issues.

We have wrangled with these questions and suggest that Minimal Household Units provide a useful framework to monitor improvements in housing outcomes. (Lauster and Bergmann 2025) This can be augmented with a range of related metrics, for example the ones exemplified in Figure 1, Figure 2, or Figure 4.

Miron made his observations after looking back at 40 years of improving housing outcomes between 1941 to 1981 (Miron 1988; Miron 1989), while we have been making the same observation when looking back at the last 40 years 1981 to 2021, except during that period we saw deteriorating housing outcomes. During those last four decades Household formation did not go back as much as it grew in the preceding four decades, and they did not decrease in all of Canada, Quebec saw continued gains. But improving housing outcomes seems natural and we don’t think much about them, while deteriorating (or even stagnant) housing outcomes are painful and much more visceral, especially while incomes are still rising and many other aspects of life are continuing to improve. At the same time the main metrics we use to monitor housing outcomes, chiefly shelter cost to income ratios, have failed to capture the great improvements in housing outcomes 1941 to 1981 as observed by Miron, and they have done a fairly poor job at capturing the decline since as we have pointed out previously. (von Bergmann and Lauster 2023a)

With Canada’s renewed effort to undo our housing shortage we accumulated over the past 40 years maybe now is the right time to develop better metrics that allow us to track progress.

Conclusion

Housing is a Housing Problem. Which is to say there’s not enough of it. Vacancy rates are a direct measure of shortages immediately available to apartment hunters, but short-term variation means they aren’t always linked to underlying structural problems. Prices and rents can point toward shortages, but only if we accept underlying market dynamics of supply and demand (which we pretty much do in the Canadian context). Here we want to make it plain that there is also a relatively straightforward demographic measure of housing shortage rooted in the flexibility of the household. Doubling up within existing households offers a degree of slack to markets where there aren’t enough dwellings to go around. Doubling up can make housing appear more affordable. But doubling up also represents a hardship, as well as a ready pool of demand exerting price pressure. As such, it’s important to track rates of doubling up (and/or actual v. expected household formation) in order to better understand housing hardship related to shortage. Elevating household formation and doubling up to a primary metric to measure housing progress also serves as an important compliment to traditional affordability metrics used in Canada that suffer from collider bias that makes it difficult to use them to track progress in solving housing problems.

As an important bonus, tracking doubling up demonstrates how shortage is at the heart of Canada’s housing problems. There’s no simple solution, for instance involving a tweak to allocation, that will solve our housing problems without adding a lot more housing. We’ve done it before, adding a lot more housing in the post-war years, both market and non-market (but mostly market) and it mostly worked! Things got better! Since 1981, it’s clear this project has stalled, and we simply haven’t kept up. That sounds like a housing problem.

As usual, the code for this post is available on GitHub for anyone to reproduce or adapt for their own purposes.

## datetime
Sys.time()

[1] "2025-08-01 21:42:29 PDT"

## repository
git2r::repository()

Local:    main /Users/jens/R/mountain_doodles
Remote:   main @ origin (https://github.com/mountainMath/mountain_doodles.git)
Head:     [9d47816] 2025-08-01: Merge pull request #10 from maswiebe/patch-2

## Session info 
sessionInfo()

R version 4.5.1 (2025-06-13)
Platform: aarch64-apple-darwin20
Running under: macOS Sequoia 15.6

Matrix products: default
BLAS:   /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRblas.0.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.12.1

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/Vancouver
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
 [1] vctrs_0.6.5               cli_3.6.5                
 [3] knitr_1.50                rlang_1.1.6              
 [5] xfun_0.52                 generics_0.1.4           
 [7] jsonlite_2.0.0            glue_1.8.0               
 [9] git2r_0.36.2              htmltools_0.5.8.1        
[11] mountainmathHelpers_0.1.4 scales_1.4.0             
[13] rmarkdown_2.29            grid_4.5.1               
[15] evaluate_1.0.4            tibble_3.3.0             
[17] fastmap_1.2.0             yaml_2.3.10              
[19] lifecycle_1.0.4           compiler_4.5.1           
[21] dplyr_1.1.4               RColorBrewer_1.1-3       
[23] htmlwidgets_1.6.4         pkgconfig_2.0.3          
[25] rstudioapi_0.17.1         farver_2.1.2             
[27] digest_0.6.37             R6_2.6.1                 
[29] tidyselect_1.2.1          pillar_1.11.0            
[31] magrittr_2.0.3            tools_4.5.1              
[33] gtable_0.3.6              ggplot2_3.5.2