[CTPP] First Impressions of TAZ-UP

TO: CTPP News mailing list & MPO staffs FR: Chuck Purvis, MTC We received our copy of TIGER'98 and the TAZ-UP software on April 7th. I already had ArcView 3.1 installed on my 233 MHz PC, actually on a 1 gigabyte jaz cartridge. ArcView takes up 83 MB of space; TAZ-UP an additional 61 MB. So far, so good. Installing county TIGER files into TAZ-UP can be *very* slow for large urban counties. I started installing Alameda County (CA) on Friday, April 9 at 4:00 PM. It took 60 minutes to install! My largest county, Santa Clara County, took 90 minutes to install files of 40.2 megabytes in size. My entire region (9 counties) takes 205 MB in space. The "log" records that are written as part of this installation process note that I have 104,600 polygons (this number of polygons is the number of records that should be exported from TAZ-UP once all of my edits are complete). RECOMMENDATION: Use the fastest PC you can afford. I believe the documentation recommends at least a 200 MHz machine, but I would highly recommend something like a 450 MHz PC. And I think that a gigabyte of free disk space should be adequate for most regions. After installing these county files, my first step was to "validate" the existing boundaries: "invalid boundaries"; "contiguity errors"; and "completeness errors". This is where I initially started to freak out: we have 2,445 invalid boundaries in our region; 106 contiguity problems; and 1 completeness problem. The contiguity and completeness errors are manageable; the invalid boundary errors were highly unexpected (and may be unmanageable?) Many of my invalid boundary errors are "F84" errors which are basically old 1990 block boundaries (be they tract boundaries or block group boundaries) that are flagged by the Census Bureau as invalid because they aren't associated with any physical feature (e.g., roads, streams, power lines). My spot check of my invalid boundary errors suggest that 90 percent of mine are "F84" errors. I even got "F84" errors in a county (Napa County) where I was strictly using 1990 Census block groups as my 1990 TAZes! My desire is that my Year 2000 TAZ boundaries are nested on Year 2000 Census Tracts. I essentially want to create what I would call "user-defined block groups." The big issue is "what are my year 2000 Census Tract boundaries?" This is where you (MPOs working on this project) will need to contact your regional office census geographer to check up on the status of your Year 2000 Tract Boundaries. I may be wrong in my interpretation of this, but Year 2000 Tract boundaries will be valid CTPP TAZ boundaries. I had numerous phone conversations this past Friday with our USDOT and Census folk back in DC, and they've expressed concerns about our plight regarding these invalid boundary issues. I'm still fuzzy on this, so I'm hoping that the Bureau and USDOT folks can clear up these issues before we all get too hot under the collar with all of these invalid boundary issues. (USDOT is also very concerned because all of the TIGER files for the entire US aren't out yet :-( The "contiguity errors" are very manageable. Some of these contiguity errors are due to correspondence errors that are our fault, leading to some really unintended results. The rest of these errors are due to a misallocation of "water blocks" that separate real, physical islands. An example in my region is Alcatraz Island and Treasure Island in the middle of San Francisco Bay. They're part of the same TAZ, but were separated by a "water block" that includes much of the Bay, plus Fishermans' Wharf and Pier 39. So, a simple solution is to include the Fishermans' Wharf "water block" with Alcatraz Island, as one TAZ, and have Treasure Island as its own TAZ. My point is that I believe that all of the contiguity errors in your TAZ boundary files can (and probably should) be eliminated. Be sure to have "water blocks" connect your sandbars and physical islands to your "mainland" blocks. In terms of the TAZ-UP software, I have no problems. It works as advertised, though it's all (ArcView/TAZ-UP) very slow with large urban counties on a 233 MHz PC. I wish there were "multiple un-dos" since I tend to make mistakes in batches, but I'll learn to make only one mistake at a time. Well, those are my first impressions on TAZ-UP and this TAZ definition program. Just take it easy and don't freak out (too much) when all your invalid boundaries start to pile up! Cheers, Chuck Purvis, MTC - Oakland/San Francisco/San Jose metro region. ******************************************************* e-mail: cpurvis(a)mtc.ca.gov Chuck Purvis, AICP Senior Transportation Planner/Analyst, Planning Section Metropolitan Transportation Commission 101 Eighth Street, Oakland, CA 94607-4700 (510) 464-7731 (voice) (510) 464-7848 (fax) WWW: http://www.mtc.ca.gov/ MTC DataMart & InfoMart: http://www.mtc.ca.gov/facts_and_figures/datamart.htm MTC FTP Site: ftp://ftp.abag.ca.gov/pub/mtc/planning/ Personal WWW: http://home.earthlink.net/~clpurvis/ *******************************************************