Chapter 12. PostGIS追加機能
Prev     Next

Chapter 12. PostGIS追加機能

Table of Contents

本章では、PostGISのソースアーカイブとソースレポジトリのextrasフォルダにある機能を記述します。 これらは必ずPostGISバイナリ版に同梱されているものではありませんが、通常は実行可能なplpgsqlベースのものまたは標準的なシェルスクリプトです。

12.1. 住所標準化

これは、PAGC standardizerから分かれたものです (オリジナルのコードはPAGC PostgreSQL Address Standardizerにあります)。

住所標準化は単一行の住所のパーサで、入力に住所を取り、テーブルに保存された規則と、補助テーブルlex (lexicon, 語彙)およびgaz (gazetteer, 地名集)とを基に正規化します。

コードは、address_standardizerという名前の、一つのPostgreSQLエクステンションとしてビルドされます。CREATE EXTENSION address_standardizer;でインストールできます。address_standardizerエクステンションとともに、address_standardizer_data_usというサンプルデータのエクステンションがビルドされます。これには、アメリカのgaz, lexとrulesテーブルデータがあります。このエクステンションはCREATE EXTENSION address_standardizer_data_us;でインストールできます。

このエクステンションのコードはPostGISのextensions/address_standardizer内にあり、現在は自己充足しています。

インストール手順については、Section 2.3, “PAGC住所標準化ツールのインストールと使用”を参照してください。

12.1.1. パーサの動作

パーサは右から左に見ます。最初に郵便番号、州/県、市のMACRO (訳注: マクロ)要素を見ます。その後、番地または交差点もしくはランドマークを扱う場合には、MICRO (訳注: マイクロ)要素を見ます。現在は、国別コードや国名を見ませんが、将来的には導入できると思います。

国別コード

USまたはCAを仮定します。郵便番号か州/県で米国かカナダを分けますが、判別できない場合は米国とします。

郵便番号

Perl互換の正規表現を使用して認識します。正規表現は現在はparseaddress-api.cにあり、必要な際の変更は比較的簡単です。

州/県

Perl互換の正規表現を使用して認識します。正規表現は現在はparseaddress-api.cにありますが、将来的には、メンテナンスを簡単にするためにインクルードファイルに移動するかも知れません。

12.1.2. 住所標準化の型

Abstract

本節では住所標準化でインストールされたPostgreSQLデータ型の一覧を挙げます。独自関数をデザインする時に特に重要となるキャストの振る舞いを記述しています。

  • stdaddr — 住所の要素からなる複合型です。standardize_address関数が返す型です。

12.1.3. 住所標準化テーブル

Abstract

本節では、住所標準化が住所の正規化に使うPostgreSQLテーブルの書式を挙げます。これらのテーブルはここで参照している名前と同じである必要はありません。例または独自ジオコーダのために、国ごとに異なるlex (lexicon, 語彙)、gaz (gazetteer, 地名集)およびrulesテーブルを持つことができます。これらのテーブルの名前は、住所標準化関数に渡されます。

同梱されているaddress_standardizer_data_usエクステンションには、米国の住所標準化のためのデータがあります。

  • rules table — 規則テーブルには、住所入力順列トークンから標準化した出力順列への対応付けに関する規則の集合が入ります。それぞれの規則は、入力トークン、-1 (終端)、出力トークン、-1、規則の種類を示す数字、規則の階級、からなります。
  • lex table — lexテーブルは英数字の入力をクラス分けして (a) 入力トークン (the section called “入力トークン” 参照)と (b) 標準化表現 とに関連付けます。
  • gaz table — gazテーブルは、地名を標準化し、入力と、(a)入力トークン (the section called “入力トークン”を参照して下さい)および (b) 標準化された表現とを関連付けるために使われます。

12.1.4. 住所標準化関数

  • debug_standardize_address — パースしたトークンと標準化のリストをJSON形式の文字列で返します
  • parse_address — 1行の住所を取り、分割します。
  • standardize_address — lexテーブル、gazテーブルおよび規則テーブルを使って、入力住所をstdaddr形式で返します。

12.2. Tigerジオコーダ

Abstract

米国国勢調査局が公開しているTIGER (Topologically Integrated Geographic Encoding and Referencing system ) / Line and Master Address database exportで動作するよう書かれた、PL/pgSQLベースのジオコーダです。

データローダ機能、住所正規化、住所ジオコーダおよび逆ジオコーダ、の四つの要素があります。

米国のための設計ですが、概念および機能の多くは適用可能で、他国の住所と道路ネットワークで動作するように適合させることができます (訳注: 日本の地名については未知です)。

Tiger関連の関数、道路型前置辞・道路型後置辞・州といった再利用可能な参照データ、データロード管理のための様々な制御テーブル、全てのロードされたテーブルが継承するスケルトンテーブル、を収容するためのtigerというスキーマが、スクリプトによって作成されます。

tiger_dataという、もう一つのスキーマが作られます。ここに、ローダが米国国勢調査サイトからダウンロードしてデータベースにロードした州ごとの全ての国勢調査データが収容されます。現在のモデルでは、州ごとのテーブルは、ma_addrやma_edgesといったように名前の先頭に州コードを付けていて、州データのみに強制する制約が付いています。これらのテーブルはtiger schemaにあるaddr, faces, edges等から継承されています。

全てのジオコード関数は基底テーブルを参照するだけです。そのため、tiger_dataデータスキーマやそのデータを他のスキーマに分割できないという条件はありません。例えば、州ごとに異なるスキーマにしても、tiger内のテーブルから継承されているなら使用可能です。

お手持ちのデータベース内のエクステンションを有効にし、使用するデータをロードする方法については、Section 2.4.1, “TigerジオコーダをPostGISデータベースで有効にする”を参照して下さい。

[Note]

Tigerジオコーダ (tiger_2010)を使っている場合には、extras/tiger内にあるupgrade_geocoder.bat / .sh を使ってアップグレードすることができます。tiger_2010とtiger_2011以上での大きな変更点は、countyテーブルとstateテーブルが、stateごとに出現することがなくなっています。tiger_2010からのデータを持っていて、tiger_2015に置き換えたい場合には、Section 2.4.4, “Tigerジオコーダとデータのアップグレード”を参照して下さい。

[Note]

PostGIS 2.2.0での新規機能は、Tiger 2015データに対応したことと、住所標準化がPostGISの一部に取り入れられたことです。

PostGIS 2.1.0での新規機能は、PostgreSQL 9.1以上では、TigerジオコーダをPostgreSQLエクステンションモデルでインストールすることができるようになったことです。詳細についてはSection 2.4.1, “TigerジオコーダをPostGISデータベースで有効にする”を参照して下さい。

PostGISが用意しているNormalize_Addressの代替としてPagc_Normalize_Address関数があります。コンパイルとインストールの方法については、Section 2.3, “PAGC住所標準化ツールのインストールと使用”を参照して下さい。

設計:

このプロジェクトの目標は、任意の米国住所文字列を処理し、正規化したTiger国勢調査データを使ってポイントジオメトリを生成し、与えられた住所の位置や、位置のもっともらしさを反映した評価値を算出する、十分に実用的なジオコーダを構築することです。なお、評価値は高いほど悪い結果とします。

PostGIS 2.0.0で導入されたreverse_geocodeは、GPS位置のストリート住所と交差点を得るのに便利です。

ジオコーダは、PostGISに慣れている方ならだれでもインストールと使用が容易な程度に単純であるべきで、PostGISがサポートする全てのプラットフォームで簡便にインストール、使用ができるべきです。

書式や綴りの誤りがあっても確実に機能するための十分なロバスト性があるべきです。

将来のデータ更新が使えるか、最小のプログラムの変更で他のデータが使えるための十分な拡張性もあるべきです。

[Note]

関数が確実に動作するために、tigerスキーマは、データベース検索パスに追加されていなければなりません。

  • Drop_Indexes_Generate_Script — tigerスキーマとユーザが指定したスキーマ上の、全ての主キーでなく、かつユニークでないインデックスを削除します。スキーマを指定しない場合のデフォルトスキーマは、tiger_dataです。
  • Drop_Nation_Tables_Generate_Script — 指定したスキーマ内のテーブルのうち、county_all, state_allまたは、county or stateを削除するスクリプトを生成します。
  • Drop_State_Tables_Generate_Script — 指定したスキーマ内の、名前が州コードから始まるテーブルを全て削除するスクリプトを生成します。スキーマが指定されていない場合のデフォルトスキーマはtiger_dataです。
  • Geocode — 住所を文字列 (もしくは他の正規化された住所)として取り、可能性のある位置の集合を返します。返される集合の要素は、NAD 83経度緯度のポイントジオメトリ、正規化された住所と評価値を持ちます。評価値は低いほど可能性が高いことを示しています。結果は評価値の低い順に並べ替えられます。オプションにmax_result (最大結果数、デフォルトは10)とrestrict_region (制限領域、デフォルトはNULL)を渡すことができます。
  • Geocode_Intersection — インタセクトする二つのストリート、州コード、市名、郵便番号を引数に取り、最初の交差点の可能性のある位置の集合を出力します。geomoutにNAD83経度緯度のポイント、normalized_addressにそれぞれの位置、ratingに評価値がそれぞれ入ります。評価値が低いほど合致度が高くなります。結果は評価値の低い順にソートされます。最大結果数を渡すことができ、デフォルトは10です。Tigerデータ (エッジ、フェイス、住所)と、PostgreSQLあいまい文字列合致 (soundex, levenshtein)を使います。
  • Get_Geocode_Setting — tiger.geocode_settingsテーブルに格納されている設定のうち指定したものの値を返します。
  • Get_Tract — ジオメトリで指定した位置の米国国勢調査統計区またはtractテーブルのフィールドを返します。デフォルトでは、統計区の短縮名を返します。
  • Install_Missing_Indexes — ジオコーダで結合や検索条件に使われ、インデックスが付いていなキーカラムを持つ全てのテーブルを探し、インデックスを追加します。
  • Loader_Generate_Census_Script — 指定した州について、tract (統計区)、bg (block group, 細分区グループ)、tabblock (ブロック)をダウンロードし、tiger_dataに格納するための、指定したプラットフォーム用のシェルスクリプトを生成します。行ごとに州ごとのスクリプトが返されます。
  • Loader_Generate_Script — 指定したプラットフォーム用の、指定した州のTigerデータをダウンロードし、格納準備を行い、tiger_dataスキーマに格納するシェルスクリプトを生成します。行ごとに州ごとのスクリプトが返ります。最新版ではTiger 2010のデータ構造変更に対応していて、国勢統計区、細分区グループ、細分区 (tabblocks)テーブルをダウンロードすることができます。
  • Loader_Generate_Nation_Script — 指定したプラットフォーム用の、国と州のルックアップテーブルをロードするシェルスクリプトを生成します。
  • Missing_Indexes_Generate_Script — ジオコーダで結合に使われるキーカラムを持ち、インデックスが付いていないキーカラムを持つすべてのテーブルを検索し、インデックスを追加するSQLデータ定義言語を出力します。
  • Normalize_Address — 文字列で住所が与えられると、道路後置辞、前置辞、正規化された種別、番地、ストリート名等をフィールドに分けて持つnorm_addy複合型を返します。tiger_geocoderに同梱されているルックアップデータで動作します (Tigerデータ自体は不要です)。
  • Pagc_Normalize_Address — 文字列のストリート住所を与えると、道路後置辞、前置辞、標準タイプ、番地、ストリート名等を複数フィールドに分解して持つnorm_addy複合型を返します。この関数は、tiger_geocoder同梱のルックアップテーブルだけを使います (Tigerデータは不要です)。住所標準化エクステンションが必要です。
  • Pprint_Addy — norm_addy複合型オブジェクトを与えると、印刷表現を返します。通常はnormalize_addressと併用します。
  • Reverse_Geocode — 登録されている空間参照系に基づくポイントジオメトリを引数に取り、理論的に可能性のある住所の配列と交差するストリートの配列を一つのレコードで返します。include_strnum_range = trueの場合には、交差するストリートに番地範囲を追加します。
  • Topology_Load_Tiger — Tigerデータの定義領域をPostGISトポロジにロードして、Tigerデータをトポロジの空間参照系に投影変換し、トポロジの許容精度にスナップします。
  • Set_Geocode_Setting — ジオコーダ関数の振る舞いに影響を与える設定を行います。

PostGIS用の二つのオープンソースジオコーダがあります。これらはTigerジオコーダと違い、他国のジオコーディングに対応している利点があります。

  • Nominatimは、OpenStreetMapの地名集データを使います。データのロードにはosm2pgsqlが必要です。PostgreSQL 8.4以上とPostGIS 1.5以上が必要です。Webサービスのインタフェースとして作られていて、Webサービスと呼ばれるような設計に見えます。Tigerジオコーダと同じように、ジオコーダと逆ジオコーダの要素を持ちます。文書からでは、Tigerジオコーダのような純粋なSQLインタフェースを持っているのか、多くの処理がWebインタフェースに実装されているのか、は明確ではありません。

  • GIS Graphyも、PostGISを使用したもので、NominatimのようにOpenStreetMap (OSM)データを使用します。OSMデータのロードを行うローダとNominatimのように米国だけでなくジオコーディングを行う能力があります。Nominatimとよく似ていて、Webサービスとして動作し、Java 1.5、サーブレットアプリケーション、Apache Solrに依存しています。GisGraphyは、複数プラットフォームで動作し、他の機能の中には逆ジオコーダがあります。