MABLE/Geocorr (Version 2) - Help Page
Table of Contents:
Background and Overview
Where the application runs
The Geocorr engine is mirrored and can be accessed via the following URLs:
The SEDAC site is considered the primary mirror, the CENSUS mirror is
definitely the fastest, and the OSEDA mirror contains the newest of
the newest. All mirrors other than test versions contain the same
What the application does
The MABLE/Geocorr geographic correspondence engine generates files
and/or reports showing the relationships between a wide variety of
geographic coverages for the United States. It can, for example, tell
you with which county or counties each ZIP code in the state of
California shares population. It can tell you, for each of those
ZIP/county intersections, what the size of that intersection is (based
on 1990 population or other user-specifed variable) and what portion of
the ZIP's total population is in that intersection. The application
permits the user to specify the geographic scope of the correspondence
files (typically, one or more complete states, but with the ability to
specify counties, cities, or metropolitan areas within those states),
and, of course, the specific geographic coverages to be processed. The
latter include virtually all geographic units reported in the 1990 U.S.
census summary files, and several special "extension coverages" such as
103rd Congress districts, PUMA areas used in the 1990 PUMS files, Labor
Market and Commuting Zone areas, and even hydrolgical unit codes
(watersheds.) The application creates a report file and a
comma-delimited ascii file (by default) which the user can then browse
and/or save to their local disk.
What is a "Correlation List"?
The output files created by this application are referred to as
"correlation lists". Other commonly used terms for such entities are
"equivalency files", "crosswalk files", and "geographic correspondence
files". A correlation list consists of a set of "source
geocodes" specifying the geographic coverage to be related (i.e
the "known" geographic coverage), and a set of "target
geocodes" specifying the geographic coverage to which we want to
relate the source areas. Frequently (always, in the case of files
generated by this application) the correlation list will include a
variable to measure the absolute "size" of the correspondence (such as
the land area of the intersection or the number of persons living in
the intersection). When such an absolute measure is present then there
may also be an allocation factor variable that indicates what
portion of the source area is located within the target
area. An entry in a census tract to ZIP correlation list (i.e. a list
with "census tract" as the source coverage and ZIP as the target) might
contain the population living in the tract/ZIP intersection and a
number indicating what decimal portion of the tract's total population
also live within the ZIP. The sum of these allocation factors for any
specific value(s) for the source geocodes(s) should always be 1.0. For
COUNTY TRACT ZIP POP AFACT
29510 1101.00 63109 1250 .500
29510 1101.00 63110 625 .250
29510 1101.00 63111 625 .250
Here we see 3 entries from a tract-to-ZIP correlation list. All 3
entries are for the same source code, census tract 1101.00 within
county 29510 (city of St. Louis, Mo.) The entries show that the tract
intersects with 3 different ZIP codes (estimate based on 1990 census)
and show the absolute and relative sizes (POP and AFACT, respectively)
of the intersections. Note that if we add the 3 POP values we get
the total POP value for the tract (2500), while if we add the 3 AFACT
values we get (as always) 1.0.
Typically (always in this application unless overridden with an option)
correlation lists are sorted first by the source geocodes, and then by
the target geocodes within the source codes.
Who/what is MABLE?
"MABLE" is an acronym for Master Area Block Level Equivalency.
This is the name of the database that is used by the geocorr engine to
create the correlation lists. "Block" here refers to 1990 census
blocks, the smallest geographic units used in tabulating the 1990
census. It was chosen as the base unit for the application because the
Census Bureau used these blocks as their "atomic unit" for all other
census-based geographies in 1990. Thus, census blocks will never cross
a place (city) or MCD (county subdivision, township, New England town)
boundary. While they can and do cross ZIP code boundaries, for the
sake of this application (and based on the Census Bureau's offical 1990
Block-ZIP Equivalency file) each block is assigned to a unique ZIP code
(vintage October, 1991). The MABLE database is actually a collection
of 51 state-level datasets containing a total of just under 7 million
How does GEOCORR work?
The hard part was building the database and the user interface. The actual
processing is fairly simple. Once you determine the geographic universe that
the user specifies as well as the source and target geocodes and weighting
variable, it is a matter of extracting these items from the appropriate entries
in the MABLE database. This yields a set of census blocks for the geographic
area specified, each one identified by the source and target geocodes and with
a measure of its "size" (population, land area or number of housing units.) To
build the correlation list outputs (listing and/or .csv file) is a
relatively simple process of sorting and aggregating. What this amounts
to is using the census blocks as a kind of "geographic pixel", or
indivisable geographic unit. All correlations are "rounded off" to the
census block level. For a majority of the geographic codes the roundoff
error is 0 since most of them are never split by blocks. The resulting
file is similar to the sort of result you can get from a GIS by doing a
polygon intersection operation. But it goes much faster (and the output
is presented in a more convenient format perhaps) because we have already
determined all the spatial correspondences and stored the results in
MABLE: all we need to do is pull out the subset of the approximately 7 million
pre-defined answers and aggregate them.
We'll work on a separate module for discussing the real nitty gritty details of
the programming and interface tools used to build the application. But basically
the application was written in SAS(r) and uses Perl interface scripts to handle
the forms output. The MABLE database is a series of SAS datasets and views
with auxiliary "tables" (SAS format codes, for those familiar with the
package) which are used to "look up" some of the codes during geocorr
processing. Most of the SAS code (and all of the dababase design)
was done by John Blodgett of the Urban Information Center, University of
Missouri St. Louis under a contract with SEDAC/CIESIN. The Perl interface
routines were written primarily by Hendrik Meij of CIESIN. The HTML design
and coding have been a joint effort.
Overview of the Geocorr Form
The form has gotten rather large as we have added more features. But the
basic features that we expect most users of the application will be
interested in most of the time are still all contained in the basic Input Options
and Output Options sections. A 1-line set of links allows jumping
directly to any of the 5 sections of the form. The order in which you
specify options is, of course, irrelevant.
These are the options
that control the basic nature of the correlation list you want to have built
for you. Here you specify the states, the geocodes and the weighting variable.
Note that here, as throughout the form, most items have been assigned default
values, so you need to at least consider each one. If you do not, then the
default value remains in effect and you need to be sure that this is acceptable.
In other words, don't rush through the form assuming that if you fail to fill
something out that is important, that you will be prompted for the value. If
you do not specify the weighting variable (for example), the program assumes POP and does so
without any dialogue with the user.
Click on one or more state names in this select box to indicate the state or
states that you wish to process. You must specify at least one state
(if you don't, the application will abort the run with a message
reminding you that this is a required option with no default.) Note that
on some of the mirrors you may see notes indicating limits on the number
of states that may be selected during certain times. Be sure to note
these limits. If you need to run the application for large numbers of
states, please do so on weekend or during off hours.
The first choice, "Random pick", is used mostly for testing and
demo'ing, when you just want to see how or if something works and you
con't care which state you choose. (Delaware is also a good choice in
Be sure you know how your browser works when making multiple selections from a
select list like this. Netscape, for example, requires that you hold down the
"ctrl" key while clicking on items to get multiple selections; but IBM's Web
Explorer (OS/2) does not - each click makes a new selection and you have to click on
a selected item to de-select it. Be careful with this.
Link to the MAGGOT file
This application makes use of a lot of different levels of geography
("coverages"), most of them corresponding to standard Census Bureau
defined areas. To help users who are not familiar with these types of
geography, we have created this auxiliary help file with more
detailed descriptions of each of the area types. "MAGGOT" is an acronym
for Master Area Geographic Glossary of Terms. Please check MAGGOT if you
have questions about any of the geographies before you send a
note asking for additional explanation.
Source and Target Geocodes
These two (side-by-side with identical entries) select boxes are used to
tell geocorr which geographic units you are interested in. Note that we
have pre-selected some defaults for you (census tract to ZIP code), but
you really need to think about what values you want for these options.
The "Entire Universe" selection can be used when you just want to relate
one kind of geography to the whole selected area. This option is most
useful in conjunction with the point-and-radius or bounding box features.
For example, you can select "county" as the source and "Entire Universe"
as the target with Population as the weighting variable. This is an
extremely inefficient way to have geocorr simply print a report
with the total populations of these counties (if this is all you want we
have a link in the Geographic Filters section that will give you this
information a lot more quickly.) But if you also specify point-and-radius
valued, geocorr will then produce output showing the population of each
county within the specified radius. It will only process counties in the
selected states, of course.
Note that these geocode menus have more entries that are
visible on the form, so be sure to scroll down to see all the goodies.
You also need to carefully note the parenthesized asterisks used to point
to important footnotes for certain codes. It may be important to know,
for example, that HUC codes are not available for Alaska and Hawaii. (To
date, this is the only instance we are aware of in MABLE, where a geocode
is not available for all 50 states plus the District of Columbia.)
Click on one or more geographic codes you want to use for the "source"
portion of the correlation list. The output will normally be sorted by the
values of these codes. For example, if you select COUNTY and TRACT (the defaults)
then the output file will be sorted
by county and then tract. The sort order is the order in which the variables
appear in this select list. Certain geocodes occur in a hierarchy so that
selecting them automatically triggers selection of a higher-level qualifying
variable. These are MCD (implies COUNTY), TRACT (implies COUNTY), BLOCK GROUP
(implies COUNTY and TRACT), and BLOCK (implies COUNTY and TRACT; block group
is not selected but it is implicitly present as the 1st digit of the block.)
Note that COUNTY is a 5-digit code that includes the state code. STATE is
usually added to the output file as an extra id variable, even if it is
not explicity selected as one of the source or target geocodes; but this
is not the case if COUNTY is chosen, since these codes allow you to
derive the state.
Most codes are FIPS (Federal Information
Processing Standard) if defined, or census codes otherwise. Be sure you
understand that selecting multiple source geocodes means that the source areas
are the intersection areas formed by looking at values for all the
source codes. Thus if you click on COUNTY, MCD and ZIP for the source geocodes
then the "source areas" represented on the resulting correlation lists are
formed by the intersection of these 3 area types: i.e. a portion of a ZIP code
within an MCD within a county. If what you actually want is a correlation list
for MCD's and a (separate) correlation list for ZIP codes, then you need to
invoke the application twice; geocorr creates only one list per run.
Most of what was said for the source geocodes, above, apply equally to the
target geocodes. Do not select the same geocode in both lists. The codes you
select here define an area formed by the intersection of those areas. The
correlation list defines the relationship of the source codes to these
target areas. The default value (what you'll get if you do not click
in this select box at all) is ZIP - the 1991 5-digit ZIP code (as defined in
the Census Bureau's ZIP-Block equivalency file -- see the MAGGOT file
Concentric Ring Pseudo-Geocodes
This is one of those things that reads as though it was terrifically
technical and complex, but when you see an example, you see that its
actually pretty simple. When you choose this geocode (in either the
source or target list), then you must provide some additional
information in the Point and Distance Options sections. Just
remember, that what happens when you choose this is that you are
creatinga a new geographic coverage based on geometry rather than any
pre-defined boundaries. Think of a dartboard target, with a small circle
at the center, and then concentric circles surrounding that; this is what
these "CRG"s look like. The precise location and size of these areas are
specified later in the form. Each block-level entry in MABLE has an x-y
coordinate associated with it, and these "internal points" can be
mathematically assigned to these ring areas using a simple distance
formula. You can use this feature to do applications such as examining a
100-mile radius of a city or ZIP code, and finding out approximately how
many persons (in 1990) lived within a 25-mile radius, in the 25-to-50
mile "ring", and in the 50-to-100 mile "ring". Lots of possibilities
here. For further discussion see the Point and
Distance options section, below.
Digits of hydrological Unit Codes to keep
This option lets you specify the level of detail for the huc (aka
"watersheds") codes. For a more detailed description of huc's and the
meaning of the 4 levels see the MAGGOT file.
Select a single variable to be used to measure the amount of intersection between
the source and target geocodes on the output file. By default, the 1990
(complete count) population will be used. On the output this variable
will contain the sum for all the blocks used in creating the output
record. While the primary reason for processing such a weight variable
is to provide some measure of the degree of intersection of two sets of
geocodes, you can also take advantage of this to have geocorr simply
count people of housing units or square miles in selected jurisdictions.
Want to know the population (1990) of Labor Market Areas in your state?
Just select your state, then LMA90 as the source code and state (or
Entire universse) as the target code, with pop90 as the weighting
variable. Each line of the output list will contain the 1990 total
population of one LMA in your state.
Option to ignore blocks with 0 value for the weighting variable
There are many census blocks that occupy space but have no population. When
building a correlation list with POP as the weighting variable you may find
that leaving these blocks in results in output lines showing a correspondence
that has a value of 0 for the POP and AFACT (allocation factor) variables.
This indicates some spatial overlap between the areas, but no population in
that overlap. If you check this box then those lines with 0 values for
the weight variable will not be present on your output. It will also make
processing slightly faster since the program will have fewer observations
These options specify details about the output generated by geocorr. In many
cases you will be able to accept all defaults for these options (unlike
the input options where accepting all defaults would be very rare.)
Have weighted centroids on output file(s)?
Each of the census block entries in the MABLE database has a pair of latitude,
longitude coordinates for an "internal point" of the census block. This is
the geometric centroid of the block except in those few cases where the true
centroid is not within the block, in which case it is moved to a location just
inside the block. When you select this option, geocorr keeps these coordinate
values and as it processes the blocks within the source/target geocode groups
it takes a weighted average of their values (using the weight variable specified
in the INPUT OPTIONS section - usually 1990 population.) The result of this
is that on the output files you will have two extra columns of data, INTPTLNG
and INTPTLAT (these are terrible names and we may get around to changing them -
make sense on the MABLE database, but not on the output). They will be in
degrees, with 6 digits after the decimal point kept (if needed.) West longitude
is assumed, no minus signs.
Second allocation factor (afact2): target to source
The standard output correlation list from geocorr has a single AFACT allocation
factor variable which indicates the decimal portion of the source geocodes
contained within the target geocodes. It may also be useful to know how this
works going in the other direction, i.e. to know what portion of the target
area (the complete target area, not just the part within the source area) is
contained in the source geocodes. Selecting this option causes geocorr to do
the extra processing and calculations required to create such a "dual factored
list". The best way to see how it works is to select the option once and study
the AFACT2 values.
Sort by target geocodes
Normally the output file is sorted by the source geocodes, then by the target
geocodes within the source. This option lets you override the default and
have it sorted by the target codes first. An example of where you might
want to use this option would be in creating a ZIP to CD103 list. You want to
look at which ZIPs and what portions of those ZIPs make up each Congressional
District. But you want the results organized by CD first, so that you can
focus on the portion of the report relevant to the district you want to mail
to. Specifying this option causes the output to be sorted by CD first, then
show all the ZIPs within each CD together with allocation factors
indicating what portions of the ZIP are in the CD. (If you specified
CD103 as the source and ZIP as the target, you would get the sort the way
you wanted, but then the AFACT allocation factor values would show the
portion of the CD that was within the ZIP, which is typically a very small
and relatively useless number.)
There are two basic output files available - each is optional and each
has its own options for specifying what it contains.
Generate a CSV file
This option is selected by default, meaning that geocorr will create an ascii file
in comma-delimited format that you'll be able to browse (preview) and then save
to your local disk. Generally this is the option to use if you want to do
processing of the correlation list back on your platform using your favorite
software package. The ".csv" file extension is a standard that is recognized
by most Windows programs, making it easier to import the data into those
applications. Note that this file will have the variable names as values in
the first line (the "header" record), which when imported into a
spreadsheet such as Excel or Lotus will become the first row. If you have
no interest in obtaining such a file (you only want the report format)
then click on this box to turn off the option. It will save processing
Codes and/or names on CSV file
In many cases it will be convenient to carry along names to go with the codes
on your output file. If you select "Codes & Names" or "Just Names" then,
for any geocode for which geocorr has a "name table" and that you select
as either a source or target geocode, the program will add a new variable
(with name ending with "NM", e.g. PLACENM, COUNTYNM, etc.) to the output
ascii (.csv) file. Usually, if you want names, you should select the
"codes and names" option, rather than asking for just the names.
Use tabs (not commas) ad delimiter
Some software packages accept tab characters to delimit fields, just as
commas serve as field delimiteds in .csv files. An advantage of using
tabs as the delimiter is that when you browse the file (with Netscape and
MS IE, at least) the tab characters make the data fields start on tab
stops, so its easier to see what the data values are. But we've had
trouble importing tab-delimited into excel.
Generate a listing file
You'll normally want to leave this option selected so you can at least see a
nicely formatted eye-readable version of your output (the .csv file is intended
more to be program-readable than eye-readable although you can browse it and
count commas.) This is the preferred format for using as a reference report.
The lines can be up to 157 characters across and it will print 240 lines before
generating a page break with fresh column headers. Source geocodes will always
appear first (leftmost) on the report and consecutive duplicate values of the
source geocodes will be blanked out to emphasize "breaks" in the value of
the source codes. This will normally be the largest output file. If you
do not need or want it then you can save processing time by deselecting
Codes and/or names on listing
See the discussion, above, of names for the output CSV file. Generally, you
are more likely to want names on the listing output than on the .csv file.
The default is Just Codes, so you have to select this option to get the names included.
Point and Distance Options
Geocorr permits the selection of geography based on geographic
coordinates. Specifically, blocks from the MABLE database can be filtered
(excluded from further processing) by using their internal point
coordinates (a spatial centroid that is stored on the MABLE database) to
determine their location. You can specify limiting processing based on a
specified point and a radius about that point, or using a rectangular
"bounding box" criteria. In either case the coordinates should be
specified in units of decimal degrees with longitudes assumed to be "west"
(leading minus signs are assumed and are optional.)
Specify a point and distance filter
If you enter values for a specified point location as decimal degrees of longitude
and latitude you are telling geocorr that you want it to calculate the distance
between that point and the "internal point" of each census block on the MABLE
database that is otherwise selected for processing (i.e. that first passes the
other geographic filters we'll be discussing, below.) Note that the longitude
value entered is assumed to be West longitude and the leading minus sign is
optional; if entered, it is ignored. Entering a value of "92.6543" is interpreted
as 92.6543 degrees west longitude. Geocorr expresses all coordinates with
this convention: longitudes on output files are also expressed as positive values
for west longitudes. Many GIS programs will require these values to be negated
if these coordinates are to be processed.
You cannot enter just one of the coordinate values: if you specify a longitude
value then you must specify a latitude value as well.
Label of Point This box can be used to enter a descriptive label for
the point. This label is picked up and used as part of the descriptive
label for the distance variable which is included on the output file when
you specify a point. This is an optional entry so you need not specify
Ring or Radius distance in kilometers This check box can be used if
you want the value in the following box to be interpreted as kilometers
rather than in miles.
Value for radius or radius of largest ring This entry is used
in conjucntion with the coordinates of the specified point in three
- If you did not select "Concentric Ring Pseudo-geocode" from
the source/target geocode lists and you enter a value here, then it will
be used to select only blocks whose center points are within the
specified distance from the specified point.
- If you specify a value of 0 here, then no filtering of
blocks based on distance will be done, but such distances will be
calculated and an average weighted value of these distances will be
included on the output file(s).
- If you did select a "Concentric Ring Pseudo-geocode" option from
either the source or target geocode lists, then you should enter the
radius of the largest ring here.
Using this option has a dramatic effect on the way you interpret the entries
in the output correlation list, since everything there has to be qualified by
starting with the initial filtering options. Typically, use of this option,
will be used with a very large target area (such as a complete state or metro
area) and the real correlation is between the n-mile circular area and that
large target area or areas. For example, you could specify a place-to-state
correlation list (source geocodes=place, target geocodes=state), with a metro
area filter (only the portions of the places with the specified metro area are
processed) and the coordinates of the metro airport entered with a radius of
3 miles specified. What results is that only blocks within 3 miles of the
airport are selected. On output the POP figure shows the total persons living
in the specified places and also in blocks that are within 3 miles of the
airport, and the AFACT variable will typically be 1.0 since ALL of the blocks
in the selected place will be associated with the same state. It is critical
to remember that the POP figure shown is not the total population of the place,
but only the population of the portion of the place within 3 miles of the
specified point. If you need to know what portion of the total population of
the place is within this circle, you will have to do some special postprocessing,
since this figure is not readily generated directly by geocorr.
Note that whenever you specify the point option a DISTANCE variable is
added to the output file. This distance is in miles (or kilometers if you
checked that box) and represents the approximate distance from the calculated
weighted centroid of the output area (source/target intersection) and the
specified point. When you are using the point-and-radius options strictly as
a filter you may well have no interest in this item, but it is included in the
Note:This DISTANCE variable and the weighted x-y coordinates
of the output areas will not be kept if you have requested Ring
pseudo-codes. We decided to force these items to be dropped in this case
because when dealing with a donut-shaped area, the meaning of a weighted
average of the coordinates of the blocks making up such an area is at
best meaningless, and at worst confusing and misleading.
Defining Ring criteria
There are two mutually exclusuve ways in which you may specify the specific
Ring-shaped areas that you want geocorr to determine for you. You can
specify a value for # of equi-distant rings; this value must be
a positive integer (no fractional portion allowed) between 1 and 10.
Geocorr will divide the radius by this number to determine the size
(distance between the inner and outer radii) of each ring. Geocorr will
process at most 10 such rings. If your areas are not of uniform size,
then you may explicitly enter the outer diameters of each in the
boxes provided. In this case, you should not enter a value for the
# of areas. Enter the values in ascending order, starting with box #1.
The last value entered should have the same value as you entered for the
radius of the largest ring (or you can omit that value altogether when
entering these explicit values.) Please type carefully.
Links to Assist in Getting Coordinates
We have provided a number of links to web sites that can be of some
assistance in determining the lat-long coordinates of the location you
have in mind. Our personal favorite is the Census Bureau's
Gazetteer application. It lets you type a ZIP code or a city name
or a county name (all within state) and will return you a list of
geographic entities that match your request. This returned page will
have links on it to allow you to jump to the TMS map server to view
the area you want to study. We have also provided a direct link to the
TMS (Tiger Map Server) application, but in most cases you'll be better
off using the Gazetteer as a way to access this application with the area
you have in mind already displayed. Otherwise you have to wait for TMS to
display a map of the Washington, D.C. area which is unlikely to be what
The Yahoo Map Server is excellent for getting down to street
address or street intersection level and seeing the area of interest. It
does not explicitly return latitude longitude coordinates. However, with
your address showing on the map, move your mouse to the "Printer Preview"
button and then observe the URL corresponding to it at the bottom of your
browser window: it contains the coordinates you need. Write them down so
you can enter them in the form when you return to Geocorr.
Finally, we provide a link to Michigan State's Weather Station
Bounding Box Filter Option
This is simple. You enter the lat-long coordinates of the extrema
coordinates to define a rectangualar area, or "bounding box", to which
you want Geocorr to restrict itself. Only blocks with internal coordinates
inside this "box" will be selected. Coordinates should be in degrees,
with decimal notation (no minutes or seconds). If you accidentally
switch the low/high values the program will check for this and switch
them back for you. Minus signs for longitudes are optional - west longitude
Geographic Filtering options
For many applications by the time you get to this point on the input form
you'll be ready to click on the "Run Request" button to tell geocorr you are
finished with your specifications. All the
options that remain have to do with limiting the set of blocks that will be
processed by geocorr by specifying lists of county, place or
metro-area level codes that will be used to limit the areas processed.
General information re filtering by geographic code lists
Geocorr allows you to specify lists of 3 types of geographic areas that will
be used to further limit the geographic universe ("further" meaning, following
state-level filtering which is mandatory and is dealt with under INPUT OPTIONS
and prior to coordinate-based filtering based on bounding box or maximum
The first box to check is preceded by the explanation for its use: to
specify that if multiple types of geocodes are used to filter that they each
be considered as sufficient rather than necessary conditions
for inclusion. For example if I do not check this box and I then enter a value
in the "place codes" box for Kansas City, Mo and a value in the "county codes"
box for Jackson county, Mo, then the universe would be limited to the portion
of Kansas City within Jackson County. But when I check this box then the
conditions become "or"-ed instead of "and"-ed, meaning I want all blocks that
are either in the city of Kansas City or in Jackson County. So now I
get all of the city (which I did not before) plus I get the parts of Jackson
County that are not inside the city.
To limit the universe based on one or more counties to be selected you can
enter their FIPS codes in the box provided. Be careful to enter full 5-digit
codes when processing multiple states; 3-digit codes are OK if you only selected
a single state for processing. Specifying a code for a state that was not
selected will cause an error and geocorr will not complete processing. If you
need to look up a county code, simply click on the "County codes" hyperlink.
You'll have to note what the codes are and enter them after returning from the
the linked-to code pages.
Similar processes apply for filtering by place and by metro area, except,
of course, that there is no option for entering a state portion of the codes.
Simply enter the 5-digit FIPS place codes or the 4-digit MSA, CMSA or PMSA metro codes
in the appropriate boxes.
Be sure to specify leading zeroes in all codes.
Don't forget to click on the SUBMIT button to tell the application
that you have finished with specifications and are ready for processing.
Accessing and Understanding the Output
When and if your request is successfully processed you should see
a screen with a series of filenames and descriptions, with each of the
filenames being a hyperlink to the file itself. There are four possible
output files, depending on what options you select. These are each
The summary.log file
This file gives a very brief summary of what you requested and a little
about what the program did to satisfy the request. It tells you, for
example, how many census blocks were selected for processing and how many
lines (records, observations) actually made it to the output files. The
first line on this file tells you what your "Process id" was for this
request. If you have any problems with your request you need to be sure
to save this key number and report it to the authors with a description
of what went wrong. In most cases, you'll find that you should be able
to safely ignore this file unlesss you have a problem.
The geocorr.lst file
This is your listing (i.e. report format) file. It is usually the largest
of the output files, and often the most important. Note its size before
attempting to print or save it to your desktop since it may be quite
large. If you filled in that box on the form that let you specify a name
other than "geocorr" you should see that name here instead of geocorr.
The same applies for the .csv file, next.
The geocorr.csv file
This is your comma-delimited ascii file. You might want to
browse/preview it, but you'll most likely want to save this back on your
local disk. You should be able to easily load the file into a
spreadsheet for further local processing.
The varlst.lst file
This is a very short file that simply provides a little extra information about the
variables, as specified in the header record,
on your .csv file. If you did not request a comma-delimited
file then you will not get this file either: they are a matched set. The
report lists each of the variables (fields) on your file and adds a
descriptive label to help you identify what each means. You'll note that
the variables have a consistent order in this report and on the .csv file
with the source geocode fields appearing first, followed by the target
codes and then the weight variable, allocation factor(s) and any x-y
coordinate and distance-to-specified-point items. If you did not
explicitly specify "state" as one of your geocodes you will nonetheless
see it added to this file as well, usually after the last target geocode
and just before the weighting variable.
These files are all stored in a temporary directory and will remain there
for a period of several hours or so. But you should retrieve them to your
local system before exiting the application.
If you do not receive any output, or you get output that you feel is not
consistent with what you requested, please be sure to record the date
and the process id number associated with the query before reporting the
Last Update: 02-22-97