JP2002229993A - 通信ネットワークを通じて地図データを配信するシステム及び方法 - Google Patents

Abstract

(57)【要約】 【課題】 ユーザからの１回の地図要求に応えて配信さ
れる地図データのデータサイズをいたずらに増大させる
ことなしに、その配信された地図データの利便性を向上
させる。 【解決手段】 サーバシステム１０は、携帯電話などの
クライアント３０から、ある地点の地図データを要求さ
れると、地図データベース１２から要求された地点を中
心とする所定の広さ範囲のターゲット地域のベクトル地
図データを読み出し、このベクトル地図データの座標値
の精度を落としてデータサイズを縮小した上で、そのベ
クトル地図データをクライアント３０に送る。クライア
ント３０は、受信したベクトル地図データからラスタ地
図イメージを描画して表示する。配信される地図の地域
的広さ範囲は、地図の種類や、ユーザの希望や、通信速
度などに応じて、狭すぎず広すぎもしない適度な広さ範
囲、例えば、市街地図は４００ｍ×４００ｍ程度、道路
地図は１．５ｋｍ×１．５ｋｍ程度に設定される。

Description

【発明の詳細な説明】

【０００１】

【発明が属する技術分野】インターネットなどの通信ネ
ットワークを通じて、携帯電話、PDA又はパーソナルコ
ンピュータなどの画像表示機能をもったクライアントに
地図データを配信して地図を表示させるためのシステム
及び方法に関する。

【０００２】

【従来の技術】例えば携帯電話のためのインターネット
を利用したサービスの一つとして、サーバから携帯電話
へ地図データを配信するサービスが広く行われている。
地図を配信するサーバは、ベクトルイメージデータ形式
の地図データ（ベクトル地図データ）を蓄積しており、
携帯電話から場所の指定を受けると、その指定場所を中
心とする所定距離範囲の地域について、ベクトル地図デ
ータに基づいてラスタイメージデータ形式の地図データ
（ラスタ地図データ）を描画し、このラスタ地図データ
を携帯電話に送信する。似たようなサービスは、携帯電
話だけでなく、インターネットにアクセスできる様々な
端末に対して行われている。

【０００３】

【発明が解決しようとする課題】このような従来の地図
配信サービスの一つの欠点は、１回の地図要求に対して
配信される地図が、ユーザにとって、地域的な広さ範囲
において狭すぎるか、または、表示の詳細さにおいて粗
すぎる点である。

【０００４】例えば、携帯電話の場合、現状では、個々
の建物や街路の形状や名称が詳細に表わされた市街地図
をサーバに要求した場合、サーバから配信される詳細市
街地図のカバーする地域的な範囲はたかだか２００ｍ×
２００ｍ程度の狭い地域である。この程度に狭い地域の
地図ではユーザには使いずらい。一方、より広い地域の
地図を要求すると、配信されてくる地図は、例えば道路
しか描かれてないような粗い内容の地図になり、これで
は街を歩く用途には適さない。

【０００５】一方、ユーザが指定場所を適当にずらして
何度も市街地図の要求を発すれば、その都度に位置のず
れた市街地図が配信されてくる。しかし、多数回のキー
操作が煩わしく、トータルの待ち時間も長くなり、通信
料金も増大してしまう。さらに、地図要求を発する都度
に、前に表示されていた地図から新たに要求した地図へ
と画面表示が一気に不連続に切り替わるから、ユーザ
は、広い地域全体の様子を把握することが難しい。

【０００６】これら問題の主たる原因は、端末のもつ通
信速度やメモリ容量や表示能力等の制限から、１回の通
信要求に対して配信されるデータのサイズがかなり小さ
いこと、及び配信される地図データがラスタイメージデ
ータであることにある。

【０００７】類似の問題は、携帯電話への地図配信サー
ビスに限らす、他の種類のクライアントへの地図配信サ
ービスでも、多かれ少なかれ存在する。

【０００８】したがって、本発明の目的は、通信ネット
ワークを通じて地図データを配信するサービスにおい
て、ユーザからの１回の地図要求に応えて配信される地
図データのデータサイズをいたずらに増大させることな
しに、その配信された地図データの利便性を向上させる
ことにある。

【０００９】

【課題を解決するための手段】本発明の第1の観点に従
う通信ネットワークを通じて地図データを配信するため
の方法は、遠隔のクライアントから地図要求を受ける地
図要求受信ステップと、その地図要求に応答して、オリ
ジナルのベクトル地図データに基づいて、クライアント
へ配信されるべきターゲット地域のベクトル地図データ
を準備する地図データ準備ステップと、準備されたベク
トル地図データを通信ネットワークを通じて前記クライ
アントへ送信する地図データ配信ステップとを備える。
上記の地図データ準備ステップでは、配信されるべきベ
クトル地図データに含まれる座標値のデータサイズを、
地図データベースから取得したオリジナルのベクトル地
図データのもつオリジナルの座標値のデータサイズより
縮小することにより、配信されるべきベクトル地図デー
タのデータサイズを、対応するオリジナルのベクトル地
図データのデータサイズより縮小するステップが含まれ
ている。

【００１０】この方法によれば、縮小されたデータサイ
ズのベクトル地図データがクライアントに配信される。
よって、配信された地図データがカバーするターゲット
地域の広さ範囲は、従来よりも広く設定することが可能
である。また、クライアントはベクトル地図データを受
けるので、表示した地図の拡大縮小やスクロールが可能
になる。その結果、地図の利便性が向上する。

【００１１】好適な実施形態では、配信されるベクトル
地図データの座標値は緯度方向及び経度方向それぞれ1
バイトにしている。さらに、ターゲット地域を複数のブ
ロックに分割して、各ブロックごとに座標系を設定する
ことで、一層のデータサイズの削減を図っている。

【００１２】好適な実施形態では、ターゲット地域の広
さ範囲は、クライアントから要求された地図データの地
図レベルに応じて定められている。例えば、要求された
地図レベルが、個々の建物の形状まで表した市街地図で
ある場合、ターゲット地域の広さ範囲がほぼ４００ｍ×
４００ｍ以上である。また、要求された地図データの地
図レベルが、道路の走る経路は表すが個々の建物の形状
までは表していない道路地図であるとき、ターゲット地
域の広さ範囲はほぼ１．５ｋｍ×１．５ｋｍ以上であ
る。この程度の広さ範囲のターゲット地域をカバーした
地図であれば、ユーザは利用し易い。

【００１３】クライアントには様々な種類の端末が採用
し得るが、好適な実施形態では携帯電話である。携帯電
話の場合、他の端末に比較して、通信速度が遅く、メモ
リ容量が小さく、また、ディスプレイ画面も狭いので、
本発明の利点が生かせる。

【００１４】好適な実施形態では、サーバシステムから
クライアントに、ベクトル地図データからラスタ地図デ
ータを描画するための地図アプリケーションをダウンロ
ードするステップも設けられる。

【００１５】本発明の第２の観点に従う通信ネットワー
クを通じて地図データを配信するための方法は、遠隔の
クライアントから地図要求を受ける地図要求受信ステッ
プと、配信されるべき地図データの地図レベルに応じ
て、ターゲット地域の広さ範囲を決定する地域的広さ範
囲決定ステップと、クライアントからの地図要求に応答
して、前記地図レベルに応じて決定された広さ範囲を有
したターゲット地域についてのベクトル地図データを準
備する地図データ準備ステップと、準備されたベクトル
地図データを通信ネットワークを通じて前記クライアン
トへ送信する地図データ配信ステップとを備える。

【００１６】この方法によれば、クライアントから要求
された地図データの地図レベル（地図の縮尺や用途によ
る種別、例えば、大縮尺の市街地図、中縮尺の道路地図
など）に応じてターゲット地域の広さ範囲が決定され、
その広さ範囲をもったターゲット地域のベクトル地図デ
ータがクライアントへ配信される。ターゲット地域の広
さ範囲を、地図レベルに応じて狭すぎず又は広すぎない
よう適切に設定することで、使いやすい地図データをク
ライアントに提供できる。例えば、好適な実施形態で
は、要求された地図レベルが市街地図の場合、ターゲッ
ト地域の広さ範囲は４００ｍ×４００ｍ程度かそれ以
上、また、要求された地図データの地図レベルが道路地
図の場合、ターゲット地域の広さ範囲は１．５ｋｍ×
１．５ｋｍ程度かそれ以上である。クライアントに送ら
れるターゲット地域の地図データはベクトル地図データ
であるから、クライアントは、表示した地図を、その適
度な広さ範囲をもったターゲット地域内でスクロールし
たり拡大縮小したりすることができ、利便性が高い。

【００１７】本発明の第３の観点に従う通信ネットワー
クを通じて地図データを配信するための方法は、遠隔の
クライアントから地図要求を受ける地図要求受信ステッ
プと、ターゲット地域の広さ範囲を可変的に決定する地
域的広さ範囲決定ステップと、クライアントからの地図
要求に応答して、一つの地図レベルをもつベクトル地図
データであって、前記可変的に定められた広さ範囲を有
したターゲット地域のベクトル地図データを準備する地
図データ準備ステップと、準備されたベクトル地図デー
タを通信ネットワークを通じてクライアントへ送信する
地図データ配信ステップとを備える。

【００１８】この方法によれば、或るターゲット地域に
ついて、一つの地図レベルの地図データを配信する場合
に、そのターゲット地域の広さ範囲を可変的に設定でき
る。よって、例えば、４００ｍ×４００ｍ、２００ｍ×
８００ｍ、８００×４００ｍなどの異なる広さ範囲をも
つターゲット地域のいずれについても、例えば大縮尺の
詳細な市街地図のような、同じ地図レベルのベクトル地
図データを配信することができる。広さ範囲は、ユーザ
が自分の目的などに応じて可変的に決定できるようにし
ても良いし、サーバシステムが個々の地域の事情などに
応じて可変的に決定できるようにしてもよい。例えば、
鉄道駅名を中心とする市街地図が要求された場合、その
駅の駅周辺市街が南北に細長く伸びていれば、それに合
わせた南北に細長い地域的範囲を設定し、東西南北にほ
ぼ均等に広がっていれば、それに合わせた正方形の地域
的範囲を設定するというようなことができる。いずれの
地域的範囲を設定しても、同じ地図レベルの地図が提供
され、しかもそれはベクトルデータであるが故に、表示
地図のスクロールや拡大縮小が可能であるから、利便性
が高い。

【００１９】

【発明の実施の形態】図１は、本発明の一実施形態にか
かる地図データ配信システムの全体構成を示す。

【００２０】図１に示すように、地図配信サービスを行
うサーバシステム１０に、インターネットや移動電話ネ
ットワークなどの通信ネットワーク２０を介して、クラ
イアント３０が通信可能になっている。この実施形態の
説明では、クライアント３０が携帯電話である場合を例
にとるが、クライアント３０が他の種類の装置、例えば
パーソナルコンピュータ、PDA、ゲームコンピュータ、
テレビジョンセットなどであってもよいことは言うまで
もない。１つのクライアント３０しか図示してないが、
通常は多数のクライアントが存在することも言うまでも
ない。

【００２１】サーバシステム１０は、地図ソースサーバ
１１、地名・緯度経度変換サーバ１３、地名検索サーバ
１４および地図配信サーバ１５を有する。これらのサー
バ１１、１３〜１５は、同じ一台のコンピュータマシン
に集中して存在していてもよいし、複数台のコンピュー
タマシンに分散して存在していてもよい。

【００２２】地図ソースサーバ１１は、地図データベー
ス１２を有し、この地図データベース１２には、例えば
日本全国のような配信可能な全地域をカバーする地図デ
ータが管理されている。ここで管理されている地図デー
タは、ベクトルイメージデータ形式（地名などのテキス
ト形のデータも含んでいる）のベクトル地図データであ
る。

【００２３】地名・緯度経度変換サーバ１３は、地名の
指定を受け取って、その地名を、その地名をもつ場所の
代表地点の緯度経度情報に変換するものである。例え
ば、駅名、施設名、市町村名または番地などを、その
駅、施設、市町村、番地区画の代表地点の緯度経度情報
に変換する。

【００２４】地名検索サーバ１４は、例えばWWW（ワー
ルドワイドウェブ）サーバであり、クライアント３０と
交信しながらインタラクティブな方法で、ユーザの所望
する地名を検索してクライアント３０に返すものであ
る。

【００２５】地図配信サーバ１５は、例えばWWWサーバ
であり、ユーザの所望する地名の場所を中心とした地域
（以下、ターゲット地域という）の地図データを地図ソ
ースサーバ１１から取得して、クライアント３０に送信
するものである。この地図配信サーバ１５からクライア
ント３０へ送られる地図データは、ベクトルイメージデ
ータ形式のベクトル地図データであり、地図ソースサー
バ１１が管理しているベクトル地図データを若干簡略化
してデータサイズを縮小したものである。このベクトル
地図データから地図のラスタイメージ（ラスタ地図デー
タ）を描画する処理は、クライアント３０側で行われ
る。

【００２６】地図配信サーバ１５は、地名検索サーバ１
４で検索された地名などをユーザ別に記憶しておくため
のユーザデータベース１６を有する。また、地図配信サ
ーバ１５は、クライアント３０にダウンロードされるべ
き地図アプリケーションプログラム１７を有しており、
この地図アプリケーション１７は、例えばＪＡＶＡ（登
録商標）アプリケーションであり、クライアント３０に
おいて、ベクトル地図データからラスタ地図データを描
画して画面に表示する処理や、表示した地図の拡大／縮
小やスクロールを行うための処理などを行う。

【００２７】クライアント３０には、あらかじめウェブ
ブラウザ３１がインストールされており、このウェブブ
ラウザ３１は、地名検索サーバ１４にアクセスして地名
の検索を行ったり、地図配信サーバ１５にアクセスして
地図アプリケーション１７をダウンロードしたりするこ
とができる。

【００２８】図２は、地図配信サービスが行われるとき
のシステム全体の動作シーケンスを示す。

【００２９】図２に示すように、クライアント３０のウ
ェブブラウザが、地名検索サーバ１４にアクセスして地
名検索画面４１を受信して開き、その地名検索画面４１
にユーザ入力された条件を地名検索サーバ１４に送っ
て、該当する地名を検索してもらう（ステップ４２）。
検索された地名は地名検索画面４１に表示される。

【００３０】その地名検索画面４１上でユーザが所望の
地名を確定させると、地名検索サーバ１４が、その地名
を地名・緯度経度変換サーバ１３に送信する（ステップ
４３）。地名・緯度経度サーバ１３は、その地名を、そ
れに該当する場所の代表地点の緯度経度情報に変換し、
その緯度経度情報を地名検索サーバ１４に返す（ステッ
プ４４）。地名検索サーバ１４は、クライアント３０の
識別情報(クライアントID)とユーザ所望の地名ととも
に、その地名の緯度経度情報を地図配信サーバ１５に送
る（ステップ４５）。地図配信サーバ１５は、そのクラ
イアントID、地名および緯度経度情報を、ユーザデータ
ベース１６に登録する（ステップ４６）。

【００３１】一方、クライアント３０のウェブブラウザ
は、地名検索が終わると、地図アプリケーションをダウ
ンロードするための画面４７を表示し、その画面４７上
でユーザが地図アプリケーションのダウンロードを要求
する操作を行うと、ウェブブラウザは、地図アプリケー
ションのダウンロード要求を地図配信サーバ１５に送信
する（ステップ４８）。地図配信サーバ１５は、その要
求に応答して、地図アプリケーション１７をクライアン
ト３０へ送る（ステップ４９）。

【００３２】ダウンロードされた地図アプリケーション
は、クライアント３０に自動的にインストールされて起
動され、地図レベルを選択するための画面５０を開く。
ここで、地図レベルとは、地図の縮尺又は用途などによ
る地図の種類のことであり、例えば、１万分の１市街地
図（個々の建物の形状や名称、個々の街路の形状や名称
などを詳細に表した市街地図であり、歩行者向け、また
はピンポイントで場所を特定する用途向け）、２万５千
分の１地形図（道路や主要施設名称などが表示されたい
わゆる道路地図であり、自動車や自転車など搭乗者向
け）などがある。この地図レベル選択画面５０上でユー
ザが所望の地図レベルを選択すると、地図アプリケーシ
ョンは、地図データの要求を地図配信サーバ１５に送る
（ステップ５１）。この地図データ要求には、パラメー
タとして、クライアントID、選択された地図レベル、そ
の地図レベルに応じた地図の地域的広さ範囲などが付
く。ここで、地図の地域的広さ範囲とは、１回の地図デ
ータ要求に対して配信される地図データがカバーすべき
ターゲット地域の距離寸法、例えば緯度方向の長さLと
経度方向の幅Wである。配信されるべき地図の地域的広
さ範囲は、それがユーザの選択した地図レベルに応じた
適度な広さ範囲になるように、地図アプリケーションが
決定する。例えば、選択された地図レベルが１万分の１
市街地図の場合には、地図の地域的広さ範囲L×Wは例え
ば４００ｍ×４００ｍであり、選択された地図レベルが
２万５千分の１地形図の場合には、地図の地域的広さ範
囲L×Wは例えば１．５ｋｍ×１．５ｋｍである。

【００３３】地図配信サーバ１５は、クライアント３０
から上記地図データ要求を受けると、それに付いている
クライアントIDを頼りに、ユーザデータベース１６か
ら、ユーザ所望の地名と緯度経度情報を読み出す（ステ
ップ５２）。そして、地図配信サーバ１５は、地図ソー
スサーバ１１に対して地図データの要求を送る（ステッ
プ５３）。ここで、この地図データ要求には、パラメー
タとして、緯度経度情報、ユーザ選択された地図レベ
ル、その地図レベルに応じた地図の地域的広さ範囲など
が含まれる。

【００３４】地図ソースサーバ１１は、地図配信サーバ
１５から上記地図データ要求を受けると、要求された緯
度経度を中心にした、要求された地域的広さ範囲をもつ
ターゲット地域について、要求された地図レベルのベク
トル地図データを地図データベース１２から読み込み、
そのベクトル地図データを地図配信サーバ１５に送る
（ステップ５４）。地図配信サーバ１５は、地図ソース
サーバ１１から受け取った上記ターゲット地域のベクト
ル地図データをクライアント３０の地図アプリケーショ
ンに送る（ステップ５５）。ここで、地図配信サーバ１
５からクライアント３０に送られるベクトル地図データ
は、地図ソースサーバ１１の地図データベース１２で管
理されているオリジナルのベクトル地図データから一部
データが間引かれて、データサイズが縮小されている。
このデータサイズを縮小する処理は、地図配信サーバ１
５又は地図ソースサーバ１１で行われる。

【００３５】クライアント３０の地図アプリケーション
は、地図配信サーバ１５から受信したベクトル地図デー
タからラスタ地図データ（ラスタ地図イメージ）を描画
して地図表示画面５６に表示する。地図アプリケーショ
ンは、さらに、受信したベクトル地図データの中に含ま
れている、役所、駅、ガソリンスタンド、コンビニエン
スストア、景勝地などの各種地理物の種別番号に基づい
て、それら各種地理物の図象記号のラスタイメージデー
タ（例えば、GIF形式）を地図配信サーバ１５に要求し
て受信し(ステップ５７、５８)、その図象記号も地図表
示画面５６に表示された地図上の該当位置に表示する。
地図アプリケーションは、受信したベクトル地図データ
のターゲット地域の範囲内であれば、画面表示された地
図のスクロールや拡大縮小をユーザ要求に応じて自由に
行える。

【００３６】以上のシーケンスの中で、ステップ４８、
４９の地図アプリケーションのダウンロードは、クライ
アント３０の地図アプリケーションが既にインストール
されている場合には、省略することができる。

【００３７】図３は、上述のシーケンス中の特に、クラ
イアント３０の地図アプリケーションの動作をより詳細
に示している。図４は、上述のシーケンス中の特に、地
図ソースサーバ１１と地図配信サーバ１５の地図データ
を送信する動作を詳細に示している。

【００３８】図３に示すように、地図アプリケーション
は、図２に示した地図レベル選択画面５０上で地図レベ
ルがユーザ選択されると（ステップ６１）、その地図レ
ベルに応じて、配信される地図データがカバーすべき地
域的広さ範囲（緯度方向長さL×経度方向幅W）を決定
し、その地図レベルのその地域的広さ範囲をもつ地図デ
ータを地図配信サーバ１５に要求する（ステップ６
２）。

【００３９】ここで、地図の地域的広さ範囲L×Wは、ユ
ーザ選択された地図レベルの地図の用途から判断して、
ユーザにとって狭すぎず、かつ、通信待ち時間や通信料
金の点から広すぎない、適度な広さ範囲に決定される。
例えば、１万分の１市街地図は、前述したように、個々
の建物や街路などの地物の形状や名称が詳細に表された
市街地図であって、歩行者向けやピンポイントで場所を
特定する用途向けであるが、その地域的広さ範囲L×W
は、例えば４００ｍ×４００ｍである。通常、４００ｍ
×４００ｍ以上の広さ範囲の地域をカバーした詳細市街
地図であれば、歩行者の利用やピンポイントでの場所指
定などの用途に、狭すぎることはない。しかも、この程
度の広さ範囲であれば、駅前などの商業エリアの主要部
をほぼ収めることができる。また、例えば、２万５千分
の１地形図は、前述したように、道路や主要施設名称な
どが表示されたいわゆる道路地図であり、自動車や自転
車などの搭乗者向けであるが、その地域的広さ範囲は例
えば１．５ｋｍ×１．５ｋｍである。通常、１．５ｋｍ
×１．５ｋｍ以上の広さ範囲をカバーする道路地図な
ら、自動車や自転車などの搭乗者の利用に耐えられる。

【００４０】地図アプリケーションから上記のような地
図レベルと地図の地域的広さ範囲L×Wをもった地図デー
タが要求されると、図４のステップ７１に示すように、
地図配信サーバ１５が、ユーザデータベース１６から、
要求された地名の緯度経度情報を読み出し、その緯度経
度情報の地点を中心とする、要求された地域的広さ範囲
L×Wをもつターゲット地域について、要求された地図レ
ベルのベクトル地図データを、地図ソースサーバ１１に
要求し、そして、地図ソースサーバ１１は、その要求さ
れたターゲット地域のベクトル地図データを、地図デー
タベース１２から取得する。

【００４１】ここで、地図データベース１２内には、図
５に示すように、いくつかの地図レベルの地図データ８
１、８２、８３、…がある。例えば、前述した１万分の
１市街地図のデータ８１、前述した２万５千分の１地形
図のデータ８２、さらに、２０万分の１地勢図のデータ
８３、より小縮尺の地方図のデータ（図示省略）、より
小縮尺の日本全国図のデータ（図示省略）などである。
各地図レベルの地図データは、図中１万分の１市街図に
ついて例示しているように、複数のレイヤ８４、８４、
…に分けられている。ここで、レイヤ８４，８４、…と
は、地図を構成する地理物の種類別の地図データであ
り、例えば、道路種類別の道路枠線図のレイヤ、建造物
種類別の建造物多角形のレイヤ、地形種類別の地形線図
レイヤ、名称種類別の名称テキストのレイヤなどであ
る。

【００４２】ステップ７１で、要求された地図レベルの
地図データを地図データベース１２から取得するとき、
その要求された地図レベルの全てのレイヤの地図データ
を取得する。

【００４３】再び図４を参照して、次にステップ７２へ
進む。ここでは、地図ソースサーバ１１又は地図配信サ
ーバ１５が、地図データベース１２から取得した地図デ
ータを、レイヤ毎に、複数の小面積ブロックに分割し、
そして、各ブロック内のベクトル地図データの座標値
（X,Y）のデータを、より座標精度の低いデータサイズ
の小さい座標値データに変換する。例えば、オリジナル
の座標値は、緯度方向座標Xおよび経度方向座標Yのいず
れも、複数バイトデータで表されているが、これを、緯
度方向座標Xおよび経度方向座標Yのいずれについても１
バイトデータに変換する。これにより、ベクトル地図デ
ータのデータサイズは大幅に縮小される。

【００４４】図６は、このステップ７２の処理によって
データサイズ縮小された地図データのブロックと座標値
（X,Y）を説明するための図である。

【００４５】図６に示す地図データは、１万分の１市街
地図の例であり、４００ｍ×４００ｍの広さ範囲をもつ
ターゲット地域８０をカバーしている。このターゲット
地域８０内の中心点８１は、ユーザ所望の地名に対応す
る緯度経度情報の地点に当たる。また、右上端の地点８
２は、このターゲット地域８０を特定するための基準地
点として使われる。このターゲット地域８０は、４００
ｍ×４００ｍの広さ範囲を持つが、それが３×３等分割
されて、９つの小面積ブロック９０、９０、…に区分さ
れる。よって、個々のブロック９０の広さ範囲は約１３
３ｍ×１３３ｍである。それらのブロック９０、９０、
…には、＃１〜＃９のブロック番号がそれぞれ割り当て
られている。何番のブロックが４００ｍ×４００ｍのタ
ーゲット地域内のどの場所に位置するかは規則で決まっ
ている。例えば、図示のように、右上端ブロックのブロ
ック番号が＃１であり、そこから、X方向へ次にY方向へ
とラスタスキャンする順序でブロック番号が順次に割り
当てられる。

【００４６】個々のブロック９０内では、他のブロック
から独立した緯度・経度方向のXY座標系があり、緯度方
向座標値Xおよび経度方向座標値Yのいずれもが１バイト
データで表され、よって、XおよびYの各方向について０
から２５５までの２５６個の座標値がある。よって、１
点の座標（X,Y）の位置的精度は約１３３ｍ÷２５６＝
約５０ｃｍである。このように座標の精度を低下させて
も、この約５０ｃｍという精度は、人が市街地図を利用
する際に十分過ぎるほどに高い精度である。

【００４７】再び図４を参照して、次にステップ７３に
進む。ここでは、地図ソースサーバ１１又は地図配信サ
ーバ１５が、上記のステップ７２でデータサイズを縮小
したベクトル地図データに所定のデータヘッダ部をつ
け、所定フォーマットをもつ地図データのパック仕立
て、そして、地図配信サーバ１５がその地図データパッ
クにクライアント３０の地図アプリケーションに送信す
る。

【００４８】図７は、その地図データパックの構成を示
す。

【００４９】図７に示すように、地図データパック１０
０には、このパック全体のデータサイズの記述と、デー
タヘッダ部１０１と、その地図データを構成する全レイ
ヤ１〜ｎの各レイヤ別のレイヤデータ１０２、１０２、
…とが含まれる。データヘッダ部１０１には、抽出右上
X座標、抽出右上Y座標、レイヤ個数ｎ、X方向ブロック
数、Y方向ブロック数が記述される。ここで、抽出右上X
座標及び抽出右上Y座標は、図６に例示した、この地図
データがカバーするターゲット地域８０の右上端地点
（基準地点）８２の座標値である。また、レイヤ個数ｎ
は、このパック１００に含まれる地図データのレイヤ１
〜ｎの個数である。また、X方向ブロック数及びY方向ブ
ロック数は、図６に例示した、この地図データがカバー
するターゲット地域８０のX方向のブロック数とY方向の
ブロック数である（図６の例では、いずれも３個）。

【００５０】各レイヤのレイヤデータ１０２には、その
レイヤのレイヤ番号、ブロック数ｍ、及びその地図デー
タがカバーするターゲット地域に含まれる全てのブロッ
ク１〜ｍの各ブロック別のブロックデータ１０３、１０
３、…が含まれている。ここで、レイヤ番号はそのレイ
ヤの固有の番号であり、何番のレイヤには何の種類のデ
ータが格納されているかは予め決まっている。また、ブ
ロック数ｍは、図６に例示したように、その地図データ
がカバーするターゲット地域８０に含まれるブロック９
０の個数であり、図６の例では９個である。

【００５１】各ブロックのブロックデータ１０３には、
そのブロックのブロック番号、ブロック内のデータ種
別、ブロック内のベクトル地図データが含まれている。
ブロック番号については、図６に例示したように、何番
のブロック９０がターゲット地域８０内のどの場所に位
置するかは予め規則で決まっている。よって、それらの
ブロックの地図を、ブロック番号の順に所定の規則で
（例えば、図６のブロック番号順のように）並べれば、
自ずとそのターゲット地域８０の地図が出来上がること
になる。ブロック内のベクトル地図データでは、図６に
例示したように、それを構成するX座標値及びY座標値の
いずれもが1バイトで表されている。

【００５２】なお、図示の地図データパック１００は、
地図データをまずレイヤに分け、各レイヤを更にブロッ
クに分けた構成をもつが、変形として、地図データをま
ずブロックに分け、各ブロックをレイヤに分けた構成で
あっても良い。

【００５３】以上の地図データパック１００のデータサ
イズは、地図データがベクトルイメージデータであり、
また、そのX座標値及びY座標値のいずれもが1バイトデ
ータで表されているために、そのデータサイズはかなり
小さい。例えば、４００ｍ×４００ｍの広さ範囲をカバ
ーする1万分の１市街地図の場合、建物や街路などの形
状や名称が詳細に表されているが、その地図データパッ
クのサイズは１０ｋB程度のコンパクトになり得る。ま
た、１．５ｋｍ×１．５ｋｍの広さ範囲をカバーする２
万５分の１地形図の場合も、詳細さが市街地図より荒く
なるため、やはりその地図データパックのサイズは１０
ｋB程度のコンパクトになり得る。１０ｋB程度の地図デ
ータパックは、現状の携帯電話のもつ９６００BPSとい
う低い通信速度であっても、１０秒程度で伝送し終わ
る。通常、地図要求を発してから地図が表示されるまで
ユーザが許容できる待ち時間は、せいぜい１０秒〜１５
秒程度である。その許容待ち時間の間に、４００ｍ×４
００ｍの1万分の１市街地図や１．５ｋｍ×１．５ｋｍ
の２万５分の１地形図の地図データパックを伝送し終え
ることができる。

【００５４】再び、図３に示した、クライアント３０の
地図アプリケーションの動作流れを参照する。地図アプ
リケーションは、地図配信サーバ１５から、上述したベ
クトル地図データの地図データパックを受信する（ステ
ップ６３）。この受信に要する時間は、上述したよう
に、例えば１０秒程度である。そして、地図アプリケー
ションは、その受信したベクトル地図データから、ま
ず、所定のデフォルトの拡大率をもつデフォルトの表示
エリアについて、ラスタ地図データを描画して表示する
（ステップ６４）。ここで、表示エリアとは、画面に表
示されている地図のカバーする地域のことであり、拡大
率とは、その表示エリアの広さ範囲の逆数を相対的な数
値で表したものである（つまり、その広さ範囲の地図
を、所定の画面サイズに適したピクセル数のイメージと
して描くときの相対的な倍率）。地図アプリケーション
は、最初にデフォルトの表示エリアの地図を表示し、そ
の後は、ユーザから拡大縮小またはスクロールの要求が
あると（例えば、クライアント３０の拡大縮小用ボタン
またはスクロール用ボタンがユーザに操作されると）、
その都度、そのユーザの要求に応じて表示エリアを変更
して、その表示エリアのラスタ地図データを再描画して
表示する（ステップ６５）。

【００５５】図８は、上記の表示エリアと拡大率とにつ
いて具体的に説明したものである。

【００５６】図８において、エリア１１０は、受信した
地図データのカバーする例えば４００ｍ×４００ｍのタ
ーゲット地域である。そして、エリア１１２が、地図ア
プリケーションが最初に表示するデフォルトの表示エリ
アである。このデフォルトの表示エリア１１２は、例え
ば約１５０ｍ×約１５０ｍの広さ範囲をもち、その中心
点はターゲット地域１１０の中心点（つまり、ユーザ所
望の地名の代表地点）と一致する。

【００５７】ユーザが拡大を要求すれば、表示エリア
は、図中のエリア１１３、１１４のように、より狭くな
り（つまり、拡大率が上がり）、より詳細な地図が見れ
るようになる。ユーザが縮小を要求すれば、表示エリア
は逆に広くなり（つまり、拡大率が下がり）、より広い
地域が見れるようになる。最も広い（つまり、最小の拡
大率の）表示エリアはターゲット地域１１０と一致す
る。デフォルトの表示エリア１１２の拡大率を１００％
とすれば、最小の拡大率は例えば３３％である。ユーザ
の拡大縮小要求で、拡大率は例えば２００％、１５０
％、１００％、５０％、３３％のように段階的に切り替
わる。ユーザが拡大（または縮小）の要求ばかりを出し
つづけると、拡大率は増加（又は減少）していき、最大
値（または最小値）に達すると次に最小値（最大値）に
ジャンプし、再び増加（または減少）する、というよう
にリング状に拡大率が変化するようにしてもよい。

【００５８】最小以外の拡大率のときには、ユーザのス
クロール要求により、表示エリアはターゲット地域１１
０内を上下左右に自由にスクロールすることができる。

【００５９】このように拡大縮小やスクロールが可能な
のは、地図アプリケーションがベクトル地図データを持
っていて、このベクトル地図データを基に任意の表示エ
リアのラスタ地図イメージが描画できるからである。ベ
クトル地図データから作成したラスタ地図イメージは、
拡大率に関わらず鮮明である。

【００６０】図９は、地図アプリケーションが地図を表
示する際に、拡大率に応じて、表示するレイヤを制御す
る様子を例示した図である。

【００６１】図９に示すように、受信した地図データ
は、複数のレイヤ２００、２００、…に分かれている。
これらのうち、ある種の地理物（例えば道路の枠線、市
町村境界線など）のレイヤ２０１は、拡大率に関わらず
常に表示される。また、別の種類の地理物（例えば個々
の建物の多角形など）のレイヤ２０２は、例えば拡大率
が１００％以上のときにのみ表示され、拡大率が５０％
以下では表示されない。さらに、また別の地理物（例え
ば、番地名や建物名等の文字、図象記号など）は、例え
ば拡大率が５０％以上のときにのみ表示され、最小拡大
率３３％では表示されない。

【００６２】このように、表示するレイヤを地図の拡大
率に応じて制御することで、その拡大率に応じた最適な
情報の表示ができる。

【００６３】以上説明した実施形態によれば、ユーザの
1回の地図要求に対して配信される地図データは、デー
タサイズが過大でなく、よって、長すぎない待ち時間と
高すぎない通信料金で受信でき、ユーザが利用するのに
便利な広さ範囲の地域をカバーし、さらに、表示された
地図の拡大縮小やスクロールが可能である。

【００６４】上記実施形態で例示した市街地図について
の４００ｍ×４００ｍ、道路地図についての１．５ｋｍ
×１．５ｋｍという、1回の通信で配信される地図デー
タの地域的広さ範囲は、好適な一例であり、もっと広く
することもできる。例えば、市街地図は１ｋｍ×１ｋｍ
程度、或いは３ｋｍ×３ｋｍ程度、道路地図は５ｋｍ×
５ｋｍ程度、或るいは１０ｋｍ×１０ｋｍ程度というよ
うにである。

【００６５】上記実施形態では、配信される地図データ
の地域的広さ範囲は、地図アプリケーションが、配信対
象の地図の地図レベルに応じて決定していたが、それ以
外の方法として、サーバシステムがユーザの要求する地
図レベルや用途などに応じて決定するようにしてもよい
し、ユーザが任意に決定できるようにしてもよい。

【００６６】ユーザが地図の地域的広さ範囲を決定する
ことは、従来の携帯電話等の地図配信サービスでも行わ
れている。ただし、従来のサービスでは、ユーザが要求
した地域的広さ範囲に応じて、サーバから配信される地
図の地図レベルが違ってくる。例えば、２００ｍ×２０
０ｍ程度以下では市街地図、それより広いと道路地図と
いうようにである。これに対し、本発明の原理に従え
ば、ユーザの要求する地域的広さ範囲の大小にかかわら
ず、同一地図レベルの地図データを配信するように構成
することができる。例えば、１００ｍ×１００ｍから１
ｋｍ×１ｋｍ程度の間でユーザがどの広さ範囲を指定し
ても、ユーザが1万分の1市街地図を望んでいるならば、
その1万分の1市街地図のベクトル地図データを配信する
というようにである。

【００６７】また、ユーザ又はサーバシステムが決定で
きる地域的広さ範囲は、必ずしも正方形でなくてもよ
く、緯度方向の長さLと経度方向の幅Wなどの地域的広さ
範囲の各部の寸法を任意に指定する等の方法で、長方形
やその他の形状の地域的広さ範囲を指定できるようにし
てもよい。例えば、或る道路に沿って細長く伸びる商店
街を見たいような場合、それに合わせた細長い形状の地
域的広さ範囲が指定できれば、利便性が一層向上する。

【００６８】今後は通信速度等がますます向上し、より
広大な地域の地図データを、より短時間により低料金で
配信することが可能になるであろう。ただし、そうなっ
た場合でも、ユーザがその全域を見る可能性が殆ど無い
ようなやたらに広大な地域の地図データを配信する方法
より、むしろ、ユーザの利用目的に照らして必要十分と
思われる適度な地域的広さ範囲を自動的又はユーザの希
望に応じて決定し、その適度な広さ範囲のターゲット地
域の地図データを配信する方法の方が、待ち時間や通信
信料金を更に一層削減できるという利点がある。

【００６９】上述した実施形態は、本発明を説明するた
めの例示にすぎず、本発明の範囲を上記実施形態にのみ
限定する趣旨ではない。本発明は、その要旨を逸脱する
ことなく、上述の実施形態以外の様々な態様で実施する
ことができる。

【図面の簡単な説明】

【図１】本発明の一実施形態にかかる地図データ配信シ
ステムの全体構成を示すブロック線図。

【図２】地図配信サービスが行われるときのシステム全
体の動作シーケンスを示す図。

【図３】クライアント３０の地図アプリケーションの動
作を示すフローチャート。

【図４】地図ソースサーバ１１と地図配信サーバ１５の
地図データを送信する動作を示すフローチャート。

【図５】地図データベース１２内にある地図データの構
成を示す図。

【図６】図４のステップ７２の処理でデータサイズを縮
小されたベクトル地図データのブロックと座標値を説明
した図。

【図７】1回の地図データ要求に対して配信される地図
データパックの構成を示す図。

【図８】クライアントに表示される地図の拡大率と表示
エリアを説明した図。

【図９】地図アプリケーションが地図を表示する際に、
拡大率に応じて、表示するレイヤを制御する様子を説明
した図である。

【符号の説明】

１０ サーバシステム ２０ 通信ネットワーク ３０ クライアント ８０、１１０ 配信される地図データがカバーするター
ゲット地域 ９０ 小面積のブロック X 各ブロック内の1バイトの緯度方向座標値 Y 各ブロック内の1バイトの経度方向座標値

Claims (11)

【特許請求の範囲】
1. 【請求項１】 オリジナルのベクトル地図データを蓄積
   した地図データベースと、 遠隔のクライアントから地図要求を受ける地図要求受信
   手段と、 前記クライアントからの前記地図要求に応答して、前記
   地図データベース内のオリジナルのベクトル地図データ
   に基づいて、前記クライアントへ配信されるべきターゲ
   ット地域のベクトル地図データを準備する地図データ準
   備手段と、 準備された前記ベクトル地図データを通信ネットワーク
   を通じて前記クライアントへ送信する地図データ配信手
   段とを備え、 前記地図データ準備手段が、前記配信されるべきベクト
   ル地図データに含まれる座標値のデータサイズを、前記
   地図データベースから取得したオリジナルのベクトル地
   図データのもつオリジナルの座標値のデータサイズより
   縮小することにより、前記配信されるべきベクトル地図
   データのデータサイズを、対応する前記オリジナルのベ
   クトル地図データのデータサイズより縮小するようにな
   った通信ネットワークを通じて地図データを配信するた
   めのサーバシステム。
2. 【請求項２】 前記ターゲット地域が、前記クライアン
   トから要求された地図データの地図レベルに応じて定め
   られた広さ範囲を有する請求項1記載のサーバシステ
   ム。
3. 【請求項３】 前記クライアントから要求された地図デ
   ータの地図レベルが、個々の建物の形状を表した市街地
   図であるとき、前記ターゲット地域の広さ範囲がほぼ４
   ００ｍ×４００ｍ以上である請求項２記載のサーバシス
   テム。
4. 【請求項４】 前記クライアントから要求された地図デ
   ータの地図レベルが、道路の走る経路は表すが個々の建
   物の形状までは表していない道路地図であるとき、前記
   ターゲット地域の広さ範囲がほぼ１．５ｋｍ×１．５ｋ
   ｍ以上である請求項２記載のサーバシステム。
5. 【請求項５】 前記クライアントが携帯電話である請求
   項１記載のサーバシステム。
6. 【請求項６】 前記クライアントに対して、前記クライ
   アントが受けた前記ベクトル地図データからラスタ地図
   データを描画するための地図アプリケーションをダウン
   ロードするアプリケーションダウンロード手段を更に備
   えた請求項1記載のサーバシステム。
7. 【請求項７】 遠隔のクライアントから地図要求を受け
   る地図要求受信ステップと、 前記クライアントからの前記地図要求に応答して、オリ
   ジナルのベクトル地図データに基づいて、前記クライア
   ントへ配信されるべきターゲット地域のベクトル地図デ
   ータを準備する地図データ準備ステップと、 準備された前記ベクトル地図データを通信ネットワーク
   を通じて前記クライアントへ送信する地図データ配信ス
   テップとを備え、 前記地図データ準備ステップには、 前記配信されるべきベクトル地図データに含まれる座標
   値のデータサイズを、前記地図データベースから取得し
   たオリジナルのベクトル地図データのもつオリジナルの
   座標値のデータサイズより縮小することにより、前記配
   信されるべきベクトル地図データのデータサイズを、対
   応する前記オリジナルのベクトル地図データのデータサ
   イズより縮小するステップが含まれている通信ネットワ
   ークを通じて地図データを配信するための方法。
8. 【請求項８】 遠隔のクライアントから地図要求を受け
   る地図要求受信手段と、 前記クライアントからの前記地図要求に応答して、配信
   されるべき地図データの地図レベルに応じた広さ範囲を
   有したターゲット地域のベクトル地図データを準備する
   地図データ準備手段と、 準備された前記ベクトル地図データを通信ネットワーク
   を通じて前記クライアントへ送信する地図データ配信手
   段とを備えた、通信ネットワークを通じて地図データを
   配信するためのサーバシステム。
9. 【請求項９】 遠隔のクライアントから地図要求を受け
   る地図要求受信ステップと、 配信されるべき地図データの地図レベルに応じて、ター
   ゲット地域の広さ範囲を決定する地域的広さ範囲決定ス
   テップと、 前記クライアントからの前記地図要求に応答して、前記
   地図レベルに応じて決定された広さ範囲を有した前記タ
   ーゲット地域のベクトル地図データを準備する地図デー
   タ準備ステップと、 準備された前記ベクトル地図データを通信ネットワーク
   を通じて前記クライアントへ送信する地図データ配信ス
   テップとを備えた、通信ネットワークを通じて地図デー
   タを配信するための方法。
10. 【請求項１０】 遠隔のクライアントから地図要求を受
    ける地図要求受信手段と、 前記クライアントからの前記地図要求に応答して、一つ
    の地図レベルをもつベクトル地図データであって、可変
    的に定め得る広さ範囲を有したターゲット地域のベクト
    ル地図データを準備する地図データ準備手段と、 準備された前記ベクトル地図データを通信ネットワーク
    を通じて前記クライアントへ送信する地図データ配信手
    段とを備えた、通信ネットワークを通じて地図データを
    配信するためのサーバシステム。
11. 【請求項１１】 遠隔のクライアントから地図要求を受
    ける地図要求受信ステップと、 ターゲット地域の広さ範囲を可変的に決定する地域的広
    さ範囲決定ステップと、 前記クライアントからの前記地図要求に応答して、一つ
    の地図レベルをもつベクトル地図データであって、前記
    可変的に定められた広さ範囲を有した前記ターゲット地
    域のベクトル地図データを準備する地図データ準備ステ
    ップと、 準備された前記ベクトル地図データを通信ネットワーク
    を通じて前記クライアントへ送信する地図データ配信ス
    テップとを備えた、通信ネットワークを通じて地図デー
    タを配信するための方法。