I am looking to find workers by place of residence from the 1980 Census for several cities and counties in Virginia. The data would be compared to the workers from the 1990 and 2000 CTPP's, so it should be from the 1980 CTPP or comparable source. I looked at the Census web site and could not find this data. Any help is appreciated. Thanks!
Andrew Pickard, P.E.
Senior Transportation Engineer
Hampton Roads Planning District Commission
723 Woodlake Drive
Chesapeake, VA 23320
Phone: (757) 420-8300 Fax: (757) 523-4881
E-mail: apickard(a)hrpdc.org
Web: www.hrpdc.org
Brian,
In the Part 1 data for Oregon and California, we are aware that Mean, Median, and Standard Deviation tables for travel time to work were calculated incorrectly, as mentioned by you. Census Bureau fixed the error before they mailed out the CDs for all other states.
Census Bureau also sent an errata sheet go out with all the Part 1 packages - the errata sheets show some of the errors that were observed by us in the LAST minute. For Oregon, and California, the mean travel time tables will be re-done for the final version. Most of the other issues mentioned on the errata sheet are related to the CTPP Access Tool software, and those errors will be fixed too.
Nanda Srinivasan
-----Original Message-----
From: Brian.J.GREGOR(a)odot.state.or.us
[mailto:Brian.J.GREGOR(a)odot.state.or.us]
Sent: Monday, September 29, 2003 4:53 PM
To: ctpp-news(a)chrispy.net
Subject: [CTPP] CTPP Mean Travel Time Calculations
Please excuse me if this observation has already been posted to the list.
The mean travel times to work by county (for Oregon) reported on the CTPP
disk are less than the times reported on the Census Bureau web site
(QuickFacts). The CTPP numbers can be reproduced by dividing aggregate
travel times reported in the CTPP by all workers reported in the CTPP. The
Quick Facts numbers can also be reproduced using the CTPP data using the
numbers of workers who do not work at home. This has been the standard
approach to calculating mean travel times (including the 1990 CTPP).
Was it intentional for the 2000 CTPP to use all workers in the calculation?
If so, users should be made aware that the 2000 CTPP mean travel time
numbers are not comparable to the 1990 CTPP mean travel time numbers.
Brian Gregor, P.E.
Transportation Planning Analysis Unit
Oregon Department of Transportation
Brian.J.GREGOR(a)odot.state.or.us
(503) 986-4120
TO: CTPP-News
1. I'm forwarding an excellent story by a Pittsburgh journalist analyzing the residential mobility patterns of young residents in the Pittsburgh region, and other major regions in the country, using the 1-percent PUMS data. I'm forwarding Mr. Houser's e-mail from the Investigative Reporters & Editors Census listserv.
2. Note that ALL DATA for the 5-percent PUMS data has been released, as of last Wednesday, 9/24/03. The data is available from this link:http://www.census.gov/Press-Release/www/2003/PUMS5.html
3. The following is another PUMS-related e-mail from the State Data Center listserv, from Marc Thomas of NIPC. The link to the State Data Center Annual 2003 meeting has some interesting powerpoint presentations, one of which deals with Beyond 20/20 and PUMS.
Marc's message:
Having gone to the PUMS CD-ROM training at the annual conference, I feel
that a lot of ground was hurriedly covered in the hour we had available.
If Bill Savino could put together some additional screen shots on building
a PUMS table that could be appended to his PowerPoint slideshow on
http://www.census.gov/sdc/www/natmtg03.html it would be much appreciated.
***********************************************************************************************************************************
Please excuse me if this observation has already been posted to the list.
The mean travel times to work by county (for Oregon) reported on the CTPP
disk are less than the times reported on the Census Bureau web site
(QuickFacts). The CTPP numbers can be reproduced by dividing aggregate
travel times reported in the CTPP by all workers reported in the CTPP. The
Quick Facts numbers can also be reproduced using the CTPP data using the
numbers of workers who do not work at home. This has been the standard
approach to calculating mean travel times (including the 1990 CTPP).
Was it intentional for the 2000 CTPP to use all workers in the calculation?
If so, users should be made aware that the 2000 CTPP mean travel time
numbers are not comparable to the 1990 CTPP mean travel time numbers.
Brian Gregor, P.E.
Transportation Planning Analysis Unit
Oregon Department of Transportation
Brian.J.GREGOR(a)odot.state.or.us
(503) 986-4120
Please remove my name from this email list.
>>> <Steven.Bowman(a)DOT.STATE.IA.US> 9/26/03 7:26:57 AM >>>
Please add JAY.Larson(a)dot.state.ia.us to the CTPP-news listserve
Thanks
Steven Bowman
Iowa Dept. of Transportation
800 Lincoln Way
Ames, Iowa 50010
Ph.515.239.1337
Please add JAY.Larson(a)dot.state.ia.us to the CTPP-news listserve
Thanks
Steven Bowman
Iowa Dept. of Transportation
800 Lincoln Way
Ames, Iowa 50010
Ph.515.239.1337
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
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(a)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.comwww.MadisonAreaMPO.org
>>> "Cindy L. Pellett" <cpellett(a)emdc.org> 09/25/03 01:43PM >>>
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
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.comwww.MadisonAreaMPO.org
>>> "Cindy L. Pellett" <cpellett(a)emdc.org> 09/25/03 01:43PM >>>
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
The CTPP guidebook CDs were mailed to all State DOTs and MPOs and FHWA Division Office planners approximately September 15. The CTPP Guidebook includes an introduction to Census data, including how the decennial census is conducted, introduction to CTPP 2000 including all the tables, the variable categories, and issues such as confidentiality, rounding, thresholds, etc. Finally, several case studies show how the census data can be used in transportation planning applications. We hope you find the material informative and enjoy it!
Responses to Chuck's questions.
1. Yes, there is an audio track that should function with the most basic of sound card and speakers. There is not audio for each screen shot, it is intermittent, except the "expert panel" discussion in Case Study 4.
2. Until we run out of copies, you can request additional copies of the CD by sending an email to : ctpp(a)fhwa.dot.gov or to Nanda directly, at: nanda.srinivasan(a)fhwa.dot.gov
Please be sure to include a complete mailing address. PLEASE limit your request to less than 50 copies. (If you have a problem with that, you are going to have to talk to me instead of Nanda!)
There are no copying restrictions, so YOU can make as many copies as you like!
Elaine Murakami
FHWA Office of Planning
206-220-4460 in Seattle (most of the time)
202-366-6971 in Wash DC (some of the time)
elaine.murakami(a)fhwa.dot.gov
-----Original Message-----
From: Chuck Purvis [mailto:CPurvis(a)mtc.ca.gov]
I received my copy of the FINAL "CTPP Guidebook" CD in yesterday's mail. Thanks! We will make copies for our internal use.
Question #1: Is there an "audio track" on the CD that requires a sound card and speakers, or is this a "silent movie"?
Question #2: Are you planning to have a "web form" for ordering extra copies of the CTPP Guidebook CD, or do you want everyone to call (or e-mail) Nanda, or do you want *us* to make copies for everybody in our region?
Thanks in advance!
Chuck
**************************************************************
Charles L. Purvis, AICP
Principal Transportation Planner/Analyst
Metropolitan Transportation Commission
101 Eighth Street
Oakland, CA 94607-4700
(510) 464-7731 (office)
(510) 464-7848 (fax)
www: http://www.mtc.ca.gov/
Census WWW: http://www.bayareacensus.ca.gov/
**************************************************************
