とりあえず、なんとなくPostGISの使い方がわかってきたので、PostGISなテーブルにデータを挿入する方法をメモしておく。
INSERT INTO [テーブル名]
([カラム名])
VALUES
(
GeomFromText(‘POINT([経度] [緯度])’,[座標系])
);
座標系はSRIDってやつなので、WGS84の場合は4326になる。経度と緯度は度分秒ではなく度であらわし、分秒は度の小数として指定（Google Mapsと同じ）。POINTってのはポイントってこと（当たり前）。というか、これも関数。多分挿入するカラムと同じである必要があると思う。他にも型に合わせてLINESTRINGとかPOLYGONとかあるみたい。当面はPOINTだけ知っていればよさそう。
PostGISを使って空間座標を格納するカラムをテーブルに追加する際は、create文で一気に作るのではなく（本当は一気に作ることもできるだろうが）、最初に空間座標以外のカラムでテーブルをつくり、あとからPostGISの関数を使って空間座標カラムを追加する。専用の関数を使うのだから、それだけで事足りているのだろうと思っていたら、別途インデックスを作成することもできるようだ（言い方をかえると、別途作成しなくてはいけない）。
PostGISのマニュアルではこんな具合に書いてある。
CREATE INDEX [インデクス名] ON [テーブル名] USING GIST ( [ジオメトリカラム名] );
でもウェブを調べると、カラム名の後ろに半角スペースをつけて「GIST_GEOMETRY_OPS」というおまじないをつけてあることが多い。これの意味を調べたけど、今のところよくわからない。もうちょっと調べなくては。
インデックスを作成した後は、PostgreSQLがうまくインデックスを使ってくれるようにバキュームをかけておかなくてはいけないらしい（統計情報収集）。こういうことを知らなかったので、今までいかに何も考えずにデータベースを使っていたのかがばれてしまう。
VACUUM ANALYZE [テーブル名] [カラム名];
これで空間座標のカラムにインデックスが効いて、位置検索するときに速度向上が見込める（らしい）。数千行以上のデータを扱う際は入れておくべき、とのこと。
データベースの作り方で一工夫必要だったわけだが、テーブルに位置情報を格納するカラムを作るのはさらに一工夫必要だ。
ID番号、地点名、位置情報の3つを格納するテーブルを作成することにする。テーブルを作成する際は、まず最初に、位置情報を格納するカラム以外のカラムだけでテーブルを作成する。つまりID番号、地点名だけのテーブルを作成する。例えばこんな具合に。
CREATE TABLE positions (
id int4 SERIAL PRIMARY KEY,
name varchar(128)
);
そして、PostGISをインストールした際にたくさん設置された関数群のうちの一つを使用して、位置情報を格納するカラムを追加する。ここではlatlngというカラム名を使用することにする。
SELECT AddGeometryColumn(‘public’,’positions’,’latlng’,4326,’POINT’,2);
publicはスキーマ名
positionsはテーブル名
latlngはカラム名
4326は測地系の番号（この数字はWGS84）
POINTは型（他にLINESTRINGとかPOLYGONとか）
2は2次元
つまりSELECT文を使って、AddGeometryColumn関数を実行しているということ（この関数でカラムを追加）。この作業でようやくPostGISなテーブルが作成される。ここまできて、ようやく今までやってきたことの意味が理解できるようになる。
4326ってどこから出てきたのか。実はこの数字はPostGISなデータベースに自動的に作られるテーブル「spatial_ref_sys」に全て格納されている。このテーブルには約3000行のデータが格納されているのだが、これらは全て座標系だ。4326の値は外部キーのようになっているということ。
そして位置情報格納カラム「latlng」を作成した関数AddGeometryColumnはカラムを追加するだけでなくて、そのカラムの情報を「geometry_coumns」に格納している。ためしにこのテーブルを開くと、先ほどの関数の引数と似たような内容でデータが格納されていることが一目瞭然だ。
もうここまでくればPostGISに関する理解はほぼできたといっても過言ではない（と思いたい）。「なんで最初からわけのわからないテーブルが二つも作られているの」「どうやって使うの」という問題は通り過ぎてしまったわけで、後は希望通りの処理を返してくれるPostGISな関数がどれなのか、ということを探すことになる。
ただしもう一つ知っておかなければいけないことがある。それは測量に関する知識だ。当たり前だが地球は丸い。というか球だ（実際は球ではなくてもっと歪んでいる）。球を無理やり平面に押し込めたのが地図だ。軟式のテニスボールをカッターで切り刻んでみればわかるが、本来球はどうやっても平面にはならない。でも、それでも人間が理解しやすいようにPostGISは答えを返してくれる（らしい）。そんなPostGISをこれから徐々に使っていこうと思う。
当面PostGISを使うので、思ったことや気づいたこと、わかったことをメモしていくことにする。
お試しインストールだけしたPostGISだったが、やっぱり気になるので少しだけ試すことにした。何をどうすればよいのかわからないし、書籍も皆無な状態なので、いつものように検索しつつ・・・の確認作業。
データベースの作成からはじめないといけない。PostgreSQLのデータベース作成で、以前はデータベースのテンプレートなんて「なんのこっちゃ」ということで気にも留めていなかったけれど、ここから勉強だ。というか「こういう用途だったのね」と再認識した。PostGISインストール時に自動的に作成されたtemplate_postgisというデータベーステンプレートを元にデータベースの作成をしなくてはいけない。要はコピーして新規作成。
createdb -T template_postgis dbname
これでdbnameという名前のデータベースが作成される。大量の関数群と二つのテーブルがあらかじめ作成された状態になっている。でもまだまだ序の口。だいたいなんで最初からテーブルが作成されているのかわからない。どうやって位置情報を格納するのかもわからない。わからないことだらけだ。
とりあえず、小さいことからコツコツと始めることにする。
PostgreSQLを長期間vacuumせず放置してディスクを浪費した件で、対処方法を調べたのでメモ。
一番簡単なのはvacuumをかけることだが、vacuumをかけるにはディスク容量を必要とする。例えばデータベース容量が膨れ上がって2GBになってしまったが実際は1GB程度のデータベースだったと仮定する。このデータベースにvacuumをかける際、ディスクの空き容量として1GB程度が必要になる（らしい）。しかもvacuumには時間がかかりそう。多分、いったんデータベースがダンプされ、データベースを削除し、ダンプされたデータベースから復旧する、というイメージなんだと思う。
とりあえず実際のデータベース容量がわからず、かつ膨れ上がったデータベース（テーブル）がテンポラリ用途で使用していたので、不要な行をすべて削除してからダンプした。ほとんどファイル構造だけのダンプなので数十キロバイトですんだ。その後dropdbでデータベースを削除した。2GB強のデータベースだったが、数秒で削除された。その後、データベースを再作成して、ダンプデータから復旧。これで復旧できた。空き容量もしっかり確保できた。
データベースは適当に運用しちゃだめだね。