Prepared by the Geography Division, U.S. Census Bureau, Federal Highway Administration (FHWA) and American Association of State Highway and Transportation Officials (AASHTO)
In support of the Census Transportation Planning Products (CTPP) the U.S. DOT and the U.S. Census Bureau will obtain census 2010 block equivalencies for Traffic Analysis Zones (TAZs) from Metropolitan Planning Organizations (MPOs) and State Departments of Transportation in 2011. The 2010 TAZ geography will then be added to the Census Bureau's TIGER file and these equivalency files will be used by the ACSO for the CTPP 5-year tabulation (2006 through 2010 ACS records).
A. Population and Workers
Basic counts of population at residence geography and workers at workplace geography will be available at the block, block group, or 2000 TAZ level to assist the user with delineation of 2010 TAZs.
These will include:
The geography features supplied by the Census Bureau will be those included in the MAF/TIGER Database (MTDB). The TAZ delineation schedule dictates that MPOs will be defining TAZ entity plans during 2011. The 2010 vintage TIGER file is expected to be used.
The software will need to create a Census TAZ (small), and a Census TAD (large) (Transportation Analysis District)
The software will allow for two levels of TAZs to be defined and saved. These are:
A typical Base TAZ is a level of data aggregation similar in size with respect to area, population, and worker count to a BG, and specifically designed to fit local planning needs by MPOs. A Base TAZ represents the smallest level of geography at which the CTPP data are tabulated. A Base TAZ may be defined to encompass a single census block, several census blocks, a BG or BGs, a census tract or tracts, a place, a county subdivision, or an entire county. Base TAZs are useful geographic entities because census tracts often split major employment centers. Thus, Base TAZs are not required to nest within census tracts or BGs.
These business rules are a mix of criteria that must be followed and guidelines that are suggested, but not required. If a TAZ entity does not meet the suggested minimum threshold or compactness indicator, the software will display a warning message, but the TAZ will not be rejected.
B. Suggested TAZ Minimum Thresholds
For 2010, the base TAZ may be similar to TAZs defined in 2000. The Census Bureau recommends that the minimum resident worker population and workers by place of work level should be approximately 600 persons. This minimum corresponds to the minimum threshold allowable for 2010 Census block groups. However, this threshold is only a guideline or recommendation and is not a requirement. Base TAZs may be defined with fewer than 600 residents or workers; however, as a general rule, data reliability and availability improves as population size or number of workers increases.
MPOs are not required to define TAZs; these entities are optional. Thus, TAZ geography will not provide blanket coverage for the U.S. MPOs choosing to not delineate TAZs do have the option of using other geographic entities such as census BGs or tracts for CTPP data tabulation. It will be the responsibility of the State DOT to define TAZs outside of MPO territory. MPO areas where no TAZs are defined will use tracts as default geography for small area tabulation in CTPP 5-year data products.
It is suggested that TAZs should be compact in nature. Nonetheless, compactness will not preclude delineation because there will be cases where long, narrow commercial corridors are necessary. The Census Geography Division is developing a method for guidelines for determining compactness. Failing to meet this guideline will prompt the software to issue a warning to the user, but will not preclude the TAZ entity from being accepted.
All TAZs must nest within a County. TAZs do not need to nest within Block Groups, Tracts, Places, MCD or another geographic unit. Furthermore, TAZ's have to nest within TAD's.
E. Contiguity and Slivers
Each TAZ must be defined as a single polygon with no uncoded sliver polygons between TAZs. Also, no two TAZ entities of the same type can overlap or cover the same area. The purpose is to avoid any small area with a small resident population and worker count that may be inadvertently missed when creating TAZs. Furthermore, all TAZs must be defined as complete polygons.
F. Water and Island Features
When setting a TAZ entity boundary, land and water polygons inside the boundary must be included. This is necessary to eliminate "pockets" within TAZs which can create problems when calculating TAZ "compactness" and determining completeness of coverage. Some islands will have their own unique TAZ. If an island does not have a unique TAZ and is combined with a land TAZ, then the intervening water polygons must be included to create a contiguous TAZ.
G. Overlapping TAZs
Each MPO will be asked to identify the counties within their area of jurisdiction. For purposes of the TAZ delineation program, each county must be assigned to only one MPO. In cases where a jurisdiction is included in more than one MPO, the MPOs will work together under the supervision of the State DOT to define TAZs for their respective MPO areas. If conflict arises between neighboring MPOs, the State DOT(s) and the MPOs in question will work to resolve the issue. If no settlement occurs, the Census Bureau will determine to which MPO to assign the territory.
H. MPO identification
Every MPO must be uniquely identifiable by the Census Bureau using an 8 character alphanumeric code. The participant will be required to enter the 8 digit MPO identification code already compiled and managed by FHWA.
Every TAZ entity must be uniquely identifiable using an up-to-8 character alphanumeric identification code. That is, there cannot be duplicate codes for any TAZ entity within a county.
J. Boundary Restrictions
TAZs may not cross county boundaries, implicitly meaning they cannot cross state boundaries as well. There are no other restrictions on TAZ boundary delineation, as long as they do not incorporate any area already included within another TAZ, and boundaries follow the set of eligible features listed below.
K. Creating TAZ Polygon Features
Base TAZs are built by selecting 2010 census blocks. Census TAZs can not split Census blocks.
L. Eligible Boundary Features
State and county boundaries must always be boundaries for TAZs. This takes precedence over all other criteria requirements.
The TAZ software should be flexible, user friendly, and as easy to use as possible. The software must be intuitive and generally guide the user through the review process, particularly through the review of the specific identified entities that do not meet the TAZ requirements so that the user can check, and either edit or provide a justification for, each of the related TAZ geographic entity issues. The software should then verify that all of the different entities meet the TAZ module requirements and create block equivalency files or shapefiles in the correct specified format.
The software will provide at a minimum four layers of Census boundaries files that the user can select as a starting point for TAZ delineation:
TAZ layer from the Census 2000
2010 census tracts
2010 census block groups
2010 census block
The user should be able to save and re-title the file for use as a base for the new TAZ plan. If none of these layers are selected as a starting point, then the user can aggregate different features (as listed in K. Creating TAZ Polygon Features)
B. Ancillary (non-Census) Data
Users must be allowed to import and display the following kinds of data files for use as a reference when delineating TAZ entities:
The software will allow participants to import a shapefile, for example updated MPO TAZ, for display which can then be used to select polygons to form the TAZs being defined.
Generally speaking, the delineation/edit/review process will be county-based. That is, edits to a TAZ plan for an MPO crossing county boundaries can occur only within the "active" county. Thus, in cases where the MPO delineation area crosses county boundaries, the user must choose which portion of the delineation is active on a county-level basis.
After the user completes each TAZ entity plan, the software must perform a series of edits/checks on the plan. Situations identified by the edits/checks must either be corrected, or the user must supply an explanation stating why a correction is not needed.
The necessary checks that will fail a submitted entity will include completeness, continuity, unique numbering. Checks that will only provide a user warning will include resident worker or worker level and compactness.
Once the user reviews and completes each of the edits/checks, the software must verify that the information meets the stated requirements and no new problems were introduced in the process of resolving other edits/checks. Effectively, if any edits or changes are made to an entity plan, the software must perform a final check on the plan to verify that no new problems were introduced via these changes. This final verification must be performed before the software will deem a plan as complete and ready for submission.
If any of the various verification edits/checks fail, the software must guide the user in how to correct the problem by stating:
The user should then be allowed to open the appropriate review sections, and if necessary, run the section-specific edit/check to locate the problems and fix them accordingly. Following that, the user must run the verification tools again. The user should be required to repeat this process until the TAZ submission meets all of the requirements.
Once the verify stage has been completed and all edits/checks pass, the software must create the BLOCK EQUIVALENCY FILE and two types of shapefiles (Base TAZ's and TAD's) specified in this document in the described formats for each TAZ plan. The software must then zip all of these files together for submission to the Census Bureau. The software also must create a report listing all TAZs that do not meet the recommended resident or workplace thresholds.