The usccflows data set accessed by this query has rows that summarize movement of the population between U.S. counties using the decennial census. The tricky part of using this data set is to understand that we have two sides of every migration referred to as the "anchor" side and the "To/From" side. The anchor is the side you start with usually. We do that here by selecting all rows for a single anchor county. Then we look at all the migration data available going into or out of that county broken down by the "To/From" county of each "flow".
Filetype accessed: mig2000 : Migration Flows Between States & Counties, 1995-2000
Data Set accessed: usccflows
Dexter features used:
- Advanced Report formatting Options: By variables for report; ID variables for report; and custom style used ("brick").
- Option in Section I to pipe report directly to browser with no Output menu screen.
Can be easily modified to:
- Select a different county (or counties) anywhere in the U.S.
- Change the sort variable to NetMig instead of GrossMig to see which counties contributed the most substantial net inflow.
Degree of Difficulty: 4 - somewhat difficult.
Saved Query File:
Annotated Dexter Query Form (As filled out to define this query)
Section I: We choose to generate just a report file in html format. This allows us to check the box indicating that we want the output sent directly back to the browser without using an intermediate Output Menu page.
Section II: We use what appears to be a redundant condition in the first row here, specifying that the anchor county must be in state 29. You could omit this because the select on the next line includes the state as part of the county code. But the data set is indexed by State so doing it this way makes the extraction run just a little faster. How did we know what code to use here? If we did not already know it, we could have followed the link at the top of the form to "detailed metadata" and on that page in the Key variables section we could have clicked on State to get a list of the codes and their meanings as they appear in this data set. Then, of course, the County codes link is right next to the State link. If we wanted to do Cook County, IL we could easily find out that the code to use is 17031. If the Detailed Metadata link were not available we could have used the geographic codes lookup web application.
Section III: Nothing too complicated here. We chose to omit the two county code identifiers. Usually such codes just clutter up a report. They tend to be more useful on output files (csv or dbf) where they can be used to merge data from multiple sources.
Section IV: These options may be "Non-essential" if you are not interested in labeling your report carefully with titles and footnotes. We also use the Sort option to cause the report to be sorted by the values of the variable grossmig. The leading minus sign here indicates a descending sort.
Section V: The Advanced Report options all get used here. We use the "Use variables labels..." checkbox to improve the column headers in the report. The "By variables for report.." text box lets us specify that the value of variable county is to be displayed as a "by line" in the report. This is a more reliable way of documenting what the Anchor county is for the report (since it is a constant value we might have omitted it from the report and just said something in the title.) By having it as a by line variable we saved wasting space by displaying it as a column in every line of the report.
Specifying county2 as an ID variable for the report causes it to be displayed as the leftmost column of the report (in place of the OBS number column which is the default ID column). It also displays in a different color or font (this varies with the output style used).
We specify (by selecting off the drop-down select list) the "brick" style to give use a report a red and gray color scheme instead of the default blue and white.