I haven't tried this method yet, but I plan to grid both 1990 and 2000 block population in Workstation ArcInfo and calculate a new grid equal to [2000 block population grid - 1990 block population grid] *100 /1990 block population grid. The result should be a new grid that is neither 2000 blocks nor 1990 blocks but rather a population change grid. You could do this with Spatial Analyst in ArcView too. If someone were to ask me how the population change relates to 2000 block geography, I would just overlay the 2000 block boundaries over my population change grid. -----Original Message----- From: Dan Seidensticker [mailto:dseidensticker@ci.madison.wi.us] Sent: Thursday, September 25, 2003 3:35 PM To: ctpp-news(a)chrispy.net; cpellett(a)emdc.org Subject: Re: [CTPP] Re-designating urban growth boundary. Cindy, I've done something similar when transferring 1990 TAZs to the 2000 Census Block geography. I used ArcInfo Workstation to accomplish this, but maybe you can find a way to use the same methodology in ArcView 8.3. TRANSFER_FROM poly coverage = 1990 Census Blocks TRANSFER_TO poly coverage = 2000 Census Blocks NEW_TRANSFER point coverage = 2000 Census Block Centroids with 1990 Census Block ids. Make sure TRANSFER_TO has unique label-ids. Use CENTROIDLABELS to move all label points to center of respective polygons in TRANSFER_TO. Convert TRANSFER_TO polys to a point coverage by dropping all other geometry using DROPFEATURES and then BUILD as POINT. Use IDENTITY on TRANSFER_TO point coverage with TRANSFER_FROM as the polygon overlay coverage to create a point coverage NEW_TRANSFER. Each point in the NEW_TRANSFER point coverage now has a unique 2000 Block-id along with another field that is the 1990 Census Block id. This is essentially a geographic equivalency table. Each record is a 2000 Census block with it's 1990 Census block equivalent. Finally you can relate (or join) the NEW_TRANSFER point table to the TRANSFER_TO coverage (2000 Census Blocks) using the 2000 Block id as the relate item. If you were to color the 2000 Census Blocks using the 1990 Census id field, you should get a map similar to the original 1990 Census Block Map. If all the 2000 blocks were truly nested inside a 1990 block this would work perfectly, but unfortunately that's not the case (new streets, etc). Depending how different the geography of the two poly coverages are, you may have to do a little manual clean up to be sure the label centroid of the TRANSFER_TO coverage fell into the correct TRANSFER_FROM polygon. It's kind of hard to describe this without drawing some sketches also, but maybe it will get you in the right direction. ---------------------- Trivia Question: Who is often considered the father of GIS? 1. Michael Goodchild 2. Jack Dangermond 3. Bill Gates 4. Roger Tomlinson Dan Seidensticker GIS Specialist Madison Area Metropolitan Planning Organization, City of Madison Planning Unit 121 S. Pinckney Street, Suite 400 Madison, WI 53703 Voice: 608-266-9119 Fax: 608-261-9967 Email: dseidensticker(a)cityofmadison.com www.MadisonAreaMPO.org We are currently using a GIS (ArcView 8.3) to assist in re-designating our urban growth boundary and want to use the 1990 and 2000 Census blocks to determine population change (so that we can predict where future growth is going to occur). Using the Census 2000 block relationship files, we can examine how the blocks from the two censuses compare (i.e. one-to-one, one-to-many, etc.). However, in order to do a direct comparison between the 1990 and the 2000 blocks, we need to have a comparable geometry between the two datasets. For example, if you have a one-to-many relationship within a particular block unit, the "many" 2000 blocks need to be aggregated to match the "one" 1990 block and visa versa with the many-to-one relationship. In a sense, a "cluster" database will be created which will include all the one-to-one blocks and also all the aggregated blocks. I have done various intersects and dissolves within ArcView, but have not been able to create a database that globally aggregates the smaller units into the larger units successfully. If any GIS'ers can offer some advice, it would be greatly appreciated. Also, have any MPO GIS'ers analyzed block level population changes around their boundaries to forecast which fringe areas will likely fall into their MPOs in 2010? Cindy Pellett Bangor, ME