pgRouting

FOSS4G 2008 Osakaに行ってきました。

今回特に気になっていたのはpgRoutingハンズオンセッション。
開発者に教えてもらえる数少ないチャンスだったのに、なんだかもったいなくすごしてしまったかもしれない。
vmwareの設定に時間が取られ実際の操作はあまりできなかったかなというのが正直な印象。

私も含め参加者サイドの問題だが、あらかじめHPに目を通しておけばよかったといまさら反省。

操作の感想としては特に難しいということはないが、データ整備は難しいと思う。特にshooting-starアルゴリズムのデータは難しい。

というのも、それ以外のdijkstraやA-Starでは、経路1は接続する経路が何本あろうと1フィーチャでいいのだが、Shooting-Starでは経路1に対して、接続する複数の経路ごとにコストを設定できるため、経路に設定するコストごとにフィーチャを登録する必要がある。

きっと言葉では伝わらないとは思うが、これは相当なコストがかかる作業だ。そして複雑すぎて、データ作成時のミスが発生しやすい。

また製作者でありハンズオンの講師でもあるDaniel Kastlさんによると3つのアルゴリズムで差が出るとしても数％程度だということだ。

速度に影響するのはむしろデータ件数のほうが問題ということをきくと、自分でもし使うならShooting-Starは扱いにくい。

dijkstra_sp_deｌtaはあらかじめ始点終点が入る大きさのバウンディングボックスで絞込みを行ってから検索を行うそうだ。これはいい。ほかのアルゴリズムにも同様のものはあるのだろうか

オープンストリートマップ(osm)のデータをどのように使えるのか非常に興味があったのだが、時間が足りず残念。しかしよい体験だったともう。

次回は日本のosmデータで簡単なでもサイトの構築間で行える時間があるとうれしい。
また基本的な用語(source,target,cost,to_cost,rule)の説明が先にないとなかなかわかりにくいと思う。

いや予習しなかった私が悪いんですけど。

そんなわけでDaniel さんありがとう。


そのほか面白かったもの
・「Seven years of FOSS Business in an European company」　Claude氏
　　オープンソースをビジネスとすることは可能だということ。日本ではどうだろう？
　　先ほどのDaniel さんが質問されていていたのが印象的だった。

・　MySQLへの地理空間距離関数の追加

　　postgisは遅いからMySQLで球面距離の計算をできるようにしたとのこと。

　　2つのDBの計測時間を見るとその差は唖然とするものがあるが、

　　postgresびいきなので今ひとつ納得がいかないものがあった。

　　だが業界としては健全な方向に進んでいるのだと思う。

　　常に選択肢がひとつなんてのはよくない。

　　適材適所データベースを使い分けて、ユーザのストレスは少ないほうがよい。


やはりというか開発者サイドの話が多く、利用者として訪れた私は少し場違いだったかもしれない。

それなりに楽しめたけど。


それ以外の雑感
・ubuntu　=　Windowsになる日がくるかも

PC持ち込んでいる人はubuntuかWindowsが多いように思った。それだけ完成されているということか。

確かに私のPCも家ではubuntuだ。ハンズオンの参加者はみなWindowsだったけど。

・firebird

シングルファイル構成なDBだそうで、ファイルサイズが小さいうちは非常に扱いやすそう。
(追記：複数ファイルからなる構成も可能らしい)

簡単なリポジトリなどにはちょうどいいかも。ちょっと調べたいと思った。

大規模なDBとしては向かないところもあると思うが、何事も適材適所。

すべてにおいてOracleが最高ではない。



主催者サイドの方々お疲れ様でした。