回答:
わかりましたベン、ここに私の仮定がある：
1）既にデータを取得しています（シェープファイルにいくつかのアドレスポイントがあり、ミズーリ州の国勢調査地区と国勢調査ブロックシェープファイルをダウンロードしました）。
2）住所ポイントのジオコーディングはすでに完了しており、データを簡単に投影できます。
3）OGR / PostGISソリューション（両方とも無料）に満足している。
これらのソフトウェアがない場合のインストールノートを次に示します。PostGISをサポートするPostGREをインストールする方法。（BostonGISでは。私はちょうどそれが最高のハウツーそこだと思う、そのタイトルに犯罪を取ることはありませんしてください。）また、ここでの1、2、および3つのPythonバインディングでGDAL / OGRをインストールする方法を説明するサイト。
警告：実際の分析（つまりST_Contains、以下のもの）を実行する前に、すべてのレイヤーが同じ投影になっていることを確認する必要があります。シェープファイルがある場合、 Quantum GIS（QGIS）またはOGR（またはArcGISがある場合はArcGIS）を使用して、ある投影から別の投影に簡単に変換できます。または、PostGIS関数を使用してデータベースで投影変換を実行できます。基本的にあなたの毒を選ぶか、これがつまずきかどうか教えてください。
これらの指定により、PostGISを使用して一部の住所ポイントデータに地域とブロックの属性を追加しました。
最初にogr2ogr、3つのシェープファイルをPostGISにインポートしました。
ogr2ogrを使用して住所をインポートします。
ogr2ogr -f "PostGreSQL" PG:"host=127.0.0.1 user=youruser dbname=yourdb password=yourpass" "E:\path_to\addresses.shp" -nln mcdon_addresses -nlt geometry
ogr2ogrを使用してインポート国勢調査（ミズーリ州）：spMoWest接尾辞は、私はすでにミズーリ州平面西の足に自分のデータを翻訳した意味。
ogr2ogr -f "PostGreSQL" PG:"host=127.0.0.1 user=youruser dbname=yourdb password=yourpass" "E:\path_to\st_tract10_spMoWest.shp" -nln mo_tracts_2010 -nlt geometry
ブロックデータのインポート（ミズーリ州）： これにはしばらく時間がかかりました。実際、私のコンピューターはクラッシュし続け、私はその上にファンを置かなければなりませんでした！ああ、また、ogr2ogrフィードバックをしませんので、パンチをしないでください。必ず待ってください。そうすれば最終的に終了します。
ogr2ogr -f "PostGreSQL" PG:"host=127.0.0.1 user=youruser dbname=yourdb password=yourpass" "E:\path_to\st_block10_spMoWest.shp" -nln mo_blocks_2010 -nlt geometry
データのインポートが完了したら、PgAdmin III（PostGREs GUI）を起動し、データベースを参照して、これらの新しいデータを使用してPostGREsqlがより速く実行されるようにいくつかのクイックメンテナンスコマンドをスローします。
vacuum mcdon_addresses;
vacuum mo_tracts_2010;
vacuum mo_blocks_2010;
次に、インポートした生のアドレスポイントの数に興味があったので、簡単に実行しましたCOUNT(*)。通常、このようなタスクの開始時にカウントを行い、後で「健全性チェック」の足がかりを与えます。
SELECT COUNT(*) FROM mcdon_addresses;
-- 11979
次のフェーズでは、2つの新しいテーブルを作成し、路線属性を徐々に追加してから、ブロック属性を元のアドレスポイントテーブルに追加しました。ご覧のように、PostGIS ST_Contains関数は、それぞれのケースでポイントの新しいテーブルを作成し、それぞれが内部に落ちたポリゴンのブロックとブロックの属性を取得するという重い作業を行いました。
注意！簡潔にするために、各テーブルからいくつかのフィールドのみを取得しています。ほとんどすべてのものが必要になるでしょう。私が言うほとんどあなたが省略する必要がありますのでので、ogr_fidあなたが結合しているテーブルからフィールド（多分他の人を？）、それ以外の場合はPostgresは同じ名前を持つ両方のフィールドに文句を言うでしょう。..
（PS私はこれを理解しながら、ここでいくつかのスヌーピングを行いました：http : //postgis.net/docs/manual-1.4/ch04.html）
トラクト属性を使用して住所ポイントの新しいテーブルを作成します。 注：各出力列の先頭に、どのテーブルで開始したかを示すヒントを付けています（以下で理由を説明します）。
CREATE TABLE mcdon_addresses_wtract AS
SELECT
a.wkb_geometry,
a.route AS addr_route,
a.box AS addr_box,
a.new_add AS addr_new_add,
a.prefix AS addr_prefix,
a.rdname AS addr_rdname,
a.road_name AS addr_road_name,
a.city AS addr_city,
a.state AS addr_state,
a.zip AS addr_zip,
t.statefp10 AS tr_statefp10,
t.countyfp10 AS tr_countyfp10,
t.tractce10 AS tr_tractce10,
t.name10 AS tr_name10,
t.pop90 AS tr_pop90,
t.white90 AS tr_white90,
t.black90 AS tr_black90,
t.asian90 AS tr_asian90,
t.amind90 AS tr_amind90,
t.other90 AS tr_other90,
t.hisp90 AS tr_hisp90
FROM
mcdon_addresses AS a,
mo_tracts_2010 AS t
WHERE
ST_Contains(t.wkb_geometry, a.wkb_geometry);
PostGREがスムーズに実行し続けるようにテーブルを維持します。
vacuum mcdon_addresses_wtract;
今、2つの質問がありました。
ST_Containsは実際に機能しましたか？..and .. 使用したデータ入力を考えると、返されるアドレスの数は意味がありますか？
同じクエリを使用して両方に答えることができました：
select count(*) from mcdon_addresses_wtract;
-- returns 11848
損失に関する簡単な考察：最初に、ArcGISでチェックし（QGISでこれを行うこともできます）、同じカウントを返しました。では、なぜ違いがあるのでしょうか？まず、いくつかの住所はミズーリ州の外にあり、私はミズーリ州のポリゴンとのみ比較しました。第二に、綿密な分析で、住所データに不適切なデジタル化の例がいくつかあったようです。具体的には、捕捉されなかったポイントの多くにST_Containsは空の属性フィールドがありました。これは、デジタル化中に何かがファウルになった良い兆候です。また、それらは使用可能なデータではなかったことを意味します。この時点で、合理的に戻ってデータを改善し、より明確な分析を行えるようになったため、違いに満足しています。
次に進むと、次のステップでは、住所/道路テーブルにブロックデータの属性を追加しました。同様に、新しいテーブルを作成して、各出力フィールドにプレフィックスを付けて、元のテーブルを示します（プレフィックスは非常に重要です）。
CREATE TABLE mcdon_addr_trct_and_blk AS
SELECT
a.*,
b.pop90 AS blk_pop90,
b.white90 AS blk_white90,
b.black90 AS blk_black90,
b.asian90 AS blk_asian90,
b.amind90 AS blk_amind90,
b.other90 AS blk_other90,
b.hisp90 AS blk_hisp90
FROM
mcdon_addresses_wtract AS a,
mo_blocks_2010 AS b
WHERE
ST_Contains(b.wkb_geometry, a.wkb_geometry);
もちろん、テーブルを維持します。
vacuum mcdon_addr_trct_and_blk;
各出力フィールドに接頭辞を付けた理由は、そうしなかった場合、一部のフィールドが同じ名前になり、最終製品で互いに区別することができなくなるためです（また、PostGREがこれに途中で不満を言っているかもしれません。名前を変更していたので、チャンスを与えませんでした）。たとえば、上記の両方のステップからの次の2つのフィールドを考えます。名前を変更した理由がわかります。
t.pop90 AS tr_pop90 -- would have been simply pop90
b.pop90 AS blk_pop90 -- also would have been pop90 !
トラクトとブロックのデータセットを持つ住所ができたので、まだ同じ数のポイントがありますか？
select count(*) from mcdon_addr_trct_and_blk;
-- 11848 (thumbs up!)
はい、そうです！必要に応じて、作成した最初のテーブルを削除できますmcdon_addresses_wtract。分析にはもう必要ありません。
最後のアクションとして、あなたはありますが、ArcGISのような他のプログラム、（ノートの、QGISは問題なくPostGISのデータを読み取ることができます）でそれを見ることができるようにESRIシェープファイルへのPostgresからデータをエクスポートします。興味がある場合は、ogr2ogrを使用して変換を実行できます。
ogr2ogr -f "ESRI Shapefile" "E:\path_to\addr_trct_blk.shp" PG:"host=127.0.0.1 user=youruser dbname=yourdb password=yourpass" "mcdon_addr_trct_and_blk"
最後に、このコマンドを実行すると、次のような警告が表示される可能性があります。
警告6：正規化/洗濯されたフィールド名： 'tr_statefp10'から 'tr_statefp'
これは、シェープファイル内のフィールド名が非常に長くなる可能性があるため、OGRがそのフィールド名を短くしなければならなかったことを意味します。
もちろん、これはこの仕事を達成する多くの方法の1つにすぎません。
FCCにはAPIがあります：http : //www.fcc.gov/developer/census-block-conversions-api