2008年11月13日
GoogleMapsと連動したいならPostGISの他にmysqlという選択肢も出てきた あとジオメディアサミット関西も
随分以前に、GoogleMapsと連動したいなら幾何データ型よりPostGISという記事を書いたけど、徐々にmysqlという選択肢も出てきつつある、という話。
特にGoogleMaps連動に限った話ではなく、位置情報を扱う場合、ということだけど、その辺は前記事を踏襲してみた。
ネタは最近行ったFOSS4G 2008 OSAKAで仕入れたもの。
FOSS4Gに関しては、OSAKAだけでなくTOKYOも行ったので、遅れたレポートに意味があるのかはともかくまたレポートまとめたいと思っているのだけれど、忙しいわ、今指の調子がぶっ壊れてるわで余裕がない。
とりあえずこのネタだけ先に書く。
話としては、沖電気さんが発表した、mysqlに、PostGISの地理計算用関数の一部(distance_sphere, distance_spheroid)を、ユーザ定義関数として移植したという話題。
ご存知のように、mysqlでも4.1以降幾何データ型と空間インデックスには対応しているので、 経緯度座標系での矩形検索なら、これまででもできた。
で、沖電気さんではmysqlとPostGISについて、空間インデックスを使った場合の矩形検索のベンチマークを取られたらしい。
その結果、沖電気さんが選択された検索条件では、両者のパフォーマンスに10倍近い差が出たらしい(もちろん、早いのはmysql。また、あまり詳しい検索条件はちょうどその時席外してて判らなかったが、10倍もの差が出るのは並列にクエリを走らせた場合で、単発クエリならばそこまでの差はなかった模様)。
なので沖さんでは、このあたりのシステムを組むのにmysqlを選択したそうなのだけど。
ところが、構築し始めて、はたと困ったらしい。
mysqlだと、PostGISにある球面/楕円体面上での距離を求める関数(distance_sphere, distance_spheroid)がない。
単純に平面計算するdistance関数だと、東京大阪間くらいにもなると数kmで誤差が出る。
といって、工程的にもパフォーマンス的にも、もうPostGISには戻れない。
どうすんべ?ということで、考えてみればPostGISもmysqlもオープンソースなので、distance_sphere, distance_spheroidをmysqlに移植すればいいんじゃないか?というので試してみたとのこと。
球面/楕円体面上での距離を求めるアルゴリズム自体は、特に解析せず2つの経緯度から距離を求めるPostGISからのロジックをそのまま持ってきて、その上にmysqlでの幾何オブジェクト型を経緯度に変換するラッパーを書いたところ、動いたらしい。
これで、mysqlでも、クエリ一発で球面上での距離計算をした検索結果を得られるようになったわけだ。
この関数を発表したところ、mysqlのコミュニティからすごく反響があったらしい。
mysqlのファウンダーのサインがもらえたり、メインストリームのブログでも取り上げてもらえたり。
mysqlではGIS系の専門家が少ない(メインストリームのGIS系関数も、メンテナがいない状況?)らしく、すごく歓迎されたとのこと。
単にラッパーを書いただけ(もちろん、それに目をつけて、実際に作るところがすばらしいのだけど、ご本人が謙遜してそう言われていたのでそのまま書いておく)で、注目を集められるので、mysqlでは位置情報処理分野にまだまだフロンティアがあるようで、GIS系の技術者の人もmysqlだからと思わず、いろいろ移植してみてはどうか、と言われていた。
もちろん、まだまだ課題も残っていて、たとえばdistance系の関数の問題点として、空間インデックスが効かないため、まず矩形検索で空間インデックスで篩いをかけてやり、篩いに残った行だけで距離検索をかけてやる、というのが検索手順になっている。
ところが、座標系は経緯度座標系なのに対し、求める距離計算は球面上の計算なので、篩いのための矩形をどのように求めるか、というのが問題として残っており、今のところメルカトル図法に変換した座標系で関数インデックスを張ってやり、メルカトル図法上で篩いをかけたあと、距離計算するというのがベストプラクティスになっている。
が、mysqlだとまだ今のところ上記を実現する経路がないので、自前で何とかして外接矩形を求めてやらないといけない。
沖さんが、その辺をどうされているのか聞いてみたい、というか聞けばよかった。
ちなみに、FOSS4G 2008 OSAKAでは、こちらの記事でも採り上げたとおり、「第1回ジオメディアサミット関西」の併催されました。
私も、ケータイ国盗り合戦について、技術面ではなくマーケティング系の話題でしゃべったのですが、資料などはこちらで他発表と一緒に公開されていますので、ご笑覧ください。
そういえば、私、ジオメディアサミット中はタイムキーパーやっててメモ取ってないので、ジオメディアサミットについては追ってレポート、と言ってもそれほどいまさら書くレベルのものは書けないかも...。
他の人のレポートにリンク張りますので、そっちで雰囲気を感じていただければと思います。
FOSS4G 2008 TOKYOについては、いまさらではありますけれども、いずれ書きます。
- 第1回ジオメディアサミット関西の感想とジオメディア忘年会のお知らせ
- 第一回ジオメディアサミット関西、大成功です(感謝!)
- 第1回ジオメディアサミット関西に参加
- ジオメディアサミット関西でNavitte!についてライトニングトークしてきました
1エントリ・1アイヌリンク:
気軽にアイヌ刺しゅうを 札幌の学芸員 テキスト作製、技法を図解
道立アイヌ総合センター(札幌市中央区北2西7、かでる2・7内)の津田命子(のぶこ)学芸員(62)が、資料を調べるなどしてアイヌ民族の伝統的な刺しゅうの技法をひもとき、その成果を「アイヌ刺しゅう入門 チヂリ編」として刊行した。
図解中心のテキストで、初心者や身近に指導者がいない人にもアイヌ文化に触れる機会を提供してくれそうだ。
こちらの本みたいですね。(というか、またAmazonだけで楽天なかったよ...楽天で売ってたら、貯まりまくってるポイントでタダで買えるし、即効買ったんだけど)
OSGeo.jp のかやまです
KOFでMySQLな人とお話したのですが。
MySQLの本家ではPostGISに対抗して幾何データの関連を作り直しているらしいですよ。
ちょいと期待しています。
おおー、本当ですか!
沖さんの話を聞いた限りでは、なんかメンテナいないっぽいという話だったのですが、それは超期待です。
...いや、正直な話、私も実際にはmysqlらぶなので、GIS用途のためだけにPostgreSQL使うのは閉口してた感はあるのです。
PostgreSQL/PostGIS愛ばりばりの方には申し訳ないのですが。
どこまで対応してくれるでしょうか...。
幾何演算とかまで対応してくれれば、PostGISいらなくなるので超うれしいのですが。
ノウハウはそのまま使えますし。
下手な発表でしたが、なんとか内容が伝わっているようで一安心。というか、ここの記事のほうがうまく、まとまってますね(苦笑)
MySQLのGISまわりの話は中の人でも温度差があるようで、情報も違うみたいで...私の方の情報が間違っていることを期待してます。
![[ここギコ!]](http://kokogiko.net/logo.png)



・3Dどきゅめんと…って何?点字文書?(Ufoceleb)
・コロカの詳細が判りました&店舗誘導における来店検知の方法について(kokogiko)
・コロカの詳細が判りました&店舗誘導における来店検知の方法について(通りすがり)
・可視光通信って自位置特定にも使えるんじゃないか(Light Wire)
・新型インフルエンザでマスクとか(和知父くま)
・気持ちのよいサービス2:タクシーに携帯電話忘れたら届けてくれた(あああ)
・「ちっ、早すぎたな」と捨て台詞が言えるだけの何をお前はやったのか(kokogiko)
・国連人権委、アイヌ・琉球文化の保護を日本に勧告(TeraC)
・街頭募金に意味がないとは思えない(mukke)