PostGISの機能と守備範囲について

Toru Mori @jg2tkh

11月上旬に開催されるFOSS4G Tokyo/Osaka（OSGeo財団日本支部主催）に、PostGISコミュニティの責任者のPaul Ramsey氏の来日が決定しました。ジオ系のサービスのバックエンドで必須の存在のPostGISのグルであるPaulが初来日です。こうご期待！

megumeru @megumeru

CMSってMySQLとか使うけど,データはCMS間で共有できないんだよね・・・・。

まげぱX @Magepa

@megumeru データベースエンジンが共通でもスキーマもインターフェースも違いますから…。しかしモデル間のデータ変換はできたらおもしろそうですね。

megumeru @megumeru

@Magepa MTでいれた情報をWordPressに渡したり,Xoopsの情報をNucleusで使ったりとかできるとすごい可能性が広がる気がするんですけどねぇ。何が違うんだろう。

まげぱX @Magepa

@megumeru まったくのべつものですwwスキーマはパフォーマンスやデータベースのサイズに関わるとこなので、viewに合わせてそれぞれ違う物になります。

Kozo Kamada @geo80k

@megumeru MT 以外は MySQL でないと動かないんじゃなかったっけ？　GISer なら PostgreSQL ベースでＣＭＳを構築しないとアカンような気がする。（といいつつ、自分のノートには何も知らなかった頃に入れた Nucleus が入っているけど）

まげぱX @Magepa

@geo80k 最近はSQLiteで大体のものは動きます。

Kozo Kamada @geo80k

@Magepa 「SQLite で動く」は、「PostGISが」でないと、私の文脈では意味がないのですが、大丈夫でしょうか？

Kozo Kamada @geo80k

@Magepa すみません、わかりにくかったですね。「たとえデータ交換ができたとしても、地理空間情報の取り扱いに長けていない SQL エンジンで CMS を構築していてはベストではないような気がする」という文脈です。だから、もとのmegumeru さんの発言から少しそれています。

まげぱX @Magepa

@geo80k SpatiaLiteでは足りないでしょうか。

Kozo Kamada @geo80k

@Magepa ごめんなさい、Spatial Lite というものを存じませんでした。PostGIS と Spatial Lite の関係が、MySQL と SQLite の関係に平行なのであれば、私の心配は不要だということになるわけですね。ご教示ありがとうございました。

まげぱX @Magepa

@geo80k むしろPostGISの格納は全然SQL的な物を使ってないですが。。何のためにRDBMSに入れてるのか私にはよくわからないです。あと、今のCMSとPostGISみたいな情報は一つのDBに同居させたくない物を感じます。分けた方が便利です。

Masaki Ito @niyalist

この辺りの疑問点を11月くらいまでにゆるやかに議論，整理して，FOSS4Gでぶつけましょうよ！ RT @Magepa: @geo80k むしろPostGISの格納は全然SQL的な物を使ってないですが。。何のためにRDBMSに入れてるのか私にはよくわからないです。

Nobusuke Iwasaki@つくば @wata909

@Magepa 格納にSQL的なもの，というのはどういうことでしょうか？SQLというのはデータベースに対するクエリーのための言語だ，ぐらいの認識しかないので，よろしければ例示してもらえるとうれしいです。お暇なときで結構ですので。

まげぱX @Magepa

@wata909 組み込み関数ではなくSQLでたたいて出てきたWKBをそれぞれのポイントに分けることができるかできないか、という視点です。関数をつかうアクセスはその負荷をDB側に固定することになり、スケーラビリティ的にも不利だと思っています。

まげぱX @Magepa

@wata909 たとえばPostGisで山口県にある500m以上直線が続く舗装道路、みたいなものを得るにはデータから見直さなければいけなかったりすると思ってます。本来こういった使い方はDBの得意分野のはず...はずなんだ

Nobusuke Iwasaki@つくば @wata909

@Magepa ありがとうございます。あとのコメントは理解できたのですが、最初のコメントは半分ぐらいしか理解できませんでした(汗もうちょっと勉強が必要なようです。

Nobusuke Iwasaki@つくば @wata909

@Magepa それから後半のコメントのような例だと線形参照を使うとできるかもと思いました(できないかも知れないですけど)。ただあれも、そのためのデータを作らなければなりませんし、長さという属性にしか対応しませんから、汎用性という意味では十分ではないと思います。

hfu @_hfu_

@Magepa @wata909 幾何処理をDBでやるかクライアントでやるか。私は飛び交うWKBHexの分量とかWKBHexのパーズコストとか想像しながらいつも悩みますが、最終的には、私の場合、クライアントがJavaとかRubyで重めなので、DB側で幾何処理することが多いです。

hfu @_hfu_

@Magepa @wata909 PostGIS で SQL 関数で幾何処理、裏ではGEOSが働いているんでしたっけ？内部で何段もデータ形式の変換が掛かっているようで（←古い？）、効率的な印象はないですが、それでも Java とか Ruby でパーズしなおして処理するより速い印象

hfu @_hfu_

@Magepa @wata909 「腐ってもC」「餅は餅屋」みたいな感じで。クライアント側での、例えばJTSを使った処理とか、少なくともジオデータのライトユースには大げさな印象も。ヘビーユースでは、状況によっては「DB側じゃ非効率だね」というものがありそう

hfu @_hfu_

@Magepa 「スクリプト言語でやるなら、PostGIS をジオメトリエンジンとして使っちゃっていいじゃん」という知恵を、私は 「@kokogiko の第一法則」と呼んでいます。（ジオデータとコンテンツを同じDBに入れるべきかという話とは離れますが...。）

hfu @_hfu_

SpatialLite は、私は Ruby から使えたら絶対にファンになるところなのですが、Ruby からは使えなくて、その理由が SQLite の方針によるもののようなので、ちょっと手を出さないでいます。

まげぱX @Magepa

@_hfu_ 最高速度を目指すのであれば現状そうなのだと思いますが、GISで必要なのは開発者の取り込みだと考えています。Posgres固定とか(Web)業界非標準拡張を引きずるのはちょっとやってみようか層を大量に取りこぼす形になっているとおもいます。

まげぱX @Magepa

@_hfu_ GEOSをSQL方向に拡張してGEOS、proj4を組み合わせてやや遅いけどスクリプト言語からDBからSQLネイティブでGeoSpartial開発、というスタイルが確立できたら、裾野が広がりつつ、速くするにはPostGIS!みたいな動きができないかなぁと妄想中です。