デジタルマッピングシステム
デジタルマッピングシステムの態様を実装するための種々の方法、システム、および装置が開示されている。1つの掛かる方法は、場所リクエストをクライアント側コンピュータデバイスから地図タイルサーバへ送ること、場所リクエストに応答して1セットの地図タイルを受信すること、前記受信した地図タイルをタイルグリッドに組立てること、タイルグリッドをクリッピング形状に対して整列させること、そして、結果を地図画像として表示することを含む。本発明の態様に従う1つの装置は、場所リクエストをクライアント側コンピュータデバイスから地図タイルサーバへ送るための手段、場所リクエストに応答して1セットの地図タイルを受信するための手段、前記受信した地図タイルをタイルグリッドに組立てるための手段、タイルグリッドをクリッピング形状に対して整列させるための手段、そして、結果を地図画像として表示するための手段を含む。かかる装置は、更に、表示した地図画像上への対話式オーバレイとして方向制御またはズーム制御のオブジェクトを含んでもよく、地図タイル画像上に経路または場所のオーバレイも、含んでいてもよい。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、2004年5月3日出願の米国仮特許出願第60/567,946号に対する優先権を主張し、その全体を引用して本明細書に組込む。本出願はまた、2004年3月23日出願の米国仮特許出願第60/555,501号に対する優先権を主張し、その全体を引用して本明細書に組込む。
【0002】
本発明の原理に整合する実装様態は、一般的にマッピングシステムに関し、より詳細には、デジタル環境におけるマッピングシステムに関する。
【背景技術】
【0003】
コンピュータ化したマッピングシステムが、旅行計画を容易にするために開発されてきた。例えば、旅行計画インターネットウェブサイトが、商用に供されており、良く知られている。そのようなウェブサイトは、普通にはユーザが要求した場所クエリを入力することができ、それにより要求した場所に関連する地図がユーザへ提供できる。また、良く知られたウェブサイトは、ユーザに旅行の出発点と終着点を記入させて、次いで旅程を計算しユーザへ提供することに使用できる。
【0004】
以下に続く本発明の幾つかの態様の詳細な検討のための背景として、図1から図4が、従来の例示的デジタルマッピングシステムの幾つかの態様を表す。図1は、地図リクエスト記入のウェブページ105を表示するウェブブラウザのユーザインタフェース100を示す。図示のように、ユーザは、所望の場所のモンタナ州45619、ビリングス、メインSt.353を記入した。地図を作成するべき所望の場所を記入した後に、図1に示すように、ユーザは次いで、「地図リクエスト」ボタン110を選択することで(普通には遠隔サーバから)地図を要求する。地図画像は次いで、普通には遠隔サーバで生成され、ユーザのコンピュータデバイスへ送信され、結局地図表示のウェブページにあるウェブブラウザのユーザインタフェース100上に表示される。
【0005】
図2は、ウェブブラウザのユーザインタフェース100上の例示的地図表示のウェブページ200を示す。ここでは、地図表示のウェブページ200は、図1からの地図リクエストの結果を表示している。表示された情報は、一般的に地図画像205から成り、要求された場所および周囲の領域を表す。図2に示すように、要求された場所は、地図画像205上に住所アイコン208で識別され、住所アイコン208は、普通には地図画像205の中心に配置される。また、要求された場所および住所アイコン208は、地図表示のウェブページ200内の地図凡例ウィンドウ210にも表示されてもよい。住所アイコン208は、普通には簡単な二次元画像であり、地図画像205内で他のそのようなアイコンと近接近して表示される場合、視覚的混乱を生じることがあり、それぞれのアイコンが地図画像205内で実際に示す箇所に関してユーザを困惑させ、誤り導くことがある。
【0006】
地図のウェブページ200は、地図画像205が表示される様式を制御するよう選択できるボタンまたは他のユーザインタフェースオブジェクトも表示できる。例えば、図2に示すように、ズーム制御オブジェクト220が一般的に設けられ、ユーザが「拡大」または「縮小」することを容認し、それによって地図画像205の表示された縮尺比にそれに応じて影響を及ぼし、その一方で、普通には住所アイコン208で印付けた所望の場所を画像の中心に保持する。また、「下向矢印」方向ボタン215等の方向ボタンまたは他の同様なユーザインタフェースオブジェクトが設けられてもよく、地図画像205の「南の」境界を越えたためにこれまでは隠されていたより多くの地図情報を表示すること等によってユーザが画像を「パン」することを容認し、その一方で、これまで表示されていた地図情報の「北の」部分の相当する部分をシフトさせて隠す。図2に示すように、そのような画像制御オブジェクトは、従来では地図画像205の境界領域の外側に表示され、地図表示ウェブページ200内の地図画像205のために利用可能なスペースの量を低減させる。
【0007】
普通には、(図2に示すズーム制御オブジェクト200または方向ボタンボタン215等の)画像制御オブジェクトが選択される場合、HTTPリクエストがサーバへ送信され、サーバはそこで選択されたズームレベルで表示されるべき新規の地図情報を含む新規の画像を送信する。
【0008】
具体的には、図3に示すような、例示的システムにおいて、ウェブブラウザ300は、要求された地図画像に対する場所情報を含むHTTPリクエストをウェブサーバ305へ送る。HTTPリクエストは、図1に示すように、データ記入ウェブページ105を通してウェブブラウザユーザインタフェース100を介して受信した場所データから成ってもよい。例えば、図1に示し、先に説明したように、ユーザは以下の地図を作成するべき所望の場所を記入してよい:モンタナ州45619、ビリングス、メインSt.353。ユーザは次いで、「地図リクエスト」ボタン110を選択することで道案内を要求し、この選択イベントが、結局図3に示すHTTPリクエストをウェブブラウザ300からウェブサーバ305へ(直接的または間接的に)送信させる。HTTPリクエストに応答して、ウェブサーバ305は、データベースクエリ(「DBクエリ」)を地図ベクターデータベース310へ送る。地図ベクターデータベース310は、普通には所望の場所データについての対応するベクターを決定し、これらのベクターをウェブサーバ305へ送信する。ウェブサーバ305は次いで、普通には受信したベクターを用いて所望の地図のビットマップ画像を生成し、ビットマップをウェブブラウザ300が対応している画像フォーマット(例えば、GIF、PNG、JPEG等)に変換する。ウェブサーバ305は次いで、画像をウェブブラウザ300へ、一般的にそれをハイパーテキスト記述言語(HTML)コード内に埋め込んで送信する。地図画像は次いで、(図2に示し、先に説明したように)ウェブブラウザユーザインタフェース100によりユーザへ表示される。従って、ユーザが郵便住所を記入すること、または現在の地図ビューの付近にあるナビゲーションリンクをクリックすることで新規の地図ビューを要求する場合に、ウェブブラウザ300は、ウェブサーバ305へ新規の地図ビューの境界を示すリクエストを送る。ウェブサーバ305は、次にデータベースから対応するベクターベースの地図データを抽出し、地図のビットマップ画像を描画する。ウェブサーバ305は次いで、ビットマップ画像をウェブブラウザ300が対応している画像フォーマットへ変換し、画像を、場合によってはHTMLに埋め込んで、ユーザへの表示のためにウェブブラウザ300へ返す。そのようなシステムの商用実装様態は、AOL社のMapQuest (http://www.mapquest.com)、ヤフー社のTelcontarベースの「SmartView」地図(http://maps.yahoo.com)、およびマイクロソフト社のMapPoint.netスイート (例えば、http://maps.msn.com)を含む。
【0009】
図4は、地図データをウェブブラウザへ提供するために使用される第2の例示的システムを示す。図4に示すように、ウェブブラウザ300は、図3に対して先に説明したものと同じ様式でHTTPリクエストをウェブサーバ305へ送信する。ウェブブラウザ300からのHTTPリクエストを受信すると、図4に示すウェブサーバ305は、要求された場所データを含むデータベースクエリ(「DBクエリ」)を地図ラスタデータベース410へ送信する。地図ラスタデータベース410は、データベースクエリに基づいて適切な画像を大きい予め描画した地図画像の中から抽出する。要求された画像は次いで、ウェブサーバ305へ送信され、ウェブサーバ305はそこで先に説明したように画像をウェブブラウザ300へ送信する。従って、図4に示すようなデジタルマッピングシステムでは、ベクターを抽出し、地図画像を描画するステップは、大きい予め描画した画像の適切な一部を単に抽出するステップで置き換えられる。そのようなシステムの商用実装様態は、英国のMultiMaps (http://multimaps.com)およびオーストラリアのWhereIs (http://www.whereis.com.au) を含む。かかるシステムは、普通にはかかる地図の印刷バージョンを生成することにも使用される同じベクターベースのファイルから地図画像を生成することにも、注目すべきである。
【0010】
上記の問題の幾つかは数多くのより小さい画像(「タイル」として知られる)をウェブサーバ305からウェブブラウザ300へ送信することによって克服できるであろうことにデジタルマッピングウェブサイトの幾つかのプロバイダが気付いた。これらのより小さいタイルは、次いで、ウェブブラウザ300によってより大きい画像に組立てることができる。例えば、マイクロソフト社のTerraServer米国サイトは(http://terraserver.homeadvisor.msn.com/)、現在、衛星写真を表示するためにタイル化する手法を用いている。
【発明の開示】
【0011】
デジタルマッピングシステムの態様を実装するための種々の方法、システム、および装置が開示されている。1つのかかる方法は、場所リクエストをクライアント側コンピュータデバイスから地図タイルサーバへ送ること、場所リクエストに応答して1セットの地図タイルを受信すること、前記受信した地図タイルをタイルグリッドに組立てること、タイルグリッドをクリッピング形状に対して整列させること、そして、結果を地図画像として表示することを含む。本発明の態様に従う1つの装置は、場所リクエストをクライアント側コンピュータデバイスから地図タイルサーバへ送るための手段、場所リクエストに応答して1セットの地図タイルを受信するための手段、前記受信した地図タイルをタイルグリッドに組立てるための手段、タイルグリッドをクリッピング形状に対して整列させるための手段、そして、結果を地図画像として表示するための手段を含む。かかる装置は、更に、表示した地図画像上への対話式オーバレイとして方向制御またはズーム制御のオブジェクトを含んでもよく、地図タイル画像上に経路または場所のオーバレイも、含んでいてもよい。
【0012】
この明細書に組込まれ、その一部を構成する添付図面は、種々の実施の形態を図示する。
【0013】
【0014】
【0015】
【0016】
【0017】
【0018】
【0019】
【0020】
【0021】
【0022】
【0023】
【0024】
【0025】
【0026】
【0027】
【0028】
【0029】
【0030】
【0031】
【0032】
【0033】
【0034】
【0035】
【0036】
【0037】
【0038】
【0039】
【0040】
【発明を実施するための最良の形態】
【0041】
本発明の実施形態を開示の種々の態様を、マッピング情報を取得し、表示するための装置、システム、および方法の文脈の中で明細書に説明する。以下の説明は例証的のみであり、何らかの限定を行うものではないことを当該技術に精通する者は感知するであろう。他の態様もこの開示の恩恵を有する者にとり容易に自明であろう。
【0042】
例えば、Java言語、JavaScript、Javaアプレット技術、C、C++、Perl、Pascal、Smalltalk、FORTRAN、アセンブリ言語、HTML(すなわち、ハイパーテキスト記述言語)、DHTML(すなわち、ダイナミックハイパーテキスト記述言語)、XML(すなわち、拡張可能記述言語)、XLS(すなわち、拡張可能スタイル言語)、SVG(すなわち、スケーラブルベクターグラフィックス)、VML(すなわち、ベクター記述言語)、マクロメディア社のFlash技術等の、数多くのコンピュータプログラミング言語が、本発明の態様を実装することに使用されてもよい。更に、手続き型、オブジェクト指向、または人工知能技術等の種々のプログラミング手法が、それぞれ特定の実装要件によって用いられてもよい。
【0043】
同じ参照番号を、この文書において図面および説明の全体にわたり用いて、同じかまたは同様の部分に言及する。更に、本明細書における幾つかの図は、方法およびシステムを示すフローチャートである。これらフローチャートのそれぞれのブロック、およびこれらフローチャートにおけるブロックの組合せは、コンピュータプログラム命令で実装されてもよいことが理解されるであろう。これらのコンピュータプログラム命令は、コンピュータまたは他のプログラム可能な装置上へ読み込まれてマシンを生じてもよく、それによりコンピュータまたは他のプログラム可能な装置上で実行する命令はフローチャートのブロック(単数または複数)に指定された機能を実装するための構造を作成する。また、コンピュータまたは他のプログラム可能な装置に特定の様式で機能するよう指図できるこれらのコンピュータプログラム命令は、コンピュータ可読メモリに格納されてもよく、それによりコンピュータ可読メモリに格納された命令がフローチャートのブロック(単数または複数)に指定された機能を実装する命令体系を含む製造品を作成する。また、コンピュータプログラム命令は、コンピュータまたは他のプログラム可能な装置上へ読み込まれてよく、一連の操作上のステップをコンピュータまたは他のプログラム可能な装置上で実行させて、コンピュータ実装のプロセスを作成し、それによりコンピュータまたは他のプログラム可能な装置上で実行する命令がフローチャートのブロック(単数または複数)に指定された機能を実装するためのステップを提供する。
【0044】
従って、フローチャートのブロックは、指定された機能を実行するステップの組合せおよび指定された機能を実行するためのステップの組合せに対応している。また、フローチャートの各ブロック、およびフローチャートにおけるブロックの組合せは、指定の機能またはステップを実行する特別用途ハードウェアに基づくコンピュータシステム、または特別用途ハードウェアおよびコンピュータ命令の組合せで実装できることも、理解されるであろう。
【0045】
図5は、本発明の態様に従う分散型ネットワークシステム500を示す。コンピュータデバイス503が、ネットワーク505へ接続されて、示されている。また、種々のサーバも、ネットワーク505へ接続されている。例えば、ウェブサーバ510、タイルサーバ515、および場所データサーバ520は、全てがネットワーク505と通信しているとして示されているが、他のサーバ(不図示)も、ネットワーク505へ接続されてもよい。コンピュータデバイス503は、パーソナルコンピュータ、携帯電話、携帯情報端末、車両に配置されるナビゲーションシステム等の演算用に構行われたどのような種類のデバイスであってもよい。サーバ510、515および520は、ネットワークサーバまたはウェブサーバ等のそれぞれがネットワーク505上でホスティングサービス能力のあるどのようなデバイスであってもよい。また、サーバ510、515および520は、ユーザ入力に基づいて幾らかまたは全てのマッピング情報を決定および/または取得する能力があってもよい。代替として、コンピュータデバイス503は、旅程を決定および/または取得する能力を装備していてもよい。幾つかの実装では、コンピュータデバイスおよびサーバ(またはその種々の部分)は、1つ以上のマシンに共同で配置されていてもよい。
【0046】
ネットワーク505は、どのような種類の分散型ネットワークであってもよく、例えばローカルエリアネットワーク、広域ネットワーク、交換電話ネットワーク、イントラネット、インターネットまたはワールドワイドウェブネットワーク等であってもよい。代替として、ネットワーク505は、コンピュータデバイス503とサーバ510、515、および520との間の直接的な接続であってもよい。コンピュータデバイス503、ネットワーク505および/またはサーバ510、515、および520は、どのような種類の有線または無線接続を介して通信してもよい。その上、ネットワーク505と通信しているコンピュータデバイス503、サーバ510、515、および520、ならびに、他のコンピュータデバイス(不図示)、および/または他のサーバ(不図示)が、本明細書中に説明するいずれかまたは全ての機能を実行することに使用されてもよい。
【0047】
図6は、コンピュータデバイス503、またはサーバ510、515、および520の例示的な線図である。コンピュータデバイス/サーバ503/510/515/520は、バス600、1つ以上のプロセッサ605、主メモリ610、読出専用メモリ(ROM)615、記憶装置620、1つ以上の入力デバイス625、1つ以上の出力デバイス630、および通信インタフェース635を含んでいてもよい。バス600は、コンピュータデバイス/サーバ503/510/515/520の構成要素間での通信を許容する1つ以上の導線を含んでいてもよい。
【0048】
プロセッサ605は、命令を解釈して実行するどのような種類の従来のプロセッサ、マイクロプロセッサ、または処理ロジックを含んでいてもよい。主メモリ610は、プロセッサ605による実行のための情報および命令を格納するランダムアクセスメモリ(RAM)または別の種類の動的記憶装置を含んでいてもよい。ROM615は、プロセッサ605による使用のための静的情報および命令を格納する従来のROM装置または別の種類の静的記憶装置を含んでいてもよい。記憶装置620は、磁気および/または光学記録媒体およびその対応する駆動部を含んでいてもよい。
【0049】
入力デバイス625は、キーボード、マウス、ペン、スタイラス、手書き認識、音声認識、生体メカニズム等の、ユーザが情報をコンピュータデバイス/サーバ503/510/515/520へ入力することを許容する1つ以上の従来のメカニズムを含んでいてもよい。出力デバイス630は、ディスプレイ、プリンタ、スピーカ等を含む、ユーザへ情報を出力する1つ以上の従来のメカニズムを含んでいてもよい。通信インタフェース635は、コンピュータデバイス/サーバ503/510/515/520が他のデバイスおよび/またはシステムと通信することを可能にするどのようなトランシーバのようなメカニズムを含んでいてもよい。例えば、通信インタフェース635は、ネットワーク505等のネットワークを介して別のデバイスまたはシステムと通信するためのメカニズムを含んでいてもよい。
【0050】
下記で詳細に説明するように、コンピュータデバイス503および/またはサーバ510、515、および520は、データ記憶装置620等の別のコンピュータ可読媒体から、または通信インタフェース635を介して別のデバイスからメモリ610へ読出されてもよいソフトウェア命令に基づいて操作を実行してもよい。メモリ610内に含まれるソフトウェア命令は、プロセッサ605に後述するプロセスを実行させる。代替として、配線で接続された回路が、ソフトウェア命令の代わりにまたはそれと組合せて使用されて本発明に整合するプロセスを実装してもよい。従って、種々の実装は、ハードウェア回路およびソフトウェアのどのような特定の組合せにも限定されない。
【0051】
ウェブブラウザユーザインタフェース(図1および図2に示すウェブブラウザインタフェース100等)を備えるウェブブラウザ(図3および図4に示すウェブブラウザ300等)は、情報(文章および図形情報等)をコンピュータデバイス503上に表示することに使用されてもよい。ウェブブラウザ300は、図5に示すネットワーク505を介して受信した情報を表示することのできるどのような種類の視覚的表示を備えていてもよく、例えばマイクロソフト社のInternet Explorerブラウザ、ネットスケープ社のNavigatorブラウザ、MozillaのFirefoxブラウザ、PalmSource社のWeb Browser、またはネットワーク405と通信することのできるいずれかの他の閲覧もしくは他のアプリケーションソフトウェア等であってもよい。また、コンピュータデバイス503は、ブラウザアシスタントを含んでいてもよい。ブラウザアシスタントは、プラグイン、アプレット、ダイナミックリンクライブラリ(DLL)、または同様の実行可能なオブジェクトもしくはプロセスを含んでいてもよい。更に、ブラウザアシスタントは、ウェブブラウザ300へ拡張機能を提供するツールバー、ソフトウェアボタン、またはメニューであってもよい。代替として、ブラウザアシスタントは、ウェブブラウザ300の一部であってもよく、その場合、ブラウザ300はブラウザアシスタント機能を実装することになる。
【0052】
ブラウザ300および/またはブラウザアシスタントは、ユーザとコンピュータデバイス503および/またはネットワーク505との間の媒介物として動作してもよい。例えば、ネットワーク505に接続されたデバイスから受信したソースドキュメントまたは他の情報は、ブラウザ300を介してユーザへ出力されてもよい。また、ブラウザ300およびブラウザアシスタントの両方は、ソースドキュメントをユーザへ出力する前に受信したソースドキュメント上に操作を行うことができる。更に、ブラウザ300および/またはブラウザアシスタントは、ユーザ入力を受信し、ネットワーク505に接続されたサーバ505/515/520または他のデバイスへ入力されたデータを送信してもよい。
【0053】
例示的システムの概要およびユーザインタフェース
下記でより詳細に説明するように、一実施の形態の幾つかの態様は、それぞれ適切な1セットの分離したズームレベルの大きい(例えば、米国全体の規模の)連続した地図のラスタ画像の存在を想定している。一時的なオフライン段階中に、システムは、この大きいラスタ画像を生成し、所望の地図ビューより一般的に1桁小さいサイズのセグメント(例えば、長方形タイル)に切り分け、これらのタイルをウェブブラウザが対応しているフォーマットでサーバ側データベースに格納する。
【0054】
図7の例に示すように、ウェブユーザが新規の地図ビューをアプリケーションソフトウェア700(例えば図3および図4に示すウェブブラウザ300等)を介して要求する場合、ウェブブラウザに(または、限定しないが、図6に示す主メモリ610、ROM615、および/または記憶装置620として実装できるであろう、図7にローカルメモリ705として示すウェブブラウザのキャッシュに)既に存在するタイルと併せて必要である最小の1セットのタイルのみに対するHTTPリクエストが、サーバ710へ送られて、新規ビューを作成する。これらのHTTPタイルリクエストに対する応答のフォーマットは、ヘッダフィールドにウェブブラウザがタイルをローカルでキャッシュに格納するよう促す情報を含んでいる。1セットのスクリプトを実行することによって、ウェブブラウザは次いで、組み合わせたタイルのセットをユーザへの提供のための新規ビューにシームレスに組立てる。古い地図ビューは一般的に未だブラウザに存在しているため、追加のスクリプトを用いて、古い地図ビューから新しい地図ビューへの移行を、パンおよび/またはズーム操作の一部として、滑らかに動画化してもよい。その上、場所マーカーおよび経路を、例えば、ドライブ道案内、局所検索、職業別電話帳の参照等のユーザリクエストに応答して、予め描画した地図タイルの上に重ね合わせることができる。加えて、同様な技法は、例えば、地図画像上で地域および街路を強調することに使用できる。
【0055】
エンドユーザ(例えば図5に示すコンピュータデバイス上で動作しているウェブブラウザと対話しているユーザ等)の視点から、図8は、本発明の態様に従う地図リクエストと地図表示とを組み合わせたページ800の一実施の形態を表す。図8に示すように、ページ800は、地図画像805、重ね合わされた地図方向制御オブジェクト815、重ね合わされたズーム制御オブジェクト820、場所リクエストテキスト記入フィールド825、検索ボタン830、情報ウィンドウ840、場所マーカー845、場所マーカーの陰影850、および情報ウィンドウの陰影855を含む。後で詳細に説明するように、地図画像805は、タイルグリッドを地図画像805とほぼ同じサイズと形状を有するクリッピング形状に対して整列させることによって実際に生行われる。タイルグリッドは、一実施の形態で、表示のためにより大きい画像にシームレスに編行われる数多くのより小さい個々の地図タイルを備える。当該技術に精通する者に周知である画像オーバレイ技術および絶対位置決め技法を用いて、地図方向制御オブジェクト815およびズーム制御オブジェクト820は、地図画像805それ自体内に実際に配置されてもよく、それによって表示ページ800内で地図画像805のために利用可能である領域を増大させる。このようにして、地図画像805に対する任意のサイズが実装されてもよく、それは地図タイルの全ての数に限定されない。その上、どのような任意の点も、地図画像805の中心に配置されてもよい。一実施の形態では、場所クエリテキスト記入フィールド825は、単一のテキストフィールドとして実装され、それにより地図を作成するべき所望の場所の種々の構成要素(例えば、番地、市、州、または郵便番号等)が多数のフィールドを用いて指定される必要はない。後で検討するように、一実施の形態では、図8はまた、課金点860を地図画像の中心に含む(とはいえ、課金点860は、普通には地図画像805上における可視特徴ではない)。
【0056】
検索ボタン830が選択される場合、テキスト記入フィールド825内に記入された地図を作成するべき所望の場所は、ユーザのコンピュータデバイスまたは遠隔サーバのいずれかで解析され、地図画像805が(本文書全体にわたり説明されている詳細なプロセスによって)生成および表示される。記入フィールド825内に記入された所望の場所もまた、その元の形式または解析した形式のいずれかで地図タイトル840として繰り返され、表示されてもよい。地図を作成するべき所望の場所は、場所マーカー845およびその陰影850によって地図画像805内に図形で識別される。後で説明するように、角度付き陰影を備える場所マーカーを視覚的に二次元に表示する効果を使用することによって、特に多数の場所マーカーが相互に近接して配置される場合、地図画像805内の視覚的混乱は最少にされ、場所マーカーに対応する地図上の実際の場所は、より容易に地点として識別されるであろう。
【0057】
ユーザ画像制御機能の観点で、地図方向制御オブジェクト815は、地図をクリッピング形状サイズの、例えば25%だけ矢印の方向にパンさせる1セットの矢印ラベル付パンボタンとして実装されてもよい。また、これらのボタンは、「西」、「北」または「北西」等のコンパス方位でラベル付けもできる。図8に示すように、ズーム制御オブジェクト820は、地図を単一レベルだけそれぞれ拡大および縮小させる「+」および「−」のラベル付きボタンを含んでいてもよい。これらのボタンはまた、対応するズームレベルの主たる地理的な抽象概念、例えば、「街路」、「市」、「郡」、「州」、「国」等によってラベル付けられてもよい。また、図8に示すように、ズーム制御オブジェクト820も、それぞれのズームレベルに対する分離した位置を持つスライダを含んでもよい。ユーザの視点から、スライダを特定のズームレベルへ移動させることは、対応するズームレベルを選択することと同じ効果を有してもよい。
【0058】
一実施の形態で提供されるユーザインタフェース機能の追加の例として、地図画像805の特定の部分を「クリックする」か、または他の方法で選択することで、選択した場所を地図画像805の中心へパンさせる一方で、地図画像805の特定の部分を「ダブルクリックする」か、または他の方法で強調して選択することで、選択した場所を地図画像805の中心へパンさせると同時にズームレベルを増大させる。別の実施の形態では、地図画像805の特定の部分を「ダブルクリックする」か、または他の方法で強調して選択することで、選択した場所を地図画像805の中心へパンさせる一方で、場所マーカー(地図画像805内のマーカーまたは地図画像805に隣接のマーカーのいずれか)をクリックするか、または他の方法で選択することで、マーカーに関連する情報ウィンドウを開き、その後に地図画像の何れかの部分をクリックするか、または他の方法で選択することで、情報ウィンドウを閉じる。地図の動的サイズ変更も、一実施の形態で対応されている。例えば、表示ウィンドウ800がサイズ変更される場合、ウィンドウ内部の地図画像805は再び中心に合わされ(それにより、これまでのウィンドウサイズで中心であった場所を維持し)、地図はサイズ変更され(それにより、地図は新規ウィンドウがより小さい場合により小さい領域を、新規ウィンドウがより大きい場合により大きい領域を示し)、ズームレベルを変更することがなく、または一般的にユーザのウェブブラウザへの画像情報の再送信を必要としない。一実施の形態では、ユーザは地図画像805のコーナーまたは他の部分を(例えば、マウスのアイコンが選択したコーナーへ示す間に、マウスボタンを押すことによって)「つかむ」ことができ、それを「ドラッグ」して地図画像をサイズ変更する(例えば、マウスを選択した場所へ移動させる間マウスボタンを押し、次いでマウスボタンを放す)。
【0059】
一実施の形態は、マウスのドラッグ機能を実装し、それによって地図ビューは、例えば、ユーザのマウスボタンを押し、マウスを新規の場所へ所望の地図ビューがもたらされるまでドラッグし、次いでマウスボタンを放すことによって、滑らかに位置を変えてもよい。その上、地図スクロール機能も、一実施の形態で実装され、それによって地図ビューは、単にユーザのキーボード上の矢印キーの起動により、または同様なユーザの動作により位置を変える(つまり「パン」)されてもよい。
【0060】
一実施の形態では、全部または部分的な郵便住所をテキスト記入フィールド825内に記入することで、地図画像805を対応する場所へパンさせ、記入された住所の完全性によって決まるレベルへズームさせる。例えば、「カリフォルニア州、バークリー、ブリストルDr.6936」を記入することで、対応する場所へパンし、ズームレベルを街路のレベルの近くに設定し、これに対して、より明確な住所情報なしに単に「カリフォルニア州、バークリー」を記入することで、バークリーの市の中心へパンし、ズームレベルを都市のレベルへ設定することになる。その上、場所の輪郭が、一実施の形態で実装され、それにより、ユーザが明確な住所の代わりに大まかな領域(例えば、市、州、または郵便番号)を指定する場合、輪郭線が大まかな領域の周りに描画でき、(例えば、図28における場所輪郭線2810で示すように)それを強調する。この機能は、ユーザが距離を測り、興味のある領域に焦点を当てることを支援できる。また、一実施の形態では、ユーザは1セットのショートカット(例えば「自宅」、「仕事場」、または「祖母の家」等)を定義してもよく、それは、記入されるか、または他の方法で選択された場合、所望のショートカット場所への地図画像における「ジャンプ」動作(または、要求された場所が現在の場所に充分に近い場合「ズーム/パン」動作)を生じる。
【0061】
図8に示すように、一実施の形態は、また、「情報ウィンドウ」機能を実装し、それによってマーカー845等の場所マーカーをクリックするか、または他の方法で選択することで、マーカーで表された場所についてのより多くの情報を含む、地図画像805内に重ね合わされた、対話式ウィンドウ840およびその陰影855を開く。
【0062】
テキスト記入フィールド825の中へ地図を作成するべき単一の場所を記入することに加えて、一実施の形態では、ユーザは組合せた検索を実行してもよく、それによってユーザは単一のテキストボックス内に検索する項目および全ての地図を作成する場所(例えば、「サンフランシスコにある映画館」または「マウンテンビュー近くのピザ店」)を指定してもよい。その上、先に説明した場所ショートカットと併せて、ユーザは、特定の場所の名前(例えば、「自宅」、「仕事場」)を与えることができ(それは、住所録もしくは同様のデータベースまたはユーザのコンピュータデバイス上のユーティリティと関連していても、していなくてもよい)次いで、テキスト記入フィールド825内へ検索先を記入する場合に(例えば、「仕事場近くのバー」を検索する場合に)ショートカット名を用いる。
【0063】
一実施の形態はまた、ドライブ道案内機能を図8に示すような単一のテキスト記入フィールド825によって、または代替として、(図27に示すテキスト記入フィールド825および828で示すように)出発する場所のための1つのテキスト記入フィールドおよび終着場所のための第2テキスト記入フィールドによって、のいずれかで実装する。更なる例示的な代替として、ドライブ道案内機能はまた、出発する場所フィールドのための1セット(例えば、出発する住所、出発する市、出発する州等)および終着場所フィールドのための第2セットの2セットの特定のテキスト記入フィールドによって実装されてもよい。ドライブ道案内の記入フィールドインタフェースにかかわらず、一実施の形態は、経路情報のクライアント側描画を実装する。具体的には、一実施の形態で、サーバが、曲がり角ごとの文章の道案内を、経路全体の図形描出のためのベクター情報と並んで、クライアントのコンピュータデバイスへ送信する。
【0064】
グラフィックによるドライブ道案内は次いで、以前に描画した地図画像の上にオーバレイとしてクライアントによって描画される。別の実施の形態では、クライアントがベクター情報を受信すると、クライアントは経路オーバレイ画像のグラフィック定義を演算し、そのあと実際のオーバレイ画像を供給するようリクエストをサーバへ送信する。その上、図27に示すように、文章のドライブ道案内手引き2730(例えば、「モフェットBlvd.出口を取る」)が、ウェブページ800上で地図画像805の近傍に表示されてもよい。文章のドライブ道案内の1つをクリックするか、または他の方法で選択することで、地図画像805の対応するセクション(例えば、南行きUS−101からモフェットBlvd.へのフリーウェイ出口ランプ)を指す情報ウィンドウを開く。図27に示すように、情報ウィンドウは、地図画像805の対応するセクションの拡大図を表示する。
【0065】
一実施の形態では、情報ウィンドウは、追加として、「衛星」ボタンまたは同様なユーザインタフェースオブジェクトを含み、それは、クリックするか、または他の方法で選択される場合、地図のグラフィック拡大図を同じ領域の対応する衛星写真で置き換える。グラフィカルなドライブ道案内(すなわち、経路を描出した軌跡)も、また、衛星画の上にオーバレイとして表示できる。「衛星」ボタンまたは同様なユーザインタフェースオブジェクトはまた、主な地図画像805内に(またはそれに関連して)含まれてもよく、それにより、クリックするか、または他の方法で選択される場合、「衛星」ボタンは、図8に表した図形種類の地図画像805を同じ領域の対応する衛星写真で置き換える。
【0066】
サーバ側アーキテクチャおよび地図タイルの生成
一実施の形態では、地図は、地図画像の予め描画した「タイル」の1セットをブラウザにおいて一緒にまとめることによって表示される。これらの地図タイルは、オフラインフェーズで、所定数(例えば、15)の分離したズームレベルのそれぞれでカバーされる地理的領域全体の非常に大きい地図を描画し次いで、これらの地図をタイルに切り分け、そしてタイルを適切な画像フォーマット(例えば、GIF)にエンコードすることによって作成される。予め描画したタイルは、1セットのサーバからの静的画像として提供される。例えば、米国大陸全体をカバーするために、数億ものタイルが必要とされ、タイルのための合計ファイルサイズは数百ギガバイトもの程度のデータである。要望に応じて基調を成すデータから地図画像を描画する代わりに、地図全体がセクション(タイル)で予め描画され、適切なタイルが必要である場合にクライアントへ送られる。従って、一般的に、所与の地図タイルが、クライアントへ一度のみ送信される必要がある。この手法は、従来のシステムより信頼性があり、より早く、そして必要とする帯域幅はより狭い。
【0067】
従って、ユーザにとりトランスペアレントであるオフラインプロセスにおいて、地図システムでカバーされる領域全体の1セットの大きい連続した予め描画したラスタ画像が生行われる。そのような1セットのラスタ画像は、例えば、街路から国のレベルの範囲に及ぶズームレベルのそれぞれについて提供される。結局ユーザのウェブブラウザで組立てられ、表示される(図8に示すような)それぞれの地図画像805は、これらの大きい所定のラスタ画像の1つの(普通には長方形の形状にされる)サブ領域に一致する。代替として、地図画像の境界は、地図画像を取巻く背景と合う、つまり溶け込む地図画像の境界上へ画像を重ね合わせることで異なる形状に見えるよう(例えば、図8に示すように角を丸めた長方形)に変更してもよい。
【0068】
一実施の形態では、ズームレベルは、0からZまで番号付けられ、0は街路のレベルに最も近いレベルを、Zは街路のレベルから最も遠く離れたレベルを表す。興味のある領域内の任意の緯度/経度(「緯/経」)点が、原点つまりオリゴ(例えば、連続した米国の地理的中心)として指定および定義される。そこで、それぞれのズームレベルzで、座標三重項(0,0,z)が、この原点を含むz−レベルのラスタ画像の画素へ割り当てられる。x−軸座標が左から右へ延び、y-軸座標が上から下へ延びる標準的なコンピュータグラフィックスの規約を用いて、一意の座標三重項(x,y,z)が、それぞれのラスタ画像のそれぞれの画素へ割り当てられる。
【0069】
座標変換ルーチンは、ズームレベルzを与えられると、緯/経の座標対を適切な(x,y,z)画素座標へ変換し、またその逆も行う。この変換の詳細は、初回にラスタ画像を作成することに使用された地図投影によって決まる。
【0070】
基調を成す地図情報が大幅に変化する場合にのみ実行される必要がある初期のオフラインフェーズ中に(例えば、数ヶ月ごとに一回)、大きいラスタ画像のそれぞれは、長方形のタイルに「切り分け」られる。図9に示すように、一実施の形態では、大きいラスタ画像を地図タイルに生成し切り分けるプロセスは、地図ペインターライブラリ910と併せたタイルメーカー905、および市販のRME(「リッチ地図エンジン」)ライブラリ915によって協調的に実行される。数あるタスクの中で、タイルメーカー905は、とりわけラベル配置がかかわっている箇所で、隣接するサブ画像タイルがそれらの共通の境界線に沿って密接に並ぶことを確保する。当該技術に精通する者に周知の地図投影課題がある場合、地図システムでカバーされた領域をより小さい領域に分割し、それぞれを別々に扱うことが必要かもしれない。
【0071】
なお図9を参照して、基調を成す地図データは、地図データ記憶装置領域920に格納される。一実施の形態では、格納された地図データは、Telcontar社(デジタル地図およびナビゲーション情報の商用プロバイダ)によってRMF(リッチ地図フォーマット)ファイルにコンパイルされた市販のNavTechデータを備える。RMFは、空間的クエリ処理のために最適化されたコンパクトなバイナリフォーマットであることを当該技術に精通する者は認知するであろう。数あるタスクの中で、本発明の一実施の形態は、地図画像を生成し、経路情報を作成することにこのフォーマットを活用する。RMFは多次元風にデータを組織化する空間的フォーマットであり、それにより現実的に相互に近接した特徴がデータベースにおいてすぐそばに格納される。これは、一旦空間的にフォーマットされたデータセットにある項目が見付かると、すぐ近くの他の項目も比較的容易に見付けられることを意味する。データを組織化することに、順次にまたは層で等の多くの他の方式があることを当該技術に精通する者は認知するであろう。なお図9を参照して、一実施の形態で、タイルメーカー905は、地図ペインターライブラリ910と通信してタイルを作成するための地図データを要求する。地図ペインターライブラリ910は、次に市販のRMEライブラリ915と通信して地図データ記憶装置920からの情報にアクセスする。RMEライブラリは、2つ以上の項目の地理的関係を関与させる情報を要求する空間的クエリに対応していることを当該技術に精通する者は認知するであろう。例としては、「所与の領域内で該当する地図特徴は何か?」または「所与の領域内で該当する一定の閾値より高い優先レベルを有する地図特徴は何か?」である。空間的クエリの結果は、地図ペインターライブラリ905を介してタイルメーカー905へ送信され、地図タイルを生成することに使用される。タイル作成プロセスの結果として得られる地図タイルは、地図タイル記憶装置領域900に格納される。
【0072】
大きいラスタ画像のいずれかのサブ領域ビューを地図画像805としてユーザのウェブブラウザ上に再現するために、一実施の形態では、ブラウザ側のスクリプトは、所望のビューを一緒に完全にカバーする最小セットのタイルのみを必要とする。どのような所与の実装様態についても、タイルのサイズは、以下のトレードオフを前提として、経験的に確定できる:(1)より大きいタイルは所与のビューを作成することに必要であるタイルの合計サイズを(画素およびバイトの両方で)増大させる傾向がある;その一方で、(2)より小さいタイルは所与のビューを作成することに必要である別々のHTTPリクエストの数を増大させる傾向がある。一実施の形態では、128×128画素のタイルサイズが使用され、GIFフォーマットで格納される。他の実施の形態は、256×256画素のタイルサイズを使用し、GIF、JPEG、またはPNGフォーマットのいずれかで格納される。他のタイルサイズおよび画像格納フォーマットは、それぞれの特定の実装様態の要件次第で使用されてもよい。従って、これらのタイルは、規則正しい正方形グリッドを形成し、この性質は一実施の形態でシステム実装を容易にする。しかし、当該技術に精通する者は、クライアント側でのシームレスな組立てを容認するどのような形状およびサイズのタイルへの大きいラスタ画像の他のどのような分割も、本発明の効果を達成するために使用されてもよいことを、認知するであろう。
【0073】
代替として、サーバ側のデータベースでなく、一実施の形態で、それぞれのタイルは、例えば下記のような一意のURLを用いてアクセス可能な別々のファイルに単純に格納されてもよい。
http://<domain>/7/-18/1/-145_12_7.gif
ここで、この例でのディレクトリパス 7/-18/1 は、この例示的事例において (-145,12,7) に等しいタイル座標だけによって決まる。
【0074】
簡単にするために、それぞれのズームレベルzの第1タイルは、タイルの左上画素が座標(0,0,z)を有するように配置される。この規則は、それぞれのタイルへの一意の座標三重項の割り当てを、タイルの左上画素の画素のxおよびy座標をそれぞれタイルの幅および高さで整数除算することによって容易にする。従って、緯/経の座標、画素の(x,y,z)座標およびタイルの(x,y,z)座標の合計3つの座標系が利用される。当該技術に精通する者が認知するであろうように、座標系のこの特定の選定は任意であり、一実施の形態で使用されるアルゴリズムを説明することを単に補助するように選ばれる。一般的に、どのような一貫性のある座標系も充分であると考えられる。次に、それぞれの画素は一意のタイルに属し、その座標は容易に演算される。
【0075】
フロントエンドサーバ
一実施の形態では、フロントエンドサーバ(例えば図7に表すサーバ710または図5のウェブサーバ510等)は、ユーザによって発信されたそれぞれのクエリに、JavaScriptで実装されたクライアント側コードでアクセスされるデータを含む隠されたフレームに対するウェブページを返すことで応答する。従って、フロントエンドサーバ710/510は、ユーザのブラウザ上で動いているJavaScriptベースの1セットのプログラムと対話してダイナミックHTML(「DHTML」)コードを生成する。このメカニズムにより、図8に示す地図ビュー805をパンおよびズームする等の、先に説明したユーザインタフェース機能は、フロントエンドサーバ710/510と対話せずにクライアントのコンピュータデバイス内で実装できる。代わりに、図5に示すように、クライアントのコンピュータデバイス503は、ただ単にタイルサーバ520からタイルを必要に応じて要求し、表示しさえすればよく、タイルサーバ520は、図9に関連して上記で説明したように以前に生行われたタイルのセットを提供する。
【0076】
フロントエンドサーバ710/510の作動の基本モードは、地図表示ページ800にある(図8に示すフィールド825等の)テキスト記入フィールド内に記入されたユーザのクエリへの応答を提供することである。ユーザがクエリを発信する場合、クライアント側のJavaScriptコードは、クエリの内容だけでなく地図ビューの現在の状態も含むHTTPリクエストを形成し、その情報をフロントエンドサーバ710/510へ発信し、結果のページが隠されたiフレーム(または「仮想ページ」)に表示するように指図する。このメカニズムは、(例えば、ドライブ道案内およびその他の項目のためのオーバレイ等のマッピングシステムの種々の特徴を含む)マッピングシステムを実装することに必要とされるデータを、主/可視のウェブページを再度読み込む必要なく、しかしブラウザの履歴および戻る/進むボタンが予想通り作働することをなお有効にしている間に、クライアントが受信することを容認し、それによりユーザは、局所検索を行い、例えば次いで、道案内を入手し、そして局所検索の結果へ復帰するようクリックして戻ってもよい。仮想ページがクライアントで読み込まれると、主ページ上のJavaScriptは、(1)HTMLのタイトルを変更すること;(2)検索フォームを変更すること;(3)タイルグリッドにあるHTMLのIMG参照を地図画像に表示されるべきタイルのURLで置き換えること;(4)地図表示をパンおよび/もしくはズームすること;ならびに/または(5)地図上に1つ以上のオーバレイを加えることもしくは置き換えること、によって仮想ページからデータを抜き出し、それに応じて主ページを調節してよい。
【0077】
一実施の形態では、以下の種類のクエリが認知され、処理される:
【0078】
1)場所クエリ(例えば、「バークリー」)。これらは、単一の地理的場所を含むクエリである。そのようなクエリに応答して、フロントエンドサーバ710/510は、クライアントに、その場所へ地図をパンおよび/またはズームし、表示上でその場所の境界をマークするように指図する。例えば、一実施の形態で、「点」クエリ(例えば、図8に示すように、特定の住所に対する)は、要求された場所に対する場所マーカーを含む表示の結果になり、その一方で、「線」クエリ(例えば、街路番号を特定せずに、特定の都市における特定の街路に対する)は、要求された線がオーバレイとして地図上に強調されている表示の結果になり、そして、「領域」クエリ(例えば、「エニイタウン(随意市)」等の特定の都市に対する)は、(図28に示すように)要求された領域がオーバレイとして地図上に際立たせられている表示の結果になる。
【0079】
2)局所検索クエリ(例えば、「ピザ店」、「郵便局」)。これらのクエリは、ビジネス名、カテゴリ、またはその他のセットの検索用語を含むが、地理的場所を含まないクエリである。そのようなクエリに応答して、当該技術に精通する者に既知の技法を用いて、フロントエンドサーバ710/510は、ユーザの地図ナビゲーションまたは場所を求めるクエリからの結果の位置決めに基づいて現在の地図ビュー内で(またはその近傍で)クエリに一致するビジネスを検索し、クライアントのコンピュータデバイス503に、結果を地図画像805上に1セットの場所マーカー845/850として、選択肢でそれぞれのマーカーが象徴している検索結果を記述する、地図画像805に付随した、地図凡例と並んで、表示するように指図する。
【0080】
3)条件付局所検索クエリ(例えば、「パロアルトにあるピザ店」、「サンフランシスコ近くのシングルモルトスコッチ店」)。これらは、検索用語および地理的場所の両方を含むクエリである。そのようなクエリに応答して、フロントエンドサーバ710/510は、クライアントのコンピュータデバイス503に、表示された場所へパンおよび/またはズームし、その場所内またはその周りで見付けられた検索結果を表示するよう指図する。代替として、クエリに含まれる地理的情報は緯/経点へ変換され、局所検索がこの1セットの緯/経点に対して導かれ、その後に局所検索の結果にある全ての場所が地図画像上に表示されることを確保するようにズームレベルが設定される(「ニューヨークにある大きな寿司店」の検索を仮定して、結果の表示に対する図24を参照)。
【0081】
4)ドライブ道案内クエリ(例えば、「サンフランシスコからニューヨークまで」、「自宅から仕事場まで」、または「カリフォルニア州、ロサンゼルス、メインSt.123から、カリフォルニア州、パロアルト、ユニバーシティAve.801まで」)。これらは、2つの区別できる地理的場所を含むクエリである。先に説明したように、そのようなクエリに応答して、一実施の形態で、フロントエンドサーバ710/510は、経路情報を、文章の曲がり角ごとの道案内と共に、クライアントへ送信でき、クライアントは次いで、地図画像805に強調されたオーバレイ進路として経路を表示してもよい。先にも、説明したように、ユーザは、(例えば、特定のドライブ手引きをクリックするか、または他の方法で選択することで)経路の一部分を拡大することによって文章の道案内と対話して、追加の文章のまたはグラフィカルな詳細を取得してもよい。
【0082】
フロントエンドサーバ710/510は、クエリ分類器に基づいて選択される数多くの様々な論理的制御フローとして実装できる。クエリ分類器は、クエリが検索用語、地理的場所識別子、および文字の文章を含む成分部品へのクエリ文字列の分解の仕方を定義する1セットのテンプレートを取る場所抽出器を含む。例えば、「{QUERY} {STANDALONE_CITY}」等のテンプレートは、ユーザによって単に「ピザパロアルト」として記入されたクエリに一致することになり、カリフォルニア州、パロアルトの中心部近傍の「ピザ店」を検索する結果になる。場所抽出器は、街路名、都市名等の種々の種類の1セットの場所の名前から成る比較的大きいデータベースへのアクセスを有する。
【0083】
一実施の形態では、図10に示すように、フロントエンドサーバ710/510は、また、ジオコーディング/ジオマップ(geomap)サーバ1010を含み、それは体系的でない場所を、体系的場所に加えて図8の地図画像805上にマークできる地理的点/線/領域に変換する。図10にも示すように、ジオマップサーバ1010は、掘り下げ(drill-down)サーバ1015、地図データ記憶装置領域920、場所データサーバ1000、および局所検索サーバ1010と協調的に通信して、番地、街路、交差点、興味のある点、都市、近隣、郵便番号、郡、首都圏、州等(だけでなくそれらの国際的に同等なもの)の地理的特徴を処理する。番地等の点特徴について、変換の結果は、単一の(緯度、経度)点である。街路等の線の特徴について、および都市等の領域の特徴について、変換の結果は、ポリライン(例えば、街路について)、またはポリゴン(例えば、都市について)のいずれかであり、それはこれらの特徴のそれぞれを定義する。代替として、変換の結果は、単純に、軸合わせした境界付けボックスであってもよい。
【0084】
図10に、また、示すように、一実施の形態では、フロントエンドサーバ710/510は、また、所与の地理的場所での、またはその周りの検索結果を見出すための局所検索サーバ1005を含む。「パロアルトにあるピザ店」等の組合せたクエリについて、局所検索サーバ1005は、実行する前にジオコーディング/ジオマップサーバ1010の結果を受信することを待ってもよい。デジタルマッピングシステムについて、順応性のある場所絞り込みの定義および距離平準化の概念を有する局所検索サーバ1010内で局所検索の採点アルゴリズムを実装することが望ましい。ユーザは、所与の1セットのクエリ用語に一致するビジネスを現在の地図ビュー内で有利に検索できなくてはならない。これは、局所検索コードがただ中心点と半径だけの代わりに最小と最大の緯度および経度座標の形体を有する絞り込みを容認することを必要とする。幾らかの程度の距離平準化が、一般的に必要である。換言すれば、地図表示の厳密な中心での結果が、表示ビューのほかのどこかの結果より高い得点となってはならない。例えば、「パロアルトにあるピザ店」を検索して、2店のパロアルトピザ店営業所が、一方が他方よりパロアルトの中心部にたまたま近いために異なる得点となってはならない。
【0085】
一実施の形態では、「ドライブ道案内」クエリがフロントエンドサーバ710/510で認知される場合、フロントエンドサーバは、起点および目的地の住所を1セットの簡単な曲がり角ごとの道案内だけでなく経路に沿った(緯度、経度)座標を指定するポリラインに変換する。フロントエンドサーバ710/510は次いで、経路全体に沿ったベクター情報を含む1セットのポリラインと並んで、曲がり角ごとの道案内をクライアントのコンピュータデバイスへ(例えば、vPageにある)XMLを用いて送信してよい。一実施の形態では、1セットのポリラインをクライアントへ送信する前に、フロントエンドサーバは、クライアントへ送信されるグラフィカルデータ点の合計数を(例えば、当該技術に精通する者に周知の幾何学的操作を用いて、ポリラインのフルセットに対して削除した場合に1または2画素等の一定の所定の閾値以下のエラーの結果になるいずれかのデータ点を1セットのポリラインから削除して)低減し、それぞれの非削除のデータ点をその点が視覚的に妥当になるズームレベルを定義する「グループ」へ割り当てる(例えば、グループ「A」にあるデータ点は、各ズームレベルで表示されることを必要とすることがあり、その一方で、グループ「B」にあるデータ点は、ズームレベルが都市のレベルのビュー以下の精細さに相当するズームレベルを通り越して増大されるまで表示されることを必要としない等)。
【0086】
一実施の形態では、ユーザがドライブ道案内クエリを記入した後に、地図画像805は、選択された経路全体の概観を表示する。ユーザは次いで、経路の一部を拡大し、より詳細なビューを入手してもよい。
【0087】
一実施の形態では、課金メカニズムが、ユーザによってリクエストされた地図ビューの数の経過を把握するために、例えば、地図ビューに関してユーザ訪問の地図領域の合計量の経過を把握するために実装される。図8を参照すると、先に述べたように、課金点860は、地図画像の中心で定義される(とはいえ、課金点860は普通には地図画像805上で可視でない特徴である)。従って、例えば、地図画像805が幅400画素および高さ400画素で定義された領域を備える場合、他の課金点は、水平および垂直の方向に400画素の間隔で定義される(それによって課金点グリッドを作成する)。従って、一実施の形態では、各地図ビューは、少なくとも1件のトランザクションを含む。ユーザがパン操作を始動する場合、課金点グリッドは地図と並んで「移動」し、新規の課金点が地図ビューの中へ入る場合にはいつでも追加の課金トランザクションを発動する。例えば、ユーザが地図画像を200画素だけ右へパンする場合、新規課金点がビューへ入り、新規トランザクションを発動する。一実施の形態では、新規トランザクションはまた、所与のズームレベルでこれまで不視であった地図領域を表示するズーム操作の結果としても、発動されることになろう。トランザクションは、一実施の形態で、クライアントによってフロントエンドサーバ710/510へ報告され、フロントエンドサーバは、全てのユーザからのトランザクション情報を収集し、それを地図情報の商用プロバイダとの契約上の目的に使用する。
【0088】
クライアント側のアーキテクチャおよびアルゴリズム
本発明の実施の形態は、先端的なウェブブラウザで利用可能な広範囲の技術を用いて実装されてもよい。幾つかの実施の形態の共通の図形的特徴は、1セットの地図タイルを「クリッピング形状」の後ろに組立てる能力である。加えて、ユーザのコンピュータデバイス503でのホスト技術は、表示レイアウトへの適度に効率の良い動的な変更を容認するはずである。クライアントのウェブブラウザは、ちらつきを回避するように二重バッファ型の(または同様の)表示を用いてかかる動的な変更を実行する方が好ましいが、必須ではない。例えば、DHTMLは、二重バッファ型表示エンジンを使用する。DHTMLを使用する一実施の形態では、ブラウザは、ユーザの入力、HTTPの完了および時間切れ等のイベントに応答してスクリプト機能を実行する。スクリプト実行中にウェブページに行われた全ての変更は、少なくとも論理的に、画面外のバッファに記録され、それはスクリプトが制御をブラウザへ戻す場合に表示される。
【0089】
下記でより詳細に説明するように、一実施の形態に従うクライアント側アルゴリズムは、一般的に地図タイルレイアウトへ1セットの変更を成すことによって進行し、次いでこれらの変更によって定義された新規のフレームを表示するようにホストシステムに要求する。一実施の形態では、クライアント側での地図表示機能は、以下のとおりのHTMLコードで実装されてもよい:
<div id="mapView" style="position: relative; overflow: hidden;">
<div id="mapDiv" style="position: absolute;">
<table id="mapTable"><tbody>
<tr><td><img src="images/bg.gif"></td>
...
</table>
</div>
</div>
この実施の形態では、サイト上のJavaScriptコードが、mapTableの <img> 要素にある適切な地図タイルを配置することによって、およびmapDivをmapViewに対して移動させることによって地図をパンおよびズームする。従って、この実施の形態でのクライアント側アルゴリズムは、2つの主要な図形要素を実装する。第1要素は、(普通には長方形の)「クリッピング形状」であり、それを通してユーザは地図画像805を見ることになり、それはユーザの地図ビューの形状を定義する。単に一実施の形態でのクライアント側アルゴリズムを明らかにするだけの目的で、クリッピング形状の任意の画素が、その原点として割り当てられる(例えば、長方形のクリッピング形状の事例では左上の画素)。第2の要素は、クリッピング形状より大きく、それの背後に配置されるタイルのグリッドであり、それによりクリッピング形状を共用するグリッドの一部のみがユーザにとって可視である。一実施の形態のこの検討の残部について、このグリッドは長方形であり、このグリッドがサイズを変更するのはクリッピング形状がそうした場合およびその場合のみであることを想定するものとする。この性質が当てはまらない場合には本明細書で検討したアルゴリズムの変形が存在することを当該技術に精通する者は認知するであろう。
【0090】
一般的に、クリッピング形状は、ウェブブラウザのウィンドウ800に対して固定されたままであり、それに反して、本発明の態様に従うクライアント側のスクリプトは、とりわけ地図画像805をパンするようにタイルグリッドの場所をクリッピング形状に対して移動させることになる。図11は、これらの2つの要素を示す一方で、図12は、ウェブページ上への表示のためにクリッピング形状を通してタイルグリッドを処理する結果を表す。図11に示すように、5×5の正方タイルグリッド配列1100は、25の個々のタイル(そのそれぞれが赤い境界の線で定義される)を備える。正方クリッピング形状1110(黒い長方形として示す)は、クライアントのウェブブラウザ上に地図画像として表示されることになるタイルグリッドのサブセットを定義する。図12には、「クリップされた」タイルグリッド配列1200が、クリッピング形状の境界と連続している境界とともに、表示されている。先に述べたように、図8に示す地図画像805も、より大きいタイルグリッド配列の、クリッピング形状と対比された結果である。図13は、基調を成すタイルグリッド座標およびクリッピング形状1305を示し、それは図11および図12に示すもの等の1セットの表示された画像に対応する。図13には、5×5のタイルグリッド配列1300内の25のタイルのそれぞれが一意の1セットのタイル座標によって表されている。
【0091】
一実施の形態では、クリッピング形状は、固定サイズの300×300画素の長方形であり、図8に示すようにウェブページ800の中心に位置決めされる。クリッピング形状は、一実施の形態で、style "overflow: hidden; position: relative" およびid "mapView" を持つDIV要素として実装される。タイルグリッドは、固定サイズの5×5のタイルである。それは、id "mapTable" を持つTABLE要素として実装される。mapTableの25TDの子供達のそれぞれは、単一のIMG要素を含み、それによりタイルを配置することは単にIMG要素のSRC属性を適切に変更することを伴う。mapTable要素は、id "mapDiv" および style="position: absolute" を持つDIV要素の子供である。mapViewおよびmapDivのPOSITIONスタイルは、mapDivのLEFTおよびTOPスタイルを単に変更するによってタイルグリッドをクリッピング形状に対して移動させることを可能にする。
【0092】
一般的に、クリッピング形状のサイズに比べてタイルグリッドのサイズは、下記で説明する種々の実装要因に依存してよい。大まかに言えば、(画素で)クリッピング形状の(幅および高さの両方で)少なくとも2倍のサイズであるタイルの最小のグリッドが、使用されてもよい。また、実装様態の選定次第で、ユーザがクリッピング形状のサイズまたは形状を変更する場合に、タイルグリッドのサイズを動的に変更することが必要かもしれない。
【0093】
以下の例示的な検討の目的で、AおよびBは、タイルグリッドの(タイルの観点における)それぞれ幅および高さを表す。タイルグリッドにおけるそれぞれの位置は、座標の対(a,b)を割り当てられ、左上の位置が座標(0,0)を有し、右下の位置が座標(A−1,B−1)を有する。計算中に、タイルグリッドの外側に該当する位置(a,b)への参照が成されてもよく、ここで、a<0もしくはA≦a、またはb<0もしくはB≦bである。
【0094】
一実施の形態で作成されたそれぞれの地図画像では、クリッピング形状とタイルグリッドとの間の共用部分は、フルクリッピング形状に等しいことになり、それにより地図タイルのみがクリッピング形状によってユーザへ公表される。この文書の残部において、この事実は「共用部分条件」と命名される。
【0095】
上記の想定および定義を適所に置き、クリッピング形状の原点で公表された地図画素の画素座標三重項(x,y,z)によってどのような地図ビューも一意的に照会できる。
【0096】
初期化およびキャッシュ格納
一実施の形態では、ユーザが当初の地図ビュー(x,y,z)を要求したと想定し、更に、対応する地図画素(x,y,z)がタイル(xx,yy,z)に属することを想定すると、クライアント側のスクリプトは以下のように進行する。第1に、タイルグリッドが共用部分条件に違反しないどのような様式でもクリッピング形状に対して配置される。第2に、(a,b)がその時点でクリッピング形状の原点を含むタイルグリッドの位置として定義される。第3に、クリッピング形状を共用するタイルグリッドにあるそれぞれの位置(a+a',b+b')について、タイル(xx+a',yy+b',z)が配置される。第4に、そして最後に、結果として得られたフレームが表示される。
【0097】
一般的に、タイルをともかくタイルグリッド位置に配置することは、一般的にブラウザにタイルがブラウザのキャッシュに存在するか否かを最初に点検させることになり、存在しない場合、必要であるタイルを求める適切なHTTPリクエストを発行させる。所与の実装様態の特定のホスト技術次第で、このHTTPリクエストは、同期してまたは非同期で実行されてもよい。本発明の実施の形態は、ウェブブラウザに個々のタイルをローカルでキャッシュに格納するように仕向けることで性能を改善する。従って、ブラウザ側のスクリプトがブラウザに特定のタイルを表示するように命令する場合、ブラウザは、タイルがブラウザのキャッシュに既に存在しない場合のみHTTPサーバからタイルを要求することになる。このようにして、本発明の実施の形態は、重複した像を含む別々の地図ビューから、これらの別々のビューが異なるブラウザセッションに属する場合でさえ、恩恵を得る。確かに、一旦ユーザが領域をオンラインの間に見た後に、ユーザのブラウザで既にキャッシュに格納されたタイルのみが必要である限り、ユーザは、その同じ領域をオフラインの間に、見ることができる。
【0098】
この効果を達成するために、クライアント側のスクリプトは、一実施の形態で、タイルの座標三重項のみによって決まるURL(「Universal resource locator」)によってそれぞれのタイルを別々に識別する(例えば、http://somedomain.com/tiles?x=0&y=0&z=0)。一般的に、ウェブブラウザは、それぞれのタイルを含むHTTP応答に含まれる期限切れ時間を使用することによって、および/または、ブラウザのキャッシュにあるタイルの直前に改変された時間をサーバ側上のタイルの直前に改変された時間と対比することによって、自身のキャッシュを管理する。これらの2つの方法の後者は、キャッシュに格納されたタイルが使用されるべき場合でさえいくぶん費用の掛かるHTTPリクエストを必要とするので、タイルを送信するHTTPサーバは、以下のトレードオフを前提として経験的に確定された非常に長い時間切れ期間を報告するように構成されてもよい。一方では、より長い期限切れ期間は、正しくキャッシュに格納されたタイルのために必要であるHTTPリクエストの数を最少限する傾向がある。他方では、より短い期限切れ期間は、大きい地図入力ラスタが変化する場合、新規のタイルをウェブブラウザへより早く発効させる(それは、実地面で、新規の道路建設を補正することに、またはラスタを作成する地図描画システムシステムへの改善を活用することに発生することがあろう)。
【0099】
代替として、実装様態は、バージョン番号をタイルのURLへ加えてもよく(例えば、http://www.somedomain.com/tiles?x=0&y=0&z=0&v=1.0)、期限切れ日付をできる限り将来まで報告するようにタイルを送信するHTTPサーバを構成し、そして、新規のタイルが発効を必要とする場合のみ新規タイルのバージョン番号をブラウザ側のスクリプトへ送信する何らかの他の手段を用いてもよい。この代替のシステムは、既に正しくキャッシュに格納されたタイルのためにブラウザによって発行されるHTTPリクエストを最少限にする一方で、新規タイルがキャッシュに格納された古いタイルの代わりに使用されるべき場合に全面的な制御を与える。しかし、この代替は、ブラウザのキャッシュにおいて新規タイルが古いタイルを置き換えるものではないので、ブラウザ側でより多くのディスク容量を使用する傾向が確かにある。本発明の実施の形態は、タイルをサーバからウェブブラウザへ転送することにとりわけHTTPの使用に依拠しないことに注目されたい。ブラウザが対応している他の転送プロトコル、例えばHTTPSまたはFTP等が、代わりに使用できる。当該技術に精通する者が認知するであろうように、それぞれの転送プロトコルは、僅かに異なった手法を要求してタイルをキャッシュに格納することがある。本発明の実施の形態は、また、最新のパンおよびズーム操作に基づいて発見的アルゴリズムを実装してもよく、近い将来に必要でありそうであるタイルを予測し、これらのタイルをブラウザのキャッシュへ転送することにアイドルタイムおよび/または帯域幅を使用する。代替として、アイドルタイムおよび/または帯域幅は、現在は可視でないタイルグリッドにおける位置を更新すること、および/またはユーザが単一レベルのズームの移行を要求することになるとすれば必要であろうタイルを要求することに専念してもよい。
【0100】
図14は、地図タイルをウェブブラウザへ送信し、タイルをウェブブラウザにローカルでキャッシュに格納するための一実施の形態のフローチャートを示す。ステップ1400で、クライアントは場所の候補を受信する(例えば、ユーザは地図を作成するべき場所を図8に示すテキスト記入フィールド825内に記入し、そのあと図8の検索ボタン830を選択してもよい)。次に、ステップ1405で、クライアントのコンピュータデバイスは、場所の候補を場所サーバ(例えば、図10に示す場所データサーバ1000、図5に示す場所データサーバ520、または図7に示すサーバ710)へ送信する。場所サーバは次いで、場所の候補をステップ1410で解析し、場所データの生成の結果になる。ステップ1415で、クライアントは、この場所データを場所サーバから受信し、ステップ1420で、クライアントは、受信した場所データを用いてタイルリクエストを作成する。タイルリクエストにあるそれぞれのタイルについて、クライアントは、要求したタイルが既にローカルで格納されているか否かを判断する。具体的には、ステップ1425で、クライアントは、要求したタイルが既にローカルで格納されているか否かを判断する。
【0101】
タイルが既にローカルで格納されている場合、ステップ1435で、クライアントはそのローカルメモリからタイルを取り出す。代替として、タイルが既にローカルで格納されていない場合、ステップ1430で、クライアントはタイルをサーバ(図5に示すタイルサーバ515等)から取り出す。ステップ1440で、タイルがローカルまたは遠隔のタイル記憶装置のいずれかから取り出されると、要求したタイルが表示される。次に、ステップ1445で、次のタイルリクエストが決定される。さらに多くのタイルがリクエスト内に残っている場合(ステップ1450で行われる判断)、プロセスのループはステップ1425へ戻り、ここで新規に要求したタイルが既にローカルで格納されているか否かに関して判断が行われる。代替として、それ以上タイルがリクエスト内に残っていない場合、プロセスはステップ1455で終了する。
【0102】
多くのターゲットホスト技術は非同期のHTTPリクエストへのアクセスを供与していることに注目すべきである。この特徴は、クライアント側のスクリプトがパン移行中にタイルをタイルグリッドに配置することを容認し、そこでタイルが実際に到着する前にタイルグリッドの移動を開始し、従って、一時的に間違ったタイル(または、代替として、空きスペースつまり空白タイル)をユーザへ表示する。一般的に、所与の実装様態の特定の要件次第で、そのような非同期性は、地図を移動させる前に全ての新規のタイルが到着することを常に待つことに起因することがある非常に長い待ち時間にとって好ましいと見なされてもよい。幾つかの実施の形態では、非同期のリクエストを発行する前に、タイルグリッドにある古いタイルを地図の背景色と同一色である(そしておそらくだいたい常にブラウザのキャッシュにある)静的タイルで置き換えることが有益であることもある。代替として、より複雑な実装様態では、全ての新規のタイルの到着またはやや短い時間切れ期間の期限切れのいずれか(のどちらか早く発生すること)を待ってから地図の移動を開始する。かかる実装様態では、同一色のタイルは時間切れの事例のみに使用されることになろう。
【0103】
オーバレイ
一実施の形態に従うと、基本の地図画像の域を超えた全ての追加の情報(例えば、ドライブ経路、特定の場所)は、オーバレイとして描画でき、クライアント側上で地図の上に配置できる。この手法は全ての追加の情報に使用でき、それは、サーバが要望に応じて特定の追加の情報でいずれの地図も描画する必要がないことを意味する。オーバレイは、例えば、場所マーカーおよび経路を表示すること、ならびに街路および特定の領域を強調することに使用できる。当該技術に精通する者が認知するであろうように、オーバレイは種々の方式で(例えば、画像またはベクターにより)実装されてもよい。例えば、クライアント側のJavaScriptが、HTML要素を地図表示の上に配置してもよい。先に説明したコードの断片の観点で、全てのオーバレイ要素はmapDivに配置されてもよく、それによりそれらはmapDivが移動される場合に地図と共に自動的に移動する。これらのオーバレイ要素の幾つかは、ウェブページが最初に読み込まれる場合に、既にHTMLコード中に(style="display:none"で)あることがあり、その一方で、その他はJavaScriptコードにより後で追加されてもよい。
【0104】
図15は、ドライブ道案内をオーバレイとして地図画像上へ表示するために一実施の形態に従い使用されてもよいフローチャートを図示する。ステップ1500で、クライアントは、ユーザから既に説明した様式でドライブ道案内を求めるリクエストを受信する。ステップ1505で、クライアントは、要求された旅程情報を場所サーバへ送信する。ステップ1510で、場所サーバは、フロントエンドサーバ機能の説明に関連して先に説明したように、旅程情報を解析する。ステップ1515で、クライアントは、先に説明したように、文章のおよび地理的な旅程データを場所サーバから受信する。ステップ1520で、クライアントは、オーバレイのドライブ道案内経路軌跡を地図画像上へ表示することに必要とされるベクターを決定する。ステップ1525で、クライアントは、先に説明したように、図14のフローチャートに従って基本の地図画像を描画する(このステップが既に行われていない場合)。一実施の形態では、ステップ1528で、クライアントは次いで、ドライブ道案内経路軌跡をオーバレイとして基本の地図画像上へ描画する。別の実施の形態では、ステップ1528へ進行する代わりに、ステップ1530で、クライアントは、ステップ1520でクライアントによって計算されたベクター情報に基づいて、場所サーバから旅程画像オーバレイを要求する。この実施の形態では、ステップ1535で、場所サーバが、旅程画像を作成し、それをクライアントへ送信する。最後に、この実施の形態ではステップ1540で、クライアントが、最終的な旅程画像を地図画像上へ重ね合わせる。オーバレイのドライブ道案内を持つ例示的な表示した地図画像を図26に示す。
【0105】
幾つかの実施の形態では、特定のウェブブラウザ(例えば、Mozilla/Firefox)は、上記で説明したようなベクターグラフィックスを描画する能力がないことがある。そのような実装様態では、図10に示すジオマップサーバ1010等の資源が、(例えば、1セットのドライブ道案内に関連するポリラインに対する)オーバレイのビットマップ画像を生成してよく、そこでブラウザは、この透明な画像を地図画像上へ複合してよい。この例ではブラウザがジオマップサーバ1010から直接的にこの画像を要求するために、リクエストはプロトコルバッファの代わりにURLを介している。線の幅および色は、ジオマップサーバ1010へのコマンド−線の選択肢として指定されてもよい。
【0106】
パン操作
一実施の形態では、地図画像のパン操作は、以下のように実装されてもよい。第1に、ユーザが1つの地図ビュー(x,y,z)から新規の地図ビュー(x',y',z')へ同じズームレベルでのパンを要求したと推定し、パンがnフレームにわたり動画的にされるべきことを推定する(ここで、n=1は、古いビューから新規ビューへの切替えが単一ステップで行われることを示し、その一方で、nの高い値は切替えが滑らかな動画的のパンとして提供されるべきことを示す)。更に、2つの地図ビューが、xおよびy軸の両方に沿って、2つのビューの間の距離に加えてクリッピング形状のサイズがタイルグリッドのサイズより(画素で)小さいという意味で、タイルグリッドのサイズに比べて相互に「近い」ことを想定する。
【0107】
上記の想定および定義を念頭に置いて、タイルグリッドの「下へ回転」の操作は、一番下の行を取り、それを一番上の行にすることと定義され、そこで残った位置がそれらの古い場所をクリッピング形状に対して保持するように、結果として得られるグリッドを配置する。同じように、「上へ回転」は一番上の行を一番下の行にすることと定義され、「左へ回転」は左の列を右の列にすること、そして最後に「右へ回転」は右の列を左の列にすること、と定義される。これらの回転操作は、タイルグリッドを移動させることが、そうしなければ共用部分条件に違反することになろう事例に使用される。勿論、同じ効果を(例えば、グリッドにあるそれぞれのタイルを1つの場所だけシフトすることで)達成できるであろう他の様式があるが、しかし上記の操作上の定義が効率的であると分かった。クライアント側のスクリプトは、従って、以下のように進行する。第1に、(dx,dy)=(x,y)-(x',y')とし、(a,b)をその時点でクリッピング形状の原点を含むタイルグリッドの位置とする。第2に、1とnの間のいずれかの整数iについてi*(dx,dy)/nのオフセットだけタイルグリッドが移動された場合にクリッピング形状で共用することになろうそれぞれの位置(a+a',b+b')について、タイル(xx+a',yy+b',z)を位置((a+a')mod A,(b+b')mod B)に配置する。第3に、必要な場合、共用部分条件がタイルグリッドを(dx,dy)のオフセットだけ移動させることによって違反しなくなるまでタイルグリッドを回転させる。第4に、1とnの間のそれぞれのiについて、タイルグリッドを(dx,dy)/nのオフセットだけ移動させ、結果として得られるフレームを表示する。ホストシステムの効率次第で、フレーム間で幾らかの時間一時停止することが必要になることがある。このプロセスにおける第2および第3のステップの順番は逆にしてもよいことを当該技術に精通する者は認知するであろう。また、nが1に等しいと想定することによる第2ステップにおける僅かな緩和は、ほとんど正しい提供の結果になろう(とはいえ、幾つかの中間のフレームはパンが水平でも垂直でもない場合に少しのタイルを欠落することがある)ことに注目されたい。また、上記のプロセスは連続した地図画像に沿って滑らかなパンを提供することを当該技術に精通する者は、認知するであろう。
【0108】
図16は、一実施の形態に従い地図画像のパン操作を実行するためのフローチャートを表す。ステップ1600において、クライアントは、(例えば、図8に示すような方向制御オブジェクト815の起動によって)パンイベントを示すコマンドをユーザから受信する。ステップ1605で、クライアントは、基調を成す地図タイルに対してクリッピングビューアを実質的に移動させる。そこで、ステップ1610で、クライアントは、パン操作の結果として新規に必要であるタイルの場所を決定する。これが決定されると、ステップ1615で、クライアントは、この場所データを用いて、タイルリクエストを作成する。最後に、ステップ1525で、クライアントは、図14に示し、先に説明したプロセスに従い、必要とされるいずれのタイルも取得する。
【0109】
図17から図21は、一実施の形態に従いクリッピング形状の幅の1/3だけ西へパンする例示的プロセスを示す。図17は、先に説明したプロセスの第2ステップでタイルが更新される前の地図画像およびタイルグリッドの状態を描出し、その一方で、図18は、この更新が完了した後の状態を表す。図19は、先に説明した第3ステップに従い1つの「右へ回転」操作が実行された後の状態を描出し、その一方で、図20は、第4ステップで数フレームが表示された後の状態を表す。最後に、図21は、パン操作プロセスが完了した後の最終状態を表す。
【0110】
より大きいグリッドは、上記のプロセスを用いて一般的により長いパンが滑らかに提供されることを容認することを当該技術に精通する者は認知するであろう。一実施の形態では、クリッピング形状のサイズの2倍より僅かに大きいグリッドを使用する実装様態の選定は、現在の地図ビューのサイズまでの滑らかなパンを容認する。タイルグリッドのサイズを増大させることなくより長いパンを実行するために、パン操作全体が、単純に一連のより小さいパン操作に分割されてもよいが、この手法は僅かに滑らかでない提供の結果になることがある。
【0111】
上記のパン操作アルゴリズムは、動画の第1フレームでさえ提供する前に全ての必要なタイルを更新する。この手法は、ユーザがリクエストをする時間と地図が実際に開始する時間との間に少し待ち時間を導入することがある。これを克服するために、実装様態は、n−フレームのパンを、たとえばn回の別々の1−フレームのパンに分割することを選んでもよい。しかし、ただこの技法のみでは、それぞれのフレームを作成する作業量は更新を必要とするタイルの数で大幅に変動することがあるので、滑らかでない提供の結果になることがある。より洗練された実装様態は、この問題を、将来フレームのために必要であるタイルを予測的に更新してフレームの間で更新を必要とするタイルの数を均等にすることによって克服する。
【0112】
ズーム操作
一実施の形態では、「ズーム操作」は、2つのビュー(x,y,z)と(x',y',z')との間の移行を称し、ここでz≠z'であり、2つのビューに対応する緯/経値はクリッピング長方形のサイズと比べて接近している。以下の検討は、アンカーを含む画素が2つのビューのそれぞれにおいてクリッピング形状の同じ画素を占有するという意味で、緯/経「アンカー」の周りに「垂直」であるズーム操作に焦点を当てる。普通には、ズーム操作のアンカーは、クリッピング形状の中心であることもあろうが、しかしそれは、また、場所マーカー(例えば図8に示すマーカー845等) の緯/経、ユーザによって選択された画素に対応する緯/経、または地図画像内の他のどのような場所でもあり得よう。パン操作をズーム操作と組合せる移行は幾つかの実装様態で組合されてもよいことに注目すべきである。
【0113】
一般的に、ズーム操作は、クリッピング形状で共用する各タイルが更新されなければならないので、タイル更新の観点でパン操作より高価な操作である。この理由のために、そして滑らかに動画的に行うズームは費用の掛かる画像の拡大縮小操作を必要とするために、一実施の形態は、先に説明した初期化ステップを単に実行することによって、全てのズーム操作を単一のフレームで実行する。
【0114】
以下の検討は、一実施の形態に従いユーザへ滑らかに動画的に行うズーム操作を提供する手法を概説し、それは幾つかの例示的ホスト技術(例えば、FlashおよびJavaアプレット)において実装可能である。簡単にするために、2つのズームレベルzとz'の間の拡大縮小係数差異が厳密に2であること、z'=z+1であること、そしてn動画フレームにわたる移行を提供することが望ましいことを想定する。この検討において、「最終フレーム」は、上記で説明した初期化ステップを用いて単一フレームで単にズーム操作することによって作成されることになるフレームを称する。更に、s(拡大縮小係数)が2のn乗根に等しいとする。
【0115】
これらの定義および想定を念頭に置いて、ズーム操作アルゴリズムの一実施の形態は、以下のように進行する。第1に、最終フレームが組立てられる(が、表示されない)。第2に、1とn−1の間のiについて:(a)最終フレームのために必要であるタイルがs^(n−i)の係数で拡大縮小される;(b)拡大縮小されたタイルはアンカーが正しく配置されるように配置される;そして(c)結果として得られるフレームが表示され、適切な場合一時停止が含まれる。第3に、最終フレームが表示される。
【0116】
代替として、z'=z−1の場合、現在のビューのタイルが、最終のビューのタイルの代わりに以下のように拡大縮小されてもよい。第1に、上記のように、最終フレームが組立てられる(が、しかし表示されない)。第2に、1とn−1の間のiについて:(a)現在のビューのタイルがs^(i) の係数で拡大縮小される;(b)拡大縮小されたタイルはアンカーが正しく配置されるように配置される;そして(c)最終フレームが表示され、適切な場合一時停止が含まれる。
【0117】
上記の実装様態の両方の第2ステップ(パート(a))において、第2ステップのパート(b)が実行された後にクリッピング形状を通して結局公表されるタイルのためにのみ拡大縮小が必要とされることに注目されたい。また、第2実装様態の第1ステップは第3ステップまで延期できることにも、注目されたい。これらの実装様態の両方において、同じ地理的領域をカバーするのにより高いズームレベルではより少ないタイルが必要であるので、全ての中間のフレームは、より高いズームレベルのタイルを用いて作成される。より込み入った代替の実装様態は、より低いズームレベルからのタイルを使用することによって、または現在および最終のフレームの両方からの拡大縮小されたタイルをアルファブレンドすることによって、中間フレームの幾つかを作成することを追求し、「モーフィング」と同様の効果を作成する。また、多数のズームレベルに及ぶズーム移行も、一連の単一レベルの移行として実装されてもよい。
【0118】
図22は、一実施の形態に従いズーム操作を実装するための例示的フローチャートを表す。ステップ2200で、クライアントは、(例えば、図8に示すように、ズーム制御オブジェクト820の起動によって)ズーム動作イベントを受信する。ステップ2205で、クライアントは、ズームした表示の中心を決定する。そこで、ステップ2210で、クライアントは、決定された中心の場所データを用いて新規のズームレベルでタイルリクエストを作成する。最後に、クライアントは、図14に関連して先に説明したプロセスに従いズームした地図を描画する。
【0119】
スライド操作およびジャンプ操作
以下の検討は、ただ滑らかなズーム操作およびパン操作のみのためには遠過ぎる地図ビューの間の移行を考慮する。例えば、現在の地図は、カリフォルニア州バークリーにある街路を表示することがあるが、ユーザは、ニューヨーク州のダウンタウンのマンハッタンにある街路のナビゲーションショートカットを選択するか、またはビューを要求するかもしれない。この状況への2つの例示的手法が提供され、「スライド操作」および「ジャンプ操作」と命名される。
【0120】
一実施の形態の「スライド操作」手法に従って、クライアント側のスクリプトは、最終ビューを組立て、(普通には別々のタイルグリッドを利用して)それを現在のビュー上へ古いビューに対して新規ビューの方向から滑らかにスライドさせる。代替として、一実施の形態の「ジャンプ操作」手法に従って、クライアント側のスクリプトは、最初に縮小し、そのあとパンし、そして最後に目標のビューをズーム戻しする。クライアント側のスクリプトは、最低のズームレベルへ縮小し、それぞれの特定の実装様態の要件にとってパンを(画素で)十分短くさせる最低のズームレベルでパンを導く。より洗練された実施の形態は、この「ボックス形状」の動き(すなわち、ズームで上昇、パン、ズームで降下)を滑らかな曲線形の動きに変換する。「ジャンプ操作」手法は、「スライド操作」手法が必要とするよりはるかに多大の数のタイルおよびより多くの演算資源を必要とすることを当該技術に精通する者は認知するであろう。
【0121】
サイズ変更
主として地図ビューの周囲のウェブサイト次第で、ユーザは、地図ビューがサイズおよび/または形状を変更することを要求することがある。タイルグリッドのサイズをクリッピング形状のサイズに関係付ける仕方の実装様態の選定に依存して、この要求は、次にタイルグリッドのサイズ変更を余儀なくさせることがある。この操作のために幾多の可能な実装様態があり、以下を含むがそれに限定されない。現在ビューが(x,y,z)であること、対応する画素がタイル(xx,yy,z)に属すること、そして、クリッピング形状のサイズ変更はその原点の周りで行われるはずであることを想定する。そこで、第1ステップは、クリッピング形状をサイズ変更/形状変更することである。次に、必要な場合、タイルグリッドのサイズは、共用部分条件に違反しないために必要な最小サイズへ(例えば、複数の行を一番下へおよび/または複数の列を右へ加えることによって)増大および移動される。次に、(a,b)が今はクリッピング形状の原点を含むタイルグリッドの位置であるとする。次のステップとして、クリッピング形状を共用するタイルグリッドにおけるそれぞれの位置(a+a'、b+b')について、タイル(xx+a',yy+b',z)を配置する。次に、フレームが表示される。最後に、必要な場合、タイルグリッドのサイズは、タイルグリッドがかさねてクリッピング形状のサイズの少なくとも2倍であるように、(例えば、複数の行を一番下へおよび/または複数の列を右へ加えることによって)増大される。サイズ変更の移行は、先に説明したように、パンの移行を動画的に行うのと同じ技法を用いて動画的にできる。また、特定の実装様態のために所望の場合、タイルグリッドを増大させる最終ステップは、タイルグリッドのサイズを増大および移動させる当初のステップの中へ組合せてもよいことに注目されたい。原点は上記の検討では任意に選ばれたこと、およびこの条件が一般的に真であることは当てにできないことを当該技術に精通する者は認知するであろう。しかし、上記で説明したステップは、当該技術に精通する者によってこの追加の複雑さを説明するように容易に調整されてもよい。
【0122】
場所マーカー
先に述べたように、一実施の形態に従う場所マーカーは、(情報ウィンドウ等の他のオブジェクトと並んで)、対応する陰影とともに地図画像上へオーバレイでき、それはそれらの相対的位置を識別することを容易にする。一実施の形態では、陰影が、あたかも場所マーカーが地図上に垂直に立っているかのように見えるように描画でき、陰影は45°の角度で傾斜され、係数√2で引き伸ばされ、そして垂直面上へ後方に投影される。そのような陰影は、場所マーカーが三次元様式で地図上に配置されたように見えさせるようにでき、ユーザが場所マーカーで指向された場所をより正確な様式で識別する助けをし、そしてまた、多数のマーカーが相互に干渉することを防止する助けもする特徴である。加えて、場所マーカーは、地図画像上へ重ね合わされたアンチエイリアス処理されたマーカーを含むアルファチャネルを持つPNGファイルによって表されてもよい。図23は、本発明の一実施の形態に従い1セットの場所マーカーを地図画像上へ重ね合わせるための例示的フローチャートを表す。ステップ2300で、クライアントは、ユーザから場所に基づく情報を求めるリクエストを受信する。そこで、ステップ2305で、クライアントは、リクエストを場所サーバへこれまでに説明した様式で送信する。ステップ2310で、場所サーバはリクエストを解析する。次に、ステップ2315で、クライアントは、場所に基づく情報を場所サーバから受信する。ステップ2320で、クライアントは、この情報を1セットの画素情報へ翻訳する。そこで、ステップ2325で、クライアントは、地図画像上へ重ね合わされるか、または他の方法で配置されるべきマーカーおよび陰影の画像を(ローカルまたは遠隔の場所サーバからのいずれかで)取り出す。ステップ2330および2335で(それらは特定の実装様態のために所望される場合には明瞭に逆にできる)、クライアントは、それぞれ陰影およびマーカーを地図画像上へ(例えば、それらを地図画像上へ重ね合わせることで)配置する。図24は、本発明の態様に従う、「ニューヨークにある大きな寿司店」を求めるテキストフィールド825での例示的リクエストの結果を表示する、(「A」から「J」と命名された)多数の重ね合わされた場所マーカーを持つ例示的地図表示のウェブページを表す。
【0123】
重ね合わされた画像の別の例として、図27は、本発明の態様に従う重ね合わされたドライブ道案内経路軌跡を持つ例示的地図表示のウェブページを表す。図27は、所望の出発住所を示すための第1テキスト記入フィールド825、終着住所を示すための第2テキスト記入フィールド828、所望のドライブ道案内に対応する強調された重ね合わされた経路軌跡2710、対応する1セットの文章のドライブ道案内2730、ドライブ道案内の終着点を示す場所マーカー845およびその陰影855、ドライブ道案内の出発点を示す同様な場所マーカーおよびその陰影855、および、経路に沿った特定の選択された手引き(例えば、「モフェットBlvd.出口を取る」)に対する詳細な地図ビュー2725を表示する情報ウィンドウ2720およびその陰影855を含む。同様に、図28は、本発明の態様に従う重ね合わされた領域境界軌跡を持つ例示的地図表示のウェブページを表す。
【0124】
図29は、本発明の一実施の形態に従い地図画像上へ(図8に示す情報ウィンドウ840およびその陰影855等の)1セットの情報ウィンドウを重ね合わせるための例示的フローチャートを表す。ステップ2900で、クライアントは、場所情報のユーザの選択を受信する(例えば、ドライブ道案内クエリの結果として生行われたドライブ手引きをユーザが選択する場合)。ステップ2905で、クライアントは、場所情報に基づいて対応するHTMLコードを作成する。例えば、HTMLコードはXSLT(Internet Explorerまたは他の市販のウェブブラウザで利用可能な共通のスクリプト言語)を用いて場所情報を含むXMLコードをHTMLに変換することによって作成されてもよい。作成されたHTMLコードは次いで、図26Aに示すHTMLテーブル2605等のテーブルの中へ挿入されてもよい。そこで、ステップ2910で、クライアントは、その後に地図画像上へ重ね合わされるHTMLウィンドウの境界の固定の部分のために1セットの予め描画した区画(例えば、図26Aに示すように第1コーナー区画2610、第2コーナー区画2612、第3コーナー区画2614、第4コーナー区画2615、および指示区画2622)を取得する。ステップ2915で、クライアントは、これらの予め描画した区画を接続して情報ウィンドウの境界の非固定の部分を作成する。例えば、情報ウィンドウの外側境界は、図26Aに示すように、例えば、接続された線2620により等の予め描画した区画の間の線を生成することで確定されてもよい。そこで、ステップ2920で、下記で検討するように、クライアントは、その後に地図画像上へ重ね合わされる1セットの予め描画した区画を確定および取得し、情報ウィンドウの陰影画像の固定の部分を生成する。ステップ2922で、下記で、また、検討するように、クライアントは、予め描画した区画を接続して情報ウィンドウの陰影画像の残りを埋める。
【0125】
図26Bは、基素の構成要素と並んで、情報ウィンドウと共に使用するための(また、図8および27で要素855として示す)情報ウィンドウの陰影2625の例を示す。陰影画像2625は、上記で説明したように作成された情報ウィンドウ2600の動的サイズに比例して対応するように動的に作成されてもよい。陰影画像2625を動的に作成するための例示的方法は、図26Bを参照して、以下のように進行してよい。陰影画像2625の高さは、情報ウィンドウ2600の高さの半分として設定されてもよい。図26Bに示すように、HTMLテーブルの陰影2625のサイズは、陰影のぼやけた輪郭線(存在する場合)を含み、それが半分の高さで陰影を含むことができるように確定される。情報ウィンドウの角度付きの垂直線(例えば、線2635)は、等角図法に一致するように所定の角度、例えば、角度45度でそれらを斜めにすることで作成されてもよい。例えば、オフセット線2635は、角度45度に設定される。これらの角度付きの線は、クライアントまたはサーバのいずれかで、クリッピング長方形を用いて予め描画した角度付きの陰影線の必要とされる部分のみを表示することで作成されてもよい。クライアントは、また、陰影画像のコーナーおよび指示区画のための1セットの予め描画した区画を確定する。図26Bでは、例えば、情報ウィンドウの陰影ボックスコーナー区画2640および情報ウィンドウの陰影指示区画2645が、サーバからまたはローカルでのいずれかで取得されてもよい。情報ウィンドウ2600のサイズに基づいて陰影画像の境界を確定した後に、そして適切な予め描画した区画を取得しクリッピングした後に、そこで接続線の残りが確定され、描かれてもよい。
【0126】
陰影画像は、また、図26Bに示すような、陰影同様の外見を作成するように埋められてもよい。陰影同様の外見を更に向上させるために、情報ウィンドウの下部に最も近い陰影画像部分が、最も暗くおよび/または最も鮮明であってよく、その一方で、陰影画像の部分が情報ウィンドウの下部から遠く離れて配置されている埋め部を徐々に色を薄くするおよび/またはぼやけさせる。
【0127】
図29へ戻り参照すると、ステップ2925で、クライアントは、陰影を地図画像上へ重ね合わせる。最後に、ステップ2930で、クライアントは、情報ウィンドウを地図画像上へ重ね合わせる。図8、26A、26Bおよび27の例から分かるように、この方法は、デジタル地図上にその陰影と並んで表示される場合に、全体として三次元的に見える情報ウィンドウを作成する。選択肢で、三次元的外見は、情報ウィンドウが北から始まって南へ配置されるように多数のタイルウィンドウを配置することで向上させることがあり、それにより奥行きの感覚も提供される。情報ウィンドウを東から西へ配置すること等の他の選択肢も利用可能である。この方法は、また、2つ以上のマーカーを地図上に配置する場合に使用されてもよい。
【0128】
図25を参照すると、同様な技法が、場所マーカー2500のための角度付き陰影2505を生成することに用いられてもよい。
【0129】
図30は、本発明の一実施の形態に従い地図画像表示ウィンドウをサイズ変更するための例示的フローチャートを表す。ステップ3000で、クライアントは、地図画像表示ウィンドウのサイズでの変更の通知を受信する(例えば、ユーザによるウィンドウのサイズ変更動作の結果として)。そこで、ステップ3005で、クライアントは地図画像ウィンドウの中心を決定する。次に、ステップ3010で、クライアントは、ウィンドウのサイズが増大されたか否かを判断する。そうである場合、ステップ3025で、クライアントは、新規の追加のスペースを埋めることに必要とされるかもしれない新規のいずれの地図タイルのIDを決定し、ステップ3030でクライアントは、これらの新規のタイルを、そのローカルキャッシュまたは遠隔サーバのいずれかから要求する。ステップ3035で、クライアントは、新規タイルをタイルテーブル配列に配置し、新規地図画像を表示する。代替として、ステップ3010でクライアントが、ウィンドウのサイズが減少されたと判断する場合、ステップ3015で、クライアントは、クリッピング形状ウィンドウのサイズを比例して低減する。最後に、ステップ3020で、クライアントは、クリッピング形状ウィンドウを地図画像の中心上に再度中心を合わせる。
【0130】
高解像度印刷
従来のウェブ地図サイトから地図ビューを印刷すると、地図ビューが先端的なプリンタの解像度より1桁低いことが多い画面の解像度で提供されるので、一般的に粗悪な出力を作成する。しかし、幾つかのホスト技術は(一実施の形態で使用されたようなDHTMLを含み)、印刷のために好適な解像度での地図タイルを使用する地図ビューの組立てを容易にする。従って、一実施の形態で地図画像の高品質ハードコピーを達成するために、地図ビューは、印刷解像度のタイルを用いて再組立てできる。一実施の形態はHTML IMG要素を用いてタイルをタイルグリッドに配置するために、128×128画素のサイズで1つ(例えば、screen_tile.gif)、512×512画素のサイズでもう1つ(例えば、print_tile.gif)の同じ地図タイルの2つの画像が、それぞれ表示および印刷の目的に使用されてもよい。図31は、本発明の一実施の形態に従い地図画像の高品質印刷のための例示的な1セットの様々な解像度の地図画像タイルを表す。図31に示す第3画像は、第1画像の高解像度バージョンのように見えることを当該技術に精通する者は気が付くであろう。この所見を用いて、ユーザからの印刷リクエストに応答して、現在の地図ビューは、印刷−解像度のタイルを用いて再組立てされてもよく、優れた印刷出力を達成する。
【0131】
この文書に説明および示されたフローチャートのステップを実装するためのソフトウェアおよび/またはハードウェアは、コンピュータデバイス503ならびに/もしくはサーバ510、515、および520とのどのような組合せ上でも、またはコンピュータデバイス503とネットワーク505との間で接続されているインターネットサービスプロバイダのサーバ等の図示されていない他のコンピュータデバイスもしくはサーバ上でも、実装されてもよい。その上、図示のブロックは、異なる順番で実行されてもよく、図示した厳密な順序で実行されることを必要としない。その上さらに、非依存の動作は並列して実装されてもよい。
【0132】
上記で説明したような実施の形態の態様は、図に図示した実装様態において多くの様々な形体のソフトウェア、ファームウェア、およびハードウェアで実装されてもよいことも、当該技術で通常の技量の者に明白であろう。本発明の原理に整合する態様を実装することに使用される実際のソフトウェアコードまたは特化した制御ハードウェアは、本発明の限定とはならない。従って、実施の形態の幾つかの態様の作動および挙動は、特定のソフトウェアコードに関連することなく説明した当該技術で通常の技量の者が本明細書の説明に基づいて態様を実装するソフトウェアおよび制御ハードウェアを設計することをできるであろうことが理解される。更に、実施の形態の幾つかの部分は、1つ以上の機能を実行する「ロジック」として実装されてもよい。このロジックは、特定用途向け集積回路またはフィールドプログラマブルゲートアレー等のハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組合せを含んでいてもよい。
【0133】
幾つかの例示的な実施の形態が、添付図面に示され、説明された。しかし、そのような実施の形態は単に例証的であり、制限的でないと理解されるものとする。種々の他の改変形態が当該技術に精通する者に思い浮かぶであろうために、本開示は、明示的に開示した特定の構造および編成に限定されてはならない。
【図面の簡単な説明】
【0134】
【図1】地図リクエスト記入のウェブページを表示する例示的なウェブブラウザを示す。
【図2】ウェブブラウザ上の例示的な地図表示を示す。
【図3】例示的な従来のベクターベースのデジタルマッピングシステムのアーキテクチャを示す。
【図4】例示的な従来のラスタベースのデジタルマッピングシステムのアーキテクチャを示す。
【図5】本発明の態様に従う分散型ネットワークシステムを示す。
【図6】本発明の態様に従うクライアント側またはサーバ側のコンピュータデバイスの例示的なブロック線図である。
【図7】本発明の態様に従う例示的なタイルベースのデジタルマッピングシステムのアーキテクチャを示す。
【図8】本発明の態様に従う例示的な地図リクエスト記入と地図表示とを組み合わせたウェブページを示す。
【図9】本発明の態様に従う例示的なサーバ側アーキテクチャを示す。
【図10】本発明の原理に整合する例示的なサーバ側アーキテクチャの更なる態様を示す。
【図11】本発明の態様に従う例示的な地図画像のタイルグリッドおよびクリッピング長方形を示す。
【図12】本発明の態様に従い例示的タイルグリッドをクリッピング長方形と対比した後に結果として得られる地図画像を表す。
【図13】本発明の態様に従う例示的な1セットの表示した画像に対応する基調を成すタイルグリッド座標およびクリッピング形状を示す。
【図14】本発明の態様に従い、地図タイルをウェブブラウザへ送信し、タイルをウェブブラウザにローカルでキャッシュに格納するための一実施の形態のフローチャートを示す。
【図15】ドライブ道案内をオーバレイとして地図画像上へ表示するために一実施の形態に従い使用されてもよいフローチャートを示す。
【図16】本発明の一実施の形態に従い地図画像のパン操作を実行するためのフローチャートを表す。
【図17】本発明の一実施の形態に従いクリッピング形状の幅の1/3だけ西へパンする例示的プロセスを示す図であって、同パンの第1の状態を示す。
【図18】同パンの第2の状態を示す図。
【図19】同パンの第3の状態を示す図。
【図20】同パンの第4の状態を示す図。
【図21】同パンの第5の状態を示す図。
【図22】本発明の一実施の形態に従いズーム操作を実装するための例示的フローチャートを表す。
【図23】本発明の一実施の形態に従い1セットの場所マーカーを地図画像上へ重ね合わせるための例示的フローチャートを表す。
【図24】本発明の態様に従う多数の重ね合わされた場所マーカーを持つ例示的地図表示のウェブページを表す。
【図25】本発明の態様に従う例示的場所マーカーの詳細を表す。
【図26A】本発明の態様に従う例示的情報ウィンドウの詳細を表す。
【図26B】本発明の態様に従う追加の例示的情報ウィンドウの詳細を表す。
【図27】本発明の態様に従う重ね合わされたドライブ道案内経路軌跡を持つ例示的地図表示のウェブページを表す。
【図28】本発明の態様に従う重ね合わされた領域境界軌跡を持つ例示的地図表示のウェブページを表す。
【図29】本発明の一実施の形態に従い地図画像上へ1セットの情報ウィンドウを重ね合わせるための例示的フローチャートを表す。
【図30】本発明の一実施の形態に従い地図画像表示ウィンドウをサイズ変更するための例示的フローチャートを表す。
【図31】本発明の一実施の形態に従い地図画像の高品質印刷のための例示的な1セットの様々な解像度の地図画像タイルを表す。
【技術分野】
【0001】
関連出願の相互参照
本出願は、2004年5月3日出願の米国仮特許出願第60/567,946号に対する優先権を主張し、その全体を引用して本明細書に組込む。本出願はまた、2004年3月23日出願の米国仮特許出願第60/555,501号に対する優先権を主張し、その全体を引用して本明細書に組込む。
【0002】
本発明の原理に整合する実装様態は、一般的にマッピングシステムに関し、より詳細には、デジタル環境におけるマッピングシステムに関する。
【背景技術】
【0003】
コンピュータ化したマッピングシステムが、旅行計画を容易にするために開発されてきた。例えば、旅行計画インターネットウェブサイトが、商用に供されており、良く知られている。そのようなウェブサイトは、普通にはユーザが要求した場所クエリを入力することができ、それにより要求した場所に関連する地図がユーザへ提供できる。また、良く知られたウェブサイトは、ユーザに旅行の出発点と終着点を記入させて、次いで旅程を計算しユーザへ提供することに使用できる。
【0004】
以下に続く本発明の幾つかの態様の詳細な検討のための背景として、図1から図4が、従来の例示的デジタルマッピングシステムの幾つかの態様を表す。図1は、地図リクエスト記入のウェブページ105を表示するウェブブラウザのユーザインタフェース100を示す。図示のように、ユーザは、所望の場所のモンタナ州45619、ビリングス、メインSt.353を記入した。地図を作成するべき所望の場所を記入した後に、図1に示すように、ユーザは次いで、「地図リクエスト」ボタン110を選択することで(普通には遠隔サーバから)地図を要求する。地図画像は次いで、普通には遠隔サーバで生成され、ユーザのコンピュータデバイスへ送信され、結局地図表示のウェブページにあるウェブブラウザのユーザインタフェース100上に表示される。
【0005】
図2は、ウェブブラウザのユーザインタフェース100上の例示的地図表示のウェブページ200を示す。ここでは、地図表示のウェブページ200は、図1からの地図リクエストの結果を表示している。表示された情報は、一般的に地図画像205から成り、要求された場所および周囲の領域を表す。図2に示すように、要求された場所は、地図画像205上に住所アイコン208で識別され、住所アイコン208は、普通には地図画像205の中心に配置される。また、要求された場所および住所アイコン208は、地図表示のウェブページ200内の地図凡例ウィンドウ210にも表示されてもよい。住所アイコン208は、普通には簡単な二次元画像であり、地図画像205内で他のそのようなアイコンと近接近して表示される場合、視覚的混乱を生じることがあり、それぞれのアイコンが地図画像205内で実際に示す箇所に関してユーザを困惑させ、誤り導くことがある。
【0006】
地図のウェブページ200は、地図画像205が表示される様式を制御するよう選択できるボタンまたは他のユーザインタフェースオブジェクトも表示できる。例えば、図2に示すように、ズーム制御オブジェクト220が一般的に設けられ、ユーザが「拡大」または「縮小」することを容認し、それによって地図画像205の表示された縮尺比にそれに応じて影響を及ぼし、その一方で、普通には住所アイコン208で印付けた所望の場所を画像の中心に保持する。また、「下向矢印」方向ボタン215等の方向ボタンまたは他の同様なユーザインタフェースオブジェクトが設けられてもよく、地図画像205の「南の」境界を越えたためにこれまでは隠されていたより多くの地図情報を表示すること等によってユーザが画像を「パン」することを容認し、その一方で、これまで表示されていた地図情報の「北の」部分の相当する部分をシフトさせて隠す。図2に示すように、そのような画像制御オブジェクトは、従来では地図画像205の境界領域の外側に表示され、地図表示ウェブページ200内の地図画像205のために利用可能なスペースの量を低減させる。
【0007】
普通には、(図2に示すズーム制御オブジェクト200または方向ボタンボタン215等の)画像制御オブジェクトが選択される場合、HTTPリクエストがサーバへ送信され、サーバはそこで選択されたズームレベルで表示されるべき新規の地図情報を含む新規の画像を送信する。
【0008】
具体的には、図3に示すような、例示的システムにおいて、ウェブブラウザ300は、要求された地図画像に対する場所情報を含むHTTPリクエストをウェブサーバ305へ送る。HTTPリクエストは、図1に示すように、データ記入ウェブページ105を通してウェブブラウザユーザインタフェース100を介して受信した場所データから成ってもよい。例えば、図1に示し、先に説明したように、ユーザは以下の地図を作成するべき所望の場所を記入してよい:モンタナ州45619、ビリングス、メインSt.353。ユーザは次いで、「地図リクエスト」ボタン110を選択することで道案内を要求し、この選択イベントが、結局図3に示すHTTPリクエストをウェブブラウザ300からウェブサーバ305へ(直接的または間接的に)送信させる。HTTPリクエストに応答して、ウェブサーバ305は、データベースクエリ(「DBクエリ」)を地図ベクターデータベース310へ送る。地図ベクターデータベース310は、普通には所望の場所データについての対応するベクターを決定し、これらのベクターをウェブサーバ305へ送信する。ウェブサーバ305は次いで、普通には受信したベクターを用いて所望の地図のビットマップ画像を生成し、ビットマップをウェブブラウザ300が対応している画像フォーマット(例えば、GIF、PNG、JPEG等)に変換する。ウェブサーバ305は次いで、画像をウェブブラウザ300へ、一般的にそれをハイパーテキスト記述言語(HTML)コード内に埋め込んで送信する。地図画像は次いで、(図2に示し、先に説明したように)ウェブブラウザユーザインタフェース100によりユーザへ表示される。従って、ユーザが郵便住所を記入すること、または現在の地図ビューの付近にあるナビゲーションリンクをクリックすることで新規の地図ビューを要求する場合に、ウェブブラウザ300は、ウェブサーバ305へ新規の地図ビューの境界を示すリクエストを送る。ウェブサーバ305は、次にデータベースから対応するベクターベースの地図データを抽出し、地図のビットマップ画像を描画する。ウェブサーバ305は次いで、ビットマップ画像をウェブブラウザ300が対応している画像フォーマットへ変換し、画像を、場合によってはHTMLに埋め込んで、ユーザへの表示のためにウェブブラウザ300へ返す。そのようなシステムの商用実装様態は、AOL社のMapQuest (http://www.mapquest.com)、ヤフー社のTelcontarベースの「SmartView」地図(http://maps.yahoo.com)、およびマイクロソフト社のMapPoint.netスイート (例えば、http://maps.msn.com)を含む。
【0009】
図4は、地図データをウェブブラウザへ提供するために使用される第2の例示的システムを示す。図4に示すように、ウェブブラウザ300は、図3に対して先に説明したものと同じ様式でHTTPリクエストをウェブサーバ305へ送信する。ウェブブラウザ300からのHTTPリクエストを受信すると、図4に示すウェブサーバ305は、要求された場所データを含むデータベースクエリ(「DBクエリ」)を地図ラスタデータベース410へ送信する。地図ラスタデータベース410は、データベースクエリに基づいて適切な画像を大きい予め描画した地図画像の中から抽出する。要求された画像は次いで、ウェブサーバ305へ送信され、ウェブサーバ305はそこで先に説明したように画像をウェブブラウザ300へ送信する。従って、図4に示すようなデジタルマッピングシステムでは、ベクターを抽出し、地図画像を描画するステップは、大きい予め描画した画像の適切な一部を単に抽出するステップで置き換えられる。そのようなシステムの商用実装様態は、英国のMultiMaps (http://multimaps.com)およびオーストラリアのWhereIs (http://www.whereis.com.au) を含む。かかるシステムは、普通にはかかる地図の印刷バージョンを生成することにも使用される同じベクターベースのファイルから地図画像を生成することにも、注目すべきである。
【0010】
上記の問題の幾つかは数多くのより小さい画像(「タイル」として知られる)をウェブサーバ305からウェブブラウザ300へ送信することによって克服できるであろうことにデジタルマッピングウェブサイトの幾つかのプロバイダが気付いた。これらのより小さいタイルは、次いで、ウェブブラウザ300によってより大きい画像に組立てることができる。例えば、マイクロソフト社のTerraServer米国サイトは(http://terraserver.homeadvisor.msn.com/)、現在、衛星写真を表示するためにタイル化する手法を用いている。
【発明の開示】
【0011】
デジタルマッピングシステムの態様を実装するための種々の方法、システム、および装置が開示されている。1つのかかる方法は、場所リクエストをクライアント側コンピュータデバイスから地図タイルサーバへ送ること、場所リクエストに応答して1セットの地図タイルを受信すること、前記受信した地図タイルをタイルグリッドに組立てること、タイルグリッドをクリッピング形状に対して整列させること、そして、結果を地図画像として表示することを含む。本発明の態様に従う1つの装置は、場所リクエストをクライアント側コンピュータデバイスから地図タイルサーバへ送るための手段、場所リクエストに応答して1セットの地図タイルを受信するための手段、前記受信した地図タイルをタイルグリッドに組立てるための手段、タイルグリッドをクリッピング形状に対して整列させるための手段、そして、結果を地図画像として表示するための手段を含む。かかる装置は、更に、表示した地図画像上への対話式オーバレイとして方向制御またはズーム制御のオブジェクトを含んでもよく、地図タイル画像上に経路または場所のオーバレイも、含んでいてもよい。
【0012】
この明細書に組込まれ、その一部を構成する添付図面は、種々の実施の形態を図示する。
【0013】
【0014】
【0015】
【0016】
【0017】
【0018】
【0019】
【0020】
【0021】
【0022】
【0023】
【0024】
【0025】
【0026】
【0027】
【0028】
【0029】
【0030】
【0031】
【0032】
【0033】
【0034】
【0035】
【0036】
【0037】
【0038】
【0039】
【0040】
【発明を実施するための最良の形態】
【0041】
本発明の実施形態を開示の種々の態様を、マッピング情報を取得し、表示するための装置、システム、および方法の文脈の中で明細書に説明する。以下の説明は例証的のみであり、何らかの限定を行うものではないことを当該技術に精通する者は感知するであろう。他の態様もこの開示の恩恵を有する者にとり容易に自明であろう。
【0042】
例えば、Java言語、JavaScript、Javaアプレット技術、C、C++、Perl、Pascal、Smalltalk、FORTRAN、アセンブリ言語、HTML(すなわち、ハイパーテキスト記述言語)、DHTML(すなわち、ダイナミックハイパーテキスト記述言語)、XML(すなわち、拡張可能記述言語)、XLS(すなわち、拡張可能スタイル言語)、SVG(すなわち、スケーラブルベクターグラフィックス)、VML(すなわち、ベクター記述言語)、マクロメディア社のFlash技術等の、数多くのコンピュータプログラミング言語が、本発明の態様を実装することに使用されてもよい。更に、手続き型、オブジェクト指向、または人工知能技術等の種々のプログラミング手法が、それぞれ特定の実装要件によって用いられてもよい。
【0043】
同じ参照番号を、この文書において図面および説明の全体にわたり用いて、同じかまたは同様の部分に言及する。更に、本明細書における幾つかの図は、方法およびシステムを示すフローチャートである。これらフローチャートのそれぞれのブロック、およびこれらフローチャートにおけるブロックの組合せは、コンピュータプログラム命令で実装されてもよいことが理解されるであろう。これらのコンピュータプログラム命令は、コンピュータまたは他のプログラム可能な装置上へ読み込まれてマシンを生じてもよく、それによりコンピュータまたは他のプログラム可能な装置上で実行する命令はフローチャートのブロック(単数または複数)に指定された機能を実装するための構造を作成する。また、コンピュータまたは他のプログラム可能な装置に特定の様式で機能するよう指図できるこれらのコンピュータプログラム命令は、コンピュータ可読メモリに格納されてもよく、それによりコンピュータ可読メモリに格納された命令がフローチャートのブロック(単数または複数)に指定された機能を実装する命令体系を含む製造品を作成する。また、コンピュータプログラム命令は、コンピュータまたは他のプログラム可能な装置上へ読み込まれてよく、一連の操作上のステップをコンピュータまたは他のプログラム可能な装置上で実行させて、コンピュータ実装のプロセスを作成し、それによりコンピュータまたは他のプログラム可能な装置上で実行する命令がフローチャートのブロック(単数または複数)に指定された機能を実装するためのステップを提供する。
【0044】
従って、フローチャートのブロックは、指定された機能を実行するステップの組合せおよび指定された機能を実行するためのステップの組合せに対応している。また、フローチャートの各ブロック、およびフローチャートにおけるブロックの組合せは、指定の機能またはステップを実行する特別用途ハードウェアに基づくコンピュータシステム、または特別用途ハードウェアおよびコンピュータ命令の組合せで実装できることも、理解されるであろう。
【0045】
図5は、本発明の態様に従う分散型ネットワークシステム500を示す。コンピュータデバイス503が、ネットワーク505へ接続されて、示されている。また、種々のサーバも、ネットワーク505へ接続されている。例えば、ウェブサーバ510、タイルサーバ515、および場所データサーバ520は、全てがネットワーク505と通信しているとして示されているが、他のサーバ(不図示)も、ネットワーク505へ接続されてもよい。コンピュータデバイス503は、パーソナルコンピュータ、携帯電話、携帯情報端末、車両に配置されるナビゲーションシステム等の演算用に構行われたどのような種類のデバイスであってもよい。サーバ510、515および520は、ネットワークサーバまたはウェブサーバ等のそれぞれがネットワーク505上でホスティングサービス能力のあるどのようなデバイスであってもよい。また、サーバ510、515および520は、ユーザ入力に基づいて幾らかまたは全てのマッピング情報を決定および/または取得する能力があってもよい。代替として、コンピュータデバイス503は、旅程を決定および/または取得する能力を装備していてもよい。幾つかの実装では、コンピュータデバイスおよびサーバ(またはその種々の部分)は、1つ以上のマシンに共同で配置されていてもよい。
【0046】
ネットワーク505は、どのような種類の分散型ネットワークであってもよく、例えばローカルエリアネットワーク、広域ネットワーク、交換電話ネットワーク、イントラネット、インターネットまたはワールドワイドウェブネットワーク等であってもよい。代替として、ネットワーク505は、コンピュータデバイス503とサーバ510、515、および520との間の直接的な接続であってもよい。コンピュータデバイス503、ネットワーク505および/またはサーバ510、515、および520は、どのような種類の有線または無線接続を介して通信してもよい。その上、ネットワーク505と通信しているコンピュータデバイス503、サーバ510、515、および520、ならびに、他のコンピュータデバイス(不図示)、および/または他のサーバ(不図示)が、本明細書中に説明するいずれかまたは全ての機能を実行することに使用されてもよい。
【0047】
図6は、コンピュータデバイス503、またはサーバ510、515、および520の例示的な線図である。コンピュータデバイス/サーバ503/510/515/520は、バス600、1つ以上のプロセッサ605、主メモリ610、読出専用メモリ(ROM)615、記憶装置620、1つ以上の入力デバイス625、1つ以上の出力デバイス630、および通信インタフェース635を含んでいてもよい。バス600は、コンピュータデバイス/サーバ503/510/515/520の構成要素間での通信を許容する1つ以上の導線を含んでいてもよい。
【0048】
プロセッサ605は、命令を解釈して実行するどのような種類の従来のプロセッサ、マイクロプロセッサ、または処理ロジックを含んでいてもよい。主メモリ610は、プロセッサ605による実行のための情報および命令を格納するランダムアクセスメモリ(RAM)または別の種類の動的記憶装置を含んでいてもよい。ROM615は、プロセッサ605による使用のための静的情報および命令を格納する従来のROM装置または別の種類の静的記憶装置を含んでいてもよい。記憶装置620は、磁気および/または光学記録媒体およびその対応する駆動部を含んでいてもよい。
【0049】
入力デバイス625は、キーボード、マウス、ペン、スタイラス、手書き認識、音声認識、生体メカニズム等の、ユーザが情報をコンピュータデバイス/サーバ503/510/515/520へ入力することを許容する1つ以上の従来のメカニズムを含んでいてもよい。出力デバイス630は、ディスプレイ、プリンタ、スピーカ等を含む、ユーザへ情報を出力する1つ以上の従来のメカニズムを含んでいてもよい。通信インタフェース635は、コンピュータデバイス/サーバ503/510/515/520が他のデバイスおよび/またはシステムと通信することを可能にするどのようなトランシーバのようなメカニズムを含んでいてもよい。例えば、通信インタフェース635は、ネットワーク505等のネットワークを介して別のデバイスまたはシステムと通信するためのメカニズムを含んでいてもよい。
【0050】
下記で詳細に説明するように、コンピュータデバイス503および/またはサーバ510、515、および520は、データ記憶装置620等の別のコンピュータ可読媒体から、または通信インタフェース635を介して別のデバイスからメモリ610へ読出されてもよいソフトウェア命令に基づいて操作を実行してもよい。メモリ610内に含まれるソフトウェア命令は、プロセッサ605に後述するプロセスを実行させる。代替として、配線で接続された回路が、ソフトウェア命令の代わりにまたはそれと組合せて使用されて本発明に整合するプロセスを実装してもよい。従って、種々の実装は、ハードウェア回路およびソフトウェアのどのような特定の組合せにも限定されない。
【0051】
ウェブブラウザユーザインタフェース(図1および図2に示すウェブブラウザインタフェース100等)を備えるウェブブラウザ(図3および図4に示すウェブブラウザ300等)は、情報(文章および図形情報等)をコンピュータデバイス503上に表示することに使用されてもよい。ウェブブラウザ300は、図5に示すネットワーク505を介して受信した情報を表示することのできるどのような種類の視覚的表示を備えていてもよく、例えばマイクロソフト社のInternet Explorerブラウザ、ネットスケープ社のNavigatorブラウザ、MozillaのFirefoxブラウザ、PalmSource社のWeb Browser、またはネットワーク405と通信することのできるいずれかの他の閲覧もしくは他のアプリケーションソフトウェア等であってもよい。また、コンピュータデバイス503は、ブラウザアシスタントを含んでいてもよい。ブラウザアシスタントは、プラグイン、アプレット、ダイナミックリンクライブラリ(DLL)、または同様の実行可能なオブジェクトもしくはプロセスを含んでいてもよい。更に、ブラウザアシスタントは、ウェブブラウザ300へ拡張機能を提供するツールバー、ソフトウェアボタン、またはメニューであってもよい。代替として、ブラウザアシスタントは、ウェブブラウザ300の一部であってもよく、その場合、ブラウザ300はブラウザアシスタント機能を実装することになる。
【0052】
ブラウザ300および/またはブラウザアシスタントは、ユーザとコンピュータデバイス503および/またはネットワーク505との間の媒介物として動作してもよい。例えば、ネットワーク505に接続されたデバイスから受信したソースドキュメントまたは他の情報は、ブラウザ300を介してユーザへ出力されてもよい。また、ブラウザ300およびブラウザアシスタントの両方は、ソースドキュメントをユーザへ出力する前に受信したソースドキュメント上に操作を行うことができる。更に、ブラウザ300および/またはブラウザアシスタントは、ユーザ入力を受信し、ネットワーク505に接続されたサーバ505/515/520または他のデバイスへ入力されたデータを送信してもよい。
【0053】
例示的システムの概要およびユーザインタフェース
下記でより詳細に説明するように、一実施の形態の幾つかの態様は、それぞれ適切な1セットの分離したズームレベルの大きい(例えば、米国全体の規模の)連続した地図のラスタ画像の存在を想定している。一時的なオフライン段階中に、システムは、この大きいラスタ画像を生成し、所望の地図ビューより一般的に1桁小さいサイズのセグメント(例えば、長方形タイル)に切り分け、これらのタイルをウェブブラウザが対応しているフォーマットでサーバ側データベースに格納する。
【0054】
図7の例に示すように、ウェブユーザが新規の地図ビューをアプリケーションソフトウェア700(例えば図3および図4に示すウェブブラウザ300等)を介して要求する場合、ウェブブラウザに(または、限定しないが、図6に示す主メモリ610、ROM615、および/または記憶装置620として実装できるであろう、図7にローカルメモリ705として示すウェブブラウザのキャッシュに)既に存在するタイルと併せて必要である最小の1セットのタイルのみに対するHTTPリクエストが、サーバ710へ送られて、新規ビューを作成する。これらのHTTPタイルリクエストに対する応答のフォーマットは、ヘッダフィールドにウェブブラウザがタイルをローカルでキャッシュに格納するよう促す情報を含んでいる。1セットのスクリプトを実行することによって、ウェブブラウザは次いで、組み合わせたタイルのセットをユーザへの提供のための新規ビューにシームレスに組立てる。古い地図ビューは一般的に未だブラウザに存在しているため、追加のスクリプトを用いて、古い地図ビューから新しい地図ビューへの移行を、パンおよび/またはズーム操作の一部として、滑らかに動画化してもよい。その上、場所マーカーおよび経路を、例えば、ドライブ道案内、局所検索、職業別電話帳の参照等のユーザリクエストに応答して、予め描画した地図タイルの上に重ね合わせることができる。加えて、同様な技法は、例えば、地図画像上で地域および街路を強調することに使用できる。
【0055】
エンドユーザ(例えば図5に示すコンピュータデバイス上で動作しているウェブブラウザと対話しているユーザ等)の視点から、図8は、本発明の態様に従う地図リクエストと地図表示とを組み合わせたページ800の一実施の形態を表す。図8に示すように、ページ800は、地図画像805、重ね合わされた地図方向制御オブジェクト815、重ね合わされたズーム制御オブジェクト820、場所リクエストテキスト記入フィールド825、検索ボタン830、情報ウィンドウ840、場所マーカー845、場所マーカーの陰影850、および情報ウィンドウの陰影855を含む。後で詳細に説明するように、地図画像805は、タイルグリッドを地図画像805とほぼ同じサイズと形状を有するクリッピング形状に対して整列させることによって実際に生行われる。タイルグリッドは、一実施の形態で、表示のためにより大きい画像にシームレスに編行われる数多くのより小さい個々の地図タイルを備える。当該技術に精通する者に周知である画像オーバレイ技術および絶対位置決め技法を用いて、地図方向制御オブジェクト815およびズーム制御オブジェクト820は、地図画像805それ自体内に実際に配置されてもよく、それによって表示ページ800内で地図画像805のために利用可能である領域を増大させる。このようにして、地図画像805に対する任意のサイズが実装されてもよく、それは地図タイルの全ての数に限定されない。その上、どのような任意の点も、地図画像805の中心に配置されてもよい。一実施の形態では、場所クエリテキスト記入フィールド825は、単一のテキストフィールドとして実装され、それにより地図を作成するべき所望の場所の種々の構成要素(例えば、番地、市、州、または郵便番号等)が多数のフィールドを用いて指定される必要はない。後で検討するように、一実施の形態では、図8はまた、課金点860を地図画像の中心に含む(とはいえ、課金点860は、普通には地図画像805上における可視特徴ではない)。
【0056】
検索ボタン830が選択される場合、テキスト記入フィールド825内に記入された地図を作成するべき所望の場所は、ユーザのコンピュータデバイスまたは遠隔サーバのいずれかで解析され、地図画像805が(本文書全体にわたり説明されている詳細なプロセスによって)生成および表示される。記入フィールド825内に記入された所望の場所もまた、その元の形式または解析した形式のいずれかで地図タイトル840として繰り返され、表示されてもよい。地図を作成するべき所望の場所は、場所マーカー845およびその陰影850によって地図画像805内に図形で識別される。後で説明するように、角度付き陰影を備える場所マーカーを視覚的に二次元に表示する効果を使用することによって、特に多数の場所マーカーが相互に近接して配置される場合、地図画像805内の視覚的混乱は最少にされ、場所マーカーに対応する地図上の実際の場所は、より容易に地点として識別されるであろう。
【0057】
ユーザ画像制御機能の観点で、地図方向制御オブジェクト815は、地図をクリッピング形状サイズの、例えば25%だけ矢印の方向にパンさせる1セットの矢印ラベル付パンボタンとして実装されてもよい。また、これらのボタンは、「西」、「北」または「北西」等のコンパス方位でラベル付けもできる。図8に示すように、ズーム制御オブジェクト820は、地図を単一レベルだけそれぞれ拡大および縮小させる「+」および「−」のラベル付きボタンを含んでいてもよい。これらのボタンはまた、対応するズームレベルの主たる地理的な抽象概念、例えば、「街路」、「市」、「郡」、「州」、「国」等によってラベル付けられてもよい。また、図8に示すように、ズーム制御オブジェクト820も、それぞれのズームレベルに対する分離した位置を持つスライダを含んでもよい。ユーザの視点から、スライダを特定のズームレベルへ移動させることは、対応するズームレベルを選択することと同じ効果を有してもよい。
【0058】
一実施の形態で提供されるユーザインタフェース機能の追加の例として、地図画像805の特定の部分を「クリックする」か、または他の方法で選択することで、選択した場所を地図画像805の中心へパンさせる一方で、地図画像805の特定の部分を「ダブルクリックする」か、または他の方法で強調して選択することで、選択した場所を地図画像805の中心へパンさせると同時にズームレベルを増大させる。別の実施の形態では、地図画像805の特定の部分を「ダブルクリックする」か、または他の方法で強調して選択することで、選択した場所を地図画像805の中心へパンさせる一方で、場所マーカー(地図画像805内のマーカーまたは地図画像805に隣接のマーカーのいずれか)をクリックするか、または他の方法で選択することで、マーカーに関連する情報ウィンドウを開き、その後に地図画像の何れかの部分をクリックするか、または他の方法で選択することで、情報ウィンドウを閉じる。地図の動的サイズ変更も、一実施の形態で対応されている。例えば、表示ウィンドウ800がサイズ変更される場合、ウィンドウ内部の地図画像805は再び中心に合わされ(それにより、これまでのウィンドウサイズで中心であった場所を維持し)、地図はサイズ変更され(それにより、地図は新規ウィンドウがより小さい場合により小さい領域を、新規ウィンドウがより大きい場合により大きい領域を示し)、ズームレベルを変更することがなく、または一般的にユーザのウェブブラウザへの画像情報の再送信を必要としない。一実施の形態では、ユーザは地図画像805のコーナーまたは他の部分を(例えば、マウスのアイコンが選択したコーナーへ示す間に、マウスボタンを押すことによって)「つかむ」ことができ、それを「ドラッグ」して地図画像をサイズ変更する(例えば、マウスを選択した場所へ移動させる間マウスボタンを押し、次いでマウスボタンを放す)。
【0059】
一実施の形態は、マウスのドラッグ機能を実装し、それによって地図ビューは、例えば、ユーザのマウスボタンを押し、マウスを新規の場所へ所望の地図ビューがもたらされるまでドラッグし、次いでマウスボタンを放すことによって、滑らかに位置を変えてもよい。その上、地図スクロール機能も、一実施の形態で実装され、それによって地図ビューは、単にユーザのキーボード上の矢印キーの起動により、または同様なユーザの動作により位置を変える(つまり「パン」)されてもよい。
【0060】
一実施の形態では、全部または部分的な郵便住所をテキスト記入フィールド825内に記入することで、地図画像805を対応する場所へパンさせ、記入された住所の完全性によって決まるレベルへズームさせる。例えば、「カリフォルニア州、バークリー、ブリストルDr.6936」を記入することで、対応する場所へパンし、ズームレベルを街路のレベルの近くに設定し、これに対して、より明確な住所情報なしに単に「カリフォルニア州、バークリー」を記入することで、バークリーの市の中心へパンし、ズームレベルを都市のレベルへ設定することになる。その上、場所の輪郭が、一実施の形態で実装され、それにより、ユーザが明確な住所の代わりに大まかな領域(例えば、市、州、または郵便番号)を指定する場合、輪郭線が大まかな領域の周りに描画でき、(例えば、図28における場所輪郭線2810で示すように)それを強調する。この機能は、ユーザが距離を測り、興味のある領域に焦点を当てることを支援できる。また、一実施の形態では、ユーザは1セットのショートカット(例えば「自宅」、「仕事場」、または「祖母の家」等)を定義してもよく、それは、記入されるか、または他の方法で選択された場合、所望のショートカット場所への地図画像における「ジャンプ」動作(または、要求された場所が現在の場所に充分に近い場合「ズーム/パン」動作)を生じる。
【0061】
図8に示すように、一実施の形態は、また、「情報ウィンドウ」機能を実装し、それによってマーカー845等の場所マーカーをクリックするか、または他の方法で選択することで、マーカーで表された場所についてのより多くの情報を含む、地図画像805内に重ね合わされた、対話式ウィンドウ840およびその陰影855を開く。
【0062】
テキスト記入フィールド825の中へ地図を作成するべき単一の場所を記入することに加えて、一実施の形態では、ユーザは組合せた検索を実行してもよく、それによってユーザは単一のテキストボックス内に検索する項目および全ての地図を作成する場所(例えば、「サンフランシスコにある映画館」または「マウンテンビュー近くのピザ店」)を指定してもよい。その上、先に説明した場所ショートカットと併せて、ユーザは、特定の場所の名前(例えば、「自宅」、「仕事場」)を与えることができ(それは、住所録もしくは同様のデータベースまたはユーザのコンピュータデバイス上のユーティリティと関連していても、していなくてもよい)次いで、テキスト記入フィールド825内へ検索先を記入する場合に(例えば、「仕事場近くのバー」を検索する場合に)ショートカット名を用いる。
【0063】
一実施の形態はまた、ドライブ道案内機能を図8に示すような単一のテキスト記入フィールド825によって、または代替として、(図27に示すテキスト記入フィールド825および828で示すように)出発する場所のための1つのテキスト記入フィールドおよび終着場所のための第2テキスト記入フィールドによって、のいずれかで実装する。更なる例示的な代替として、ドライブ道案内機能はまた、出発する場所フィールドのための1セット(例えば、出発する住所、出発する市、出発する州等)および終着場所フィールドのための第2セットの2セットの特定のテキスト記入フィールドによって実装されてもよい。ドライブ道案内の記入フィールドインタフェースにかかわらず、一実施の形態は、経路情報のクライアント側描画を実装する。具体的には、一実施の形態で、サーバが、曲がり角ごとの文章の道案内を、経路全体の図形描出のためのベクター情報と並んで、クライアントのコンピュータデバイスへ送信する。
【0064】
グラフィックによるドライブ道案内は次いで、以前に描画した地図画像の上にオーバレイとしてクライアントによって描画される。別の実施の形態では、クライアントがベクター情報を受信すると、クライアントは経路オーバレイ画像のグラフィック定義を演算し、そのあと実際のオーバレイ画像を供給するようリクエストをサーバへ送信する。その上、図27に示すように、文章のドライブ道案内手引き2730(例えば、「モフェットBlvd.出口を取る」)が、ウェブページ800上で地図画像805の近傍に表示されてもよい。文章のドライブ道案内の1つをクリックするか、または他の方法で選択することで、地図画像805の対応するセクション(例えば、南行きUS−101からモフェットBlvd.へのフリーウェイ出口ランプ)を指す情報ウィンドウを開く。図27に示すように、情報ウィンドウは、地図画像805の対応するセクションの拡大図を表示する。
【0065】
一実施の形態では、情報ウィンドウは、追加として、「衛星」ボタンまたは同様なユーザインタフェースオブジェクトを含み、それは、クリックするか、または他の方法で選択される場合、地図のグラフィック拡大図を同じ領域の対応する衛星写真で置き換える。グラフィカルなドライブ道案内(すなわち、経路を描出した軌跡)も、また、衛星画の上にオーバレイとして表示できる。「衛星」ボタンまたは同様なユーザインタフェースオブジェクトはまた、主な地図画像805内に(またはそれに関連して)含まれてもよく、それにより、クリックするか、または他の方法で選択される場合、「衛星」ボタンは、図8に表した図形種類の地図画像805を同じ領域の対応する衛星写真で置き換える。
【0066】
サーバ側アーキテクチャおよび地図タイルの生成
一実施の形態では、地図は、地図画像の予め描画した「タイル」の1セットをブラウザにおいて一緒にまとめることによって表示される。これらの地図タイルは、オフラインフェーズで、所定数(例えば、15)の分離したズームレベルのそれぞれでカバーされる地理的領域全体の非常に大きい地図を描画し次いで、これらの地図をタイルに切り分け、そしてタイルを適切な画像フォーマット(例えば、GIF)にエンコードすることによって作成される。予め描画したタイルは、1セットのサーバからの静的画像として提供される。例えば、米国大陸全体をカバーするために、数億ものタイルが必要とされ、タイルのための合計ファイルサイズは数百ギガバイトもの程度のデータである。要望に応じて基調を成すデータから地図画像を描画する代わりに、地図全体がセクション(タイル)で予め描画され、適切なタイルが必要である場合にクライアントへ送られる。従って、一般的に、所与の地図タイルが、クライアントへ一度のみ送信される必要がある。この手法は、従来のシステムより信頼性があり、より早く、そして必要とする帯域幅はより狭い。
【0067】
従って、ユーザにとりトランスペアレントであるオフラインプロセスにおいて、地図システムでカバーされる領域全体の1セットの大きい連続した予め描画したラスタ画像が生行われる。そのような1セットのラスタ画像は、例えば、街路から国のレベルの範囲に及ぶズームレベルのそれぞれについて提供される。結局ユーザのウェブブラウザで組立てられ、表示される(図8に示すような)それぞれの地図画像805は、これらの大きい所定のラスタ画像の1つの(普通には長方形の形状にされる)サブ領域に一致する。代替として、地図画像の境界は、地図画像を取巻く背景と合う、つまり溶け込む地図画像の境界上へ画像を重ね合わせることで異なる形状に見えるよう(例えば、図8に示すように角を丸めた長方形)に変更してもよい。
【0068】
一実施の形態では、ズームレベルは、0からZまで番号付けられ、0は街路のレベルに最も近いレベルを、Zは街路のレベルから最も遠く離れたレベルを表す。興味のある領域内の任意の緯度/経度(「緯/経」)点が、原点つまりオリゴ(例えば、連続した米国の地理的中心)として指定および定義される。そこで、それぞれのズームレベルzで、座標三重項(0,0,z)が、この原点を含むz−レベルのラスタ画像の画素へ割り当てられる。x−軸座標が左から右へ延び、y-軸座標が上から下へ延びる標準的なコンピュータグラフィックスの規約を用いて、一意の座標三重項(x,y,z)が、それぞれのラスタ画像のそれぞれの画素へ割り当てられる。
【0069】
座標変換ルーチンは、ズームレベルzを与えられると、緯/経の座標対を適切な(x,y,z)画素座標へ変換し、またその逆も行う。この変換の詳細は、初回にラスタ画像を作成することに使用された地図投影によって決まる。
【0070】
基調を成す地図情報が大幅に変化する場合にのみ実行される必要がある初期のオフラインフェーズ中に(例えば、数ヶ月ごとに一回)、大きいラスタ画像のそれぞれは、長方形のタイルに「切り分け」られる。図9に示すように、一実施の形態では、大きいラスタ画像を地図タイルに生成し切り分けるプロセスは、地図ペインターライブラリ910と併せたタイルメーカー905、および市販のRME(「リッチ地図エンジン」)ライブラリ915によって協調的に実行される。数あるタスクの中で、タイルメーカー905は、とりわけラベル配置がかかわっている箇所で、隣接するサブ画像タイルがそれらの共通の境界線に沿って密接に並ぶことを確保する。当該技術に精通する者に周知の地図投影課題がある場合、地図システムでカバーされた領域をより小さい領域に分割し、それぞれを別々に扱うことが必要かもしれない。
【0071】
なお図9を参照して、基調を成す地図データは、地図データ記憶装置領域920に格納される。一実施の形態では、格納された地図データは、Telcontar社(デジタル地図およびナビゲーション情報の商用プロバイダ)によってRMF(リッチ地図フォーマット)ファイルにコンパイルされた市販のNavTechデータを備える。RMFは、空間的クエリ処理のために最適化されたコンパクトなバイナリフォーマットであることを当該技術に精通する者は認知するであろう。数あるタスクの中で、本発明の一実施の形態は、地図画像を生成し、経路情報を作成することにこのフォーマットを活用する。RMFは多次元風にデータを組織化する空間的フォーマットであり、それにより現実的に相互に近接した特徴がデータベースにおいてすぐそばに格納される。これは、一旦空間的にフォーマットされたデータセットにある項目が見付かると、すぐ近くの他の項目も比較的容易に見付けられることを意味する。データを組織化することに、順次にまたは層で等の多くの他の方式があることを当該技術に精通する者は認知するであろう。なお図9を参照して、一実施の形態で、タイルメーカー905は、地図ペインターライブラリ910と通信してタイルを作成するための地図データを要求する。地図ペインターライブラリ910は、次に市販のRMEライブラリ915と通信して地図データ記憶装置920からの情報にアクセスする。RMEライブラリは、2つ以上の項目の地理的関係を関与させる情報を要求する空間的クエリに対応していることを当該技術に精通する者は認知するであろう。例としては、「所与の領域内で該当する地図特徴は何か?」または「所与の領域内で該当する一定の閾値より高い優先レベルを有する地図特徴は何か?」である。空間的クエリの結果は、地図ペインターライブラリ905を介してタイルメーカー905へ送信され、地図タイルを生成することに使用される。タイル作成プロセスの結果として得られる地図タイルは、地図タイル記憶装置領域900に格納される。
【0072】
大きいラスタ画像のいずれかのサブ領域ビューを地図画像805としてユーザのウェブブラウザ上に再現するために、一実施の形態では、ブラウザ側のスクリプトは、所望のビューを一緒に完全にカバーする最小セットのタイルのみを必要とする。どのような所与の実装様態についても、タイルのサイズは、以下のトレードオフを前提として、経験的に確定できる:(1)より大きいタイルは所与のビューを作成することに必要であるタイルの合計サイズを(画素およびバイトの両方で)増大させる傾向がある;その一方で、(2)より小さいタイルは所与のビューを作成することに必要である別々のHTTPリクエストの数を増大させる傾向がある。一実施の形態では、128×128画素のタイルサイズが使用され、GIFフォーマットで格納される。他の実施の形態は、256×256画素のタイルサイズを使用し、GIF、JPEG、またはPNGフォーマットのいずれかで格納される。他のタイルサイズおよび画像格納フォーマットは、それぞれの特定の実装様態の要件次第で使用されてもよい。従って、これらのタイルは、規則正しい正方形グリッドを形成し、この性質は一実施の形態でシステム実装を容易にする。しかし、当該技術に精通する者は、クライアント側でのシームレスな組立てを容認するどのような形状およびサイズのタイルへの大きいラスタ画像の他のどのような分割も、本発明の効果を達成するために使用されてもよいことを、認知するであろう。
【0073】
代替として、サーバ側のデータベースでなく、一実施の形態で、それぞれのタイルは、例えば下記のような一意のURLを用いてアクセス可能な別々のファイルに単純に格納されてもよい。
http://<domain>/7/-18/1/-145_12_7.gif
ここで、この例でのディレクトリパス 7/-18/1 は、この例示的事例において (-145,12,7) に等しいタイル座標だけによって決まる。
【0074】
簡単にするために、それぞれのズームレベルzの第1タイルは、タイルの左上画素が座標(0,0,z)を有するように配置される。この規則は、それぞれのタイルへの一意の座標三重項の割り当てを、タイルの左上画素の画素のxおよびy座標をそれぞれタイルの幅および高さで整数除算することによって容易にする。従って、緯/経の座標、画素の(x,y,z)座標およびタイルの(x,y,z)座標の合計3つの座標系が利用される。当該技術に精通する者が認知するであろうように、座標系のこの特定の選定は任意であり、一実施の形態で使用されるアルゴリズムを説明することを単に補助するように選ばれる。一般的に、どのような一貫性のある座標系も充分であると考えられる。次に、それぞれの画素は一意のタイルに属し、その座標は容易に演算される。
【0075】
フロントエンドサーバ
一実施の形態では、フロントエンドサーバ(例えば図7に表すサーバ710または図5のウェブサーバ510等)は、ユーザによって発信されたそれぞれのクエリに、JavaScriptで実装されたクライアント側コードでアクセスされるデータを含む隠されたフレームに対するウェブページを返すことで応答する。従って、フロントエンドサーバ710/510は、ユーザのブラウザ上で動いているJavaScriptベースの1セットのプログラムと対話してダイナミックHTML(「DHTML」)コードを生成する。このメカニズムにより、図8に示す地図ビュー805をパンおよびズームする等の、先に説明したユーザインタフェース機能は、フロントエンドサーバ710/510と対話せずにクライアントのコンピュータデバイス内で実装できる。代わりに、図5に示すように、クライアントのコンピュータデバイス503は、ただ単にタイルサーバ520からタイルを必要に応じて要求し、表示しさえすればよく、タイルサーバ520は、図9に関連して上記で説明したように以前に生行われたタイルのセットを提供する。
【0076】
フロントエンドサーバ710/510の作動の基本モードは、地図表示ページ800にある(図8に示すフィールド825等の)テキスト記入フィールド内に記入されたユーザのクエリへの応答を提供することである。ユーザがクエリを発信する場合、クライアント側のJavaScriptコードは、クエリの内容だけでなく地図ビューの現在の状態も含むHTTPリクエストを形成し、その情報をフロントエンドサーバ710/510へ発信し、結果のページが隠されたiフレーム(または「仮想ページ」)に表示するように指図する。このメカニズムは、(例えば、ドライブ道案内およびその他の項目のためのオーバレイ等のマッピングシステムの種々の特徴を含む)マッピングシステムを実装することに必要とされるデータを、主/可視のウェブページを再度読み込む必要なく、しかしブラウザの履歴および戻る/進むボタンが予想通り作働することをなお有効にしている間に、クライアントが受信することを容認し、それによりユーザは、局所検索を行い、例えば次いで、道案内を入手し、そして局所検索の結果へ復帰するようクリックして戻ってもよい。仮想ページがクライアントで読み込まれると、主ページ上のJavaScriptは、(1)HTMLのタイトルを変更すること;(2)検索フォームを変更すること;(3)タイルグリッドにあるHTMLのIMG参照を地図画像に表示されるべきタイルのURLで置き換えること;(4)地図表示をパンおよび/もしくはズームすること;ならびに/または(5)地図上に1つ以上のオーバレイを加えることもしくは置き換えること、によって仮想ページからデータを抜き出し、それに応じて主ページを調節してよい。
【0077】
一実施の形態では、以下の種類のクエリが認知され、処理される:
【0078】
1)場所クエリ(例えば、「バークリー」)。これらは、単一の地理的場所を含むクエリである。そのようなクエリに応答して、フロントエンドサーバ710/510は、クライアントに、その場所へ地図をパンおよび/またはズームし、表示上でその場所の境界をマークするように指図する。例えば、一実施の形態で、「点」クエリ(例えば、図8に示すように、特定の住所に対する)は、要求された場所に対する場所マーカーを含む表示の結果になり、その一方で、「線」クエリ(例えば、街路番号を特定せずに、特定の都市における特定の街路に対する)は、要求された線がオーバレイとして地図上に強調されている表示の結果になり、そして、「領域」クエリ(例えば、「エニイタウン(随意市)」等の特定の都市に対する)は、(図28に示すように)要求された領域がオーバレイとして地図上に際立たせられている表示の結果になる。
【0079】
2)局所検索クエリ(例えば、「ピザ店」、「郵便局」)。これらのクエリは、ビジネス名、カテゴリ、またはその他のセットの検索用語を含むが、地理的場所を含まないクエリである。そのようなクエリに応答して、当該技術に精通する者に既知の技法を用いて、フロントエンドサーバ710/510は、ユーザの地図ナビゲーションまたは場所を求めるクエリからの結果の位置決めに基づいて現在の地図ビュー内で(またはその近傍で)クエリに一致するビジネスを検索し、クライアントのコンピュータデバイス503に、結果を地図画像805上に1セットの場所マーカー845/850として、選択肢でそれぞれのマーカーが象徴している検索結果を記述する、地図画像805に付随した、地図凡例と並んで、表示するように指図する。
【0080】
3)条件付局所検索クエリ(例えば、「パロアルトにあるピザ店」、「サンフランシスコ近くのシングルモルトスコッチ店」)。これらは、検索用語および地理的場所の両方を含むクエリである。そのようなクエリに応答して、フロントエンドサーバ710/510は、クライアントのコンピュータデバイス503に、表示された場所へパンおよび/またはズームし、その場所内またはその周りで見付けられた検索結果を表示するよう指図する。代替として、クエリに含まれる地理的情報は緯/経点へ変換され、局所検索がこの1セットの緯/経点に対して導かれ、その後に局所検索の結果にある全ての場所が地図画像上に表示されることを確保するようにズームレベルが設定される(「ニューヨークにある大きな寿司店」の検索を仮定して、結果の表示に対する図24を参照)。
【0081】
4)ドライブ道案内クエリ(例えば、「サンフランシスコからニューヨークまで」、「自宅から仕事場まで」、または「カリフォルニア州、ロサンゼルス、メインSt.123から、カリフォルニア州、パロアルト、ユニバーシティAve.801まで」)。これらは、2つの区別できる地理的場所を含むクエリである。先に説明したように、そのようなクエリに応答して、一実施の形態で、フロントエンドサーバ710/510は、経路情報を、文章の曲がり角ごとの道案内と共に、クライアントへ送信でき、クライアントは次いで、地図画像805に強調されたオーバレイ進路として経路を表示してもよい。先にも、説明したように、ユーザは、(例えば、特定のドライブ手引きをクリックするか、または他の方法で選択することで)経路の一部分を拡大することによって文章の道案内と対話して、追加の文章のまたはグラフィカルな詳細を取得してもよい。
【0082】
フロントエンドサーバ710/510は、クエリ分類器に基づいて選択される数多くの様々な論理的制御フローとして実装できる。クエリ分類器は、クエリが検索用語、地理的場所識別子、および文字の文章を含む成分部品へのクエリ文字列の分解の仕方を定義する1セットのテンプレートを取る場所抽出器を含む。例えば、「{QUERY} {STANDALONE_CITY}」等のテンプレートは、ユーザによって単に「ピザパロアルト」として記入されたクエリに一致することになり、カリフォルニア州、パロアルトの中心部近傍の「ピザ店」を検索する結果になる。場所抽出器は、街路名、都市名等の種々の種類の1セットの場所の名前から成る比較的大きいデータベースへのアクセスを有する。
【0083】
一実施の形態では、図10に示すように、フロントエンドサーバ710/510は、また、ジオコーディング/ジオマップ(geomap)サーバ1010を含み、それは体系的でない場所を、体系的場所に加えて図8の地図画像805上にマークできる地理的点/線/領域に変換する。図10にも示すように、ジオマップサーバ1010は、掘り下げ(drill-down)サーバ1015、地図データ記憶装置領域920、場所データサーバ1000、および局所検索サーバ1010と協調的に通信して、番地、街路、交差点、興味のある点、都市、近隣、郵便番号、郡、首都圏、州等(だけでなくそれらの国際的に同等なもの)の地理的特徴を処理する。番地等の点特徴について、変換の結果は、単一の(緯度、経度)点である。街路等の線の特徴について、および都市等の領域の特徴について、変換の結果は、ポリライン(例えば、街路について)、またはポリゴン(例えば、都市について)のいずれかであり、それはこれらの特徴のそれぞれを定義する。代替として、変換の結果は、単純に、軸合わせした境界付けボックスであってもよい。
【0084】
図10に、また、示すように、一実施の形態では、フロントエンドサーバ710/510は、また、所与の地理的場所での、またはその周りの検索結果を見出すための局所検索サーバ1005を含む。「パロアルトにあるピザ店」等の組合せたクエリについて、局所検索サーバ1005は、実行する前にジオコーディング/ジオマップサーバ1010の結果を受信することを待ってもよい。デジタルマッピングシステムについて、順応性のある場所絞り込みの定義および距離平準化の概念を有する局所検索サーバ1010内で局所検索の採点アルゴリズムを実装することが望ましい。ユーザは、所与の1セットのクエリ用語に一致するビジネスを現在の地図ビュー内で有利に検索できなくてはならない。これは、局所検索コードがただ中心点と半径だけの代わりに最小と最大の緯度および経度座標の形体を有する絞り込みを容認することを必要とする。幾らかの程度の距離平準化が、一般的に必要である。換言すれば、地図表示の厳密な中心での結果が、表示ビューのほかのどこかの結果より高い得点となってはならない。例えば、「パロアルトにあるピザ店」を検索して、2店のパロアルトピザ店営業所が、一方が他方よりパロアルトの中心部にたまたま近いために異なる得点となってはならない。
【0085】
一実施の形態では、「ドライブ道案内」クエリがフロントエンドサーバ710/510で認知される場合、フロントエンドサーバは、起点および目的地の住所を1セットの簡単な曲がり角ごとの道案内だけでなく経路に沿った(緯度、経度)座標を指定するポリラインに変換する。フロントエンドサーバ710/510は次いで、経路全体に沿ったベクター情報を含む1セットのポリラインと並んで、曲がり角ごとの道案内をクライアントのコンピュータデバイスへ(例えば、vPageにある)XMLを用いて送信してよい。一実施の形態では、1セットのポリラインをクライアントへ送信する前に、フロントエンドサーバは、クライアントへ送信されるグラフィカルデータ点の合計数を(例えば、当該技術に精通する者に周知の幾何学的操作を用いて、ポリラインのフルセットに対して削除した場合に1または2画素等の一定の所定の閾値以下のエラーの結果になるいずれかのデータ点を1セットのポリラインから削除して)低減し、それぞれの非削除のデータ点をその点が視覚的に妥当になるズームレベルを定義する「グループ」へ割り当てる(例えば、グループ「A」にあるデータ点は、各ズームレベルで表示されることを必要とすることがあり、その一方で、グループ「B」にあるデータ点は、ズームレベルが都市のレベルのビュー以下の精細さに相当するズームレベルを通り越して増大されるまで表示されることを必要としない等)。
【0086】
一実施の形態では、ユーザがドライブ道案内クエリを記入した後に、地図画像805は、選択された経路全体の概観を表示する。ユーザは次いで、経路の一部を拡大し、より詳細なビューを入手してもよい。
【0087】
一実施の形態では、課金メカニズムが、ユーザによってリクエストされた地図ビューの数の経過を把握するために、例えば、地図ビューに関してユーザ訪問の地図領域の合計量の経過を把握するために実装される。図8を参照すると、先に述べたように、課金点860は、地図画像の中心で定義される(とはいえ、課金点860は普通には地図画像805上で可視でない特徴である)。従って、例えば、地図画像805が幅400画素および高さ400画素で定義された領域を備える場合、他の課金点は、水平および垂直の方向に400画素の間隔で定義される(それによって課金点グリッドを作成する)。従って、一実施の形態では、各地図ビューは、少なくとも1件のトランザクションを含む。ユーザがパン操作を始動する場合、課金点グリッドは地図と並んで「移動」し、新規の課金点が地図ビューの中へ入る場合にはいつでも追加の課金トランザクションを発動する。例えば、ユーザが地図画像を200画素だけ右へパンする場合、新規課金点がビューへ入り、新規トランザクションを発動する。一実施の形態では、新規トランザクションはまた、所与のズームレベルでこれまで不視であった地図領域を表示するズーム操作の結果としても、発動されることになろう。トランザクションは、一実施の形態で、クライアントによってフロントエンドサーバ710/510へ報告され、フロントエンドサーバは、全てのユーザからのトランザクション情報を収集し、それを地図情報の商用プロバイダとの契約上の目的に使用する。
【0088】
クライアント側のアーキテクチャおよびアルゴリズム
本発明の実施の形態は、先端的なウェブブラウザで利用可能な広範囲の技術を用いて実装されてもよい。幾つかの実施の形態の共通の図形的特徴は、1セットの地図タイルを「クリッピング形状」の後ろに組立てる能力である。加えて、ユーザのコンピュータデバイス503でのホスト技術は、表示レイアウトへの適度に効率の良い動的な変更を容認するはずである。クライアントのウェブブラウザは、ちらつきを回避するように二重バッファ型の(または同様の)表示を用いてかかる動的な変更を実行する方が好ましいが、必須ではない。例えば、DHTMLは、二重バッファ型表示エンジンを使用する。DHTMLを使用する一実施の形態では、ブラウザは、ユーザの入力、HTTPの完了および時間切れ等のイベントに応答してスクリプト機能を実行する。スクリプト実行中にウェブページに行われた全ての変更は、少なくとも論理的に、画面外のバッファに記録され、それはスクリプトが制御をブラウザへ戻す場合に表示される。
【0089】
下記でより詳細に説明するように、一実施の形態に従うクライアント側アルゴリズムは、一般的に地図タイルレイアウトへ1セットの変更を成すことによって進行し、次いでこれらの変更によって定義された新規のフレームを表示するようにホストシステムに要求する。一実施の形態では、クライアント側での地図表示機能は、以下のとおりのHTMLコードで実装されてもよい:
<div id="mapView" style="position: relative; overflow: hidden;">
<div id="mapDiv" style="position: absolute;">
<table id="mapTable"><tbody>
<tr><td><img src="images/bg.gif"></td>
...
</table>
</div>
</div>
この実施の形態では、サイト上のJavaScriptコードが、mapTableの <img> 要素にある適切な地図タイルを配置することによって、およびmapDivをmapViewに対して移動させることによって地図をパンおよびズームする。従って、この実施の形態でのクライアント側アルゴリズムは、2つの主要な図形要素を実装する。第1要素は、(普通には長方形の)「クリッピング形状」であり、それを通してユーザは地図画像805を見ることになり、それはユーザの地図ビューの形状を定義する。単に一実施の形態でのクライアント側アルゴリズムを明らかにするだけの目的で、クリッピング形状の任意の画素が、その原点として割り当てられる(例えば、長方形のクリッピング形状の事例では左上の画素)。第2の要素は、クリッピング形状より大きく、それの背後に配置されるタイルのグリッドであり、それによりクリッピング形状を共用するグリッドの一部のみがユーザにとって可視である。一実施の形態のこの検討の残部について、このグリッドは長方形であり、このグリッドがサイズを変更するのはクリッピング形状がそうした場合およびその場合のみであることを想定するものとする。この性質が当てはまらない場合には本明細書で検討したアルゴリズムの変形が存在することを当該技術に精通する者は認知するであろう。
【0090】
一般的に、クリッピング形状は、ウェブブラウザのウィンドウ800に対して固定されたままであり、それに反して、本発明の態様に従うクライアント側のスクリプトは、とりわけ地図画像805をパンするようにタイルグリッドの場所をクリッピング形状に対して移動させることになる。図11は、これらの2つの要素を示す一方で、図12は、ウェブページ上への表示のためにクリッピング形状を通してタイルグリッドを処理する結果を表す。図11に示すように、5×5の正方タイルグリッド配列1100は、25の個々のタイル(そのそれぞれが赤い境界の線で定義される)を備える。正方クリッピング形状1110(黒い長方形として示す)は、クライアントのウェブブラウザ上に地図画像として表示されることになるタイルグリッドのサブセットを定義する。図12には、「クリップされた」タイルグリッド配列1200が、クリッピング形状の境界と連続している境界とともに、表示されている。先に述べたように、図8に示す地図画像805も、より大きいタイルグリッド配列の、クリッピング形状と対比された結果である。図13は、基調を成すタイルグリッド座標およびクリッピング形状1305を示し、それは図11および図12に示すもの等の1セットの表示された画像に対応する。図13には、5×5のタイルグリッド配列1300内の25のタイルのそれぞれが一意の1セットのタイル座標によって表されている。
【0091】
一実施の形態では、クリッピング形状は、固定サイズの300×300画素の長方形であり、図8に示すようにウェブページ800の中心に位置決めされる。クリッピング形状は、一実施の形態で、style "overflow: hidden; position: relative" およびid "mapView" を持つDIV要素として実装される。タイルグリッドは、固定サイズの5×5のタイルである。それは、id "mapTable" を持つTABLE要素として実装される。mapTableの25TDの子供達のそれぞれは、単一のIMG要素を含み、それによりタイルを配置することは単にIMG要素のSRC属性を適切に変更することを伴う。mapTable要素は、id "mapDiv" および style="position: absolute" を持つDIV要素の子供である。mapViewおよびmapDivのPOSITIONスタイルは、mapDivのLEFTおよびTOPスタイルを単に変更するによってタイルグリッドをクリッピング形状に対して移動させることを可能にする。
【0092】
一般的に、クリッピング形状のサイズに比べてタイルグリッドのサイズは、下記で説明する種々の実装要因に依存してよい。大まかに言えば、(画素で)クリッピング形状の(幅および高さの両方で)少なくとも2倍のサイズであるタイルの最小のグリッドが、使用されてもよい。また、実装様態の選定次第で、ユーザがクリッピング形状のサイズまたは形状を変更する場合に、タイルグリッドのサイズを動的に変更することが必要かもしれない。
【0093】
以下の例示的な検討の目的で、AおよびBは、タイルグリッドの(タイルの観点における)それぞれ幅および高さを表す。タイルグリッドにおけるそれぞれの位置は、座標の対(a,b)を割り当てられ、左上の位置が座標(0,0)を有し、右下の位置が座標(A−1,B−1)を有する。計算中に、タイルグリッドの外側に該当する位置(a,b)への参照が成されてもよく、ここで、a<0もしくはA≦a、またはb<0もしくはB≦bである。
【0094】
一実施の形態で作成されたそれぞれの地図画像では、クリッピング形状とタイルグリッドとの間の共用部分は、フルクリッピング形状に等しいことになり、それにより地図タイルのみがクリッピング形状によってユーザへ公表される。この文書の残部において、この事実は「共用部分条件」と命名される。
【0095】
上記の想定および定義を適所に置き、クリッピング形状の原点で公表された地図画素の画素座標三重項(x,y,z)によってどのような地図ビューも一意的に照会できる。
【0096】
初期化およびキャッシュ格納
一実施の形態では、ユーザが当初の地図ビュー(x,y,z)を要求したと想定し、更に、対応する地図画素(x,y,z)がタイル(xx,yy,z)に属することを想定すると、クライアント側のスクリプトは以下のように進行する。第1に、タイルグリッドが共用部分条件に違反しないどのような様式でもクリッピング形状に対して配置される。第2に、(a,b)がその時点でクリッピング形状の原点を含むタイルグリッドの位置として定義される。第3に、クリッピング形状を共用するタイルグリッドにあるそれぞれの位置(a+a',b+b')について、タイル(xx+a',yy+b',z)が配置される。第4に、そして最後に、結果として得られたフレームが表示される。
【0097】
一般的に、タイルをともかくタイルグリッド位置に配置することは、一般的にブラウザにタイルがブラウザのキャッシュに存在するか否かを最初に点検させることになり、存在しない場合、必要であるタイルを求める適切なHTTPリクエストを発行させる。所与の実装様態の特定のホスト技術次第で、このHTTPリクエストは、同期してまたは非同期で実行されてもよい。本発明の実施の形態は、ウェブブラウザに個々のタイルをローカルでキャッシュに格納するように仕向けることで性能を改善する。従って、ブラウザ側のスクリプトがブラウザに特定のタイルを表示するように命令する場合、ブラウザは、タイルがブラウザのキャッシュに既に存在しない場合のみHTTPサーバからタイルを要求することになる。このようにして、本発明の実施の形態は、重複した像を含む別々の地図ビューから、これらの別々のビューが異なるブラウザセッションに属する場合でさえ、恩恵を得る。確かに、一旦ユーザが領域をオンラインの間に見た後に、ユーザのブラウザで既にキャッシュに格納されたタイルのみが必要である限り、ユーザは、その同じ領域をオフラインの間に、見ることができる。
【0098】
この効果を達成するために、クライアント側のスクリプトは、一実施の形態で、タイルの座標三重項のみによって決まるURL(「Universal resource locator」)によってそれぞれのタイルを別々に識別する(例えば、http://somedomain.com/tiles?x=0&y=0&z=0)。一般的に、ウェブブラウザは、それぞれのタイルを含むHTTP応答に含まれる期限切れ時間を使用することによって、および/または、ブラウザのキャッシュにあるタイルの直前に改変された時間をサーバ側上のタイルの直前に改変された時間と対比することによって、自身のキャッシュを管理する。これらの2つの方法の後者は、キャッシュに格納されたタイルが使用されるべき場合でさえいくぶん費用の掛かるHTTPリクエストを必要とするので、タイルを送信するHTTPサーバは、以下のトレードオフを前提として経験的に確定された非常に長い時間切れ期間を報告するように構成されてもよい。一方では、より長い期限切れ期間は、正しくキャッシュに格納されたタイルのために必要であるHTTPリクエストの数を最少限する傾向がある。他方では、より短い期限切れ期間は、大きい地図入力ラスタが変化する場合、新規のタイルをウェブブラウザへより早く発効させる(それは、実地面で、新規の道路建設を補正することに、またはラスタを作成する地図描画システムシステムへの改善を活用することに発生することがあろう)。
【0099】
代替として、実装様態は、バージョン番号をタイルのURLへ加えてもよく(例えば、http://www.somedomain.com/tiles?x=0&y=0&z=0&v=1.0)、期限切れ日付をできる限り将来まで報告するようにタイルを送信するHTTPサーバを構成し、そして、新規のタイルが発効を必要とする場合のみ新規タイルのバージョン番号をブラウザ側のスクリプトへ送信する何らかの他の手段を用いてもよい。この代替のシステムは、既に正しくキャッシュに格納されたタイルのためにブラウザによって発行されるHTTPリクエストを最少限にする一方で、新規タイルがキャッシュに格納された古いタイルの代わりに使用されるべき場合に全面的な制御を与える。しかし、この代替は、ブラウザのキャッシュにおいて新規タイルが古いタイルを置き換えるものではないので、ブラウザ側でより多くのディスク容量を使用する傾向が確かにある。本発明の実施の形態は、タイルをサーバからウェブブラウザへ転送することにとりわけHTTPの使用に依拠しないことに注目されたい。ブラウザが対応している他の転送プロトコル、例えばHTTPSまたはFTP等が、代わりに使用できる。当該技術に精通する者が認知するであろうように、それぞれの転送プロトコルは、僅かに異なった手法を要求してタイルをキャッシュに格納することがある。本発明の実施の形態は、また、最新のパンおよびズーム操作に基づいて発見的アルゴリズムを実装してもよく、近い将来に必要でありそうであるタイルを予測し、これらのタイルをブラウザのキャッシュへ転送することにアイドルタイムおよび/または帯域幅を使用する。代替として、アイドルタイムおよび/または帯域幅は、現在は可視でないタイルグリッドにおける位置を更新すること、および/またはユーザが単一レベルのズームの移行を要求することになるとすれば必要であろうタイルを要求することに専念してもよい。
【0100】
図14は、地図タイルをウェブブラウザへ送信し、タイルをウェブブラウザにローカルでキャッシュに格納するための一実施の形態のフローチャートを示す。ステップ1400で、クライアントは場所の候補を受信する(例えば、ユーザは地図を作成するべき場所を図8に示すテキスト記入フィールド825内に記入し、そのあと図8の検索ボタン830を選択してもよい)。次に、ステップ1405で、クライアントのコンピュータデバイスは、場所の候補を場所サーバ(例えば、図10に示す場所データサーバ1000、図5に示す場所データサーバ520、または図7に示すサーバ710)へ送信する。場所サーバは次いで、場所の候補をステップ1410で解析し、場所データの生成の結果になる。ステップ1415で、クライアントは、この場所データを場所サーバから受信し、ステップ1420で、クライアントは、受信した場所データを用いてタイルリクエストを作成する。タイルリクエストにあるそれぞれのタイルについて、クライアントは、要求したタイルが既にローカルで格納されているか否かを判断する。具体的には、ステップ1425で、クライアントは、要求したタイルが既にローカルで格納されているか否かを判断する。
【0101】
タイルが既にローカルで格納されている場合、ステップ1435で、クライアントはそのローカルメモリからタイルを取り出す。代替として、タイルが既にローカルで格納されていない場合、ステップ1430で、クライアントはタイルをサーバ(図5に示すタイルサーバ515等)から取り出す。ステップ1440で、タイルがローカルまたは遠隔のタイル記憶装置のいずれかから取り出されると、要求したタイルが表示される。次に、ステップ1445で、次のタイルリクエストが決定される。さらに多くのタイルがリクエスト内に残っている場合(ステップ1450で行われる判断)、プロセスのループはステップ1425へ戻り、ここで新規に要求したタイルが既にローカルで格納されているか否かに関して判断が行われる。代替として、それ以上タイルがリクエスト内に残っていない場合、プロセスはステップ1455で終了する。
【0102】
多くのターゲットホスト技術は非同期のHTTPリクエストへのアクセスを供与していることに注目すべきである。この特徴は、クライアント側のスクリプトがパン移行中にタイルをタイルグリッドに配置することを容認し、そこでタイルが実際に到着する前にタイルグリッドの移動を開始し、従って、一時的に間違ったタイル(または、代替として、空きスペースつまり空白タイル)をユーザへ表示する。一般的に、所与の実装様態の特定の要件次第で、そのような非同期性は、地図を移動させる前に全ての新規のタイルが到着することを常に待つことに起因することがある非常に長い待ち時間にとって好ましいと見なされてもよい。幾つかの実施の形態では、非同期のリクエストを発行する前に、タイルグリッドにある古いタイルを地図の背景色と同一色である(そしておそらくだいたい常にブラウザのキャッシュにある)静的タイルで置き換えることが有益であることもある。代替として、より複雑な実装様態では、全ての新規のタイルの到着またはやや短い時間切れ期間の期限切れのいずれか(のどちらか早く発生すること)を待ってから地図の移動を開始する。かかる実装様態では、同一色のタイルは時間切れの事例のみに使用されることになろう。
【0103】
オーバレイ
一実施の形態に従うと、基本の地図画像の域を超えた全ての追加の情報(例えば、ドライブ経路、特定の場所)は、オーバレイとして描画でき、クライアント側上で地図の上に配置できる。この手法は全ての追加の情報に使用でき、それは、サーバが要望に応じて特定の追加の情報でいずれの地図も描画する必要がないことを意味する。オーバレイは、例えば、場所マーカーおよび経路を表示すること、ならびに街路および特定の領域を強調することに使用できる。当該技術に精通する者が認知するであろうように、オーバレイは種々の方式で(例えば、画像またはベクターにより)実装されてもよい。例えば、クライアント側のJavaScriptが、HTML要素を地図表示の上に配置してもよい。先に説明したコードの断片の観点で、全てのオーバレイ要素はmapDivに配置されてもよく、それによりそれらはmapDivが移動される場合に地図と共に自動的に移動する。これらのオーバレイ要素の幾つかは、ウェブページが最初に読み込まれる場合に、既にHTMLコード中に(style="display:none"で)あることがあり、その一方で、その他はJavaScriptコードにより後で追加されてもよい。
【0104】
図15は、ドライブ道案内をオーバレイとして地図画像上へ表示するために一実施の形態に従い使用されてもよいフローチャートを図示する。ステップ1500で、クライアントは、ユーザから既に説明した様式でドライブ道案内を求めるリクエストを受信する。ステップ1505で、クライアントは、要求された旅程情報を場所サーバへ送信する。ステップ1510で、場所サーバは、フロントエンドサーバ機能の説明に関連して先に説明したように、旅程情報を解析する。ステップ1515で、クライアントは、先に説明したように、文章のおよび地理的な旅程データを場所サーバから受信する。ステップ1520で、クライアントは、オーバレイのドライブ道案内経路軌跡を地図画像上へ表示することに必要とされるベクターを決定する。ステップ1525で、クライアントは、先に説明したように、図14のフローチャートに従って基本の地図画像を描画する(このステップが既に行われていない場合)。一実施の形態では、ステップ1528で、クライアントは次いで、ドライブ道案内経路軌跡をオーバレイとして基本の地図画像上へ描画する。別の実施の形態では、ステップ1528へ進行する代わりに、ステップ1530で、クライアントは、ステップ1520でクライアントによって計算されたベクター情報に基づいて、場所サーバから旅程画像オーバレイを要求する。この実施の形態では、ステップ1535で、場所サーバが、旅程画像を作成し、それをクライアントへ送信する。最後に、この実施の形態ではステップ1540で、クライアントが、最終的な旅程画像を地図画像上へ重ね合わせる。オーバレイのドライブ道案内を持つ例示的な表示した地図画像を図26に示す。
【0105】
幾つかの実施の形態では、特定のウェブブラウザ(例えば、Mozilla/Firefox)は、上記で説明したようなベクターグラフィックスを描画する能力がないことがある。そのような実装様態では、図10に示すジオマップサーバ1010等の資源が、(例えば、1セットのドライブ道案内に関連するポリラインに対する)オーバレイのビットマップ画像を生成してよく、そこでブラウザは、この透明な画像を地図画像上へ複合してよい。この例ではブラウザがジオマップサーバ1010から直接的にこの画像を要求するために、リクエストはプロトコルバッファの代わりにURLを介している。線の幅および色は、ジオマップサーバ1010へのコマンド−線の選択肢として指定されてもよい。
【0106】
パン操作
一実施の形態では、地図画像のパン操作は、以下のように実装されてもよい。第1に、ユーザが1つの地図ビュー(x,y,z)から新規の地図ビュー(x',y',z')へ同じズームレベルでのパンを要求したと推定し、パンがnフレームにわたり動画的にされるべきことを推定する(ここで、n=1は、古いビューから新規ビューへの切替えが単一ステップで行われることを示し、その一方で、nの高い値は切替えが滑らかな動画的のパンとして提供されるべきことを示す)。更に、2つの地図ビューが、xおよびy軸の両方に沿って、2つのビューの間の距離に加えてクリッピング形状のサイズがタイルグリッドのサイズより(画素で)小さいという意味で、タイルグリッドのサイズに比べて相互に「近い」ことを想定する。
【0107】
上記の想定および定義を念頭に置いて、タイルグリッドの「下へ回転」の操作は、一番下の行を取り、それを一番上の行にすることと定義され、そこで残った位置がそれらの古い場所をクリッピング形状に対して保持するように、結果として得られるグリッドを配置する。同じように、「上へ回転」は一番上の行を一番下の行にすることと定義され、「左へ回転」は左の列を右の列にすること、そして最後に「右へ回転」は右の列を左の列にすること、と定義される。これらの回転操作は、タイルグリッドを移動させることが、そうしなければ共用部分条件に違反することになろう事例に使用される。勿論、同じ効果を(例えば、グリッドにあるそれぞれのタイルを1つの場所だけシフトすることで)達成できるであろう他の様式があるが、しかし上記の操作上の定義が効率的であると分かった。クライアント側のスクリプトは、従って、以下のように進行する。第1に、(dx,dy)=(x,y)-(x',y')とし、(a,b)をその時点でクリッピング形状の原点を含むタイルグリッドの位置とする。第2に、1とnの間のいずれかの整数iについてi*(dx,dy)/nのオフセットだけタイルグリッドが移動された場合にクリッピング形状で共用することになろうそれぞれの位置(a+a',b+b')について、タイル(xx+a',yy+b',z)を位置((a+a')mod A,(b+b')mod B)に配置する。第3に、必要な場合、共用部分条件がタイルグリッドを(dx,dy)のオフセットだけ移動させることによって違反しなくなるまでタイルグリッドを回転させる。第4に、1とnの間のそれぞれのiについて、タイルグリッドを(dx,dy)/nのオフセットだけ移動させ、結果として得られるフレームを表示する。ホストシステムの効率次第で、フレーム間で幾らかの時間一時停止することが必要になることがある。このプロセスにおける第2および第3のステップの順番は逆にしてもよいことを当該技術に精通する者は認知するであろう。また、nが1に等しいと想定することによる第2ステップにおける僅かな緩和は、ほとんど正しい提供の結果になろう(とはいえ、幾つかの中間のフレームはパンが水平でも垂直でもない場合に少しのタイルを欠落することがある)ことに注目されたい。また、上記のプロセスは連続した地図画像に沿って滑らかなパンを提供することを当該技術に精通する者は、認知するであろう。
【0108】
図16は、一実施の形態に従い地図画像のパン操作を実行するためのフローチャートを表す。ステップ1600において、クライアントは、(例えば、図8に示すような方向制御オブジェクト815の起動によって)パンイベントを示すコマンドをユーザから受信する。ステップ1605で、クライアントは、基調を成す地図タイルに対してクリッピングビューアを実質的に移動させる。そこで、ステップ1610で、クライアントは、パン操作の結果として新規に必要であるタイルの場所を決定する。これが決定されると、ステップ1615で、クライアントは、この場所データを用いて、タイルリクエストを作成する。最後に、ステップ1525で、クライアントは、図14に示し、先に説明したプロセスに従い、必要とされるいずれのタイルも取得する。
【0109】
図17から図21は、一実施の形態に従いクリッピング形状の幅の1/3だけ西へパンする例示的プロセスを示す。図17は、先に説明したプロセスの第2ステップでタイルが更新される前の地図画像およびタイルグリッドの状態を描出し、その一方で、図18は、この更新が完了した後の状態を表す。図19は、先に説明した第3ステップに従い1つの「右へ回転」操作が実行された後の状態を描出し、その一方で、図20は、第4ステップで数フレームが表示された後の状態を表す。最後に、図21は、パン操作プロセスが完了した後の最終状態を表す。
【0110】
より大きいグリッドは、上記のプロセスを用いて一般的により長いパンが滑らかに提供されることを容認することを当該技術に精通する者は認知するであろう。一実施の形態では、クリッピング形状のサイズの2倍より僅かに大きいグリッドを使用する実装様態の選定は、現在の地図ビューのサイズまでの滑らかなパンを容認する。タイルグリッドのサイズを増大させることなくより長いパンを実行するために、パン操作全体が、単純に一連のより小さいパン操作に分割されてもよいが、この手法は僅かに滑らかでない提供の結果になることがある。
【0111】
上記のパン操作アルゴリズムは、動画の第1フレームでさえ提供する前に全ての必要なタイルを更新する。この手法は、ユーザがリクエストをする時間と地図が実際に開始する時間との間に少し待ち時間を導入することがある。これを克服するために、実装様態は、n−フレームのパンを、たとえばn回の別々の1−フレームのパンに分割することを選んでもよい。しかし、ただこの技法のみでは、それぞれのフレームを作成する作業量は更新を必要とするタイルの数で大幅に変動することがあるので、滑らかでない提供の結果になることがある。より洗練された実装様態は、この問題を、将来フレームのために必要であるタイルを予測的に更新してフレームの間で更新を必要とするタイルの数を均等にすることによって克服する。
【0112】
ズーム操作
一実施の形態では、「ズーム操作」は、2つのビュー(x,y,z)と(x',y',z')との間の移行を称し、ここでz≠z'であり、2つのビューに対応する緯/経値はクリッピング長方形のサイズと比べて接近している。以下の検討は、アンカーを含む画素が2つのビューのそれぞれにおいてクリッピング形状の同じ画素を占有するという意味で、緯/経「アンカー」の周りに「垂直」であるズーム操作に焦点を当てる。普通には、ズーム操作のアンカーは、クリッピング形状の中心であることもあろうが、しかしそれは、また、場所マーカー(例えば図8に示すマーカー845等) の緯/経、ユーザによって選択された画素に対応する緯/経、または地図画像内の他のどのような場所でもあり得よう。パン操作をズーム操作と組合せる移行は幾つかの実装様態で組合されてもよいことに注目すべきである。
【0113】
一般的に、ズーム操作は、クリッピング形状で共用する各タイルが更新されなければならないので、タイル更新の観点でパン操作より高価な操作である。この理由のために、そして滑らかに動画的に行うズームは費用の掛かる画像の拡大縮小操作を必要とするために、一実施の形態は、先に説明した初期化ステップを単に実行することによって、全てのズーム操作を単一のフレームで実行する。
【0114】
以下の検討は、一実施の形態に従いユーザへ滑らかに動画的に行うズーム操作を提供する手法を概説し、それは幾つかの例示的ホスト技術(例えば、FlashおよびJavaアプレット)において実装可能である。簡単にするために、2つのズームレベルzとz'の間の拡大縮小係数差異が厳密に2であること、z'=z+1であること、そしてn動画フレームにわたる移行を提供することが望ましいことを想定する。この検討において、「最終フレーム」は、上記で説明した初期化ステップを用いて単一フレームで単にズーム操作することによって作成されることになるフレームを称する。更に、s(拡大縮小係数)が2のn乗根に等しいとする。
【0115】
これらの定義および想定を念頭に置いて、ズーム操作アルゴリズムの一実施の形態は、以下のように進行する。第1に、最終フレームが組立てられる(が、表示されない)。第2に、1とn−1の間のiについて:(a)最終フレームのために必要であるタイルがs^(n−i)の係数で拡大縮小される;(b)拡大縮小されたタイルはアンカーが正しく配置されるように配置される;そして(c)結果として得られるフレームが表示され、適切な場合一時停止が含まれる。第3に、最終フレームが表示される。
【0116】
代替として、z'=z−1の場合、現在のビューのタイルが、最終のビューのタイルの代わりに以下のように拡大縮小されてもよい。第1に、上記のように、最終フレームが組立てられる(が、しかし表示されない)。第2に、1とn−1の間のiについて:(a)現在のビューのタイルがs^(i) の係数で拡大縮小される;(b)拡大縮小されたタイルはアンカーが正しく配置されるように配置される;そして(c)最終フレームが表示され、適切な場合一時停止が含まれる。
【0117】
上記の実装様態の両方の第2ステップ(パート(a))において、第2ステップのパート(b)が実行された後にクリッピング形状を通して結局公表されるタイルのためにのみ拡大縮小が必要とされることに注目されたい。また、第2実装様態の第1ステップは第3ステップまで延期できることにも、注目されたい。これらの実装様態の両方において、同じ地理的領域をカバーするのにより高いズームレベルではより少ないタイルが必要であるので、全ての中間のフレームは、より高いズームレベルのタイルを用いて作成される。より込み入った代替の実装様態は、より低いズームレベルからのタイルを使用することによって、または現在および最終のフレームの両方からの拡大縮小されたタイルをアルファブレンドすることによって、中間フレームの幾つかを作成することを追求し、「モーフィング」と同様の効果を作成する。また、多数のズームレベルに及ぶズーム移行も、一連の単一レベルの移行として実装されてもよい。
【0118】
図22は、一実施の形態に従いズーム操作を実装するための例示的フローチャートを表す。ステップ2200で、クライアントは、(例えば、図8に示すように、ズーム制御オブジェクト820の起動によって)ズーム動作イベントを受信する。ステップ2205で、クライアントは、ズームした表示の中心を決定する。そこで、ステップ2210で、クライアントは、決定された中心の場所データを用いて新規のズームレベルでタイルリクエストを作成する。最後に、クライアントは、図14に関連して先に説明したプロセスに従いズームした地図を描画する。
【0119】
スライド操作およびジャンプ操作
以下の検討は、ただ滑らかなズーム操作およびパン操作のみのためには遠過ぎる地図ビューの間の移行を考慮する。例えば、現在の地図は、カリフォルニア州バークリーにある街路を表示することがあるが、ユーザは、ニューヨーク州のダウンタウンのマンハッタンにある街路のナビゲーションショートカットを選択するか、またはビューを要求するかもしれない。この状況への2つの例示的手法が提供され、「スライド操作」および「ジャンプ操作」と命名される。
【0120】
一実施の形態の「スライド操作」手法に従って、クライアント側のスクリプトは、最終ビューを組立て、(普通には別々のタイルグリッドを利用して)それを現在のビュー上へ古いビューに対して新規ビューの方向から滑らかにスライドさせる。代替として、一実施の形態の「ジャンプ操作」手法に従って、クライアント側のスクリプトは、最初に縮小し、そのあとパンし、そして最後に目標のビューをズーム戻しする。クライアント側のスクリプトは、最低のズームレベルへ縮小し、それぞれの特定の実装様態の要件にとってパンを(画素で)十分短くさせる最低のズームレベルでパンを導く。より洗練された実施の形態は、この「ボックス形状」の動き(すなわち、ズームで上昇、パン、ズームで降下)を滑らかな曲線形の動きに変換する。「ジャンプ操作」手法は、「スライド操作」手法が必要とするよりはるかに多大の数のタイルおよびより多くの演算資源を必要とすることを当該技術に精通する者は認知するであろう。
【0121】
サイズ変更
主として地図ビューの周囲のウェブサイト次第で、ユーザは、地図ビューがサイズおよび/または形状を変更することを要求することがある。タイルグリッドのサイズをクリッピング形状のサイズに関係付ける仕方の実装様態の選定に依存して、この要求は、次にタイルグリッドのサイズ変更を余儀なくさせることがある。この操作のために幾多の可能な実装様態があり、以下を含むがそれに限定されない。現在ビューが(x,y,z)であること、対応する画素がタイル(xx,yy,z)に属すること、そして、クリッピング形状のサイズ変更はその原点の周りで行われるはずであることを想定する。そこで、第1ステップは、クリッピング形状をサイズ変更/形状変更することである。次に、必要な場合、タイルグリッドのサイズは、共用部分条件に違反しないために必要な最小サイズへ(例えば、複数の行を一番下へおよび/または複数の列を右へ加えることによって)増大および移動される。次に、(a,b)が今はクリッピング形状の原点を含むタイルグリッドの位置であるとする。次のステップとして、クリッピング形状を共用するタイルグリッドにおけるそれぞれの位置(a+a'、b+b')について、タイル(xx+a',yy+b',z)を配置する。次に、フレームが表示される。最後に、必要な場合、タイルグリッドのサイズは、タイルグリッドがかさねてクリッピング形状のサイズの少なくとも2倍であるように、(例えば、複数の行を一番下へおよび/または複数の列を右へ加えることによって)増大される。サイズ変更の移行は、先に説明したように、パンの移行を動画的に行うのと同じ技法を用いて動画的にできる。また、特定の実装様態のために所望の場合、タイルグリッドを増大させる最終ステップは、タイルグリッドのサイズを増大および移動させる当初のステップの中へ組合せてもよいことに注目されたい。原点は上記の検討では任意に選ばれたこと、およびこの条件が一般的に真であることは当てにできないことを当該技術に精通する者は認知するであろう。しかし、上記で説明したステップは、当該技術に精通する者によってこの追加の複雑さを説明するように容易に調整されてもよい。
【0122】
場所マーカー
先に述べたように、一実施の形態に従う場所マーカーは、(情報ウィンドウ等の他のオブジェクトと並んで)、対応する陰影とともに地図画像上へオーバレイでき、それはそれらの相対的位置を識別することを容易にする。一実施の形態では、陰影が、あたかも場所マーカーが地図上に垂直に立っているかのように見えるように描画でき、陰影は45°の角度で傾斜され、係数√2で引き伸ばされ、そして垂直面上へ後方に投影される。そのような陰影は、場所マーカーが三次元様式で地図上に配置されたように見えさせるようにでき、ユーザが場所マーカーで指向された場所をより正確な様式で識別する助けをし、そしてまた、多数のマーカーが相互に干渉することを防止する助けもする特徴である。加えて、場所マーカーは、地図画像上へ重ね合わされたアンチエイリアス処理されたマーカーを含むアルファチャネルを持つPNGファイルによって表されてもよい。図23は、本発明の一実施の形態に従い1セットの場所マーカーを地図画像上へ重ね合わせるための例示的フローチャートを表す。ステップ2300で、クライアントは、ユーザから場所に基づく情報を求めるリクエストを受信する。そこで、ステップ2305で、クライアントは、リクエストを場所サーバへこれまでに説明した様式で送信する。ステップ2310で、場所サーバはリクエストを解析する。次に、ステップ2315で、クライアントは、場所に基づく情報を場所サーバから受信する。ステップ2320で、クライアントは、この情報を1セットの画素情報へ翻訳する。そこで、ステップ2325で、クライアントは、地図画像上へ重ね合わされるか、または他の方法で配置されるべきマーカーおよび陰影の画像を(ローカルまたは遠隔の場所サーバからのいずれかで)取り出す。ステップ2330および2335で(それらは特定の実装様態のために所望される場合には明瞭に逆にできる)、クライアントは、それぞれ陰影およびマーカーを地図画像上へ(例えば、それらを地図画像上へ重ね合わせることで)配置する。図24は、本発明の態様に従う、「ニューヨークにある大きな寿司店」を求めるテキストフィールド825での例示的リクエストの結果を表示する、(「A」から「J」と命名された)多数の重ね合わされた場所マーカーを持つ例示的地図表示のウェブページを表す。
【0123】
重ね合わされた画像の別の例として、図27は、本発明の態様に従う重ね合わされたドライブ道案内経路軌跡を持つ例示的地図表示のウェブページを表す。図27は、所望の出発住所を示すための第1テキスト記入フィールド825、終着住所を示すための第2テキスト記入フィールド828、所望のドライブ道案内に対応する強調された重ね合わされた経路軌跡2710、対応する1セットの文章のドライブ道案内2730、ドライブ道案内の終着点を示す場所マーカー845およびその陰影855、ドライブ道案内の出発点を示す同様な場所マーカーおよびその陰影855、および、経路に沿った特定の選択された手引き(例えば、「モフェットBlvd.出口を取る」)に対する詳細な地図ビュー2725を表示する情報ウィンドウ2720およびその陰影855を含む。同様に、図28は、本発明の態様に従う重ね合わされた領域境界軌跡を持つ例示的地図表示のウェブページを表す。
【0124】
図29は、本発明の一実施の形態に従い地図画像上へ(図8に示す情報ウィンドウ840およびその陰影855等の)1セットの情報ウィンドウを重ね合わせるための例示的フローチャートを表す。ステップ2900で、クライアントは、場所情報のユーザの選択を受信する(例えば、ドライブ道案内クエリの結果として生行われたドライブ手引きをユーザが選択する場合)。ステップ2905で、クライアントは、場所情報に基づいて対応するHTMLコードを作成する。例えば、HTMLコードはXSLT(Internet Explorerまたは他の市販のウェブブラウザで利用可能な共通のスクリプト言語)を用いて場所情報を含むXMLコードをHTMLに変換することによって作成されてもよい。作成されたHTMLコードは次いで、図26Aに示すHTMLテーブル2605等のテーブルの中へ挿入されてもよい。そこで、ステップ2910で、クライアントは、その後に地図画像上へ重ね合わされるHTMLウィンドウの境界の固定の部分のために1セットの予め描画した区画(例えば、図26Aに示すように第1コーナー区画2610、第2コーナー区画2612、第3コーナー区画2614、第4コーナー区画2615、および指示区画2622)を取得する。ステップ2915で、クライアントは、これらの予め描画した区画を接続して情報ウィンドウの境界の非固定の部分を作成する。例えば、情報ウィンドウの外側境界は、図26Aに示すように、例えば、接続された線2620により等の予め描画した区画の間の線を生成することで確定されてもよい。そこで、ステップ2920で、下記で検討するように、クライアントは、その後に地図画像上へ重ね合わされる1セットの予め描画した区画を確定および取得し、情報ウィンドウの陰影画像の固定の部分を生成する。ステップ2922で、下記で、また、検討するように、クライアントは、予め描画した区画を接続して情報ウィンドウの陰影画像の残りを埋める。
【0125】
図26Bは、基素の構成要素と並んで、情報ウィンドウと共に使用するための(また、図8および27で要素855として示す)情報ウィンドウの陰影2625の例を示す。陰影画像2625は、上記で説明したように作成された情報ウィンドウ2600の動的サイズに比例して対応するように動的に作成されてもよい。陰影画像2625を動的に作成するための例示的方法は、図26Bを参照して、以下のように進行してよい。陰影画像2625の高さは、情報ウィンドウ2600の高さの半分として設定されてもよい。図26Bに示すように、HTMLテーブルの陰影2625のサイズは、陰影のぼやけた輪郭線(存在する場合)を含み、それが半分の高さで陰影を含むことができるように確定される。情報ウィンドウの角度付きの垂直線(例えば、線2635)は、等角図法に一致するように所定の角度、例えば、角度45度でそれらを斜めにすることで作成されてもよい。例えば、オフセット線2635は、角度45度に設定される。これらの角度付きの線は、クライアントまたはサーバのいずれかで、クリッピング長方形を用いて予め描画した角度付きの陰影線の必要とされる部分のみを表示することで作成されてもよい。クライアントは、また、陰影画像のコーナーおよび指示区画のための1セットの予め描画した区画を確定する。図26Bでは、例えば、情報ウィンドウの陰影ボックスコーナー区画2640および情報ウィンドウの陰影指示区画2645が、サーバからまたはローカルでのいずれかで取得されてもよい。情報ウィンドウ2600のサイズに基づいて陰影画像の境界を確定した後に、そして適切な予め描画した区画を取得しクリッピングした後に、そこで接続線の残りが確定され、描かれてもよい。
【0126】
陰影画像は、また、図26Bに示すような、陰影同様の外見を作成するように埋められてもよい。陰影同様の外見を更に向上させるために、情報ウィンドウの下部に最も近い陰影画像部分が、最も暗くおよび/または最も鮮明であってよく、その一方で、陰影画像の部分が情報ウィンドウの下部から遠く離れて配置されている埋め部を徐々に色を薄くするおよび/またはぼやけさせる。
【0127】
図29へ戻り参照すると、ステップ2925で、クライアントは、陰影を地図画像上へ重ね合わせる。最後に、ステップ2930で、クライアントは、情報ウィンドウを地図画像上へ重ね合わせる。図8、26A、26Bおよび27の例から分かるように、この方法は、デジタル地図上にその陰影と並んで表示される場合に、全体として三次元的に見える情報ウィンドウを作成する。選択肢で、三次元的外見は、情報ウィンドウが北から始まって南へ配置されるように多数のタイルウィンドウを配置することで向上させることがあり、それにより奥行きの感覚も提供される。情報ウィンドウを東から西へ配置すること等の他の選択肢も利用可能である。この方法は、また、2つ以上のマーカーを地図上に配置する場合に使用されてもよい。
【0128】
図25を参照すると、同様な技法が、場所マーカー2500のための角度付き陰影2505を生成することに用いられてもよい。
【0129】
図30は、本発明の一実施の形態に従い地図画像表示ウィンドウをサイズ変更するための例示的フローチャートを表す。ステップ3000で、クライアントは、地図画像表示ウィンドウのサイズでの変更の通知を受信する(例えば、ユーザによるウィンドウのサイズ変更動作の結果として)。そこで、ステップ3005で、クライアントは地図画像ウィンドウの中心を決定する。次に、ステップ3010で、クライアントは、ウィンドウのサイズが増大されたか否かを判断する。そうである場合、ステップ3025で、クライアントは、新規の追加のスペースを埋めることに必要とされるかもしれない新規のいずれの地図タイルのIDを決定し、ステップ3030でクライアントは、これらの新規のタイルを、そのローカルキャッシュまたは遠隔サーバのいずれかから要求する。ステップ3035で、クライアントは、新規タイルをタイルテーブル配列に配置し、新規地図画像を表示する。代替として、ステップ3010でクライアントが、ウィンドウのサイズが減少されたと判断する場合、ステップ3015で、クライアントは、クリッピング形状ウィンドウのサイズを比例して低減する。最後に、ステップ3020で、クライアントは、クリッピング形状ウィンドウを地図画像の中心上に再度中心を合わせる。
【0130】
高解像度印刷
従来のウェブ地図サイトから地図ビューを印刷すると、地図ビューが先端的なプリンタの解像度より1桁低いことが多い画面の解像度で提供されるので、一般的に粗悪な出力を作成する。しかし、幾つかのホスト技術は(一実施の形態で使用されたようなDHTMLを含み)、印刷のために好適な解像度での地図タイルを使用する地図ビューの組立てを容易にする。従って、一実施の形態で地図画像の高品質ハードコピーを達成するために、地図ビューは、印刷解像度のタイルを用いて再組立てできる。一実施の形態はHTML IMG要素を用いてタイルをタイルグリッドに配置するために、128×128画素のサイズで1つ(例えば、screen_tile.gif)、512×512画素のサイズでもう1つ(例えば、print_tile.gif)の同じ地図タイルの2つの画像が、それぞれ表示および印刷の目的に使用されてもよい。図31は、本発明の一実施の形態に従い地図画像の高品質印刷のための例示的な1セットの様々な解像度の地図画像タイルを表す。図31に示す第3画像は、第1画像の高解像度バージョンのように見えることを当該技術に精通する者は気が付くであろう。この所見を用いて、ユーザからの印刷リクエストに応答して、現在の地図ビューは、印刷−解像度のタイルを用いて再組立てされてもよく、優れた印刷出力を達成する。
【0131】
この文書に説明および示されたフローチャートのステップを実装するためのソフトウェアおよび/またはハードウェアは、コンピュータデバイス503ならびに/もしくはサーバ510、515、および520とのどのような組合せ上でも、またはコンピュータデバイス503とネットワーク505との間で接続されているインターネットサービスプロバイダのサーバ等の図示されていない他のコンピュータデバイスもしくはサーバ上でも、実装されてもよい。その上、図示のブロックは、異なる順番で実行されてもよく、図示した厳密な順序で実行されることを必要としない。その上さらに、非依存の動作は並列して実装されてもよい。
【0132】
上記で説明したような実施の形態の態様は、図に図示した実装様態において多くの様々な形体のソフトウェア、ファームウェア、およびハードウェアで実装されてもよいことも、当該技術で通常の技量の者に明白であろう。本発明の原理に整合する態様を実装することに使用される実際のソフトウェアコードまたは特化した制御ハードウェアは、本発明の限定とはならない。従って、実施の形態の幾つかの態様の作動および挙動は、特定のソフトウェアコードに関連することなく説明した当該技術で通常の技量の者が本明細書の説明に基づいて態様を実装するソフトウェアおよび制御ハードウェアを設計することをできるであろうことが理解される。更に、実施の形態の幾つかの部分は、1つ以上の機能を実行する「ロジック」として実装されてもよい。このロジックは、特定用途向け集積回路またはフィールドプログラマブルゲートアレー等のハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組合せを含んでいてもよい。
【0133】
幾つかの例示的な実施の形態が、添付図面に示され、説明された。しかし、そのような実施の形態は単に例証的であり、制限的でないと理解されるものとする。種々の他の改変形態が当該技術に精通する者に思い浮かぶであろうために、本開示は、明示的に開示した特定の構造および編成に限定されてはならない。
【図面の簡単な説明】
【0134】
【図1】地図リクエスト記入のウェブページを表示する例示的なウェブブラウザを示す。
【図2】ウェブブラウザ上の例示的な地図表示を示す。
【図3】例示的な従来のベクターベースのデジタルマッピングシステムのアーキテクチャを示す。
【図4】例示的な従来のラスタベースのデジタルマッピングシステムのアーキテクチャを示す。
【図5】本発明の態様に従う分散型ネットワークシステムを示す。
【図6】本発明の態様に従うクライアント側またはサーバ側のコンピュータデバイスの例示的なブロック線図である。
【図7】本発明の態様に従う例示的なタイルベースのデジタルマッピングシステムのアーキテクチャを示す。
【図8】本発明の態様に従う例示的な地図リクエスト記入と地図表示とを組み合わせたウェブページを示す。
【図9】本発明の態様に従う例示的なサーバ側アーキテクチャを示す。
【図10】本発明の原理に整合する例示的なサーバ側アーキテクチャの更なる態様を示す。
【図11】本発明の態様に従う例示的な地図画像のタイルグリッドおよびクリッピング長方形を示す。
【図12】本発明の態様に従い例示的タイルグリッドをクリッピング長方形と対比した後に結果として得られる地図画像を表す。
【図13】本発明の態様に従う例示的な1セットの表示した画像に対応する基調を成すタイルグリッド座標およびクリッピング形状を示す。
【図14】本発明の態様に従い、地図タイルをウェブブラウザへ送信し、タイルをウェブブラウザにローカルでキャッシュに格納するための一実施の形態のフローチャートを示す。
【図15】ドライブ道案内をオーバレイとして地図画像上へ表示するために一実施の形態に従い使用されてもよいフローチャートを示す。
【図16】本発明の一実施の形態に従い地図画像のパン操作を実行するためのフローチャートを表す。
【図17】本発明の一実施の形態に従いクリッピング形状の幅の1/3だけ西へパンする例示的プロセスを示す図であって、同パンの第1の状態を示す。
【図18】同パンの第2の状態を示す図。
【図19】同パンの第3の状態を示す図。
【図20】同パンの第4の状態を示す図。
【図21】同パンの第5の状態を示す図。
【図22】本発明の一実施の形態に従いズーム操作を実装するための例示的フローチャートを表す。
【図23】本発明の一実施の形態に従い1セットの場所マーカーを地図画像上へ重ね合わせるための例示的フローチャートを表す。
【図24】本発明の態様に従う多数の重ね合わされた場所マーカーを持つ例示的地図表示のウェブページを表す。
【図25】本発明の態様に従う例示的場所マーカーの詳細を表す。
【図26A】本発明の態様に従う例示的情報ウィンドウの詳細を表す。
【図26B】本発明の態様に従う追加の例示的情報ウィンドウの詳細を表す。
【図27】本発明の態様に従う重ね合わされたドライブ道案内経路軌跡を持つ例示的地図表示のウェブページを表す。
【図28】本発明の態様に従う重ね合わされた領域境界軌跡を持つ例示的地図表示のウェブページを表す。
【図29】本発明の一実施の形態に従い地図画像上へ1セットの情報ウィンドウを重ね合わせるための例示的フローチャートを表す。
【図30】本発明の一実施の形態に従い地図画像表示ウィンドウをサイズ変更するための例示的フローチャートを表す。
【図31】本発明の一実施の形態に従い地図画像の高品質印刷のための例示的な1セットの様々な解像度の地図画像タイルを表す。
【特許請求の範囲】
【請求項1】
デジタル地図を表示するための方法であって、
場所リクエストをクライアント側のコンピュータデバイスから地図タイルサーバへ送ることと、
前記場所リクエストに応答して1セットの地図タイルを受信することと、
前記受信した地図タイルをタイルグリッドに組立てることと、
前記タイルグリッドをクリッピング形状に対して整列させることと、
前記整列の結果を地図画像として表示することと、
を備える方法。
【請求項2】
更に、ユーザ入力に応答して前記クリッピング形状を前記タイルグリッドに対して移動させることによって前記地図画像をパンすることを備える請求項1の方法。
【請求項3】
更に、第2セットの地図タイルを受信し、前記第2セットの地図タイルを前記タイルグリッドの中へ挿入することを備える請求項2の方法。
【請求項4】
更に、
ズームした画像を求めるユーザリクエストに応答して第2セットの地図タイルを取得することと、
前記第2セットの地図タイルを第2タイルグリッドに組立てることと、
前記第2タイルグリッドを前記クリッピング形状に対して整列させ、前記整列の結果をズームした地図画像として表示することと、
を備える請求項1の方法。
【請求項5】
前記第2タイルグリッドを前記クリッピング形状に対して整列させ、前記整列の結果を地図画像として表示することは、更に、
前記場所リクエストに関連するマーカー情報を取得することと、
前記マーカー情報を前記タイルグリッドと共に組立てることと、
組立てたタイルグリッドを前記クリッピング形状に対して整列させ、前記整列の結果を地図画像として表示することであって、前記地図画像が三次元地図の外見を有すること、
を備える請求項1の方法。
【請求項6】
前記整列の結果を地図画像として表示することは、更に、前記制御ボタンを前記地図画像上へ重ね合わせることを備える請求項1の方法。
【請求項7】
デジタル地図を表示することにおいて使用するのための装置であって、
デジタル地図データから作成された地図に関連する1セットの地図タイルを生成するための手段と、
クライアントから受信した候補の場所データを解釈するための手段であって、前記候補の場所データは場所情報を含む、手段と、
前記候補の場所データから前記場所情報を決定するための手段と、
前記場所情報に関連する要求された地図タイルを前記クライアントへ提供するための手段と、
を備える装置。
【請求項8】
前記候補の場所データから前記場所情報を前記決定するための手段は、前記候補の場所データを解析するための手段を備える請求項7の装置。
【請求項9】
更に、オーバレイオブジェクトを前記クライアントへ提供するための手段を備える請求項7の装置。
【請求項10】
前記場所情報に関連する要求された地図タイルを前記クライアントへ前記提供するための手段は、地図タイルのリクエストを前記クライアントから受信するための手段を備え、前記地図タイルのリクエストは地図タイル識別子を備える請求項7の装置。
【請求項11】
前記地図タイル識別子は、前記場所情報の緯度および経度ならびに要求されたズームレベルに関連している請求項11の装置。
【請求項12】
更に、マーカー情報を求めるリクエストを受信するための手段を備える請求項7の装置。
【請求項13】
更に、
前記場所情報に関連するドライブ道案内を求めるリクエストを受信するための手段と、
前記ドライブ道案内に関連する画像オーバレイを送信するための手段であって、前記画像オーバレイは前記場所情報に関連するデジタル地図と統合されることができる、手段と、
を備える請求項7の装置。
【請求項14】
更に、
前記要求された場所情報に関連する画像オーバレイを決定するための手段と、
前記画像オーバレイを前記クライアントへ送信するための手段であって、前記画像オーバレイは前記場所情報に関連するデジタル地図の中へ統合されることができる、手段と、
を備える請求項7の装置。
【請求項15】
コンピュータプログラム製品であって、
デジタル地図を作成するようにその中に具現化されたコンピュータ読み取り可能なプログラムコードを有するコンピュータの使用に適した媒体を備え、前記コンピュータプログラム製品中の前記コンピュータ読み取り可能なプログラムコードは、
候補データを受信するためのコンピュータ読み取り可能なプログラムコードであって、前記候補データは所望の場所を示す情報を含む、コンピュータ読み取り可能なプログラムコードと、
前記候補データに基づいた場所データを受信するためのコンピュータ読み取り可能なプログラムコードであって、前記場所データは前記所望の場所の実際の場所を示す、コンピュータ読み取り可能なプログラムコードと、
前記所望の場所に関連する第1地図タイルおよび前記第1地図タイルの近傍に配置された第1セットの地図タイルを取得するためのコンピュータ読み取り可能なプログラムコードと、
前記所望の場所がクリッピング形状のほぼ中心の近傍に位置決めされるように前記第1地図タイルおよび前記第1セットの地図タイルを組立てるためのコンピュータ読み取り可能なプログラムコードと、
前記組立てた地図タイルを出力するためのコンピュータ読み取り可能なプログラムコードと、
を備えるコンピュータプログラム製品。
【請求項16】
前記所望の場所がクリッピング形状のほぼ中心の近傍に位置決めされるように前記第1地図タイルおよび前記第1セットの地図タイルを前記組立てるためのコンピュータ読み取り可能なプログラムコードは、
前記第1地図タイルおよび前記第1セットの地図タイルをタイルグリッドに組立てるためのコンピュータ読み取り可能なプログラムコードと、
前記クリッピング形状の中心が前記第1地図タイルのほぼ前記所望の場所の上に位置決めされるように前記クリッピング形状を前記タイルグリッドの上に位置決めするためのコンピュータ読み取り可能なプログラムコードと、
を備える請求項15のコンピュータプログラム製品。
【請求項17】
更に、前記所望の場所に関連するマーカー情報を取得するためのコンピュータ読み取り可能なプログラムコードを備える請求項16のコンピュータプログラム製品。
【請求項18】
前記マーカー情報は、情報ウィンドウを含む、請求項17のコンピュータプログラム製品。
【請求項19】
前記情報ウィンドウのサイズおよび形状は、前記所望の場所に関連する情報の量に基づいて動的に作成される、請求項18のコンピュータプログラム製品。
【請求項20】
前記マーカー情報は、更に、マーカーの陰影を備え、前記マーカーの陰影のサイズおよび形状は前記情報ウィンドウの前記サイズおよび前記形状に基づいて動的に作成される、請求項19の装置。
【請求項21】
更に、前記組立てた地図タイルの上に配置された1つ以上の制御オブジェクトを取得および表示するためのコンピュータ読み取り可能なプログラムコードを備える、請求項18の装置。
【請求項22】
デジタル地図を決定しそして提供するための装置であって、
場所リクエストをクライアント側のコンピュータデバイスから地図タイルサーバへ送るための手段と、
前記場所リクエストに応答して1セットの地図タイルを受信するための手段と、
前記受信した地図タイルをタイルグリッドに組立てるための手段と、
前記タイルグリッドをクリッピング形状に対して整列させるための手段と、
前記整列の結果を地図画像として表示するための手段と、
を備える装置。
【請求項23】
場所リクエストをクライアント側のコンピュータデバイスから地図タイルサーバへ送るための手段は、前記場所リクエストを地図タイルリクエストに変換するための手段を備える、
請求項22の装置。
【請求項24】
前記場所リクエストを地図タイルリクエストに前記変換するための手段は、
前記場所リクエストに関連する緯度数および経度数を受信するための手段と、
前記緯度数および前記経度数をタイル識別数に変換するための手段と、
を備える請求項23の装置。
【請求項25】
前記タイル識別数は、デジタル地図に関連する1セットのタイルの原点に対する、請求項24の装置。
【請求項26】
情報をデジタル地図上に表示するための方法であって、
場所データをユーザから受信することと、
前記場所データに基づいたデジタル地図をサーバから取得することと、
前記場所データに関連する情報マーカーを取得することと、
前記情報マーカーに関連する情報マーカーの陰影を取得することと、
三次元地図の外見を作成するように前記情報マーカーおよび前記情報マーカーの陰影を前記デジタル地図上に重ね合わせることと、
前記デジタル地図ならびに前記重ね合わされた情報マーカーおよび情報マーカーの陰影を表示することと、
を備える方法。
【請求項27】
前記場所データに関連する情報マーカーを取得することおよび前記情報マーカーに関連する情報マーカーの陰影を取得することは、
前記場所データに関連するHTMLウィンドウを作成することと、
前記HTMLウィンドウのサイズに基づいて情報ウィンドウを作成することと、
前記情報ウィンドウのサイズに基づいて情報マーカーの陰影を作成することと、
を備える請求項26の装置。
【請求項28】
更に、
ユーザの動作に関連する制御ボタンを取得することと、
前記制御ボタンを前記等角法デジタル地図上に重ね合わせることと、
を備える請求項26の装置。
【請求項29】
タイルベースのデジタル地図システムに使用されることができるタイルベースのデジタル地図データベースを作成するための装置であって、
デジタル地図データを取得するための手段と、
前記デジタル地図データからデジタル地図を作成するための手段と、
前記デジタル地図を地図タイルに変換するための手段と、
を備える装置。
【請求項30】
更に、前記地図タイルをビットマップ画像に変換するための手段を備える請求項29の装置。
【請求項31】
デジタル地図を表示するための方法であって、
場所リクエストをクライアント側のコンピュータデバイスから地図タイルサーバへ送ることと、
前記場所リクエストに応答して1セットの地図タイルを受信することと、
前記受信した地図タイルをタイルグリッドに組立てることと、
前記タイルグリッド内にクリッピング形状を配置することによって地図画像を生成することと、
を備える方法。
【請求項1】
デジタル地図を表示するための方法であって、
場所リクエストをクライアント側のコンピュータデバイスから地図タイルサーバへ送ることと、
前記場所リクエストに応答して1セットの地図タイルを受信することと、
前記受信した地図タイルをタイルグリッドに組立てることと、
前記タイルグリッドをクリッピング形状に対して整列させることと、
前記整列の結果を地図画像として表示することと、
を備える方法。
【請求項2】
更に、ユーザ入力に応答して前記クリッピング形状を前記タイルグリッドに対して移動させることによって前記地図画像をパンすることを備える請求項1の方法。
【請求項3】
更に、第2セットの地図タイルを受信し、前記第2セットの地図タイルを前記タイルグリッドの中へ挿入することを備える請求項2の方法。
【請求項4】
更に、
ズームした画像を求めるユーザリクエストに応答して第2セットの地図タイルを取得することと、
前記第2セットの地図タイルを第2タイルグリッドに組立てることと、
前記第2タイルグリッドを前記クリッピング形状に対して整列させ、前記整列の結果をズームした地図画像として表示することと、
を備える請求項1の方法。
【請求項5】
前記第2タイルグリッドを前記クリッピング形状に対して整列させ、前記整列の結果を地図画像として表示することは、更に、
前記場所リクエストに関連するマーカー情報を取得することと、
前記マーカー情報を前記タイルグリッドと共に組立てることと、
組立てたタイルグリッドを前記クリッピング形状に対して整列させ、前記整列の結果を地図画像として表示することであって、前記地図画像が三次元地図の外見を有すること、
を備える請求項1の方法。
【請求項6】
前記整列の結果を地図画像として表示することは、更に、前記制御ボタンを前記地図画像上へ重ね合わせることを備える請求項1の方法。
【請求項7】
デジタル地図を表示することにおいて使用するのための装置であって、
デジタル地図データから作成された地図に関連する1セットの地図タイルを生成するための手段と、
クライアントから受信した候補の場所データを解釈するための手段であって、前記候補の場所データは場所情報を含む、手段と、
前記候補の場所データから前記場所情報を決定するための手段と、
前記場所情報に関連する要求された地図タイルを前記クライアントへ提供するための手段と、
を備える装置。
【請求項8】
前記候補の場所データから前記場所情報を前記決定するための手段は、前記候補の場所データを解析するための手段を備える請求項7の装置。
【請求項9】
更に、オーバレイオブジェクトを前記クライアントへ提供するための手段を備える請求項7の装置。
【請求項10】
前記場所情報に関連する要求された地図タイルを前記クライアントへ前記提供するための手段は、地図タイルのリクエストを前記クライアントから受信するための手段を備え、前記地図タイルのリクエストは地図タイル識別子を備える請求項7の装置。
【請求項11】
前記地図タイル識別子は、前記場所情報の緯度および経度ならびに要求されたズームレベルに関連している請求項11の装置。
【請求項12】
更に、マーカー情報を求めるリクエストを受信するための手段を備える請求項7の装置。
【請求項13】
更に、
前記場所情報に関連するドライブ道案内を求めるリクエストを受信するための手段と、
前記ドライブ道案内に関連する画像オーバレイを送信するための手段であって、前記画像オーバレイは前記場所情報に関連するデジタル地図と統合されることができる、手段と、
を備える請求項7の装置。
【請求項14】
更に、
前記要求された場所情報に関連する画像オーバレイを決定するための手段と、
前記画像オーバレイを前記クライアントへ送信するための手段であって、前記画像オーバレイは前記場所情報に関連するデジタル地図の中へ統合されることができる、手段と、
を備える請求項7の装置。
【請求項15】
コンピュータプログラム製品であって、
デジタル地図を作成するようにその中に具現化されたコンピュータ読み取り可能なプログラムコードを有するコンピュータの使用に適した媒体を備え、前記コンピュータプログラム製品中の前記コンピュータ読み取り可能なプログラムコードは、
候補データを受信するためのコンピュータ読み取り可能なプログラムコードであって、前記候補データは所望の場所を示す情報を含む、コンピュータ読み取り可能なプログラムコードと、
前記候補データに基づいた場所データを受信するためのコンピュータ読み取り可能なプログラムコードであって、前記場所データは前記所望の場所の実際の場所を示す、コンピュータ読み取り可能なプログラムコードと、
前記所望の場所に関連する第1地図タイルおよび前記第1地図タイルの近傍に配置された第1セットの地図タイルを取得するためのコンピュータ読み取り可能なプログラムコードと、
前記所望の場所がクリッピング形状のほぼ中心の近傍に位置決めされるように前記第1地図タイルおよび前記第1セットの地図タイルを組立てるためのコンピュータ読み取り可能なプログラムコードと、
前記組立てた地図タイルを出力するためのコンピュータ読み取り可能なプログラムコードと、
を備えるコンピュータプログラム製品。
【請求項16】
前記所望の場所がクリッピング形状のほぼ中心の近傍に位置決めされるように前記第1地図タイルおよび前記第1セットの地図タイルを前記組立てるためのコンピュータ読み取り可能なプログラムコードは、
前記第1地図タイルおよび前記第1セットの地図タイルをタイルグリッドに組立てるためのコンピュータ読み取り可能なプログラムコードと、
前記クリッピング形状の中心が前記第1地図タイルのほぼ前記所望の場所の上に位置決めされるように前記クリッピング形状を前記タイルグリッドの上に位置決めするためのコンピュータ読み取り可能なプログラムコードと、
を備える請求項15のコンピュータプログラム製品。
【請求項17】
更に、前記所望の場所に関連するマーカー情報を取得するためのコンピュータ読み取り可能なプログラムコードを備える請求項16のコンピュータプログラム製品。
【請求項18】
前記マーカー情報は、情報ウィンドウを含む、請求項17のコンピュータプログラム製品。
【請求項19】
前記情報ウィンドウのサイズおよび形状は、前記所望の場所に関連する情報の量に基づいて動的に作成される、請求項18のコンピュータプログラム製品。
【請求項20】
前記マーカー情報は、更に、マーカーの陰影を備え、前記マーカーの陰影のサイズおよび形状は前記情報ウィンドウの前記サイズおよび前記形状に基づいて動的に作成される、請求項19の装置。
【請求項21】
更に、前記組立てた地図タイルの上に配置された1つ以上の制御オブジェクトを取得および表示するためのコンピュータ読み取り可能なプログラムコードを備える、請求項18の装置。
【請求項22】
デジタル地図を決定しそして提供するための装置であって、
場所リクエストをクライアント側のコンピュータデバイスから地図タイルサーバへ送るための手段と、
前記場所リクエストに応答して1セットの地図タイルを受信するための手段と、
前記受信した地図タイルをタイルグリッドに組立てるための手段と、
前記タイルグリッドをクリッピング形状に対して整列させるための手段と、
前記整列の結果を地図画像として表示するための手段と、
を備える装置。
【請求項23】
場所リクエストをクライアント側のコンピュータデバイスから地図タイルサーバへ送るための手段は、前記場所リクエストを地図タイルリクエストに変換するための手段を備える、
請求項22の装置。
【請求項24】
前記場所リクエストを地図タイルリクエストに前記変換するための手段は、
前記場所リクエストに関連する緯度数および経度数を受信するための手段と、
前記緯度数および前記経度数をタイル識別数に変換するための手段と、
を備える請求項23の装置。
【請求項25】
前記タイル識別数は、デジタル地図に関連する1セットのタイルの原点に対する、請求項24の装置。
【請求項26】
情報をデジタル地図上に表示するための方法であって、
場所データをユーザから受信することと、
前記場所データに基づいたデジタル地図をサーバから取得することと、
前記場所データに関連する情報マーカーを取得することと、
前記情報マーカーに関連する情報マーカーの陰影を取得することと、
三次元地図の外見を作成するように前記情報マーカーおよび前記情報マーカーの陰影を前記デジタル地図上に重ね合わせることと、
前記デジタル地図ならびに前記重ね合わされた情報マーカーおよび情報マーカーの陰影を表示することと、
を備える方法。
【請求項27】
前記場所データに関連する情報マーカーを取得することおよび前記情報マーカーに関連する情報マーカーの陰影を取得することは、
前記場所データに関連するHTMLウィンドウを作成することと、
前記HTMLウィンドウのサイズに基づいて情報ウィンドウを作成することと、
前記情報ウィンドウのサイズに基づいて情報マーカーの陰影を作成することと、
を備える請求項26の装置。
【請求項28】
更に、
ユーザの動作に関連する制御ボタンを取得することと、
前記制御ボタンを前記等角法デジタル地図上に重ね合わせることと、
を備える請求項26の装置。
【請求項29】
タイルベースのデジタル地図システムに使用されることができるタイルベースのデジタル地図データベースを作成するための装置であって、
デジタル地図データを取得するための手段と、
前記デジタル地図データからデジタル地図を作成するための手段と、
前記デジタル地図を地図タイルに変換するための手段と、
を備える装置。
【請求項30】
更に、前記地図タイルをビットマップ画像に変換するための手段を備える請求項29の装置。
【請求項31】
デジタル地図を表示するための方法であって、
場所リクエストをクライアント側のコンピュータデバイスから地図タイルサーバへ送ることと、
前記場所リクエストに応答して1セットの地図タイルを受信することと、
前記受信した地図タイルをタイルグリッドに組立てることと、
前記タイルグリッド内にクリッピング形状を配置することによって地図画像を生成することと、
を備える方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26A】
【図26B】
【図27】
【図28】
【図29】
【図30】
【図31】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26A】
【図26B】
【図27】
【図28】
【図29】
【図30】
【図31】
【公表番号】特表2007−531004(P2007−531004A)
【公表日】平成19年11月1日(2007.11.1)
【国際特許分類】
【出願番号】特願2007−504954(P2007−504954)
【出願日】平成17年2月5日(2005.2.5)
【国際出願番号】PCT/US2005/003832
【国際公開番号】WO2005/104039
【国際公開日】平成17年11月3日(2005.11.3)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVA
【出願人】(505281067)グーグル インク. (58)
【氏名又は名称原語表記】GOOGLE INC.
【Fターム(参考)】
【公表日】平成19年11月1日(2007.11.1)
【国際特許分類】
【出願日】平成17年2月5日(2005.2.5)
【国際出願番号】PCT/US2005/003832
【国際公開番号】WO2005/104039
【国際公開日】平成17年11月3日(2005.11.3)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVA
【出願人】(505281067)グーグル インク. (58)
【氏名又は名称原語表記】GOOGLE INC.
【Fターム(参考)】
[ Back to top ]