MET2013ERR - what is the mismatch reported exactly?

1

Hi, I think I understand the problem and the need for this variable, but I’m still a little unclear on what the mismatch is reporting in MET2013ERR variable. You aggregate census block data within PUMAs thought to be located within a metro area to see how large of a mismatch there is in between the population in the PUMA included in the boundary and that which is not?

Thanks for the clarification.

Kasey

2

Actually, I think I was confused by the protocol for 2000. So, for 2013 onward, you take the metro area population reported by the census and match it to the population reported in by summing PUMAs. The difference between the two is the reported mismatch. Since 2000 has boundaries, changes you use census blocks.

Is that what IPUMS is doing to report MET2013ERR?

3

This is the key text from the MET2013 variable description:

Inexact Correspondence with Official Delineations
…

The protocol used by MET2013 is to identify the metro area in which the majority of each PUMA’s population resided. If MET2013 identifies a metro area for a given household, it indicates that, for the PUMA in which the household resided, a majority of the PUMA’s 2010 population resided in the identified metro area.

Match Errors and Code Suppression
MET2013’s code assignment protocol yields errors of omission (residents of a MSA who are not identified as residents) and errors of commission (non-residents who are identified as residents). PUMAs often nest well within metro area boundaries, resulting in small match errors, if any. For many metro areas, however, especially smaller metro areas, the intersecting PUMAs are a poor match.

As an index of mismatch, IPUMS uses the sum of percent omission error (the portion of an MSA’s population residing in excluded PUMAs) and percent commission error (the portion of the population in associated PUMAs that did not reside in the MSA).

…

For each reported MET2013 code, the MET2013ERR variable identifies the level of the sum of errors. Researchers may use MET2013ERR to impose a more restrictive error limit if desired.

Imagine a Venn diagram. The metro area population is in one circle. The population of PUMAs associated with the metro area are in another circle. Some population may be in the metro area but not in the associated PUMAs (omission error) and some may be in the PUMAs but not in the metro area (commission error). Does that help?

We use block populations in our computations only for the 2011 and earlier ACS samples, when we need to estimate the 2010 populations of intersections between 2000 PUMAs and 2013 metro areas.

4

Yea, I think I didn’t understand how you were getting metro area population to compare to that derived from PUMA aggregation. So instead of getting an individual score for each PUMA, you get one for the entire metro area, right?

Yea, I read over the link a few times but was still left confused. I wonder if an example might provide clarity.

Thanks for your help, as always.

5

We get the populations for calculating mismatches from census summary data–not microdata. The Census Bureau provides files that identify the 2000 populations of the parts of 2000 PUMAs, and the 2010 populations of the parts of 2010 PUMAs, so we can use those. But they don’t provide any info about the 2010 populations of the parts of 2000 PUMAs; that’s why we need to use 2010 block populations for some samples.

And yes, we measure the mismatch error for each metro area, not for each PUMA. If you wanted to know the proportion of a given PUMA’s population that’s in a given metro area, you could use the crosswalk files provided in the MET2013ERR variable description.

1 Like
6

Oh, now I see how you calculate… e.g., obtain data from US Census and calculate 2010 population - 2010 population that is part of PUMAs to get rates.

Thanks.