Hi @katiehogan8! Thanks for flagging the issue with the race_ethnicity variable in people_all.csv. Here's what was happening:
Previous versions of GeoPops had a race_ethnicity variable in people_all.csv (and the Starsim People object created from people_all.csv). This variable was created from the variables race_black_alone, race_hispanic, and race_white_alone, which are exported in people.csv and come from PUMS sample household data. But race_black_alone and race_hispanic were not mutually exclusive, which created issues with the race_ethnicity variable. Now, race_ethnicity has been removed from people_all.csv. To avoid confusion, GeoPops v1.7 uses all the race categories available in PUMS sample household data (which are not mutually exclusive!):
- race_white_alone
- race_black_alone
- race_amerindian_or_alaskan
- race_asian_alone
- race_pacific_alone
- race_other_alone
- race_two_or_more
- hispanic
These variables are present in PUMS sample household data and were added to the additional_traits dictionary in the config.json file to include them in the GeoPops population.
Caveat: While these variables are present in the PUMS data, they are not currently used in the combinatorial optimization (CO) step with ACS data. So the distributions of these race/ethnicity categories in a GeoPops population may not be representative of the same population in the ACS data. Right now, GeoPops only matches on race/ethnicity of householder (race_black_alone, hispanic, and white_non_hispanic) from ACS tables B25006 and B11001I (these tables are automatically downloaded when you make a GeoPops population). But, when I compared counts of individual race/ethnicity categories for the new variables (GeoPops vs ACS), the counts were very close. So, I won't include these variables in CO just yet. Hope this makes sense! Let me know if you have any questions!
The notebook test_race_ethnicity.ipynb shows things in more detail.
Hi @katiehogan8! Thanks for flagging the issue with the race_ethnicity variable in people_all.csv. Here's what was happening:
Previous versions of GeoPops had a race_ethnicity variable in people_all.csv (and the Starsim People object created from people_all.csv). This variable was created from the variables race_black_alone, race_hispanic, and race_white_alone, which are exported in people.csv and come from PUMS sample household data. But race_black_alone and race_hispanic were not mutually exclusive, which created issues with the race_ethnicity variable. Now, race_ethnicity has been removed from people_all.csv. To avoid confusion, GeoPops v1.7 uses all the race categories available in PUMS sample household data (which are not mutually exclusive!):
These variables are present in PUMS sample household data and were added to the
additional_traitsdictionary in the config.json file to include them in the GeoPops population.Caveat: While these variables are present in the PUMS data, they are not currently used in the combinatorial optimization (CO) step with ACS data. So the distributions of these race/ethnicity categories in a GeoPops population may not be representative of the same population in the ACS data. Right now, GeoPops only matches on race/ethnicity of householder (race_black_alone, hispanic, and white_non_hispanic) from ACS tables B25006 and B11001I (these tables are automatically downloaded when you make a GeoPops population). But, when I compared counts of individual race/ethnicity categories for the new variables (GeoPops vs ACS), the counts were very close. So, I won't include these variables in CO just yet. Hope this makes sense! Let me know if you have any questions!
The notebook test_race_ethnicity.ipynb shows things in more detail.