PostGIS：球面座標系に対応するらしい＆その他雑話題

PostGISが1.5から、球面座標系に対応するみたいです。

• PostGIS does Geography - Postgres OnLine Journal
• OpenGeo : Geodetic Types
• Paul Ramsey: PostGIS gets Spherical (Directors Cut)

これまでのPostGISでのGeometryデータ型では、平面座標系であったため、経度・緯度でデータを保存すると距離演算の関数とかもその座標系上での三平方の定理演算になってしまい、球面上の2点として結果をmで返してくれるようなことはありませんでした。
distance_sphere、distance_spheroidのような関数もありましたが、インデックスを効かせた演算はできませんでしたし、これまでのPostGISで球面上距離での検索等を行おうとすると、地図投影法等の知識を駆使して、mで評価できる平面地図座標系に投影変換した結果に関数インデックスを張っておく、といった方法を採る必要がありました。

が、今回できるGeography型というのを使うと、経緯度でデータを収めても、距離演算関数を通すとちゃんと地球を球とみなし、mでの演算結果を返してくれるようです。
これで、GISに詳しくない人でも、直感的に簡単に、位置情報データをSQLで扱うことができるようになります。
単に球面座標系を扱えるようになったというだけではなく、インデックスの検索速度等も向上しているようです（もっとも、GeometryよりGeographyの方が検索処理が容易だからというわけではなくて、そもそもインデックスの作成アルゴリズムをより速いものに変えたのですが、それがまだGeography型にしか適用されていないことによるものらしいです。PostGIS 2.0からはGeometry型にも新インデックス方式が適用されるらしいので、そうなるとやっぱりGeometry型の方が速いのだろうと想像します）。

ただ、今回の対応は飽くまで「球面座標系」での対応です。
地球は実際には、極半径より赤道半径の方が長い「回転楕円体」なので、厳密には誤差が生じ、完全な対応とはいえません。
が、厳密な用途でない、いわば「GIS」ではない「Neogeography」的な用途であれば、十分実用に耐えると思われます。

私も上記の記事を読んだだけでまだ試していないのですが、また折をみて試してみようと思います。

また別の話題として、PostGISにはいろいろなジオメトリ演算の関数等もあるのですが、最近結構使いでのありそうな関数の存在を知りました。
ST_Simplifyという関数ですが、これは複雑なジオメトリの形状を間引いて、簡潔な形を算出してくれます。
これ、FOSS4Gでも発表されたと思いますが、Mapionの地図での、道路形状簡略化にも使われているそうです。

▲ Mapion地図での、日光いろは坂大縮尺。 ▲
この縮尺だと、道路形状そのまま描画しても潰れませんが...。

▲ Mapion地図での、日光いろは坂小縮尺。 ▲
道路形状そのまま描画すれば潰れるはずですが、
ST_Simplifyで道路形状を単純化して潰れないようにしています。

うまく使えば、上記のような芸当ができます。
小縮尺地図の描画以外にも、いろいろ使いでがありそうです。

さらに別の話題。

最近、TwitterでPostGISの話題をしたのですが、

• KMLって座標系の指定出来ないのかな？
  shige1973
  2009-11-12 22:07:09
• [B!] 月の杜工房 - PostGISからKML出力 http://bit.ly/QPXlj
  kokogiko
  2009-11-12 22:12:01
• @kokogiko ありがとうございます。PostGIS使えば楽なのか！
  shige1973
  2009-11-12 22:33:38
• @shige1973 特定図法のラスタデータを重畳したいとかでなければ、ベクタデータならPostGIS経由が一番早いよ。テーブルに突っ込まなくても、オンザフライでも変換できるし。
  kokogiko
  2009-11-13 11:20:23
• 正直、ジオメトリ演算するのにGEOSを頑張ってLightweight Languageにバインディングとか頑張るぐらいなら、PostGISをサーバに突っ込んでおいてSQL文一発で演算できるようにする方がはるかに楽。負荷はともかく。
  kokogiko
  2009-11-13 11:23:54
• ラスターまで考えたら、MapServerの力借りないと無理だと思う。
  kokogiko
  2009-11-13 11:24:32
• @kokogiko postGIS結構な処理もこなしてくれますよね。以前ブログに書かれていた、メルカトル図法に変換してindex効かす方法で距離計算しているのですが、今の所問題なく稼動してます。
  nonomura
  2009-11-13 12:02:09
• @kokogiko 作業ツールって発想イイですね
  shige1973
  2009-11-13 12:18:31

上記で話題にしたように、PostGISを空間DBではなく、ツールとして使うという発想、結構ありだと思っています。

PostGISは結構いろいろな座標系変換やジオメトリ演算の機能を持っていて、それはproj.4やGEOSといったライブラリの機能に因っているわけなのですが、この手のライブラリを各種言語から直接扱おうと思うと、かなり、いや相当大変です（proj.4はともかく、特にGEOSはバインディングの難しさもライブラリのインタフェースの訳判らなさも、泣きそうになる）。
ですがPostGISは、そのproj.4やGEOSの豊富な機能を、SQLというすごく判りやすいインタフェースで提供してくれ、かつDB接続なのでほとんどの言語でまず当たり前に接続できる。
なので、PostGISを空間DBではなく、proj.4やGEOSの機能を汎言語的で平易なインタフェースで使うツールとして捉え、テーブルも作らずオンザフライで位置情報演算させるためだけにアプリケーションサーバにインストールしておく、という考えはアリだと思うのです。
もちろん、直接各ライブラリを叩くよりは（叩ける環境を作れたとして、ですが）オーバーヘッドが生じるのは当然ですが、そもそもジオメトリ演算とかってそんなに頻繁に行われる処理だっけ、また同期的に処理できるほど軽い処理だっけ、というあたりから考えると、非同期でバックグラウンド処理としての用途ならば、PostGISをツールとして使うのは、考えうる構成ではないかと思います。

以上、とりとめもなくPostGIS繋がりで3題書きましたが、どれかでも参考になれば幸いです。