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
- 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:
These three areas comprise together 83% of all manual assignments.
- Florida, Charlotte Harbor
- 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
- 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
- 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.
Four major problems were identified with the USGS coverage obtained:
User should also be forewarned that hydrologic units have been clipped by
- 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
- Delineation of hydrologic unit questionable. No fix applied.
- 18020126, Upper Bear, Sierra Nevadas
- This hydrologic unit (yellow) is clearly divided by a mountain range.
The assignment of duplicates on both mountain sides is questionable. No
- 18060006, Central Coastal, CA
- 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.
(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).
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)
Last Update: 05-01-97