-
Notifications
You must be signed in to change notification settings - Fork 2
Zone Development Guidance
A TAZ is one of the basic spatial unit of travel analysis in OR-RAMP. All of the model results from OR-RAMP can be analyzed at the TAZ level including commuting pattern and mode choice. TAZs are intended to model automobile travel. Therefore, they can be much larger than MAZs since automobile impedance is less sensitive to small differences in zone size/shape. The size of TAZs can vary with the model application and can be as small as a block or more than 10 square miles. A typical TAZ system should be specifically designed to fit local planning needs by MPOs. The analyst should be cognizant of the following guidelines when delineating TAZ boundaries:
Zonal boundaries should follow Census boundaries as faithfully as possible. This is essential as the Census Bureau directly provides socioeconomic data at a variety of geographies including Census Block and Census Tract which can be used as inputs to the ABM with little or no manipulation. If a TAZ were to split a Tract or a Block, an allocation methodology to distribute the data from the split Census geography needs to be developed.
Also, Census provides a fully disaggregate dataset called Public Use Micro-data Sample at the level of a Public Use Micro-data Area (PUMA) – this dataset is used as seed data in the synthetic population. Defining TAZ boundary to be consistent with PUMA makes the population synthesizer allocation procedure more accurate.
Natural barriers such as rivers or mountains or man-made barriers such as railway tracks constitute physical boundaries. Physical boundaries restrict free movement and a centroid connector that passes over a barrier to access a road network would be unrealistic. This can be prevented by using the physical barrier as the zone boundary.
TAZ boundaries should be consistent with political boundaries such as city, county, MPO and state boundaries. This will help in performing sub-area analysis such as city-city/county-county flows. If the region uses planning districts for performing similar analysis it would be useful to line the TAZs with the planning district boundaries as well.
Consistency with previous zone boundaries should be maintained whenever possible. This would help preserve valuable socioeconomic data and the capability for comparisons.
Another factor to consider when delineating TAZ boundary is the highway network. Similar to physical boundaries discussed above, facilities including freeways, expressways, and arterials act as access barriers and hence should not split a TAZ. Arterials are used as TAZ boundaries, because they are frequently used as Census boundaries. Linking connectors to arterials results in better distribution of traffic on the network.
TAZs should be created such that it has homogenous land-use and socioeconomic characteristic. For example, a major retail development should be placed in a different TAZ than a neighboring residential development. This segmentation helps the transportation planner systematically understand activity generation as well as it helps in minimizing intra-zonal travel. In areas of dense developments, such as the central business district, it is not always possible to satisfy this condition. However, MAZs nesting within these mixed use development TAZs can be used to address this issue to some extent.
Each TAZ should consist of one non-overlapping polygon and should be uniquely identifiable using an identification code. In general, the identification code should be continuous (no skipped IDs) for the set of TAZs in the region (although it can be helpful and common practice to create discrete number series for sub-regions within the model; example within the MPO is TAZ series 1000, outside the MPO is TAZ series 2000). Also, the TAZ system should be contiguous and its coverage should span the study region (MPO in this case).
TAZ centroids should be the center of activity for automobiles, i.e. where automobiles entering the zone want to go. They should accurately represent actual roadway access connections and should not cut across barriers (tunneling). Also, sufficient number of centroid connectors needs to be coded so as to avoid concentrated loading of trips from a zone onto a particular link. It is also important not to connect a centroid to an intersection, ramps or any access restricted facility.
There are three critical elements to keep in mind when connecting zone centroids to the transportation network:
- The loading location,
- The number of loading locations (number of connectors per zone per mode), and
- The Length (or ultimately) travel time of the connectors.
For loading locations (connector placement), it's important to consider where the majority of traffic from the zone would naturally want to enter / access the transportation system. It is typically advantageous to have a "spur" residential or major driveway link to connect to as opposed to linking directly to a more major facility. Ensure to never connect directly to an access controlled facility (like an interstate). Also be aware of nature/physical barriers. Never connect over a river or ridge line where a bridge or tunnel doesn't exist.
For number of loading locations, in general fewer is better. If you have too much traffic entering at a connection point, you might consider splitting the zone prior to adding connectors. The issue with adding many connectors is that all users on the East of the zone won't access the East connector. The East-siders will use whichever connector gets them the shortest trip. So if an east-sider is headed west, they will take the West connector, even if their starting/ending point location would likely access all trips via the East side. As possible, one connector per zone is ideal; where the zone centroid is placed at the center of activity for the zone and the connector is given access to the most common access point for the activity (with a spur connection if possible/reasonable).
In cases where multiple connectors is the best course of action (splitting zones is not practical), it's important to consider the length (travel time) of each connector. Given that the single centroid is really representing multiple centers of activity, each connector length should be consider for how much time (by mode) is needed to access the average zonal activity from the given access point. In large zones especially, using the shape length of the connector is almost never advisable. At the time of capturing these instructions, Portland Metro proposed the following approach for auto connector lengths:
- Intrazonal distances = 0.024 * sqrt (acres) with a maximum cap of 0.75
- Connector lengths = Intrazonal distance * 0.6
Areas in the region that could potentially undergo development in the future should be identified and the analyst should consider separate TAZs even if the exact development boundaries are fully known in the current year.
MAZ is the smallest spatial unit of analysis in the ABM and is intended to model relatively short distance travel (i.e., walk and walk to/from transit). MAZs are generated by performing GIS operations on the Census Block and TAZ layers; explained further below. Most of the rules that applied for TAZ boundaries can also be used for MAZ boundaries. The following general guidelines should be kept in mind when creating MAZs
- MAZs should nest within TAZs and they should be coded with the ID of the TAZ it nests in (this coding can be achieved programmatically).
- As noted earlier, MAZs are used to characterize walk access – hence in areas where there is a significant amount of walk travel (dense developments such as CBD) MAZs should be small enough to walk across.
- As with TAZ, MAZs should contain homogenous land-use. For example, if one zone has two distinct areas, one with housing and one with employment, each distinct area should be a separate MAZ.
- MAZs of small irregular shapes should be reviewed and the possibility of merging it with adjacent MAZs should be explored.
- MAZs that only encompass a roadway element (e.g., a rectangular-shaped MAZ that covers a freeway and no open space, buildings, or households) should be combined with neighboring MAZs.
- MAZs should recognize physical boundaries. Ideally, if a TAZ is delineated properly there will not be any conflicts of MAZ boundaries with barriers and major facilities. But for a MAZ, care should be taken so as not to cut across streets, unless the street experiences very low volumes or it is an alley. If MAZs encompass land on either side of a higher-level street, they should be split.
- For areas in which development is anticipated, a relatively large MAZ that is generated from the procedure should be separated into smaller MAZs.
- MAZ centroids should be the center of activity for people, i.e. where people entering the zone want to go. Centroids generated based on geographic center should be reviewed to ensure this. Centroid connectors for MAZs connect to the all-streets navigation network and are generated on the fly.
- Another criteria for coding MAZs is that they should be small if there is a high density of TAPs, since we want to reflect the choice/walking time between MAZs and TAPs and if the MAZs are too big they won’t increase the accuracy of the walk times in the model.
This section describes the process of using census data to help create and define MAZ boundaries, which can have advantages since most the base year population data will be most readily available from census. This process of creation of MAZ is a partially automated and a partially manual process. For creating a MAZ layer, the Census Block layer and the TAZ layer for the region are required.
-
The Census block layer needs to be reviewed for small and irregular polygons. These should either be dissolved into adjacent blocks or when necessary the boundaries should be edited.
-
Clip the edited block layer by the TAZ layer.
-
Calculate “sliverness” and “roundness” (add two fields if it’s first time):
- SLIVERNESS= [Shape_Area]/[Shape_Length]
- ROUNDNESS= ([Shape_Area]x4x3.14)/([Shape_Length]^2)
-
Identify the sliver polygons. The thresholds (S and R) for identifying the sliver polygons should be arrived at based on experimentation by the analyst (an example set of thresholds is shown in Thresholds Used for Creating MAZ System for MORPC for the Mid-Ohio Regional Planning Commission (MORPC) model). For each pass of elimination the analyst should judge if the selection rule identifies sliver polygon to a reasonable degree.
- SLIVERNESS<=S AND ROUNDNESS <=R
| Iteration | S | R |
|---|---|---|
| 1 | <=30 feet | - |
| 2 | <=30 feet | - |
| 3 | <=120 feet | 0.9-1.1 |
| 4 | <=120 feet | <=0.1 |
| 5 | <=50 feet | <=0.15 |
| 6 | <=40 feet | - |
| 7 | <60 feet | <=0.40 |
| 8 | <=42 feet | |
| 9 | <=0.07 |
-
Apply “Eliminate” tool (Data Management/Generalization) to remove the sliver polygons (eliminating polygon by “LENGTH”).
-
Intersect the resulted polygon in Step 5 with the TAZ layer to generate the preliminary MAZ layer
-
Calculate “sliverness” and “roundness” for the preliminary MAZ layer polygons:
- SLIVERNESS= [Shape_Area]/[Shape_Length]
- ROUNDNESS= ([Shape_Area]43.14)/([Shape_Length]^2)
-
Eliminate slivers TAZ by TAZ based on a selection criteria. (this can be automated using a script)
-
Determine how many slivers remain after Step 8 and repeat Step 8 if necessary.
The automated process just described should be accompanied by visual inspection of the resulting spatial system. The analyst should verify if the zone system makes intuitive sense and identify outliers (for example an “island zone” – a zone completely contained within another zone or zones that project into the ocean are some of the issues that were encountered in regions such as MORPC and MTC) that are missed in the cleanup process.
Please note that the approach just described assumes that the region has a finalized TAZ layer to work with. Another approach would be to start by creating a MAZ system from the Census block layer (applying steps 1, 3, 4 and 5) and then grouping MAZs to create TAZs.