MapServerによるベクター地図のダイレクトWeb公開

どんな技術、サービスか

世間では、様々なフォーマットのベクター地図が利用されていると思います。公共系で使われている地理情報標準(JPGIS)、 地図ベンダー独自形式としての昭文社-MRD、MRX、ゼンリン-Zmap-TOWN2、Zmap-AREA25、国際航業-PAREA、GISベンダー独自の形式としての ESRI-shape、MapInfo-tab、SIS-bds、海外のデータ形式としてのDLG、DCW(VPF)等々、我々の身の回りには実に様々なベクター地図の フォーマットが存在すると思います。通常は、これらのフォーマットのベクター地図を、Web公開する場合、それ専用のフォーマットに変換しなければいけません。 有名な所では、例えばオープンソースのWebGISではGeoServerと並んでデファクトスタンダードであるMapServerの場合は、 PostGISと云う空間管理機能が拡張されたDB内のテーブルに格納することが、半ば必須、或いは当然の常識となっています。 つまり通常、格納/管理されている地図フォーマットそのままで、Webに公開することは出来ない訳です。 弊社のサービスは、この問題を解決すべく、任意のフォーマットのベクター地図データを直接Webサービスにつなぎます。つまり、 あなたのベクター地図をそのままの形式のまま(何のフォーマット変換も行なうことなく)Web上の地図として公開します。この技術、サービスのイメージは、図 1に示す通りです。

「MapServerによるベクター地図のダイレクトWeb公開」のイメージ
図1 「MapServerによるベクター地図のダイレクトWeb公開」のイメージ

どう実現するのか

これは、日夜研究を続けている技術なので、詳しくここで記すことは、取り敢えず控えますが、大事なキーポイントのみ、列挙すると以下の通りです。

  • MapServerの利用:OpenSourceのWebGISエンジンであるMapServerに当該ファイルを読み込む機能を追加することで、ダイレクトWeb公開を実現する。MapServer自体は、OpenSourceであるため、その分の経費を節約出来る。
  • プラグインの実装:MapServerへの機能追加は、MapServerプラグインと呼ばれる補助モジュールの中で実装される。逆に言うと、プラグインを開発することで、任意のベクター形式データをMapServerと直結させることが出来る。
  • システム構成:MapServerプラグイン(図 2で黄色で塗りつぶした部分)を利用すれば、図 2に示す様なシステム構成で、Webアプリケーションを開発することが可能である。図 2では、フレームワークとしてOpenLayersを用いているが、これは勿論、別のフレームワークでも構わない。
システム構成
図2 システム構成

皆さんにどんなメリットがあるのか

皆さんが管理しているベクター地図のフォーマットのままでWeb上の地図として公開出来る為、フォーマット変換に必要な時間が節約され、即座に、Web上への公開が可能です。
よって、例えば管理されているベクター地図が頻繁に更新される場合でも、更新した結果を即座に、ほとんどリアルタイムに公開することが可能になります。 これは特に、更新頻度が高いデータに対して、出来るだけその時点の最新データを大勢の人に共有させたいと云うニーズを持っている方にとっては大きなメリットであると思われます。

費用はいくら位かかるのか

一般論として一概に、費用は「いくら」とは申し上げられない状況です。と申しますのは、以下の要因に応じて、費用は変動するためです。費用については申し訳御座いませんが、お問い合わせ頂ければ幸いです。

  • 地図フォーマット:公開対象であるベクター地図のフォーマットは何か。
  • 作業範囲:作業範囲はどこまでか。例えば、補助モジュールの提供のみか、アプリの開発まで含まれるのか、機能的には表示のみか、編集も込みか。
  • 要求機能:プラグインの機能として、どこまで要求するか。例えば、属性検索のレベル、対象とするデータの範囲、データの翻訳の必要性の有無。
  • 要求性能:要求される性能(主に速度面)はどの位か。
  • 既存のライブラリ:当該フォーマットの地図データを読み込むめる既存のライブラリは存在するのか。それは利用可能なのか、どの程度の価格で、どの様な機能を持っているのか。
  • 利用環境:利用を想定しているWebアプリケーションのフレームワークは何か。
  • 著作権:著作権はどちらに帰属するのか。
  • これまでの経験:弊社のその時点での経験度合い。

注意点は何か

本サービスについては、実は注意すべき点があります。それは速度性能の問題です。あくまで、現状のフォーマットを優先し、それを加工/チューニングすることなく、 そのまま利用することを前提としているため、速度性能が実用レベルに達しない危険が発生し得ます。分かりやすい例として、例えば、 ベクター地図が属性と形状の2つのテーブルに分れており(同一テーブルではないと云う意味)、そのテーブルには何のインデックスも設定されておらず、 更に特別な空間管理機能が何も追加されていないDBに格納されていると云う様な云わば最悪のケースを考えたとします。この場合は、そうではないDB内のデータと比較した時に、 速度性能に著しい差が出るのは、御理解頂けるかと思います。

最後に

もし、このページに記載された技術、サービスへのニーズ、興味を御持ちならば、是非とも、弊社まで御問い合わせ下さい。

All Rights Reserved, Copyright © NCM