Master Area Block Level Equivalency (MABLE)
Master Area Block Level Equivalency (MABLE)
Date: Fri, 7 Jul 1995 12:46:41 CDT
From: John Blodgett
Subject: Water Blocks and MABLE
Comments: To: agis-l list
To: Multiple recipients of list SASPAC-L
Henk Meij and I have been working on a project (actually Henk is doing
all the work, I've just been "consulting") that would involve the
creation of a master geographic reference file. Exactly how this file
will be created and how it will be accessed and what applications will
be written to access it have not been determined but we see lots of
possibilities. A fundamental premise of the project is that we would
use current Census geography -- specifically 1990 Census Blocks -- as
a basic atomic unit that can be used to relate all other geographic
areas that the system would support. The "other geographic
areas" could be a dynamic list, but would certainly include the easy
and obvious geographies included in the block headers file on STF1B.
This would include place (city), mcd (town, township), ua, msa/cmsa/
pmsa, urban/rural class, cd, and any grid system we might want to
impose such as a square-km grid covering the U.S. (since we have the
lat-long centroid of the block on the 1B headers file). Then we could
add other codes -- like the ZIPs used in the 90 census from the ZIP-
Block equiv. files (not all blocks, but most), PUMA-A and PUMA-B codes
(derived from the PUMGEF files), current CD codes, and possibly school
districts, watersheds, telephone area codes and other more difficult-
to-impossible coverages. Theoretically, any coverage for which you
had polygons on the TIGER coordinate base could be overlaid with
a block polygon coverage to relate that coverage to the block
units. (Or, since you are not going to "split" blocks, you could
use the block centroids as a data-points coverage and just do pt-in-
pol to assign each block to a region.) You could do this "on-the-fly"
or save the result as a permanent part of MABLE.
One of the assumptions we make in using blocks as our atomic unit
is that they are geographically all-inclusive, i.e. that they cover the
entire country, and that therefore we can always "aggregate" them
spatially to any other codes/coverages in the system. (We know this
will not be perfect, as in the case with ZIP codes, but we accept
this as close enough.) The assumption that blocks are all-inclusive
turns out not to be true. As explained in the excerpt from the tech
doc (below) it turns out these things we have been calling "water
blocks" are in fact "by definition" NOT blocks after all. They may
look like blocks, and have codes like blocks, but they are not really
blocks. This is more than just a semantics problem, because the
Bureau implements this definition by excluding water blocks from any
of their geographic header as well as summary data files. Specifically
if you want the area and centroid and the census/fips place codes and
the urban/rural class of "block" 1234.00-199 in a given county you will
not be able to get this off the block headers file. The only way to
get such information (that the Bureau is making available at least --
but they must have this information stored somewhere in their TIGER
system) is to go all the way back to the TIGER Line files. You'll
need to chain them before you can calculate the areas and centroids
and you'll have to look at the codes on the TIGER line segs to get
the geographic correspondences. BIG job! Or, as Henk says:
"The end of MABLE? One idea I had was to simply lift all "99" blocks
from the BNA files by state,import them, do area calculations, then
export the attribute info. Cumbersome. Plus we still do not know the
attributes for those "99" areas."
"MABLE" is Master Area Block Level Equivalency, the working acronym
for this concept.
The purpose of this posting is to see if anyone knows of a source
of this missing information. Basically, what we need are the STF1B
headers file records for the water blocks. Maybe someone at the
Bureau knows of a secret internal file we could borrow?
In case you're curious about just what the applications of MABLE
might be, think of a Web-based forms-driven application where you
could specify a universe and two sets of geographic codes that were
supported on the MABLE file. You would enter these specs and the
immediate output could be a file relating the two sets of geography
for the specified universe. For example:
Universe: state of Missouri
Area code set 1 ("source"): county, ZIP
Area code set 2 ("target"): A-PUMA (codes used on PUMS-A files, 1990)
Typical output records:
County: 29183 ZIP: 63301 PUMA: 01300 POP: 20325 AFACT: 1.00
County: 29189 ZIP: 63134 PUMA: 01401 POP: 12000 AFACT: .75
County: 29189 ZIP: 63134 PUMA: 01402 POP: 4000 AFACT: .25
...
The output file shows how each ZIP-within-county relates to the PUMA
codes. The first record shows that the entire ZIP is in a single
PUMA, while the 2nd & 3rd records show that ZIP 63134 is split with
75% of its 1990 pop (12000 people) in PUMA 01401 and 25% in 01402.
What good would this be? If you had any data by ZIP-within-county
-- for example an address file of cancer patients -- you could readily
aggregate it by ZIP-county and then use this "correlation list" to
allocate the resulting counts to PUMA codes. Now you can use the
PUMS data to any kind of demographic profiling you want and be able
to correlate the resulting measure with cancer rates.
Another example would involve having some kind of uniform grid code
-- like a square km or even square .25 km -- that could be related
to any of the other codes in the file, such as PUMAs, cities, ZIPs,
or census tracts. Once you had that correspondence file, you could
then easily allocate data available at the grid unit -- such as land
coverage codes derived from satellite images -- to the target geos.
This is like adding land-use data to the census. And you do not even
need a GIS to do it. (Indeed, one of the possible ultimate features
of the MABLE-based system would be to not only generate the geographic
correspondece file, but perhaps even apply that file to some data
source so that the final output is not (just) the corresponce but
the actual data allocated from one coverage to the other.)
(excerpt from Census Bureau Tech Doc for STF1B cd-rom)
The Census Bureau provides measurements for both land area and total
water area for the 1990 census; the water figure includes inland,
coastal, Great Lakes, and territorial water. (For the 1980 census, the
Census Bureau provided area measurements for land and inland water.)
The Census Bureau will provide measurements for the component types of
water for the affected entities in a separate file. "Inland
water" consists of any lake, reservoir, pond, or similar body of
water that is recorded in the Census Bureau's geographic data base. It
also includes any river, creek, canal, stream, or similar feature that
is recorded in that data base as a two-dimensional feature (rather than as
a single line). The portions of the oceans and related large embayments
(such as the Chesapeake Bay and Puget Sound), the Gulf of Mexico, and the
Caribbean Sea that belong to the United States and its possessions are
considered to be "coastal" and "territorial" waters; the Great Lakes are
treated as a separate water entity. Rivers and bays that empty into
these bodies of water are treated as "inland water" from the
point beyond which they are narrower than one nautical mile across.
Identification of land and inland, coastal, and territorial waters is
for statistical purposes, and does not necessarily reflect legal
definitions thereof.
By definition, census blocks do not include water within their
boundaries; therefore, the water area of a block is always zero. Land
area measurements may disagree with the information displayed on census
maps and in the TIGER file because, for area measurement purposes,
features identified as "intermittent water" and "glacier" are reported as
land area. For this reason, it may not be possible to derive the land area
for an entity by summing the land area of its component census blocks. In
addition, the water area measurement reported for some geographic entities
includes water that is not included in any lower-level geographic entity.
Therefore, because water is contained only in a higher-level geographic
entity, summing the water measurements for all the component lower-level
geographic entities will not yield the water area of that higher-level
entity. This occurs, for example, where water is associated with a county
but is not within the legal boundary of any minor civil division, or the
water is associated with a State but is not within the legal boundary of
any county. Crews-of-vessels entities (see "Census Tract and Block
Numbering Area" and "Block") do not encompass territory and therefore have
no area measurements. ZIP Codes do not have specific boundaries, and
therefore, also do not have area measurements.
John Blodgett
Urban Information Center / Office of Computing
University of Missouri - St. Louis 8001 Natural Bridge Rd.
St. Louis, Mo 63121-4499 Phone: (314) 516-6014/6000 FAX: 516-6007
http://merrill.olm.net/pdocs/feas/pop/mable.html 8/12/95
dwmerrill@lbl.gov