--- /dev/null
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
+
+<html xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
+
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Project Overview</title>
+
+ <link rel="stylesheet" type="text/css" href="reset.css" />
+ <link rel="stylesheet" type="text/css" href="common.css" />
+</head>
+
+<body>
+
+ <h1>Project Overview</h1>
+ <p id="project_title">
+ Chlorine Transportation Optimization for the Chemical Security
+ Analysis Center
+ </p>
+
+ <h2>General Goals</h2>
+ <p>
+ The overall goal of the census-tools project is to provide the
+ applied math lab (AML) with a set of libraries and utilities
+ necessary to complete its assignment.
+ </p>
+
+ <p>
+ One of the foremost goals that must be achieved is to model the
+ average population density throughout the United States. Using
+ this data, we would like to be able to calculate the risk
+ associated with an <em>event</em> taking place somewhere in the
+ United States. This will, in general, be an accident or other
+ unexpected event that causes some damage to the surrounding
+ population and environment.
+ </p>
+
+ <p>
+ Our canonical example (for which the project was created) is that
+ of a chlorine spill. If chlorine is spilled or otherwise released
+ somewhere in the United States, we would like to be able to
+ calculate the number of people affected.
+ </p>
+
+ <h2>Specific Goals</h2>
+ <ul>
+ <li>
+ Be able to determine the average population density at any point
+ within the United States, given by GPS coordinates.
+ </li>
+
+ <li>
+ Determine the total population within a subset of the U.S. This
+ subset will be defined by a polygon or other two-dimensional
+ (possibly piecewise-defined) function.
+ </li>
+
+ <li>
+ Calculate the path that roads follow throughout the
+ U.S. Ideally, the path would be calculated in terms of GPS
+ coordinates within some <a
+ href="http://en.wikipedia.org/wiki/SRID">spatial reference
+ system</a>.
+ </li>
+ </ul>
+
+ <h2>Software Requirements</h2>
+ <p>
+ The following software is required to utilize census-tools in
+ full. It should be possible to reuse the code independently of the
+ other software, but many of the features such as database
+ integration and build system automation require third-party
+ programs.
+ </p>
+
+ <ol>
+ <li>
+ The build system utilizes <a
+ href="http://www.gnu.org/software/make/">GNU Make</a>. The
+ makefile simply automates some processes which can be run
+ manually: executing tests, downloading data, importing
+ shapefiles, etc. Other (non-GNU) versions of Make should also
+ work.
+
+ <ol>
+ <li>
+ The Make system assumes that the user has a POSIX-compatible
+ shell. The author has tested the makefiles with <a
+ href="http://en.wikipedia.org/wiki/Bash">Bash</a>, but other
+ shells such as <a
+ href="http://en.wikipedia.org/wiki/Cygwin">Cygwin</a> should
+ suffice.
+ </li>
+
+ <li>
+ <a href="http://en.wikipedia.org/wiki/Wget">wget</a> is used
+ to download the Census shapefiles.
+ </li>
+ </ol>
+ </li>
+
+ <li>
+ The underlying database management system is <a
+ href="http://www.postgresql.org/">Postgresql</a>.
+ </li>
+
+ <li>
+ The GIS capabilities are provided (to Postgresql) by <a
+ href="http://postgis.refractions.net/">PostGIS</a>.
+ </li>
+ </ol>
+
+ <h2>Census Databases</h2>
+ <p>
+ There are two Census databases (obtained as flat files) which we
+ require for our purposes. The first is <a
+ href="http://www.census.gov/Press-Release/www/2001/sumfile1.html">Summary
+ File 1</a>, which contains the block-level demographic
+ information. The second database, <a
+ href="http://www.census.gov/geo/www/tiger/">TIGER/Line</a>, gives
+ us the geometry of those block.
+ </p>
+
+ <h3>Summary File 1</h3>
+
+ <p>
+ There are a number of tables contained within the Summary File 1
+ database. We require only one of these: the geographic header
+ records. The Summary File 1 geographic header records provide,
+ among other things, the following:
+ </p>
+
+ <ul>
+ <li>The GPS coordinates of each block's centroid.</li>
+ <li>The total population contained within a block.</li>
+ <li>The total land/water area of each block.</li>
+ <li>
+ Block/state/county/tract identifiers which combine to form a
+ unique identifier.
+ </li>
+ </ul>
+
+
+ <h3>TIGER/Line</h3>
+
+ <p>
+ The TIGER/Line information comes in the form of <a
+ href="http://en.wikipedia.org/wiki/Shapefile">ESRI
+ shapefiles</a>. These shapefiles contain the geometric information
+ about the Census blocks.
+ </p>
+
+ <p>
+ Each TIGER/Line record contains,
+ </p>
+
+ <ul>
+ <li>
+ The same block/state/county/tract information as the Summary
+ File 1 geographic header records.
+ </li>
+
+ <li>
+ A redundant field, called <em>blkidfp00</em>, which contains the
+ concatenation of block/state/county/tract. This is our unique
+ identifier.
+ </li>
+
+ <li>
+ A geometry column containing a set of points, lines, and
+ polygons that define the boundaries of the block.
+ </li>
+ </ul>
+
+
+ <h3>Summary File 1 / TIGER Integration</h3>
+
+ <p>
+ We need to correlate the TIGER/Line geometric information with the
+ demographic information contained in the Summary File 1 geographic
+ header records. To do this, we need to rely on the unique
+ <em>blkidfp00</em> identifier.
+ </p>
+
+ <p>
+ For the TIGER table, this field has already been calculated. We
+ calculate it manually for the geographic header records. Then, we
+ can define a one-to-one correspondence between geographic header
+ records and TIGER/Line records. This satisfies one of our goals:
+ correlating the two tables allows us to determine the population
+ density at any point.
+ </p>
+
+
+ <h2>Importing the Data</h2>
+
+ <p>
+ <em>
+ Note: the <a href="../../makefile">makefile</a> provides a task
+ for creation/import of the databases, but its use is strictly
+ required.
+ </em>
+ </p>
+
+
+ <h3>Creation of the Database</h3>
+
+ <p>
+ A Postgres/PostGIS database is required to store our Census
+ data. The database name is unimportant (default: <em>census</em>),
+ but several of the scripts refer to the table names. For
+ simplicity, we will call the database <em>census</em> from now on.
+ </p>
+
+ <p>
+ Once the database has been created, we need to import two PostGIS
+ tables so that we can support the GIS functionality. These two
+ files are <em>lwpostgis.sql</em> and
+ <em>spatial_ref_sys.sql</em>. See the <a
+ href="../../makefile">makefile</a> for an example of their import.
+ </p>
+
+ <p>
+ Before we import any data, we need to develop a database schema
+ that models our Census data. The TIGER/Line schema is provided for
+ us, so we have modeled the Summary File 1 schema in a similar
+ fashion.
+ </p>
+
+ <p>
+ The Summary File 1 table schema is <a
+ href="../../sql/create-sf1_blocks-table.sql">defined in a standard
+ SQL script</a>. The following steps will all require that a
+ database exist, and contain the table defined by this script.
+ </p>
+
+
+ <h3>Importing the Summary File 1 Block Records</h3>
+
+ <p>
+ The Summary File 1 data are obtained as flat files. We therefore
+ utilize a Python script, <a href="../../bin/sf1blocks2sql"></a>,
+ to parse and import the blocks. The source code to the script is
+ documented, but basically, it performs three tasks: it parses each
+ record from the geographic header record file, filters out any
+ non-block records, and then writes out a SQL statement to insert
+ that record in to the Postgres/PostGIS database.
+ </p>
+
+
+ <h3>Importing the TIGER/Line Shapefiles</h3>
+
+ <p>
+ Since the shapefiles are in a standard format, we can use
+ pre-existing tools to import the data in to our SQL
+ database. PostGIS provides a binary, <em>shp2pgsql</em>, that will
+ parse and convert the shapefiles to SQL.
+ </p>
+
+ <p>
+ There is one caveat here: the <em>shp2pgsql</em> program requires
+ an SRID as an argument; this SRID is assigned to each record it
+ imports. We have designated an SRID of 4269, which denotes
+ <q>NAD83</q>, or the North American Datum (1983). There may be
+ some possibility of improvement here; since we are only
+ considering the Mid-Atlantic, there may be coordinate systems
+ (SRIDs) which are more accurate in our subset of the United
+ States.
+ </p>
+
+</body>
+</html>
--- /dev/null
+/*
+ From http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/
+
+ Modified to use text-align: inherit.
+ Also moved the line-height: 1 rule to the body element to be inherited.
+
+ Don't forget to set a foreground and background color
+ on the 'html' or 'body' element!
+*/
+
+body {
+ line-height: 1;
+}
+html, body, div, span,
+applet, object, iframe,
+h1, h2, h3, h4, h5, h6, p, blockquote, pre,
+a, abbr, acronym, address, big, cite, code,
+del, dfn, em, font, img, ins, kbd, q, s, samp,
+small, strike, strong, sub, sup, tt, var,
+dd, dl, dt, li, ol, ul,
+fieldset, form, label, legend,
+table, caption, tbody, tfoot, thead, tr, th, td {
+ margin: 0;
+ padding: 0;
+ border: 0;
+ font-weight: normal;
+ font-style: normal;
+ font-size: 100%;
+ font-family: inherit;
+ text-align: inherit;
+ vertical-align: baseline;
+}
+table {
+ border-collapse: collapse;
+ border-spacing: 0;
+}
+ol, ul {
+ list-style: none;
+}
+q:before, q:after,
+blockquote:before, blockquote:after {
+ content: "";
+}
+blockquote, q {
+ quotes: "" "";
+}