MABLE/Geocorr (Version 2) - Help Page

Background and Overview

Where the application runs

The Geocorr engine is mirrored and can be accessed via the following URLs:

http://www.census.gov/plue/geocorr
and at
http://oseda.missouri.edu/plue/geocorr
and at
http://plue.sedac.ciesin.org/plue/geocorr.

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 functionality.

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 example:

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 block entries.

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.

Programming Details

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.

Input Options

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.

Selecting state(s)

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 these cases.)

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.)

Source geocodes

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.

Target geocodes

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 for details.)

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.

Weighting variable

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 to process.

Output Options

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.)

Output Files

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 time.

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 this option.

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.

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 output nonetheless.

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 you want.

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 location page.

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 assumed.

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 radius specifications.)

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 described.

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 problem.