空間探索アルゴリズムの研究 ― 2014年04月01日 11時59分47秒
昨年にとある所で某GISソフトを使って生産作業をしている所をみました。
高いスペックのマシンを使ってて、いくらラスター背景でデータを表示してるからと言って目的の場所の要素を拡大表示するのに40秒もかかるのはおかしいと思い、それ以来、レスポンスの研究をしています。
それで、海外製のGISエンジンを使っていると「R-Tree」というものが取り上げられているので今作っているオリジナルシステムにて検証してみました。
MicroStation等で良く使ってたB-Treeよりも強力で親ノードが子ノードへポインタを持つ他にその範囲の空間索引としてレンジ（範囲）を持っている事が特徴です。
実際にそのアルゴリズムを使って検索をしてみたら、10数万筆の地番ポリゴンから1秒かからずに絵と属性を表示しました。速い！
もちろんキャッシュとして認識させた場合でですがこれを応用すると安価で高レスポンスなGISが世に送り出せるかも知れません。
近況報告でした。
高いスペックのマシンを使ってて、いくらラスター背景でデータを表示してるからと言って目的の場所の要素を拡大表示するのに40秒もかかるのはおかしいと思い、それ以来、レスポンスの研究をしています。
それで、海外製のGISエンジンを使っていると「R-Tree」というものが取り上げられているので今作っているオリジナルシステムにて検証してみました。
MicroStation等で良く使ってたB-Treeよりも強力で親ノードが子ノードへポインタを持つ他にその範囲の空間索引としてレンジ（範囲）を持っている事が特徴です。
実際にそのアルゴリズムを使って検索をしてみたら、10数万筆の地番ポリゴンから1秒かからずに絵と属性を表示しました。速い！
もちろんキャッシュとして認識させた場合でですがこれを応用すると安価で高レスポンスなGISが世に送り出せるかも知れません。
近況報告でした。
GIS作りました ― 2014年04月04日 06時00分12秒
まだ開発中なのですが、とりあえず春という事で取り組みカミングアウトのお知らせ。
最近は３次元的プレゼンテーションの要求や成果フォーマットの混在に加え、スピードレンスポンスを維持したまま安価に抑えたいというお客様のために当社オリジナルのGISを作っています。
ArcGISやSISにケンカを売る訳ではないのですが、当社の場合、検討中としてですが製品化するのか、生産作業にこのGISシステムを含めて行く事か（数量無制限。つまり無償に近い）を考えています。あくまでもお客様が予算を組むときに高価なGISエンジンの価格で頭を悩ます事のないようにスムーズに業務をこなせる事が目的で取り組まれています。そうする事で仕事を生み出し、仕事のない人に仕事を提供できるように少しでも世の中の経済に貢献できるように。
※GISシステム マチルダ（仮称。まだコードネームです。良い名前を募集中。一般的なのは好きじゃない「何とかGISとか」）
ArcGISがシェープファイルベースになっているのですが、この作っているGISの特徴はMicroStationのネイティブデザインファイル(dgn)をそのままシェープファイル(shp)と重ねて編集ができるところ。ラスターについてもGeoTIFFの他に一般的なJPGやBMP、濃いMrSIDなども視野に入れています。
※シェープファイルと高画質GeoTIFFラスターを重ねた所（クリックで拡大）
フォーマットは現在はシェープファイルとデザインですがDXFやDMフォーマットなど順次着手中。
データベースとの連携はお得意のという所なのでAccessやSQLServerなど一般的なものは今後は要求されるシステムに応じて変えていきたいと思います。
レスポンスは先日紹介した空間アルゴリズムを使っているのでその辺のGISよりは速くなっているようです。
※３次元表示サンプル。レンダリングやグリグリ３６０度回転ができる
しかし速い。他のGISが遅いのか。それとも機能を追加していくと遅くなっていってしまうのか。とりあえず、このページで詳細や更新履歴を書き込んでいきます。
シェープファイルの高速移動 ― 2014年04月06日 09時11分32秒
先日あるお客さまから相談を受けたのですが、ArcGISでシェープファイルの移動を行いたいが大量の要素数（データ数）の時に長時間かかってしまい困っているとの事。
具体的には固定資産データで30万筆以上分の要素を選択して一気に移動しようとしたら５時間〜６時間くらい返答なし（ノーレスポンス）状態になってそれっきりという事でした。
ESRIさん、こんな事でいいのか？という事で、それだけ大量の要素をGISのビュー上に展開しなおしたらパンクして当然かと思い、解決するツールを開発しました。
内容としてはシフトするパラメータ（X座標及びY座標）を与える事でシェープファイルにダイレクトに変更をかけるものです。例えば全体的に1000km、北側へずらしたいとか。
シェープファイルの構造は、バイナリ形式でエンディアン変換を用いながら行う必要があり、その昔、苦労しましたので今は何とも抵抗がありませんでした。
（参考：エンディアン嘘つかない）
SHPファイルの座標値に変化を与えると、バイナリファイル上のメインファイルヘッダの中のバウンディングボックスの値を更新する必要があります。
またSHXも同様にヘッダ部分を更新する事となり、更に大変だったのがポリゴンやポリライン個々のバイナリ要素の中にも座標の最大最小値を示すバウンディングボックスがあり、これも要更新。
これらの処理を詰め込んだソリューションとして出来上がった地味ですがマジックでも見ているような感覚になる絶品な一品。
もしかしたら、これを応用する事で系座標の変換や緯度経度の変換なども超高速でできるかも知れません。
処理スピードはダイレクト読み書きしてるだけあって申し分なく速く仕上がりました。
お困りな方がおられましたらご連絡ください。
GIS開発（その２） ― 2014年04月11日 09時15分37秒
GISの開発で奮闘してます。
現在は情報発行元のポーランド共和国の技術者と文字列の書き出し位置の表現の事で言い合いしています（いわゆるjusitificationというやつ）
最初はバグやろ？とか私は合ってるとか・・・・頑固なやつらや。
だいたい、漢字などが混在する我々日本にとって文字列の表現がいかに重要な事なのかをもう少し理解頂きたい所です。
CADとGISは先祖が異なるようなものというのは理解しているのですが、やはりそこは良いとこ取りをしたいものなので色々の解決法を模索中。
で、問題となっているのが日本の場合、文字列の書き出し位置がほとんど左下が基準になっているという事で、これがヨーロッパでは一般的に逆になるそうです。
つまり左下基準で入力するとあちらでは右上の基準で表示されるとか。
※MicroStationの文字の入力基準
研究を重ねながら何度かやりとりをしていると次のような結果にまとまりました。
※ヨーロッパ仕様と日本仕様の比較表。
水色が日本仕様で、白色がヨーロッパ仕様。カッコ書きはMicroStationのjustification番号。
総評すると、相互に向きを逆方向にしたような仕様である事が判明。
このロジックを現在開発中のGISに組み込み、内部変換を行う事で正常に表示ができました。とりあえず、無事にここはクリア。
GIS開発（その３） ― 2014年04月14日 20時33分56秒
先日、別件でお客さんが来社してくださったので開発しているGISのデモンストレーションをしてみたところ、
「うちのシステムより速い！」という好評価を頂きました。
強い要望もありましたので早速以下に、評価版として公開いたしました。
こちらのページにて評価版のダウンロードが可能です。
デモンストレーション等、必要であればご依頼ください。国内でも国外でも、どこであっても御社までお伺いして実施いたします。
差し入れチョコ頂きました。 ― 2014年04月17日 10時26分37秒
お客さんから「ニューヨークのALMOND ROCA」というチョコレートを頂きました。
行った事ないし食べた事ないけどニューヨークの味がする！
ありがとー！
最近のコメント