Will MIGMET1 variable be coming back?

#1

Following up to a question I asked last year: I know that the MIGMET1 variable (metro of residence 1 year ago) stopped being included in data sets after 2011, presumably due to the boundary changes. Last spring it sounded like the team was planning on adding it back in for the 2016 data sets, now that there are five years of new-boundary data. I don’t see it there yet. Are you still planning on adding it back in? I know I can build a crosswalk with MIGPUMA, but it would be a big time-saver!

#2

We’re aiming to release MIGMET1 for 2012-2016 samples sometime this spring.

We’ve been prioritizing other work mainly because we know that the new MIGPUMA definitions used in 2012 and later are much coarser than in the past, covering larger areas, and corresponding less well with metro area definitions, so we won’t be able to identify metro areas as well as we could with past versions of MIGPUMA. That said, we agree that it’s still worthwhile to identify what we can!

#3

I was excited to see the MIGMET variable back again! I saw (as expected) that many metros could not be identified, because of the way that the MIGPUMAs do not line up with the metro boundaries (ie Boston, Charlotte, Denver). We are continuing to do our own allocation for those MSAs. However, I noticed that Pittsburgh was included in the new MIGMET131 variable and wanted to check on that. Pennsylvania Power PUMA 1500 includes PUMA 1501 (not in Pittsburgh) and PUMA 1502 (in Pittsburgh), but it looks like everyone in MIGPUMA 1500 is coded as being in Pittsburgh in the MIGMET variable. Could you let me know if there is something that I am missing? I’d love to get rid of some of my calculations and just use MIGMET131 for Pittsburgh, but I want to make sure that it is accurate to do that. Thanks!

#4

You are correct about how Pittsburgh is coded in MIGMET131: even though Migration PUMA 1500 straddles the Pittsburgh MSA boundary, MIGMET131 identifies all prior residents of Migration PUMA 1500 as prior residents of the Pittsburgh MSA.

The reason is that we use a less restrictive, more robust assignment strategy for MIGMET131 than we did for MIGMET1:

  1. We associate any Migration PUMA with an MSA if a majority of the Migration PUMA’s 2010 population resided in that MSA.
  2. We compute the omission and commission errors for each MSA (the portion of MSA residents that don’t live in associated Migration PUMAs & the portion of the population of associated Migration PUMAs that don’t live in the MSA).
  3. We report MIGMET131 codes only for MSAs where the sum of omission and commission errors is less than 15%.

In the case of Pittsburgh, the sum of omission and commission errors is 8.3%, so even though the associated Migration PUMAs don’t match up exactly with the MSA, they match up “well enough” that we still report the Pittsburgh code.

This methodology is detailed in the MIGMET131 variable description, where you can also find spreadsheets that provide crosswalks between Migration PUMAs and MSAs, and the mismatch errors for all identified MSAs.

The MIGMET131 comparability page also summarizes the differences between MIGMET1 and MIGMET131.