This web page documents and summarizes geographic entities used in the 2012 edition of the MABLE database, accessible via the
geocorr12, Version 1.x web application. It is specifically
geared towards the geographic entities as they are used in this web application, but also includes general explanations of the
various geographic types. To see a more offical document describing the 2010 geographic entities see the 2010 Geographic Terms and Concepts page at the Census Bureau web site.
To see base maps for many of these entities (primarily the ones used for tabulating the 2010 census and/or the American Community Survey) see the Bureau's
Reference Maps page.
The Missouri State Census Data Center and
OSEDA maintain a library of geographic code modules in the form of SAS(r) format codes. These modules have special application for
SAS software users since they allow codes to be readily converted to their
corresponding names. Sometimes format modules are used not to provide names, but rather to link codes to other entities as a kind of table lookup. Note that although these modules are, technically, "code" you do
not have to be a programmer, or know any SAS, to use these as codebook files to look up a geographic code.
In the text below when a SAS format module is available for a geocode we provide a link to it at the end of the entry for that code.
Rarely, but in a few instances, there may be entries in the format code that do not appear in the MABLE data base. For example. the
$fipstab format code contains entries for Puerto Rico and U.S. territories (Guam, Virgin Islands, etc.) that are not in MABLE.
Most of these geographic codes are comprised of numeric digits but they have no numeric significance. They are stored in the MABLE database as character strings rather than binary numeric fields. In reports they will display with leading zeroes ("01" as the code for Alabama, for example, rather than just "1") and these leading zeroes also are written to output csv files by the geocorr application. When the latter get imported into Excel, however, the import routine (by default, at least) turns them into numerics and the leading 0's disappear.
The FIPS county codes are 3-digit numbers assigned within states. They
generally are odd numbers assigned in alphabetical order. Exceptions are
independent cities (i.e. cities like Baltimore and St. Louis that are not
in any county and serve as county equivalents) which are usually assigned
codes over 500 (such as '510' for some reason.) On output files and
listings we usually combine the FIPS state and county codes. Thus the
value of the County variable for Autauga County, Alabama is 01001 and for
Baltimore City, Maryland is 24510. In some states (such as Louisiana and
Alaska) the primary substate legal entities are not called counties; but for
the sake of this application they are "county equivalents" and act
exactly the same as counties. Counties appearing here are those defined
at the time of the 2010 census. There have not been any changes to the county definition since that time (as of late 2013).
See the Census Bureau web page describing any changes that may occur. There are approximately 3143 counties
in the U.S.
Only "residential" ZIP codes - those containing household addresses -
have corresponding ZCTA codes (and hence will appear in a MABLE database). There are no business or Post Office Box-only
ZCTAs, etc. The latter account for about a fourth of all ZIP codes in the
U.S. You can view/download a csv file at http://mcdc.missouri.edu/data/corrlst/Zip_to_ZCTA_crosswalk_2010_JSI.csv
that shows all ZIP codes (vintage 2010) to the corresponding ZCTA. (Uexplore/Dexter users can access the same data in the
corrlst.zip_2_zcta10 data set.)
Another problem is that ZIP codes are not really spatial entities -- they
are simply lists of addresses, organized to facilitate mail delivery.
While they often do form areas that can be viewed as geographic areas,
that is not what they really are. This can create problems when you try
to relate them to a spatial entity such as a census block. Think of a
classic census block formed by the intersection of 1st St., Elm Ave, 2nd
St. and Pine Ave. If 1st St is the northern border of the block then
folks living on the south side of 1st St. between Elm and Pine are in our
block (lets call it "101"). But people living across the street -- on the
north side of 1st St. are living in a different block, say "102". But the
U.S. Postal Service would never (well, hardly ever) have a ZIP boundary go
down the middle of a street. If this were an area where the ZIP changed
it would almost certainly divide along (vague and invisible) "back-lot
lines". For example, the folks living on both sides of 1st St. in our
example might live in ZIP 12345, while the folks living on 2nd St. might
live in 12346. Thus you have households in the same census block, but in
different ZIP codes. Hence, the fundamental concept of census block as
the atomic unit is violated. Of course, this only happens in a certain
percentage of blocks, and in many cases the ZIP boundaries are on
commercial streets where not many people live and you can assign most of
the population in the boundary blocks to the right ZIP. These issues are dealt with in
the Bureau's definitive web page (see link above) that describes how these issues were dealt with
when defining ZCTA's.
On output files this geocode is stored as ZCTA5. The variable Zipname is also included (unless otherwise
requested). This name has undergone a number of changes over recent years (2010-2013) and the current value matches
the value of the zipname variable in the zcta_master data set (in /pub/georef).
Pseudo-ZCTA codes ending with XX or HH (e.g. 594XX and 594HH in Montana) were used to designate unassigned (to any ZIP code) and
water-area blocks for the 2000 census. They have been dropped for 2010 and hence will no longer appear in any gecorr12 output. You
will see them in geocorr2k results.
To get information regarding any ZCTA (or even non-ZCTA ZIP) the MCDC offers the Display ZCTA Master
This format code was derived from a file from the U.S. Postal Service circa 2010.
Its a combination of Post Office and local geographic names. It is the
source for the ZIPNAME fields that will be added to your geocorr outputs
if you specify that you want names to got with your geocodes and you
also select ZIP as one of your geocodes.
As already mentioned, CBSA's are (almost always) comprised of complete counties or county equivalents (parishes, independent cities, etc). There is only one exception to this general rule: the portion of the city of Sullivan in Crawford County, MO was legislated to be part of the St. Louis metropolitan area. It has to do with a veteran's hospital being located there and something about a formula for federal subsidies in metro vs. non-metro areas. As of July, 2009 there were approximately 1500 people living in this area.
Scsa.sas Note that the code 426 was used for Peoria-Canton, IL until as part of the July 2015 update it was changed to now pertain
to Pensacola-Ferry Pass. FL-AL. So we updated for $csa format code to display Peoria-Canton, IL or (as of 7/15)Pensacola-Ferry Pass, FL-AL. (they should not be allowed to change these codes, but they do it anyway).