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@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
>>> "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.com
www.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@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/
**************************************************************
To: Elaine or Nanda or Ed
cc: CTPP-News
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/
**************************************************************
Subject: Census News Brief #12
From: Terriann2K(a)aol.com
September 15, 2003
Senate Appropriators Mum on Reason For Cuts in Census Funding
The committee report (S. Rept. 108-144) accompanying the Senate Fiscal
Year 2004 funding bill for the Census Bureau reveals additional detail
on how proposed budget cuts would be distributed among agency programs,
but sheds no light on why appropriators failed to meet the
Administrations funding request. The report also leaves it up to the
Census Bureau to decide how to apply a $45 million reduction in the
request for 2010 census planning.
The Senate Fiscal Year 2004 Commerce, Justice, and State, The Judiciary
and Related Agencies Appropriations bill (S.1585) allocates $550.878
million for the Census Bureau, $111.083 million less than President Bush
requested. Roughly $72 million of the funding cut would affect the
Periodic Censuses and Programs account, which includes the decennial
census. More than half of that amount -- $45 million would come out
of 2010 census planning. An anticipated carry-over of $12.2 million
from the current fiscal year would offset part of the cut in Periodics
funding. The Bureaus Salaries and Expenses account, which covers
ongoing statistical programs, received $181.8 million, $39.1 million
below the Presidents request.
The appropriations panel proposed $215.5 million for 2010 census
activities. The Administration requested $260.2 million for the three
main components of its 2010 planning strategy. Significant activities
planned for next year include launching the American Community Survey
nationwide in July 2004; census field tests in portions of Queens, New
York, and two rural counties in Georgia; an overseas enumeration test in
Kuwait, Mexico, and France; and continued updating of the TIGER map
database, with a goal of fixing misaligned features in an additional 600
counties. The committee report does not specify which 2010 activities
the proposed lower funding level might affect.
Most of the remaining funding cut would affect the quinquennial (thats
every five years, folks!) Economic Census, which is taken in the years
ending in 2 and 7. Activities planned for FY04 include continued
tabulation and publication of data collected from businesses in early
2003. S. 1585 allocates $61.3 million for the Economic Census, compared
to the full funding request of $73.8 million contained in the House bill
(H.R. 2799).
The full Senate must consider the bill before the measure is sent to a
House-Senate conference committee to work out differences between the
two versions of the funding bill. Traditionally, all members of the
House and Senate Appropriations Commerce, Justice, State and The
Judiciary Subcommittees are appointed to the conference committee. (See
the April 7, 2003, Census News Brief for information on appropriations
and authorizing committee members.) Speaking late last week at a
meeting of the National Research Councils Panel on Research on Future
Census Methods, Census Bureau Director C. Louis Kincannon said he
expects conferees to partially, but not fully, restore the money cut
from the Administrations funding request by Senate appropriators.
Census News Briefs are prepared by Terri Ann Lowenthal, an independent
consultant in Washington, DC. Please direct questions about the
information in this News Brief to Ms. Lowenthal at 202/484-3067 or by
e-mail at terriann2k(a)aol.com. Thank you to the Communications Consortium
Media Center for posting the News Briefs on the Census 2000 Initiative
web site, at http://www.census2000.org. Please feel free to circulate
this information to colleagues and other interested individuals.
--
Ed Christopher
Planning Activities
Resource Center
Federal Highway Administration
19900 Governors Drive
Olympia Fields, Illinois 60461
708-283-3534 (V) 708-574-8131 (cell)
708-283-3501 (F)
Yesterday, the ctpp-news listserv was hit by the SoBig virus. Basically
this virus works by sending itself to everybody in the infected
machine's Outlook address book. It also confuses where the virus came
from by masquerading as somebody else in the same Outlook address book.
The ctpp-news listserv is somewhat immune to this virus because the only
people who can post to the listserv are people who subscribe. So a SoBig
virus email that says it comes from billg(a)microsoft.com wouldn't go to
the list because billg(a)microsoft.com isn't a subscriber to ctpp-news.
Unfortunately, if the virus tries enough random email addresses from
somebody who subscribes to the ctpp-news listserv, it will eventually
hit the combination of email address that will allow it to post to the
listserv which in this case is sending from somebody who subscribes to
ctpp-news and to ctpp-news(a)chrispy.net.
Also unfortunately, it seems that more people who subscribe to the list
have been hit by the virus because I stopped a few more virus emails
from getting distributed to the bulk of the list. To protect the list, I
took the step of preventing emails to the ctpp-news listserv from
posting without my direct approval. So there will be delays to post to
the list until I read my email and approve incoming email.
I am working on a long term solution that will strip "bad attachments"
to email before they get distributed to the list but I don't have a
timeframe when it could be completed.
Thank you for your patience and understanding.
Chris Parrinello
