MABLE/Geocorr Usage Notes

This Usage Notes page describes, in chronological order, known problems or limitations related to this application. Notes are in chronological order, with the most recent first. updates applied to the Geocorr application.

Please use the "Comments and Suggestions" link at the bottom of this page to reach the developers.

Problem: Metro format values fail in specific regions.
Metro values in Geocorr V1 and early V2 versions were designated as $metro94, $metro95, etc. We have created one master list which is now always used and is named $metro. At the same time we fixed some english names which appeared empty for certain regions.
(Resolution Date: 07.11.97)

Problem: Program fails with fractional radii values.
Fractional values, even a ring size of 1.0 caused the program to fail. Bug has been fixed and now you can also specify a max ring of 3 and 4 areas and program will properly calculate .75, 1.5, 2.25 and 3 for outer-ring radii.
(Resolution Date: 04.24.97)

Problem: Program fails when processing many states at a time with certain geocodes
We noticed this when we ran a test to retrieve huc codes for the entire U.S. It processed all states through New York, but failed with a misleading error message when starting to process NY. But running NY by itself ran fine. And when we went back and ran the same request but omitting California, we got the same error, but now for Ohio. This suggests that the problem has to do with loading the SAS format codes (1 per state) used to look up the huc codes. The easy workaround is to break the request up into two runs, doing half the states in each. This problem will occur when selecting hucs, 1980 county, tract, MCD or place, and/or VTD codes.

Problem: Missing Hydrologic Units
While building the HUC coverages several problems were encountered explained in this section. These problems may affect the POP/HUS/LAND allocation one expects. The most basic problem was block centroids falling just outside coastal HUC boundaries. This problem was universally fixed by "snapping" those points (red) to the nearest HUC (grey) ([IMAGE]). In all, about 8,276 points (out of 7 million) were manually assigned. The basic routine for assignment involved a point in polygon algorithm.

Three regional problem areas were encountered:

Florida, Charlotte Harbor ([IMAGE])
Within the HUC coverages, Tampa Bay is assigned to a hydrologic unit but not Charlotte Harbor. Roughly 5,420 block centroids comprise this single problem area depicted in the image. There is a HUC8 code for Charlotte Harbor (03100103) but it is never used within the USGS coverage. We decided to assign all 5,420 points to this HUC. The Peace river is essentially the major feature in this area and flows into the Harbor from the north.
New Jersey, Delaware Bay ([IMAGE])
Roughly 400 block centroids were assigned to the Bay area depicted in the image, probably of very minor consequences to demographic summaries.
New York, Upper Saint Lawrence River ([IMAGE])
A total 1,077 census block centroids were added to the hydrologic unit Upper St. Lawrence. The image clearly depicts the hydrologic unit itself and the extension marked by dots in yellow. This addition may greatly influence tabulations performed in this area and should be viewed with caution.
These three areas comprise together 83% of all manual assignments.

Four major problems were identified with the USGS coverage obtained:

18070201 and 18070204, Los Angelos Area Beaches, CA
The codes above never occur in the USGS coverage. Instead the codes 1870201 and 1870204 occur which appear to be typos. These areas are Seal Beach and Newport Beach, respectively. A fix has been applied.
The code for Seal Beach never occurs in the USGS coverage. Instead the code 18700201 can be found. It is assumed that the occurring code is a typo for the Seal Beach code.
04070001, Upper Peninsula, MI ([IMAGE])
Delineation of hydrologic unit questionable. No fix applied.
18020126, Upper Bear, Sierra Nevadas ([IMAGE])
This hydrologic unit (yellow) is clearly divided by a mountain range. The assignment of duplicates on both mountain sides is questionable. No fix applied.
18060006, Central Coastal, CA ([IMAGE])
Two hydrologic units with idential code (yellow) divided by a boundary. In this case, two major rivers flow lengthwise across both units joining in a lake on the boundary. Questionable if they constitute one hydrologic unit. No fix applied.
User should also be forewarned that hydrologic units have been clipped by national boundaries.
(Resolution Date: 01.28.97)

Problem: Missing parts of NC
A user notified the developers that the total population of NC when summed across apuma and bpuma geographies was incorrect. This problem was traced to an error in processing the original ZIP-block equivalency file for NC (about a third of the counties were missing altogether). The fix required regenerating the NC portion of the MABLE database and rerunning the sample PUMA correspondence files for NC.
(Resolution Date: 10.04.96)

Problem: apuma 00602 in New Hampshire is missing.
This problem was initially reported by one of the developers while creating PUMA boundaries for both 1% and 5% geographies (see: pumaread.txt.) The problem was traced to extraneous records on the pumgef file with '000' codes for MCD's and 0 populations. The problem affected 3 New England states -- NH, ME and RI. The PUMA geographies were fixed, and the MABLE database was updated.
(Resolution Date: 11.25.96)

Problem: Population totals.
The developers ran a "quality check" program in which we took the .csv files generated by the application to relate all A and B PUMA's to counties for the entire country with POP as the weight variable. This provided a PUMA/county population figure for each of these combinations in the country. We have similar information on the PUMS geography equivalency file ("PUMGEF") that we got from the Census Bureau, and which is the basic of the PUMA codes in MABLE. Our program did a match of the population figures from MABLE/Geocorr with those from PUMGEF. Slight discrepancies were found in a few counties. The report below details these unresolved discrepancies. (We did not specify the option to skip zero-pop blocks when we ran the application, so the cases with 0 population on PUMGEF are not to be expected. But not to be worried about much either.)
(Resolution Date: none).
          Problem County/pumas
                                              MABLE     PUMGEF
COUNTY    PUMA     PTYPE    _NAG_    STATE     POP         POP        PROBLEM
04019     00201      A        42      04      133626    133620    Pops do not check
04019     00201      B        42      04      133626    133620    Pops do not check
22033     01302      A        56      22      118088    116901    Pops do not check
22033     01502      B        56      22      118088    116901    Pops do not check
29043     02500      B         1      29           .         0    Not in mable
36055     01900      A         1      36           .         0    Not in mable
36063     04600      B         1      36           .         0    Not in mable
36081     05404      A        26      36      116503    116502    Pops do not check
36081     05504      B        26      36      116503    116502    Pops do not check
40131     00101      B         2      40           .         0    Not in mable
48167     05402      B        81      48      114076    114068    Pops do not check
48167     06302      A        80      48      113716    113708    Pops do not check
48397     02200      B         1      48           .         0    Not in mable
48409     05002      B         1      48           .         0    Not in mable

Note: Problems for the New England counties that were fixed have been deleted from the report.

Problem: Missing County Names for Ak ...
The initial notice received involved missing county names for AK when the output option "Codes and Names" was selected. Other states affected were AZ. The missing information has been added to the format catalogs. In addition, the files for AK and AZ under the "Samples" button were updated (the pre-tabulated puma files). Also, the files for IA, MD, and NM have been edited changing the character '@' to an apostrophe which it should be (as in "ST. MARY'S").
(Resolution Date: 12.16.96)

| Top | SEDAC | UIC | FTP Archive | DDViewer | Credits | Comments and Suggestions |

Last Update: 05-01-97