JP3861318B2 - 情報提供方法 - Google Patents

Description

【０００１】
【産業上の利用分野】
本発明は、データベースに格納されたマルチメディア情報をネットワークを介して、各種の情報端末へ情報提供する分野に係わり、特に地図/図面情報のように詳細で大容量の内容を持ったマルチメディア情報を、通信速度や表示解像度が大幅に異なる情報端末で構成されるシステムへの情報提供に有効な方法を提供するものである。
【０００２】
【従来の技術】
種々のマルチメディア情報の中でも地図/図面情報には、地形の凹凸を示す等高線図形,建物の外形を示す家枠閉図形,地名や世帯主名を示すテキスト,航空写真・衛星画像等で構成される空間情報と、顧客・設備の状況を示す属性情報とで構成され、詳細で膨大な容量をなすことが多い。例えば、縮尺1/1500の東京都23区内の住宅地図の空間情報だけでも約3.5ギガバイトを要し、しかもこの場合、各家枠図形の一軒一軒の内部には、建物名称や世帯主名称が付記されるといった非常に詳細な内容を有する。このようなマルチメディア情報を効率良く提供するためのシステム構成方法としては、従来、データベースサーバにマルチメディアデータを格納したデータベース化を行い、これにLANを介して接続される情報端末に向けて、専用のCSS構成により情報提供するようなシステムが多かった。
【０００３】
例えば、図２に示すような専用のCSS構成による地図/図面情報提供システムについて考えると、100のデータベースサーバには120の空間・属性データベースが格納されており、これを110のデータベースサーバプログラムにより各種の検索や更新要求の為のトランズアクション処理が行われ、データベースの一貫性が管理されているものとする。この状態で、200の専用LANを介して300のクライアント端末から検索要求が出されると、ソケット結合の専用プロトコルによりデータベースサーバから所望のデータが検索され、クライアント端末に常駐する310の地図/図面情報処理といった応用処理専用のクライアントプログラムにより320の表示装置へグラフィック表示が行われる。一方400のPDA等の携帯端末から210の公衆回線を介して検索要求が出される場合には、直接100のデータベースサーバとCSS構成をとることが出来ない。この場合には、携帯端末から公衆回線を介して450に示す中継用のクライアント端末に一旦入ってから、ソケット結合の専用プロトコルによりデータを検索し、その結果を再度公衆回線を介して410に示す携帯端末の表示装置へ転送し表示する。
【０００４】
このようなCSS構成をとることの問題点としては、次のような項目が考えられる。その第１の問題点として、400のターミナル端末から直接100のデータベースサーバーとのCSS構成がとれないため中継用のクライアントを必要とし、そのクライアントに常駐させるクライアントプログラムのバージョン管理が難しいこと、及びその第２の問題点として、一般に320のクライアント端末の表示装置の解像度と410の携帯端末の表示装置の解像度とは異なる外、LANと公衆回線とではデータ転送スピードが異なるため、提供情報の解像度と転送量とを同一に扱うことが出来ないこと などが考えられる。
【０００５】
第１の問題点は、最近急速に整備されつつあるインターネットのWeb端末クライアントとWWWサーバ間のHTTPプロトコルによるCSS構成を用いることにより解決される。即ち空間・属性データベースをWWWサーバを介してネットワークに供給するように構成し、これにモザイクやネットスケープ等のWWWブラウザを載せたクライアント端末により表示するような構成をとることにより、公衆回線を介したターミナル端末にまで地図/図面情報をCSS構成で提供することが可能となる。即ち中継用のクライアントを不要とする。
【０００６】
ところが第２の問題に対しては今のところ決定的な解決策を見いだすことができない。その妥協策として次のようなデータベースの多重化方式が考えられる。即ち、高速のデータ転送が可能で高精細な表示装置を有するクライアント端末のためには、その条件に適合するように詳細で転送単位容量を大きくした専用のデータベースを用意し、データ転送が低速で低い解像度の表示装置を有するターミナル端末のためには、実際の内容からプライオリティーの低い情報を省略しエッセンスを強調するようなメディア処理を施し、転送容量を小さくした専用のデータベースをそれぞれ別に用意する方式が考えられる。
【０００７】
【発明が解決しようとする課題】
このような妥協策では、クライアント端末やターミナル端末が備えるデータ転送量と表示装置の解像度に対応して、情報提供を受けるデータベースの内容をユーザによって指定させ切り換える必要あった。このような場合、情報提供を受ける端末の種類が増加する場合には、同一の内容を持つデータベースを多重に蓄積することによるデータ容量の増加の問題が発生するほか、そのバージョン管理及びユーザ選択を行うための煩雑さの問題等が発生する。一方、提供情報が地図/図面情報のように図形や画像などのマルチメディアで構成される場合には、表示環境の変化に応じてユーザ側で自由にメディアの加工を施せないため、あらかじめ完成した表示様式となるようにメディアを加工してデータベースに格納する必要があった。本発明は、このような問題を解決するための情報提供方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記課題を克服するために、本発明では、まずデータベースサーバには単一の形態のデータベースを格納しておき、データベースの検索機能として、単に要求された内容に適合する情報を受動的に提供するだけではなく、クライアントの通信速度や表示解像度などの情報処理環境を示す端末属性を取得し、その内容に適合するようにデータベースの検索内容を実時間で加工しながら供給するような能動的な検索機構により、クライアントへの効果的な情報提供を可能とする方法を提供するものである。
【０００９】
情報提供を受ける端末の特性をユーザが意識することなく最適な形態でデータベースの内容を検索できるため、携帯型のPDAなど移動環境下での情報検索やグラフィックス専用端末での高精細３次元空間検索など変化の大きい検索要求に対しても、性能に適合した効率的な情報提供が可能となる外、データベースサーバにおけるデータベース管理も一元化されるため、データベースのメンテナンスも容易となる。
【００１０】
【発明の実施の形態】
以下、本発明の一実施例について説明する。図３は本発明による情報提供を行うためのシステム構成を示す図である。100は情報提供対象とするデータの管理を行うためのデータベースサーバ、150はユーザからの要求に応じて情報の検索・更新を実行するデータベースサーバプログラム、120は情報提供対象となるデータ群で、本実施例では、地図やCADデータを構成する空間・属性データベースとする。500はインターネッとを介して情報提供を行うためのインターフェースをなすWWW(World Wide Web)サーバ、510は要求された情報の存在アドレスを判定し、情報サービスの起動をかけるためのWWWサーバプログラム、520はWWWサーバで受け付けられた検索要求をデータベース管理システムへインタフェースするためのCGI(Common Gatteway Interface)プログラム。200はデータベースサーバとWWWサーバ間を結ぶ専用LANで、WWWサーバ内にデータべースを含ませる場合は不要となる。210は情報提供を広範囲に行うためのインターネットを成す公衆回線、350はインターネットを介して情報提供の要求を行うためのクライアント端末で、通常はパーソナルコンピュータやワークステーション等が充てられる。360はインターネットを介して情報をやり取りするためのWebブラウザプログラム、320は提供情報を表示するための表示装置で、通常はCRTや液晶ディスプレーなどが充てられる。400はPDA(Personal Digital Asistants)などの携帯端末で、無線通信などを介してインターネットと情報交換可能な端末、410はその情報を表示するための表示装置で、通常は電力消費量の少ない液晶ディスプレーが充てられる。
【００１１】
次に、本発明により構成される情報提供システムの全体の処理の流れについて、図１のブロック図に従って説明する。まずシステムの構成要素は、図３と同等に、100のデータベースサーバと500のWWWサーバ、及び350のWeb端末から構成される。このシステム構成におけるデータの流れは、次の通りである。まずWeb端末内360のWebブラウザプログラムによりユーザの要求する情報提供のための検索条件を明確にすると共に、ユーザが情報提供を受けるWeb端末の端末属性を取得する(ステップ351)。そしてこれらの検索要求条件をパラメータとして備えた検索要求をWWWサーバに向けて発行する(ステップ352) 。次にWWWサーバ内の510WWWサーバプログラム部では、検索要求を、511のアドレス解析部にて情報提供を受けるWWWサーバのアドレスへ移行することを要求しているのか又はCGIプログラムの起動を要求しているかの判定を行う。その結果CGIプログラムの起動要求を求めていることが分かった場合には、512のCGIプログラム起動部により起動をかけ、520のCGIプログラム部に実行制御を移行する。CGIプログラム部内521のSR-SQL検索要求部では、空間検索用構造化検索言語(SR-SQL)を得るための新たな構造化検索言語(SQL)を、データベースサーバに向け発行する。このSQLは、まず120の空間/属性データベース部内のSR-SQL格納テーブルに対して発行され、具体的な空間情報検索のためのSR-SQLテンプレートを151のWeb I/F関数を介して得る。次に152の端末種別判定部では、最初にWeb端末で取得された端末属性の値に基づき情報提供を行うWeb端末の種別を判定する。そして154のSR-SQL発行部では、SR-SQLテンプレートの内容に判定結果から得られるパラメータ値を代入することにより具体的な空間検索手続きSR-SQLを生成し、それを155の空間インデックス関数に与える。空間インデックス関数では、ORDBMSで管理されている空間/属性テーブルから検索条件に適合するデータを、空間インデックスを用いて高速に検索し、そのバイナリー形式の検索結果を、156〜158で示されるメディア処理用の関数(VRML生成関数、画像生成関数、要約生成関数等)に与え、各Web端末で表示処理に適合するデータ形式に変換する。この場合の関数の切り換えは、先に行われた端末種別判定結果に基づき、SQL文の中の適用関数名称の欄に書かれたパラメータ値に依存しており、特にユーザが意識する必要はない。そして最終的に得られた検索結果は、513のWWWサーバ内検索結果転送部を介して、353のWeb端末内の表示部へ表示される。また、検索結果を各 Web 端末で表示処理に適合するデータ形式に変換し端末へ送信する際、データベースに保持された情報のうち重要度の低い情報の送信を取りやめることも可能である。
【００１２】
この一連の処理の中で、Web I/F関数に対応する既存のものとしては文献１(「WWWデータベース連係システム構築法」1996年3月4日、日経BP社発刊、pp183〜187）に示されるようなWeb Data Bradeがある。このWeb Data BradeはWWWサーバとIllustra ORDBMS (Informix社のオブジェクト指向関係型データベース管理システム) とを連係させるためのインタフェースの役割をなすもので、WWWサーバからデータベースへの検索要求が出されると、データベースのアクセス手続きのテンプレートが格納されているテーブルアドレスを検索し、テンプレートを得るとともに、具体的なデータベース検索手順(SQL)を生成してデータベースから目標とする内容を検索し、その検索結果をHTMLとして合成した後、結果をWWWサーバに返すまでの一連の手続きを実行する。本発明におけるデータベースの検索手続きは、上記に示されたWeb I/F関数が主に扱っているHTMＬベースのインタフェースを拡張するもので、Web I/F関数の基本機能、即ち、Web Data Bradeで行なわれるようなデータベースへのアクセス手続きのテンプレートの検索と、具体的な検索手続きの生成、及びHTMLの合成機能等をそのまま使用している。本実施例では、データベースからの検索対象を通常の定型データではなく、地図や図面を構成する空間/属性情報であり、特にORDBMSにより一元管理されている図形データを検索対象とする点が異なる。従って上記Web I/F関数におけるデータベースへのアクセス手続きは、通常のSQLを拡張した空間検索用構造化言語(SR-SQL)であり、合成される検索結果は、ベクトルを記述するVRMLや画像を記述するGIFとなる。
【００１３】
上記までに説明した情報提供システムの処理の流れをより詳細に示すため、データベースサーバで行われる能動的な検索処理の部分に着目する。図４は、図１における各処理ステップの中で、ステップ521を開始点として、ステップ158に至るまでのORDBMSへのアクセス系を中心に、処理手続き部と入出力情報との関連をまとめたものである。以下各ステップで処理される内容の詳細について説明する。
【００１４】
最初に、ステップ521のSR-SQL検索要求部には、Web端末からWWWサーバとCGIを経由し、次の形式でユーザ要求が入力されると仮定する。検索条件としては( $place=新宿,$検索様式=円検索,$x=25,$y=50,$r=100 )、端末属性としては( $TID={x:1152,y:864} )がそれぞれ与えられるものと仮定する。この場合のTIDとしては、本実施例で用いる表示解像度の外に、グラフィックス特性や処理プロセッサの種類及び通信速度などの項目が考えられるが、説明を簡略化させるため、ここでは表示解像度だけで構成される場合について説明する。この521のSR-SQL検索要求部では、これらの検索条件と端末属性を引数として、170のSR-SQL格納テーブルを検索する。このSR-SQL格納テーブルの内容は図5に示すように、テーブル属性項目として検索様式とSR-SQLtemplateとを有し、特にSR-SQLtemplateカラムには、検索対象や条件を変数にしたSQL文が格納され、ORDBMSにて管理される。このとき、「検索様式」をキーとして対応する検索テンプレートを検索する。ここでは、検索様式は円検索であるので、円検索テンプレートSR-SQLが検索される。この検索結果の具体的な内容は次に示すように、
select $変換関数(tuple)
from $place
where Intersection ( Circle($x, $y, $r), tuple )
となり151のWeb I/F関数に渡される。今回の実施例では、ORDBMSとしてIllustraを用いる場合の説明を行うので、このWeb I/F関数はWeb Data Bradeとなる。
【００１５】
次にこのWeb Data Brade内の152の端末種別判定部では、171の端末属性テーブルを検索し、端末属性TIDをキーにして検索結果に処理を付加するための変換関数名を得る。この端末属性テーブルの内容は図6に示すように、テーブル属性項目として変換関数とTID{xmin,ymin,smax,ymax}とを有し、特にTIDカラムには、端末属性として与えられる表示部の解像度を示すパラメータの範囲を判定するためのスレッショルド値を備え、変換関数を得るためのキーとなる情報が格納され、ORDBMSにて管理される。本実施例では、TIDとしてx=1152,y=864が指定されているので、変換関数名はvrml-func()が得られることになる。又この変換関数名は、後段で説明する検索結果へのメディア変換処理を与える関数名称を示すもので、図4の156のVRML変換関数と157の画像生成関数、及び158の要約生成関数の３種類を想定する。但しこの検索結果へのメディア変換処理の数は、今回のように3種類に限定されるものではなく、必要に応じて任意の数を用意できるものとする。
【００１６】
次に153のSR-SQL生成部では、前段までに得られているSR-SQLのテンプレート(本実施例では、円検索用のテンプレート）と変換関数（本実施例では３次元空間生成用の関数vrml-func）を用いて、実際にデータベースへ検索要求として与えることが可能な空間検索用構造化言語(SR-SQL)を生成する。その生成されるSR-SQLの具体的な内容は次に示すように
select vrml-func(tuple)
from 新宿
where Intersection ( Circle(25, 50, 100), tuple )
となり、前段では変数であった$記号の部分が具体化される。更にこの生成されたSR-SQLは、154のSR-SQL発行部からデータベース検索要求として155の空間インデックス関数に与えられる。一般にこのような空間インデックス関数を用いる理由として、図形をなす座標値などの空間データを扱う場合には、広大な全体の空間データの中から必要な部分空間だけを高速に検索する必要があるためであり、通常の定型データの検索で用いられるB-Tree Index やHash Index などが使用できないことによる。その空間インデックス関数の例としては、 Illustraの場合Spatial Data Bradeが存在し、R-Tree Indexが用いられている。このR-Tree Index とは、データベースには図形をなす座標データそのものの外に各図形要素の外接長方形を格納しておき、検索位置が指定された場合にはその外接長方形と重畳関係にある図形要素だけを検索対象とすることにより、図形選択速度を高速化させるメカニズムである。更にこのSpatial Data Bradeには、この空間インデックスを利用した各種の図形検索機能が用意されている。例えば、ある位置を中心に一定の半径内に包含される図形要素を検索する円検索機能や、道路などの経路に添った一定の範囲に重畳関係をもつ図形要素を検索する経路検索機能などが存在する。ここでは、円検索機能を用いた例となっている。
【００１７】
次に空間インデックス関数からORDBMSに向けた検索要求が発行される。即ち円検索の要求からSpatial Data Brade を介して実際にORDBMSへ与えられるのは、172の属性情報テーブルと173の空間情報テーブルへの検索要求である。173の空間情報テーブルの内容は図７に示すように、テーブル属性項目として図形IDと２次元図形座標値配列とを有し、特に２次元図形座標値配列には、各図形要素をなす隣接した座標値列が(x,y)の配列として１つのカラムの中にバイナリー形式で格納され、図形IDをキーとして座標値列が検索可能となるようにORDBMSにて管理される。
【００１８】
一方172の属性情報テーブルの内容は図8に示すように、テーブル属性項目として、建物階数・世帯主名称・住所・図形ID等を備え、この中の図形IDを介して空間情報テーブルと連係関係がとれるように構成される。その連係関係の例として、空間情報テーブルから検索された図形IDを条件として属性テーブルを検索することにより、その図形の建物階数や世帯主名称を検索することができる。これより、155の空間インデックス関数(Spatial Data Brade)からORDBMSを介して173の空間情報テーブルと172の属性情報テーブルとが検索され、その結果は各変換関数のパラメータ値より156〜158に示されるメディア処理用の関数群（VRML生成関数、画像生成関数、要約生成関数）のどれか１つに与えられる。本実施例では、変換関数のパラメータはrml-funcとなっているので、156のVRML生成関数に2次元図形座標値列と建物階数とが与えられることになる。
【００１９】
次に156のVRML生成関数の処理内容の詳細について説明する。この関数で処理されるのは、173の空間情報テーブルから供給される２次元の図形データ（特にここでは建物外形とする）をベースにして、172の属性情報テーブルから供給される建物階数から推定した建物高さデータを用いて立ちあげ、仮想的な３次元の面図形を生成しこれをVRMLコード変換する内容を持つ。この処理の具体的な流れを、図9のPAD図を用いて説明する。まずステップ901では、160のORDBMSより供給される空間情報テーブルのN点構成の閉図形の座標値列｛x1,y1, ... , xn,yn｝を得る。次にステップ902では、同様に属性情報テーブルの建物階数情報h を取得する。この段階で得られた２次元の図形データのx,y座標にz座標をz=0として加え、図10のステップ903に示されるようなz=0面上の頂点を設定する。次にこれらの３次元化座標値列のコピーを生成し、建物階数から推定した建物高さデータHを、コピーした３次元化座標値列のZ座標に与える(図9,10図のStep904)。その結果コピーした３次元化座標値列は、z=H面上の空間に浮遊した座標値列となる。そこで、z=0面上の座標値列とz=H面上の座標値列との間で定義される壁面ポリゴンを生成すると共に、VRMLのオブジェクトの識別子となるindexも出力する。この壁面ポリゴンの生成処理は、座標点列数のN回だけ繰り返される(図9,10のStep905)。最後に、壁面の張られた３次元化図形の天井面にポリゴンを生成し、VRMLのオブジェクト識別子となるindex を出力する(図9,10のStep906)。
【００２０】
一方158の要約生成関数の処理内容としては、173の空間情報テーブルに格納されている図形情報の中から主要な情報だけを抽出して、情報提供先の携帯端末の表示装置に最適となるように図形データを加工することにある。この処理内容の一例としては、特開平4-30265号「ダイジェストの作成方法」に示されているような方法が考えられる。即ちその公知例に記述されている内容として、空間・属性データベースには重要な特性を持った要素毎に空間情報を格納し、要約の中心となる位置の情報は詳しく、それ以外の部分は背景情報として間引きを行ない、それらを合成して出力する方法が述べられている。本発明では、その要約を行なう方法に関する規定はなく、各応用に向けた各種の要約方法が適用可能とする。 又157の画像生成関数は、120の空間・属性データベースに格納されているバイナリ形式のデータ、特に図形がベクトル形式であるものを等価な画像データに変換して加工出力する内容を持つ。この処理内容に関しても、既に多くの公知例が存在する。例えば、米国Lighithouse Design社の図形編集ツールであるDIAGRAM!2には、ベクトル形式で記述された図形集合を1枚の等価な画像データに変換する機能を有している。従ってこの関数機能に関しても、実現方法に関する規定はない。
【００２１】
【発明の効果】
本発明によれば、データベースに格納されている単一種類の情報から、高精細で高速の表示特性を持つグラフィック端末や低解像度で処理能力の低いPDAなど各種のWeb端末に対して、それぞれ最適な表示様式となるように提供情報の加工を動的に行いWeb端末の持つ特性に適合させることができるので、情報提供のためのデータベース構築や管理コストを大幅に低減させることが可能となる。
【図面の簡単な説明】
【図１】本発明による情報提供方式による処理の流れを示す説明図である。
【図２】従来の専用CSS構成による地図/図面情報システムのブロック構成図。
【図３】本発明による地図/図面情報の提供システムのブロック構成図。
【図４】本発明による情報提供方式の核となる処理の流れを示すブロック図。
【図５】空間検索用の構造化検索言語のテンプレートを格納するテーブルの構成図。
【図６】端末属性に基づき変換関数を選択するための端末属性テーブルの構成図。
【図７】地図/図面情報を提供するための空間情報テーブルの構成図。
【図８】地図/図面情報を提供するための属性情報テーブルの構成図。
【図９】 2次元図形情報と高さ属性から3次元空間とVRMLを生成する処理の流れを示すPAD図。
【図１０】 2次元図形情報と高さ属性から3次元空間とVRMLを生成する処理の原理を示す図。
【符号の説明】
100 データベースサーバ、110 応用処理専用DBサーバプログラム 、120 空間・属性データベース、
150 データベースサーバプログラム、151 データベースとCGIを連係するWeb I/F関数、152 端末の種別の判定を行なう部分、153 空間情報検索用構造化検索言語の生成部、154 空間情報検索用構造化検索言語の発行部、155 空間インデックスに基づく高速検索を行なう部分、156 3次元空間とVRMLを生成する部分、157 ベクトルデータを画像に変換する部分、158 データベースの検索結果から要約を生成する部分、170 空間検索用構造化検索言語のテンプレートを格納するテーブル、171 端末属性からメディア加工用適用関数を検索するためのテーブル、172 属性情報を格納するテーブル、173 空間情報を格納するテーブル、
200 専用LAN、210 公衆回線、
300 クライアント端末、310 応用処理専用クライアントプログラム、320 表示装置、
350 クライアント用Web端末、360 Webブラウザ
400 携帯端末、410 表示装置、
500 WWWサーバ、510 WWWサーバプログラム、520 CGIプログラム、
901-906 2次元の図形データと階数データとから3次元空間とVRMLを生成するまでの処理の流れを構成するプログラムステップ

Claims (5)

1. 地図情報の提供を受ける端末には該端末のグラフィックス特性もしくは処理プロセッサの種類を示す端末属性を備え、
   地図情報の提供を行うデータベースサーバは上記端末から検索条件を取得する手段と、
   データベースに格納したベクトルデータを含む管理データの中から上記検索条件に合致したデータを検索する手段と、
   上記端末属性を取得する手段と、
   上記データから３次元の地図図形を生成する手段と、上記データから要約地図を生成する手段と、上記データを地図画像データに変換する手段と、を有する加工手段と、
   上記端末属性と上記加工手段の少なくとも何れかとを対応付ける手段と、を備え、
   上記データベースサーバは、上記検索条件を取得する手段を用いて上記検索条件を取得し、上記検索する手段により上記管理データの中から上記検索条件に合致したデータを検索した後、上記端末属性を取得する手段により取得した上記グラフィックス特性もしくは処理プロセッサの種類を示す端末属性を条件として上記対応付ける手段で該データの加工手段を求め、上記データを上記加工手段により上記端末属性に対応する上記３次元の地図図形、上記要約地図、及び上記地図画像データの少なくとも何れかであるデータに加工処理して端末へ供給することを特徴とする情報提供方法。
2. 請求項１記載の３次元の地図図形を生成する手段は、２次元の上記ベクトルデータと高さを示す属性データとから、３次元の空間データを生成することを特徴とする情報提供方法。
3. 請求項１記載の要約地図を生成する手段は、上記データベースに保持された情報のうち重要度の低い情報の送信を取りやめることを特徴とする情報提供方法。
4. 請求項１乃至３の何れかに記載の端末属性として、さらに縦横の表示解像度で代表される表示精度を含む属性値の組み合わせ又は通信速度を含むことを特徴とする情報提供方法。
5. 請求項１乃至４の何れかに記載の検索条件として、検索範囲を示すための幾何的な形状を指定することを特徴とする情報提供方法。

Images