JP6125406B2 - デジタルマッピングシステム - Google Patents

Description

関連出願の相互参照
本出願は、２００４年５月３日出願の米国仮特許出願第６０／５６７，９４６号に対する優先権を主張し、その全体を引用して本明細書に組込む。本出願はまた、２００４年３月２３日出願の米国仮特許出願第６０／５５５，５０１号に対する優先権を主張し、その全体を引用して本明細書に組込む。

本発明の原理に整合する実装様態は、一般的にマッピングシステムに関し、より詳細には、デジタル環境におけるマッピングシステムに関する。

コンピュータ化したマッピングシステムが、旅行計画を容易にするために開発されてきた。例えば、旅行計画インターネットウェブサイトが、商用に供されており、良く知られている。そのようなウェブサイトは、普通にはユーザが要求した場所クエリを入力することができ、それにより要求した場所に関連する地図がユーザへ提供できる。また、良く知られたウェブサイトは、ユーザに旅行の出発点と終着点を記入させて、次いで旅程を計算しユーザへ提供することに使用できる。

以下に続く本発明の幾つかの態様の詳細な検討のための背景として、図１から図４が、従来の例示的デジタルマッピングシステムの幾つかの態様を表す。図１は、地図リクエスト記入のウェブページ１０５を表示するウェブブラウザのユーザインタフェース１００を示す。図示のように、ユーザは、所望の場所のモンタナ州４５６１９、ビリングス、メインＳｔ．３５３を記入した。地図を作成するべき所望の場所を記入した後に、図１に示すように、ユーザは次いで、「地図リクエスト」ボタン１１０を選択することで（普通には遠隔サーバから）地図を要求する。地図画像は次いで、普通には遠隔サーバで生成され、ユーザのコンピュータデバイスへ送信され、結局地図表示のウェブページにあるウェブブラウザのユーザインタフェース１００上に表示される。

図２は、ウェブブラウザのユーザインタフェース１００上の例示的地図表示のウェブページ２００を示す。ここでは、地図表示のウェブページ２００は、図１からの地図リクエストの結果を表示している。表示された情報は、一般的に地図画像２０５から成り、要求された場所および周囲の領域を表す。図２に示すように、要求された場所は、地図画像２０５上に住所アイコン２０８で識別され、住所アイコン２０８は、普通には地図画像２０５の中心に配置される。また、要求された場所および住所アイコン２０８は、地図表示のウェブページ２００内の地図凡例ウィンドウ２１０にも表示されてもよい。住所アイコン２０８は、普通には簡単な二次元画像であり、地図画像２０５内で他のそのようなアイコンと近接近して表示される場合、視覚的混乱を生じることがあり、それぞれのアイコンが地図画像２０５内で実際に示す箇所に関してユーザを困惑させ、誤り導くことがある。

地図のウェブページ２００は、地図画像２０５が表示される様式を制御するよう選択できるボタンまたは他のユーザインタフェースオブジェクトも表示できる。例えば、図２に示すように、ズーム制御オブジェクト２２０が一般的に設けられ、ユーザが「拡大」または「縮小」することを容認し、それによって地図画像２０５の表示された縮尺比にそれに応じて影響を及ぼし、その一方で、普通には住所アイコン２０８で印付けた所望の場所を画像の中心に保持する。また、「下向矢印」方向ボタン２１５等の方向ボタンまたは他の同様なユーザインタフェースオブジェクトが設けられてもよく、地図画像２０５の「南の」境界を越えたためにこれまでは隠されていたより多くの地図情報を表示すること等によってユーザが画像を「パン」することを容認し、その一方で、これまで表示されていた地図情報の「北の」部分の相当する部分をシフトさせて隠す。図２に示すように、そのような画像制御オブジェクトは、従来では地図画像２０５の境界領域の外側に表示され、地図表示ウェブページ２００内の地図画像２０５のために利用可能なスペースの量を低減させる。

普通には、（図２に示すズーム制御オブジェクト２００または方向ボタンボタン２１５等の）画像制御オブジェクトが選択される場合、ＨＴＴＰリクエストがサーバへ送信され、サーバはそこで選択されたズームレベルで表示されるべき新規の地図情報を含む新規の画像を送信する。

具体的には、図３に示すような、例示的システムにおいて、ウェブブラウザ３００は、要求された地図画像に対する場所情報を含むＨＴＴＰリクエストをウェブサーバ３０５へ送る。ＨＴＴＰリクエストは、図１に示すように、データ記入ウェブページ１０５を通してウェブブラウザユーザインタフェース１００を介して受信した場所データから成ってもよい。例えば、図１に示し、先に説明したように、ユーザは以下の地図を作成するべき所望の場所を記入してよい：モンタナ州４５６１９、ビリングス、メインＳｔ．３５３。ユーザは次いで、「地図リクエスト」ボタン１１０を選択することで道案内を要求し、この選択イベントが、結局図３に示すＨＴＴＰリクエストをウェブブラウザ３００からウェブサーバ３０５へ（直接的または間接的に）送信させる。ＨＴＴＰリクエストに応答して、ウェブサーバ３０５は、データベースクエリ（「ＤＢクエリ」）を地図ベクターデータベース３１０へ送る。地図ベクターデータベース３１０は、普通には所望の場所データについての対応するベクターを決定し、これらのベクターをウェブサーバ３０５へ送信する。ウェブサーバ３０５は次いで、普通には受信したベクターを用いて所望の地図のビットマップ画像を生成し、ビットマップをウェブブラウザ３００が対応している画像フォーマット（例えば、ＧＩＦ、ＰＮＧ、ＪＰＥＧ等）に変換する。ウェブサーバ３０５は次いで、画像をウェブブラウザ３００へ、一般的にそれをハイパーテキスト記述言語（ＨＴＭＬ）コード内に埋め込んで送信する。地図画像は次いで、（図２に示し、先に説明したように）ウェブブラウザユーザインタフェース１００によりユーザへ表示される。従って、ユーザが郵便住所を記入すること、または現在の地図ビューの付近にあるナビゲーションリンクをクリックすることで新規の地図ビューを要求する場合に、ウェブブラウザ３００は、ウェブサーバ３０５へ新規の地図ビューの境界を示すリクエストを送る。ウェブサーバ３０５は、次にデータベースから対応するベクターベースの地図データを抽出し、地図のビットマップ画像を描画する。ウェブサーバ３０５は次いで、ビットマップ画像をウェブブラウザ３００が対応している画像フォーマットへ変換し、画像を、場合によってはＨＴＭＬに埋め込んで、ユーザへの表示のためにウェブブラウザ３００へ返す。そのようなシステムの商用実装様態は、ＡＯＬ社のMapQuest (http://www.mapquest.com)、ヤフー社のTelcontarベースの「SmartView」地図(http://maps.yahoo.com)、およびマイクロソフト社のMapPoint.netスイート (例えば、http://maps.msn.com)を含む。

図４は、地図データをウェブブラウザへ提供するために使用される第２の例示的システムを示す。図４に示すように、ウェブブラウザ３００は、図３に対して先に説明したものと同じ様式でＨＴＴＰリクエストをウェブサーバ３０５へ送信する。ウェブブラウザ３００からのＨＴＴＰリクエストを受信すると、図４に示すウェブサーバ３０５は、要求された場所データを含むデータベースクエリ（「ＤＢクエリ」）を地図ラスタデータベース４１０へ送信する。地図ラスタデータベース４１０は、データベースクエリに基づいて適切な画像を大きい予め描画した地図画像の中から抽出する。要求された画像は次いで、ウェブサーバ３０５へ送信され、ウェブサーバ３０５はそこで先に説明したように画像をウェブブラウザ３００へ送信する。従って、図４に示すようなデジタルマッピングシステムでは、ベクターを抽出し、地図画像を描画するステップは、大きい予め描画した画像の適切な一部を単に抽出するステップで置き換えられる。そのようなシステムの商用実装様態は、英国のMultiMaps (http://multimaps.com)およびオーストラリアのWhereIs (http://www.whereis.com.au) を含む。かかるシステムは、普通にはかかる地図の印刷バージョンを生成することにも使用される同じベクターベースのファイルから地図画像を生成することにも、注目すべきである。

上記の問題の幾つかは数多くのより小さい画像（「タイル」として知られる）をウェブサーバ３０５からウェブブラウザ３００へ送信することによって克服できるであろうことにデジタルマッピングウェブサイトの幾つかのプロバイダが気付いた。これらのより小さいタイルは、次いで、ウェブブラウザ３００によってより大きい画像に組立てることができる。例えば、マイクロソフト社のTerraServer米国サイトは（http://terraserver.homeadvisor.msn.com/）、現在、衛星写真を表示するためにタイル化する手法を用いている。

デジタルマッピングシステムの態様を実装するための種々の方法、システム、および装置が開示されている。１つのかかる方法は、場所リクエストをクライアント側コンピュータデバイスから地図タイルサーバへ送ること、場所リクエストに応答して１セットの地図タイルを受信すること、前記受信した地図タイルをタイルグリッドに組立てること、タイルグリッドをクリッピング形状に対して整列させること、そして、結果を地図画像として表示することを含む。本発明の態様に従う１つの装置は、場所リクエストをクライアント側コンピュータデバイスから地図タイルサーバへ送るための手段、場所リクエストに応答して１セットの地図タイルを受信するための手段、前記受信した地図タイルをタイルグリッドに組立てるための手段、タイルグリッドをクリッピング形状に対して整列させるための手段、そして、結果を地図画像として表示するための手段を含む。かかる装置は、更に、表示した地図画像上への対話式オーバレイとして方向制御またはズーム制御のオブジェクトを含んでもよく、地図タイル画像上に経路または場所のオーバレイも、含んでいてもよい。

この明細書に組込まれ、その一部を構成する添付図面は、種々の実施の形態を図示する。

地図リクエスト記入のウェブページを表示する例示的なウェブブラウザを示す。

ウェブブラウザ上の例示的な地図表示を示す。

例示的な従来のベクターベースのデジタルマッピングシステムのアーキテクチャを示す。

例示的な従来のラスタベースのデジタルマッピングシステムのアーキテクチャを示す。

本発明の態様に従う分散型ネットワークシステムを示す。

本発明の態様に従うクライアント側またはサーバ側のコンピュータデバイスの例示的なブロック線図である。

本発明の態様に従う例示的なタイルベースのデジタルマッピングシステムのアーキテクチャを示す。

本発明の態様に従う例示的な地図リクエスト記入と地図表示とを組み合わせたウェブページを示す。

本発明の態様に従う例示的なサーバ側アーキテクチャを示す。

本発明の原理に整合する例示的なサーバ側アーキテクチャの更なる態様を示す。

本発明の態様に従う例示的な地図画像のタイルグリッドおよびクリッピング長方形を示す。

本発明の態様に従い例示的タイルグリッドをクリッピング長方形と対比した後に結果として得られる地図画像を表す。

本発明の態様に従う例示的な１セットの表示した画像に対応する基調を成すタイルグリッド座標およびクリッピング形状を示す。

本発明の態様に従い、地図タイルをウェブブラウザへ送信し、タイルをウェブブラウザにローカルでキャッシュに格納するための一実施の形態のフローチャートを示す。

ドライブ道案内をオーバレイとして地図画像上へ表示するために一実施の形態に従い使用されてもよいフローチャートを示す。

本発明の一実施の形態に従い地図画像のパン操作を実行するためのフローチャートを表す。

本発明の一実施の形態に従いクリッピング形状の幅の１／３だけ西へパンする例示的プロセスを示す図であって、同パンの第1の状態を示す。

同パンの第２の状態を示す図。

同パンの第３の状態を示す図。

同パンの第４の状態を示す図。

同パンの第５の状態を示す図。

本発明の一実施の形態に従いズーム操作を実装するための例示的フローチャートを表す。

本発明の一実施の形態に従い１セットの場所マーカーを地図画像上へ重ね合わせるための例示的フローチャートを表す。

本発明の態様に従う多数の重ね合わされた場所マーカーを持つ例示的地図表示のウェブページを表す。

本発明の態様に従う例示的場所マーカーの詳細を表す。

本発明の態様に従う例示的情報ウィンドウの詳細を表す。 本発明の態様に従う追加の例示的情報ウィンドウの詳細を表す。

本発明の態様に従う重ね合わされたドライブ道案内経路軌跡を持つ例示的地図表示のウェブページを表す。

本発明の態様に従う重ね合わされた領域境界軌跡を持つ例示的地図表示のウェブページを表す。 本発明の一実施の形態に従い地図画像上へ１セットの情報ウィンドウを重ね合わせるための例示的フローチャートを表す。 本発明の一実施の形態に従い地図画像表示ウィンドウをサイズ変更するための例示的フローチャートを表す。 本発明の一実施の形態に従い地図画像の高品質印刷のための例示的な１セットの様々な解像度の地図画像タイルを表す。

本発明の実施形態を開示の種々の態様を、マッピング情報を取得し、表示するための装置、システム、および方法の文脈の中で明細書に説明する。以下の説明は例証的のみであり、何らかの限定を行うものではないことを当該技術に精通する者は感知するであろう。他の態様もこの開示の恩恵を有する者にとり容易に自明であろう。

例えば、Java言語、JavaScript、Javaアプレット技術、Ｃ、Ｃ＋＋、Perl、Pascal、Smalltalk、FORTRAN、アセンブリ言語、ＨＴＭＬ（すなわち、ハイパーテキスト記述言語）、ＤＨＴＭＬ（すなわち、ダイナミックハイパーテキスト記述言語）、ＸＭＬ（すなわち、拡張可能記述言語）、ＸＬＳ（すなわち、拡張可能スタイル言語）、ＳＶＧ（すなわち、スケーラブルベクターグラフィックス）、ＶＭＬ（すなわち、ベクター記述言語）、マクロメディア社のFlash技術等の、数多くのコンピュータプログラミング言語が、本発明の態様を実装することに使用されてもよい。更に、手続き型、オブジェクト指向、または人工知能技術等の種々のプログラミング手法が、それぞれ特定の実装要件によって用いられてもよい。

同じ参照番号を、この文書において図面および説明の全体にわたり用いて、同じかまたは同様の部分に言及する。更に、本明細書における幾つかの図は、方法およびシステムを示すフローチャートである。これらフローチャートのそれぞれのブロック、およびこれらフローチャートにおけるブロックの組合せは、コンピュータプログラム命令で実装されてもよいことが理解されるであろう。これらのコンピュータプログラム命令は、コンピュータまたは他のプログラム可能な装置上へ読み込まれてマシンを生じてもよく、それによりコンピュータまたは他のプログラム可能な装置上で実行する命令はフローチャートのブロック（単数または複数）に指定された機能を実装するための構造を作成する。また、コンピュータまたは他のプログラム可能な装置に特定の様式で機能するよう指図できるこれらのコンピュータプログラム命令は、コンピュータ可読メモリに格納されてもよく、それによりコンピュータ可読メモリに格納された命令がフローチャートのブロック（単数または複数）に指定された機能を実装する命令体系を含む製造品を作成する。また、コンピュータプログラム命令は、コンピュータまたは他のプログラム可能な装置上へ読み込まれてよく、一連の操作上のステップをコンピュータまたは他のプログラム可能な装置上で実行させて、コンピュータ実装のプロセスを作成し、それによりコンピュータまたは他のプログラム可能な装置上で実行する命令がフローチャートのブロック（単数または複数）に指定された機能を実装するためのステップを提供する。

従って、フローチャートのブロックは、指定された機能を実行するステップの組合せおよび指定された機能を実行するためのステップの組合せに対応している。また、フローチャートの各ブロック、およびフローチャートにおけるブロックの組合せは、指定の機能またはステップを実行する特別用途ハードウェアに基づくコンピュータシステム、または特別用途ハードウェアおよびコンピュータ命令の組合せで実装できることも、理解されるであろう。

図５は、本発明の態様に従う分散型ネットワークシステム５００を示す。コンピュータデバイス５０３が、ネットワーク５０５へ接続されて、示されている。また、種々のサーバも、ネットワーク５０５へ接続されている。例えば、ウェブサーバ５１０、タイルサーバ５１５、および場所データサーバ５２０は、全てがネットワーク５０５と通信しているとして示されているが、他のサーバ（不図示）も、ネットワーク５０５へ接続されてもよい。コンピュータデバイス５０３は、パーソナルコンピュータ、携帯電話、携帯情報端末、車両に配置されるナビゲーションシステム等の演算用に構成されたどのような種類のデバイスであってもよい。サーバ５１０、５１５および５２０は、ネットワークサーバまたはウェブサーバ等のそれぞれがネットワーク５０５上でホスティングサービス能力のあるどのようなデバイスであってもよい。また、サーバ５１０、５１５および５２０は、ユーザ入力に基づいて幾らかまたは全てのマッピング情報を決定および／または取得する能力があってもよい。代替として、コンピュータデバイス５０３は、旅程を決定および／または取得する能力を装備していてもよい。幾つかの実装では、コンピュータデバイスおよびサーバ（またはその種々の部分）は、１つ以上のマシンに共同で配置されていてもよい。

ネットワーク５０５は、どのような種類の分散型ネットワークであってもよく、例えばローカルエリアネットワーク、広域ネットワーク、交換電話ネットワーク、イントラネット、インターネットまたはワールドワイドウェブネットワーク等であってもよい。代替として、ネットワーク５０５は、コンピュータデバイス５０３とサーバ５１０、５１５、および５２０との間の直接的な接続であってもよい。コンピュータデバイス５０３、ネットワーク５０５および／またはサーバ５１０、５１５、および５２０は、どのような種類の有線または無線接続を介して通信してもよい。その上、ネットワーク５０５と通信しているコンピュータデバイス５０３、サーバ５１０、５１５、および５２０、ならびに、他のコンピュータデバイス（不図示）、および／または他のサーバ（不図示）が、本明細書中に説明するいずれかまたは全ての機能を実行することに使用されてもよい。

図６は、コンピュータデバイス５０３、またはサーバ５１０、５１５、および５２０の例示的な線図である。コンピュータデバイス／サーバ５０３／５１０／５１５／５２０は、バス６００、１つ以上のプロセッサ６０５、主メモリ６１０、読出専用メモリ（ＲＯＭ）６１５、記憶装置６２０、１つ以上の入力デバイス６２５、１つ以上の出力デバイス６３０、および通信インタフェース６３５を含んでいてもよい。バス６００は、コンピュータデバイス／サーバ５０３／５１０／５１５／５２０の構成要素間での通信を許容する１つ以上の導線を含んでいてもよい。

プロセッサ６０５は、命令を解釈して実行するどのような種類の従来のプロセッサ、マイクロプロセッサ、または処理ロジックを含んでいてもよい。主メモリ６１０は、プロセッサ６０５による実行のための情報および命令を格納するランダムアクセスメモリ（ＲＡＭ）または別の種類の動的記憶装置を含んでいてもよい。ＲＯＭ６１５は、プロセッサ６０５による使用のための静的情報および命令を格納する従来のＲＯＭ装置または別の種類の静的記憶装置を含んでいてもよい。記憶装置６２０は、磁気および／または光学記録媒体およびその対応する駆動部を含んでいてもよい。

入力デバイス６２５は、キーボード、マウス、ペン、スタイラス、手書き認識、音声認識、生体メカニズム等の、ユーザが情報をコンピュータデバイス／サーバ５０３／５１０／５１５／５２０へ入力することを許容する１つ以上の従来のメカニズムを含んでいてもよい。出力デバイス６３０は、ディスプレイ、プリンタ、スピーカ等を含む、ユーザへ情報を出力する１つ以上の従来のメカニズムを含んでいてもよい。通信インタフェース６３５は、コンピュータデバイス／サーバ５０３／５１０／５１５／５２０が他のデバイスおよび／またはシステムと通信することを可能にするどのようなトランシーバのようなメカニズムを含んでいてもよい。例えば、通信インタフェース６３５は、ネットワーク５０５等のネットワークを介して別のデバイスまたはシステムと通信するためのメカニズムを含んでいてもよい。

下記で詳細に説明するように、コンピュータデバイス５０３および／またはサーバ５１０、５１５、および５２０は、データ記憶装置６２０等の別のコンピュータ可読媒体から、または通信インタフェース６３５を介して別のデバイスからメモリ６１０へ読出されてもよいソフトウェア命令に基づいて操作を実行してもよい。メモリ６１０内に含まれるソフトウェア命令は、プロセッサ６０５に後述するプロセスを実行させる。代替として、配線で接続された回路が、ソフトウェア命令の代わりにまたはそれと組合せて使用されて本発明に整合するプロセスを実装してもよい。従って、種々の実装は、ハードウェア回路およびソフトウェアのどのような特定の組合せにも限定されない。

ウェブブラウザユーザインタフェース（図１および図２に示すウェブブラウザインタフェース１００等）を備えるウェブブラウザ（図３および図４に示すウェブブラウザ３００等）は、情報（文章および図形情報等）をコンピュータデバイス５０３上に表示することに使用されてもよい。ウェブブラウザ３００は、図５に示すネットワーク５０５を介して受信した情報を表示することのできるどのような種類の視覚的表示を備えていてもよく、例えばマイクロソフト社のInternet Explorerブラウザ、ネットスケープ社のNavigatorブラウザ、MozillaのFirefoxブラウザ、PalmSource社のWeb Browser、またはネットワーク４０５と通信することのできるいずれかの他の閲覧もしくは他のアプリケーションソフトウェア等であってもよい。また、コンピュータデバイス５０３は、ブラウザアシスタントを含んでいてもよい。ブラウザアシスタントは、プラグイン、アプレット、ダイナミックリンクライブラリ（ＤＬＬ）、または同様の実行可能なオブジェクトもしくはプロセスを含んでいてもよい。更に、ブラウザアシスタントは、ウェブブラウザ３００へ拡張機能を提供するツールバー、ソフトウェアボタン、またはメニューであってもよい。代替として、ブラウザアシスタントは、ウェブブラウザ３００の一部であってもよく、その場合、ブラウザ３００はブラウザアシスタント機能を実装することになる。

ブラウザ３００および／またはブラウザアシスタントは、ユーザとコンピュータデバイス５０３および／またはネットワーク５０５との間の媒介物として動作してもよい。例えば、ネットワーク５０５に接続されたデバイスから受信したソースドキュメントまたは他の情報は、ブラウザ３００を介してユーザへ出力されてもよい。また、ブラウザ３００およびブラウザアシスタントの両方は、ソースドキュメントをユーザへ出力する前に受信したソースドキュメント上に操作を行うことができる。更に、ブラウザ３００および／またはブラウザアシスタントは、ユーザ入力を受信し、ネットワーク５０５に接続されたサーバ５０５／５１５／５２０または他のデバイスへ入力されたデータを送信してもよい。

例示的システムの概要およびユーザインタフェース
下記でより詳細に説明するように、一実施の形態の幾つかの態様は、それぞれ適切な１セットの分離したズームレベルの大きい（例えば、米国全体の規模の）連続した地図のラスタ画像の存在を想定している。一時的なオフライン段階中に、システムは、この大きいラスタ画像を生成し、所望の地図ビューより一般的に１桁小さいサイズのセグメント（例えば、長方形タイル）に切り分け、これらのタイルをウェブブラウザが対応しているフォーマットでサーバ側データベースに格納する。

図７の例に示すように、ウェブユーザが新規の地図ビューをアプリケーションソフトウェア７００（例えば図３および図４に示すウェブブラウザ３００等）を介して要求する場合、ウェブブラウザに（または、限定しないが、図６に示す主メモリ６１０、ＲＯＭ６１５、および／または記憶装置６２０として実装できるであろう、図７にローカルメモリ７０５として示すウェブブラウザのキャッシュに）既に存在するタイルと併せて必要である最小の１セットのタイルのみに対するＨＴＴＰリクエストが、サーバ７１０へ送られて、新規ビューを作成する。これらのＨＴＴＰタイルリクエストに対する応答のフォーマットは、ヘッダフィールドにウェブブラウザがタイルをローカルでキャッシュに格納するよう促す情報を含んでいる。１セットのスクリプトを実行することによって、ウェブブラウザは次いで、組み合わせたタイルのセットをユーザへの提供のための新規ビューにシームレスに組立てる。古い地図ビューは一般的に未だブラウザに存在しているため、追加のスクリプトを用いて、古い地図ビューから新しい地図ビューへの移行を、パンおよび／またはズーム操作の一部として、滑らかに動画化してもよい。その上、場所マーカーおよび経路を、例えば、ドライブ道案内、局所検索、職業別電話帳の参照等のユーザリクエストに応答して、予め描画した地図タイルの上に重ね合わせることができる。加えて、同様な技法は、例えば、地図画像上で地域および街路を強調することに使用できる。

エンドユーザ（例えば図５に示すコンピュータデバイス上で動作しているウェブブラウザと対話しているユーザ等）の視点から、図８は、本発明の態様に従う地図リクエストと地図表示とを組み合わせたページ８００の一実施の形態を表す。図８に示すように、ページ８００は、地図画像８０５、重ね合わされた地図方向制御オブジェクト８１５、重ね合わされたズーム制御オブジェクト８２０、場所リクエストテキスト記入フィールド８２５、検索ボタン８３０、情報ウィンドウ８４０、場所マーカー８４５、場所マーカーの陰影８５０、および情報ウィンドウの陰影８５５を含む。後で詳細に説明するように、地図画像８０５は、タイルグリッドを地図画像８０５とほぼ同じサイズと形状を有するクリッピング形状に対して整列させることによって実際に生成される。タイルグリッドは、一実施の形態では、複数のより小さな個別の地図タイルで構成され、これらの地図タイルが表示用のより大きな画像にシームレスに配置されてなるものである。当該技術に精通する者に周知である画像オーバレイ技術および絶対位置決め技法を用いて、地図方向制御オブジェクト８１５およびズーム制御オブジェクト８２０は、地図画像８０５それ自体内に実際に配置されてもよく、それによって表示ページ８００内で地図画像８０５のために利用可能である領域を増大させる。このようにして、地図画像８０５に対する任意のサイズが実装されてもよく、それは地図タイルの全ての数に限定されない。その上、どのような任意の点も、地図画像８０５の中心に配置されてもよい。一実施の形態では、場所クエリテキスト記入フィールド８２５は、単一のテキストフィールドとして実装され、それにより地図を作成するべき所望の場所の種々の構成要素（例えば、番地、市、州、または郵便番号等）が多数のフィールドを用いて指定される必要はない。後で検討するように、一実施の形態では、図８はまた、課金点８６０を地図画像の中心に含む（とはいえ、課金点８６０は、普通には地図画像８０５上における可視特徴ではない）。

検索ボタン８３０が選択される場合、テキスト記入フィールド８２５内に記入された地図を作成するべき所望の場所は、ユーザのコンピュータデバイスまたは遠隔サーバのいずれかで解析され、地図画像８０５が（本文書全体にわたり説明されている詳細なプロセスによって）生成および表示される。記入フィールド８２５内に記入された所望の場所もまた、その元の形式または解析した形式のいずれかで地図タイトル８４０として繰り返され、表示されてもよい。地図を作成するべき所望の場所は、場所マーカー８４５およびその陰影８５０によって地図画像８０５内に図形で識別される。後で説明するように、角度付き陰影を備える場所マーカーを視覚的に二次元に表示する効果を使用することによって、特に多数の場所マーカーが相互に近接して配置される場合、地図画像８０５内の視覚的混乱は最少にされ、場所マーカーに対応する地図上の実際の場所は、より容易に地点として識別されるであろう。

ユーザ画像制御機能の観点で、地図方向制御オブジェクト８１５は、地図をクリッピング形状サイズの、例えば２５％だけ矢印の方向にパンさせる１セットの矢印ラベル付パンボタンとして実装されてもよい。また、これらのボタンは、「西」、「北」または「北西」等のコンパス方位でラベル付けもできる。図８に示すように、ズーム制御オブジェクト８２０は、地図を単一レベルだけそれぞれ拡大および縮小させる「＋」および「−」のラベル付きボタンを含んでいてもよい。これらのボタンはまた、対応するズームレベルの主たる地理的な抽象概念、例えば、「街路」、「市」、「郡」、「州」、「国」等によってラベル付けられてもよい。また、図８に示すように、ズーム制御オブジェクト８２０も、それぞれのズームレベルに対する分離した位置を持つスライダを含んでもよい。ユーザの視点から、スライダを特定のズームレベルへ移動させることは、対応するズームレベルを選択することと同じ効果を有してもよい。

一実施の形態で提供されるユーザインタフェース機能の追加の例として、地図画像８０５の特定の部分を「クリックする」か、または他の方法で選択することで、選択した場所を地図画像８０５の中心へパンさせる一方で、地図画像８０５の特定の部分を「ダブルクリックする」か、または他の方法で強調して選択することで、選択した場所を地図画像８０５の中心へパンさせると同時にズームレベルを増大させる。別の実施の形態では、地図画像８０５の特定の部分を「ダブルクリックする」か、または他の方法で強調して選択することで、選択した場所を地図画像８０５の中心へパンさせる一方で、場所マーカー（地図画像８０５内のマーカーまたは地図画像８０５に隣接のマーカーのいずれか）をクリックするか、または他の方法で選択することで、マーカーに関連する情報ウィンドウを開き、その後に地図画像の何れかの部分をクリックするか、または他の方法で選択することで、情報ウィンドウを閉じる。地図の動的サイズ変更も、一実施の形態で対応されている。例えば、表示ウィンドウ８００がサイズ変更される場合、ウィンドウ内部の地図画像８０５は再び中心に合わされ（それにより、これまでのウィンドウサイズで中心であった場所を維持し）、地図はサイズ変更され（それにより、地図は新規ウィンドウがより小さい場合により小さい領域を、新規ウィンドウがより大きい場合により大きい領域を示し）、ズームレベルを変更することがなく、または一般的にユーザのウェブブラウザへの画像情報の再送信を必要としない。一実施の形態では、ユーザは地図画像８０５のコーナーまたは他の部分を（例えば、マウスのアイコンが選択したコーナーへ示す間に、マウスボタンを押すことによって）「つかむ」ことができ、それを「ドラッグ」して地図画像をサイズ変更する（例えば、マウスを選択した場所へ移動させる間マウスボタンを押し、次いでマウスボタンを放す）。

一実施の形態は、マウスのドラッグ機能を実装し、それによって地図ビューは、例えば、ユーザのマウスボタンを押し、マウスを新規の場所へ所望の地図ビューがもたらされるまでドラッグし、次いでマウスボタンを放すことによって、滑らかに位置を変えてもよい。その上、地図スクロール機能も、一実施の形態で実装され、それによって地図ビューは、単にユーザのキーボード上の矢印キーの起動により、または同様なユーザの動作により位置を変える（つまり「パン」）されてもよい。

一実施の形態では、全部または部分的な郵便住所をテキスト記入フィールド８２５内に記入することで、地図画像８０５を対応する場所へパンさせ、記入された住所の完全性によって決まるレベルへズームさせる。例えば、「カリフォルニア州、バークリー、ブリストルＤｒ．６９３６」を記入することで、対応する場所へパンし、ズームレベルを街路のレベルの近くに設定し、これに対して、より明確な住所情報なしに単に「カリフォルニア州、バークリー」を記入することで、バークリーの市の中心へパンし、ズームレベルを都市のレベルへ設定することになる。その上、場所の輪郭が、一実施の形態で実装され、それにより、ユーザが明確な住所の代わりに大まかな領域（例えば、市、州、または郵便番号）を指定する場合、輪郭線が大まかな領域の周りに描画でき、（例えば、図２８における場所輪郭線２８１０で示すように）それを強調する。この機能は、ユーザが距離を測り、興味のある領域に焦点を当てることを支援できる。また、一実施の形態では、ユーザは１セットのショートカット（例えば「自宅」、「仕事場」、または「祖母の家」等）を定義してもよく、それは、記入されるか、または他の方法で選択された場合、所望のショートカット場所への地図画像における「ジャンプ」動作（または、要求された場所が現在の場所に充分に近い場合「ズーム／パン」動作）を生じる。

図８に示すように、一実施の形態は、また、「情報ウィンドウ」機能を実装し、それによってマーカー８４５等の場所マーカーをクリックするか、または他の方法で選択することで、マーカーで表された場所についてのより多くの情報を含む、地図画像８０５内に重ね合わされた、対話式ウィンドウ８４０およびその陰影８５５を開く。

テキスト記入フィールド８２５の中へ地図を作成するべき単一の場所を記入することに加えて、一実施の形態では、ユーザは組合せた検索を実行してもよく、それによってユーザは単一のテキストボックス内に検索する項目および全ての地図を作成する場所（例えば、「サンフランシスコにある映画館」または「マウンテンビュー近くのピザ店」）を指定してもよい。その上、先に説明した場所ショートカットと併せて、ユーザは、特定の場所の名前（例えば、「自宅」、「仕事場」）を与えることができ（それは、住所録もしくは同様のデータベースまたはユーザのコンピュータデバイス上のユーティリティと関連していても、していなくてもよい）次いで、テキスト記入フィールド８２５内へ検索先を記入する場合に（例えば、「仕事場近くのバー」を検索する場合に）ショートカット名を用いる。

一実施の形態はまた、ドライブ道案内機能を図８に示すような単一のテキスト記入フィールド８２５によって、または代替として、（図２７に示すテキスト記入フィールド８２５および８２８で示すように）出発する場所のための１つのテキスト記入フィールドおよび終着場所のための第２テキスト記入フィールドによって、のいずれかで実装する。更なる例示的な代替として、ドライブ道案内機能はまた、出発する場所フィールドのための１セット（例えば、出発する住所、出発する市、出発する州等）および終着場所フィールドのための第２セットの２セットの特定のテキスト記入フィールドによって実装されてもよい。ドライブ道案内の記入フィールドインタフェースにかかわらず、一実施の形態は、経路情報のクライアント側描画を実装する。具体的には、一実施の形態で、サーバが、曲がり角ごとの文章の道案内を、経路全体の図形描出のためのベクター情報と並んで、クライアントのコンピュータデバイスへ送信する。

グラフィックによるドライブ道案内は次いで、以前に描画した地図画像の上にオーバレイとしてクライアントによって描画される。別の実施の形態では、クライアントがベクター情報を受信すると、クライアントは経路オーバレイ画像のグラフィック定義を演算し、そのあと実際のオーバレイ画像を供給するようリクエストをサーバへ送信する。その上、図２７に示すように、文章のドライブ道案内手引き２７３０（例えば、「モフェットＢｌｖｄ．出口を取る」）が、ウェブページ８００上で地図画像８０５の近傍に表示されてもよい。文章のドライブ道案内の１つをクリックするか、または他の方法で選択することで、地図画像８０５の対応するセクション（例えば、南行きＵＳ−１０１からモフェットＢｌｖｄ．へのフリーウェイ出口ランプ）を指す情報ウィンドウを開く。図２７に示すように、情報ウィンドウは、地図画像８０５の対応するセクションの拡大図を表示する。

一実施の形態では、情報ウィンドウは、追加として、「衛星」ボタンまたは同様なユーザインタフェースオブジェクトを含み、それは、クリックするか、または他の方法で選択される場合、地図のグラフィック拡大図を同じ領域の対応する衛星写真で置き換える。グラフィカルなドライブ道案内（すなわち、経路を描出した軌跡）も、また、衛星画の上にオーバレイとして表示できる。「衛星」ボタンまたは同様なユーザインタフェースオブジェクトはまた、主な地図画像８０５内に（またはそれに関連して）含まれてもよく、それにより、クリックするか、または他の方法で選択される場合、「衛星」ボタンは、図８に表した図形種類の地図画像８０５を同じ領域の対応する衛星写真で置き換える。

サーバ側アーキテクチャおよび地図タイルの生成
一実施の形態では、地図は、地図画像の予め描画した「タイル」の１セットをブラウザにおいて一緒にまとめることによって表示される。これらの地図タイルは、オフラインフェーズで、所定数（例えば、１５）の分離したズームレベルのそれぞれでカバーされる地理的領域全体の非常に大きい地図を描画し次いで、これらの地図をタイルに切り分け、そしてタイルを適切な画像フォーマット（例えば、ＧＩＦ）にエンコードすることによって作成される。予め描画したタイルは、１セットのサーバからの静的画像として提供される。例えば、米国大陸全体をカバーするために、数億ものタイルが必要とされ、タイルのための合計ファイルサイズは数百ギガバイトもの程度のデータである。要望に応じて基調を成すデータから地図画像を描画する代わりに、地図全体がセクション（タイル）で予め描画され、適切なタイルが必要である場合にクライアントへ送られる。従って、一般的に、所与の地図タイルが、クライアントへ一度のみ送信される必要がある。この手法は、従来のシステムより信頼性があり、より早く、そして必要とする帯域幅はより狭い。

従って、ユーザにとりトランスペアレントであるオフラインプロセスにおいて、地図システムでカバーされる領域全体の１セットの大きい連続した予め描画したラスタ画像が生成される。そのような１セットのラスタ画像は、例えば、街路から国のレベルの範囲に及ぶズームレベルのそれぞれについて提供される。結局ユーザのウェブブラウザで組立てられ、表示される（図８に示すような）それぞれの地図画像８０５は、これらの大きい所定のラスタ画像の１つの（普通には長方形の形状にされる）サブ領域に一致する。代替として、地図画像の境界は、地図画像を取巻く背景と合う、つまり溶け込む地図画像の境界上へ画像を重ね合わせることで異なる形状に見えるよう（例えば、図８に示すように角を丸めた長方形）に変更してもよい。

一実施の形態では、ズームレベルは、０からＺまで番号付けられ、０は街路のレベルに最も近いレベルを、Ｚは街路のレベルから最も遠く離れたレベルを表す。興味のある領域内の任意の緯度／経度（「緯／経」）点が、原点つまりオリゴ（例えば、連続した米国の地理的中心）として指定および定義される。そこで、それぞれのズームレベルｚで、座標三重項（０，０，ｚ）が、この原点を含むｚ−レベルのラスタ画像の画素へ割り当てられる。ｘ−軸座標が左から右へ延び、ｙ-軸座標が上から下へ延びる標準的なコンピュータグラフィックスの規約を用いて、一意の座標三重項（ｘ，ｙ，ｚ）が、それぞれのラスタ画像のそれぞれの画素へ割り当てられる。

座標変換ルーチンは、ズームレベルｚを与えられると、緯／経の座標対を適切な（ｘ，ｙ，ｚ）画素座標へ変換し、またその逆も行う。この変換の詳細は、初回にラスタ画像を作成することに使用された地図投影によって決まる。

基調を成す地図情報が大幅に変化する場合にのみ実行される必要がある初期のオフラインフェーズ中に（例えば、数ヶ月ごとに一回）、大きいラスタ画像のそれぞれは、長方形のタイルに「切り分け」られる。図９に示すように、一実施の形態では、大きいラスタ画像を地図タイルに生成し切り分けるプロセスは、地図ペインターライブラリ９１０と併せたタイルメーカー９０５、および市販のＲＭＥ（「リッチ地図エンジン」）ライブラリ９１５によって協調的に実行される。数あるタスクの中で、タイルメーカー９０５は、とりわけラベル配置がかかわっている箇所で、隣接するサブ画像タイルがそれらの共通の境界線に沿って密接に並ぶことを確保する。当該技術に精通する者に周知の地図投影課題がある場合、地図システムでカバーされた領域をより小さい領域に分割し、それぞれを別々に扱うことが必要かもしれない。

なお図９を参照して、基調を成す地図データは、地図データ記憶装置領域９２０に格納される。一実施の形態では、格納された地図データは、Telcontar社（デジタル地図およびナビゲーション情報の商用プロバイダ）によってＲＭＦ（リッチ地図フォーマット）ファイルにコンパイルされた市販のNavTechデータを備える。ＲＭＦは、空間的クエリ処理のために最適化されたコンパクトなバイナリフォーマットであることを当該技術に精通する者は認知するであろう。数あるタスクの中で、本発明の一実施の形態は、地図画像を生成し、経路情報を作成することにこのフォーマットを活用する。ＲＭＦは多次元風にデータを組織化する空間的フォーマットであり、それにより現実的に相互に近接した特徴がデータベースにおいてすぐそばに格納される。これは、一旦空間的にフォーマットされたデータセットにある項目が見付かると、すぐ近くの他の項目も比較的容易に見付けられることを意味する。データを組織化することに、順次にまたは層で等の多くの他の方式があることを当該技術に精通する者は認知するであろう。なお図９を参照して、一実施の形態で、タイルメーカー９０５は、地図ペインターライブラリ９１０と通信してタイルを作成するための地図データを要求する。地図ペインターライブラリ９１０は、次に市販のＲＭＥライブラリ９１５と通信して地図データ記憶装置９２０からの情報にアクセスする。ＲＭＥライブラリは、２つ以上の項目の地理的関係を関与させる情報を要求する空間的クエリに対応していることを当該技術に精通する者は認知するであろう。例としては、「所与の領域内で該当する地図特徴は何か？」または「所与の領域内で該当する一定の閾値より高い優先レベルを有する地図特徴は何か？」である。空間的クエリの結果は、地図ペインターライブラリ９０５を介してタイルメーカー９０５へ送信され、地図タイルを生成することに使用される。タイル作成プロセスの結果として得られる地図タイルは、地図タイル記憶装置領域９００に格納される。

大きいラスタ画像のいずれかのサブ領域ビューを地図画像８０５としてユーザのウェブブラウザ上に再現するために、一実施の形態では、ブラウザ側のスクリプトは、所望のビューを一緒に完全にカバーする最小セットのタイルのみを必要とする。どのような所与の実装様態についても、タイルのサイズは、以下のトレードオフを前提として、経験的に確定できる：（１）より大きいタイルは所与のビューを作成することに必要であるタイルの合計サイズを（画素およびバイトの両方で）増大させる傾向がある；その一方で、（２）より小さいタイルは所与のビューを作成することに必要である別々のＨＴＴＰリクエストの数を増大させる傾向がある。一実施の形態では、１２８×１２８画素のタイルサイズが使用され、ＧＩＦフォーマットで格納される。他の実施の形態は、２５６×２５６画素のタイルサイズを使用し、ＧＩＦ、ＪＰＥＧ、またはＰＮＧフォーマットのいずれかで格納される。他のタイルサイズおよび画像格納フォーマットは、それぞれの特定の実装様態の要件次第で使用されてもよい。従って、これらのタイルは、規則正しい正方形グリッドを形成し、この性質は一実施の形態でシステム実装を容易にする。しかし、当該技術に精通する者は、クライアント側でのシームレスな組立てを容認するどのような形状およびサイズのタイルへの大きいラスタ画像の他のどのような分割も、本発明の効果を達成するために使用されてもよいことを、認知するであろう。

代替として、サーバ側のデータベースでなく、一実施の形態で、それぞれのタイルは、例えば下記のような一意のＵＲＬを用いてアクセス可能な別々のファイルに単純に格納されてもよい。
http://<domain>/7/-18/1/-145_12_7.gif
ここで、この例でのディレクトリパス 7/-18/1 は、この例示的事例において (-145,12,7) に等しいタイル座標だけによって決まる。

簡単にするために、それぞれのズームレベルｚの第１タイルは、タイルの左上画素が座標（０，０，ｚ）を有するように配置される。この規則は、それぞれのタイルへの一意の座標三重項の割り当てを、タイルの左上画素の画素のｘおよびｙ座標をそれぞれタイルの幅および高さで整数除算することによって容易にする。従って、緯／経の座標、画素の（ｘ，ｙ，ｚ）座標およびタイルの（ｘ，ｙ，ｚ）座標の合計３つの座標系が利用される。当該技術に精通する者が認知するであろうように、座標系のこの特定の選定は任意であり、一実施の形態で使用されるアルゴリズムを説明することを単に補助するように選ばれる。一般的に、どのような一貫性のある座標系も充分であると考えられる。次に、それぞれの画素は一意のタイルに属し、その座標は容易に演算される。

フロントエンドサーバ
一実施の形態では、フロントエンドサーバ（例えば図７に表すサーバ７１０または図５のウェブサーバ５１０等）は、ユーザによって発信されたそれぞれのクエリに、JavaScriptで実装されたクライアント側コードでアクセスされるデータを含む隠されたフレームに対するウェブページを返すことで応答する。従って、フロントエンドサーバ７１０／５１０は、ユーザのブラウザ上で動いているJavaScriptベースの１セットのプログラムと対話してダイナミックＨＴＭＬ（「ＤＨＴＭＬ」）コードを生成する。このメカニズムにより、図８に示す地図ビュー８０５をパンおよびズームする等の、先に説明したユーザインタフェース機能は、フロントエンドサーバ７１０／５１０と対話せずにクライアントのコンピュータデバイス内で実装できる。代わりに、図５に示すように、クライアントのコンピュータデバイス５０３は、ただ単にタイルサーバ５２０からタイルを必要に応じて要求し、表示しさえすればよく、タイルサーバ５２０は、図９に関連して上記で説明したように以前に生成されたタイルのセットを提供する。

フロントエンドサーバ７１０／５１０の作動の基本モードは、地図表示ページ８００にある（図８に示すフィールド８２５等の）テキスト記入フィールド内に記入されたユーザのクエリへの応答を提供することである。ユーザがクエリを発信する場合、クライアント側のJavaScriptコードは、クエリの内容だけでなく地図ビューの現在の状態も含むＨＴＴＰリクエストを形成し、その情報をフロントエンドサーバ７１０／５１０へ発信し、結果のページが隠されたｉフレーム（または「仮想ページ」）に表示するように指図する。このメカニズムは、（例えば、ドライブ道案内およびその他の項目のためのオーバレイ等のマッピングシステムの種々の特徴を含む）マッピングシステムを実装することに必要とされるデータを、主／可視のウェブページを再度読み込む必要なく、しかしブラウザの履歴および戻る/進むボタンが予想通り作働することをなお有効にしている間に、クライアントが受信することを容認し、それによりユーザは、局所検索を行い、例えば次いで、道案内を入手し、そして局所検索の結果へ復帰するようクリックして戻ってもよい。仮想ページがクライアントで読み込まれると、主ページ上のJavaScriptは、（１）ＨＴＭＬのタイトルを変更すること；（２）検索フォームを変更すること；（３）タイルグリッドにあるＨＴＭＬのＩＭＧ参照を地図画像に表示されるべきタイルのＵＲＬで置き換えること；（４）地図表示をパンおよび／もしくはズームすること；ならびに／または（５）地図上に１つ以上のオーバレイを加えることもしくは置き換えること、によって仮想ページからデータを抜き出し、それに応じて主ページを調節してよい。

一実施の形態では、以下の種類のクエリが認知され、処理される：

１）場所クエリ（例えば、「バークリー」）。これらは、単一の地理的場所を含むクエリである。そのようなクエリに応答して、フロントエンドサーバ７１０／５１０は、クライアントに、その場所へ地図をパンおよび／またはズームし、表示上でその場所の境界をマークするように指図する。例えば、一実施の形態で、「点」クエリ（例えば、図８に示すように、特定の住所に対する）は、要求された場所に対する場所マーカーを含む表示の結果になり、その一方で、「線」クエリ（例えば、街路番号を特定せずに、特定の都市における特定の街路に対する）は、要求された線がオーバレイとして地図上に強調されている表示の結果になり、そして、「領域」クエリ（例えば、「エニイタウン（随意市）」等の特定の都市に対する）は、（図２８に示すように）要求された領域がオーバレイとして地図上に際立たせられている表示の結果になる。

２）局所検索クエリ（例えば、「ピザ店」、「郵便局」）。これらのクエリは、ビジネス名、カテゴリ、またはその他のセットの検索用語を含むが、地理的場所を含まないクエリである。そのようなクエリに応答して、当該技術に精通する者に既知の技法を用いて、フロントエンドサーバ７１０／５１０は、ユーザの地図ナビゲーションまたは場所を求めるクエリからの結果の位置決めに基づいて現在の地図ビュー内で（またはその近傍で）クエリに一致するビジネスを検索し、クライアントのコンピュータデバイス５０３に、結果を地図画像８０５上に１セットの場所マーカー８４５／８５０として、選択肢でそれぞれのマーカーが象徴している検索結果を記述する、地図画像８０５に付随した、地図凡例と並んで、表示するように指図する。

３）条件付局所検索クエリ（例えば、「パロアルトにあるピザ店」、「サンフランシスコ近くのシングルモルトスコッチ店」）。これらは、検索用語および地理的場所の両方を含むクエリである。そのようなクエリに応答して、フロントエンドサーバ７１０／５１０は、クライアントのコンピュータデバイス５０３に、表示された場所へパンおよび／またはズームし、その場所内またはその周りで見付けられた検索結果を表示するよう指図する。代替として、クエリに含まれる地理的情報は緯／経点へ変換され、局所検索がこの１セットの緯／経点に対して導かれ、その後に局所検索の結果にある全ての場所が地図画像上に表示されることを確保するようにズームレベルが設定される（「ニューヨークにある大きな寿司店」の検索を仮定して、結果の表示に対する図２４を参照）。

４）ドライブ道案内クエリ（例えば、「サンフランシスコからニューヨークまで」、「自宅から仕事場まで」、または「カリフォルニア州、ロサンゼルス、メインＳｔ．１２３から、カリフォルニア州、パロアルト、ユニバーシティＡｖｅ．８０１まで」）。これらは、２つの区別できる地理的場所を含むクエリである。先に説明したように、そのようなクエリに応答して、一実施の形態で、フロントエンドサーバ７１０／５１０は、経路情報を、文章の曲がり角ごとの道案内と共に、クライアントへ送信でき、クライアントは次いで、地図画像８０５に強調されたオーバレイ進路として経路を表示してもよい。先にも、説明したように、ユーザは、（例えば、特定のドライブ手引きをクリックするか、または他の方法で選択することで）経路の一部分を拡大することによって文章の道案内と対話して、追加の文章のまたはグラフィカルな詳細を取得してもよい。

フロントエンドサーバ７１０／５１０は、クエリ分類器に基づいて選択される数多くの様々な論理的制御フローとして実装できる。クエリ分類器は、クエリが検索用語、地理的場所識別子、および文字の文章を含む成分部品へのクエリ文字列の分解の仕方を定義する１セットのテンプレートを取る場所抽出器を含む。例えば、「{QUERY} {STANDALONE_CITY}」等のテンプレートは、ユーザによって単に「ピザパロアルト」として記入されたクエリに一致することになり、カリフォルニア州、パロアルトの中心部近傍の「ピザ店」を検索する結果になる。場所抽出器は、街路名、都市名等の種々の種類の１セットの場所の名前から成る比較的大きいデータベースへのアクセスを有する。

一実施の形態では、図１０に示すように、フロントエンドサーバ７１０／５１０は、また、ジオコーディング／ジオマップ(geomap)サーバ１０１０を含み、それは体系的でない場所を、体系的場所に加えて図８の地図画像８０５上にマークできる地理的点／線／領域に変換する。図１０にも示すように、ジオマップサーバ１０１０は、掘り下げ(drill-down)サーバ１０１５、地図データ記憶装置領域９２０、場所データサーバ１０００、および局所検索サーバ１０１０と協調的に通信して、番地、街路、交差点、興味のある点、都市、近隣、郵便番号、郡、首都圏、州等（だけでなくそれらの国際的に同等なもの）の地理的特徴を処理する。番地等の点特徴について、変換の結果は、単一の（緯度、経度）点である。街路等の線の特徴について、および都市等の領域の特徴について、変換の結果は、ポリライン（例えば、街路について）、またはポリゴン（例えば、都市について）のいずれかであり、それはこれらの特徴のそれぞれを定義する。代替として、変換の結果は、単純に、軸合わせした境界付けボックスであってもよい。

図１０に、また、示すように、一実施の形態では、フロントエンドサーバ７１０／５１０は、また、所与の地理的場所での、またはその周りの検索結果を見出すための局所検索サーバ１００５を含む。「パロアルトにあるピザ店」等の組合せたクエリについて、局所検索サーバ１００５は、実行する前にジオコーディング／ジオマップサーバ１０１０の結果を受信することを待ってもよい。デジタルマッピングシステムについて、順応性のある場所絞り込みの定義および距離平準化の概念を有する局所検索サーバ１０１０内で局所検索の採点アルゴリズムを実装することが望ましい。ユーザは、所与の１セットのクエリ用語に一致するビジネスを現在の地図ビュー内で有利に検索できなくてはならない。これは、局所検索コードがただ中心点と半径だけの代わりに最小と最大の緯度および経度座標の形体を有する絞り込みを容認することを必要とする。幾らかの程度の距離平準化が、一般的に必要である。換言すれば、地図表示の厳密な中心での結果が、表示ビューのほかのどこかの結果より高い得点となってはならない。例えば、「パロアルトにあるピザ店」を検索して、２店のパロアルトピザ店営業所が、一方が他方よりパロアルトの中心部にたまたま近いために異なる得点となってはならない。

一実施の形態では、「ドライブ道案内」クエリがフロントエンドサーバ７１０／５１０で認知される場合、フロントエンドサーバは、起点および目的地の住所を１セットの簡単な曲がり角ごとの道案内だけでなく経路に沿った（緯度、経度）座標を指定するポリラインに変換する。フロントエンドサーバ７１０／５１０は次いで、経路全体に沿ったベクター情報を含む１セットのポリラインと並んで、曲がり角ごとの道案内をクライアントのコンピュータデバイスへ（例えば、vPageにある）ＸＭＬを用いて送信してよい。一実施の形態では、１セットのポリラインをクライアントへ送信する前に、フロントエンドサーバは、クライアントへ送信されるグラフィカルデータ点の合計数を（例えば、当該技術に精通する者に周知の幾何学的操作を用いて、ポリラインのフルセットに対して削除した場合に１または２画素等の一定の所定の閾値以下のエラーの結果になるいずれかのデータ点を１セットのポリラインから削除して）低減し、それぞれの非削除のデータ点をその点が視覚的に妥当になるズームレベルを定義する「グループ」へ割り当てる（例えば、グループ「Ａ」にあるデータ点は、各ズームレベルで表示されることを必要とすることがあり、その一方で、グループ「Ｂ」にあるデータ点は、ズームレベルが都市のレベルのビュー以下の精細さに相当するズームレベルを通り越して増大されるまで表示されることを必要としない等）。

一実施の形態では、ユーザがドライブ道案内クエリを記入した後に、地図画像８０５は、選択された経路全体の概観を表示する。ユーザは次いで、経路の一部を拡大し、より詳細なビューを入手してもよい。

一実施の形態では、課金メカニズムが、ユーザによってリクエストされた地図ビューの数の経過を把握するために、例えば、地図ビューに関してユーザ訪問の地図領域の合計量の経過を把握するために実装される。図８を参照すると、先に述べたように、課金点８６０は、地図画像の中心で定義される(とはいえ、課金点８６０は普通には地図画像８０５上で可視でない特徴である）。従って、例えば、地図画像８０５が幅４００画素および高さ４００画素で定義された領域を備える場合、他の課金点は、水平および垂直の方向に４００画素の間隔で定義される（それによって課金点グリッドを作成する）。従って、一実施の形態では、各地図ビューは、少なくとも１件のトランザクションを含む。ユーザがパン操作を始動する場合、課金点グリッドは地図と並んで「移動」し、新規の課金点が地図ビューの中へ入る場合にはいつでも追加の課金トランザクションを発動する。例えば、ユーザが地図画像を２００画素だけ右へパンする場合、新規課金点がビューへ入り、新規トランザクションを発動する。一実施の形態では、新規トランザクションはまた、所与のズームレベルでこれまで不視であった地図領域を表示するズーム操作の結果としても、発動されることになろう。トランザクションは、一実施の形態で、クライアントによってフロントエンドサーバ７１０／５１０へ報告され、フロントエンドサーバは、全てのユーザからのトランザクション情報を収集し、それを地図情報の商用プロバイダとの契約上の目的に使用する。

クライアント側のアーキテクチャおよびアルゴリズム
本発明の実施の形態は、先端的なウェブブラウザで利用可能な広範囲の技術を用いて実装されてもよい。幾つかの実施の形態の共通の図形的特徴は、１セットの地図タイルを「クリッピング形状」の後ろに組立てる能力である。加えて、ユーザのコンピュータデバイス５０３でのホスト技術は、表示レイアウトへの適度に効率の良い動的な変更を容認するはずである。クライアントのウェブブラウザは、ちらつきを回避するように二重バッファ型の（または同様の）表示を用いてかかる動的な変更を実行する方が好ましいが、必須ではない。例えば、ＤＨＴＭＬは、二重バッファ型表示エンジンを使用する。ＤＨＴＭＬを使用する一実施の形態では、ブラウザは、ユーザの入力、ＨＴＴＰの完了および時間切れ等のイベントに応答してスクリプト機能を実行する。スクリプト実行中にウェブページに対してなされた全ての変更は、少なくとも論理的に、画面外のバッファに記録され、それはスクリプトが制御をブラウザへ戻す場合に表示される。

下記でより詳細に説明するように、一実施の形態に従うクライアント側アルゴリズムは、一般的に地図タイルレイアウトへ１セットの変更を成すことによって進行し、次いでこれらの変更によって定義された新規のフレームを表示するようにホストシステムに要求する。一実施の形態では、クライアント側での地図表示機能は、以下のとおりのＨＴＭＬコードで実装されてもよい：
<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に対して移動させることによって地図をパンおよびズームする。従って、この実施の形態でのクライアント側アルゴリズムは、２つの主要な図形要素を実装する。第１要素は、（普通には長方形の）「クリッピング形状」であり、それを通してユーザは地図画像８０５を見ることになり、それはユーザの地図ビューの形状を定義する。単に一実施の形態でのクライアント側アルゴリズムを明らかにするだけの目的で、クリッピング形状の任意の画素が、その原点として割り当てられる（例えば、長方形のクリッピング形状の事例では左上の画素）。第２の要素は、クリッピング形状より大きく、それの背後に配置されるタイルのグリッドであり、それによりクリッピング形状を共用するグリッドの一部のみがユーザにとって可視である。一実施の形態のこの検討の残部について、このグリッドは長方形であり、このグリッドがサイズを変更するのはクリッピング形状がそうした場合およびその場合のみであることを想定するものとする。この性質が当てはまらない場合には本明細書で検討したアルゴリズムの変形が存在することを当該技術に精通する者は認知するであろう。

一般的に、クリッピング形状は、ウェブブラウザのウィンドウ８００に対して固定されたままであり、それに反して、本発明の態様に従うクライアント側のスクリプトは、とりわけ地図画像８０５をパンするようにタイルグリッドの場所をクリッピング形状に対して移動させることになる。図１１は、これらの２つの要素を示す一方で、図１２は、ウェブページ上への表示のためにクリッピング形状を通してタイルグリッドを処理する結果を表す。図１１に示すように、５×５の正方タイルグリッド配列１１００は、２５の個々のタイル（そのそれぞれが赤い境界の線で定義される）を備える。正方クリッピング形状１１１０（黒い長方形として示す）は、クライアントのウェブブラウザ上に地図画像として表示されることになるタイルグリッドのサブセットを定義する。図１２には、「クリップされた」タイルグリッド配列１２００が、クリッピング形状の境界と連続している境界とともに、表示されている。先に述べたように、図８に示す地図画像８０５も、より大きいタイルグリッド配列の、クリッピング形状と対比された結果である。図１３は、基調を成すタイルグリッド座標およびクリッピング形状１３０５を示し、それは図１１および図１２に示すもの等の１セットの表示された画像に対応する。図１３には、５×５のタイルグリッド配列１３００内の２５のタイルのそれぞれが一意の１セットのタイル座標によって表されている。

一実施の形態では、クリッピング形状は、固定サイズの３００×３００画素の長方形であり、図８に示すようにウェブページ８００の中心に位置決めされる。クリッピング形状は、一実施の形態で、style "overflow: hidden; position: relative" およびid "mapView" を持つDIV要素として実装される。タイルグリッドは、固定サイズの５×５のタイルである。それは、id "mapTable" を持つTABLE要素として実装される。mapTableの２５TDの子供達のそれぞれは、単一のIMG要素を含み、それによりタイルを配置することは単にIMG要素のSRC属性を適切に変更することを伴う。mapTable要素は、id "mapDiv" および style="position: absolute" を持つDIV要素の子供である。mapViewおよびmapDivのPOSITIONスタイルは、mapDivのLEFTおよびTOPスタイルを単に変更するによってタイルグリッドをクリッピング形状に対して移動させることを可能にする。

一般的に、クリッピング形状のサイズに比べてタイルグリッドのサイズは、下記で説明する種々の実装要因に依存してよい。大まかに言えば、（画素で）クリッピング形状の（幅および高さの両方で）少なくとも２倍のサイズであるタイルの最小のグリッドが、使用されてもよい。また、実装様態の選定次第で、ユーザがクリッピング形状のサイズまたは形状を変更する場合に、タイルグリッドのサイズを動的に変更することが必要かもしれない。

以下の例示的な検討の目的で、ＡおよびＢは、タイルグリッドの（タイルの観点における）それぞれ幅および高さを表す。タイルグリッドにおけるそれぞれの位置は、座標の対（ａ，ｂ）を割り当てられ、左上の位置が座標（０，０）を有し、右下の位置が座標（Ａ−１，Ｂ−１）を有する。計算中に、タイルグリッドの外側に該当する位置（ａ，ｂ）への参照が成されてもよく、ここで、ａ＜０もしくはＡ≦ａ、またはｂ＜０もしくはＢ≦ｂである。

一実施の形態で作成されたそれぞれの地図画像では、クリッピング形状とタイルグリッドとの間の共用部分は、フルクリッピング形状に等しいことになり、それにより地図タイルのみがクリッピング形状によってユーザへ公表される。この文書の残部において、この事実は「共用部分条件」と命名される。

上記の想定および定義を適所に置き、クリッピング形状の原点で公表された地図画素の画素座標三重項（ｘ，ｙ，ｚ）によってどのような地図ビューも一意的に照会できる。

初期化およびキャッシュ格納
一実施の形態では、ユーザが当初の地図ビュー（ｘ，ｙ，ｚ）を要求したと想定し、更に、対応する地図画素（ｘ，ｙ，ｚ）がタイル（ｘｘ，ｙｙ，ｚ）に属することを想定すると、クライアント側のスクリプトは以下のように進行する。第１に、タイルグリッドが共用部分条件に違反しないどのような様式でもクリッピング形状に対して配置される。第２に、（ａ，ｂ）がその時点でクリッピング形状の原点を含むタイルグリッドの位置として定義される。第３に、クリッピング形状を共用するタイルグリッドにあるそれぞれの位置（ａ＋ａ'，ｂ＋ｂ'）について、タイル（ｘｘ＋ａ'，ｙｙ＋ｂ'，ｚ）が配置される。第４に、そして最後に、結果として得られたフレームが表示される。

一般的に、タイルをともかくタイルグリッド位置に配置することは、一般的にブラウザにタイルがブラウザのキャッシュに存在するか否かを最初に点検させることになり、存在しない場合、必要であるタイルを求める適切なＨＴＴＰリクエストを発行させる。所与の実装様態の特定のホスト技術次第で、このＨＴＴＰリクエストは、同期してまたは非同期で実行されてもよい。本発明の実施の形態は、ウェブブラウザに個々のタイルをローカルでキャッシュに格納するように仕向けることで性能を改善する。従って、ブラウザ側のスクリプトがブラウザに特定のタイルを表示するように命令する場合、ブラウザは、タイルがブラウザのキャッシュに既に存在しない場合のみＨＴＴＰサーバからタイルを要求することになる。このようにして、本発明の実施の形態は、重複した像を含む別々の地図ビューから、これらの別々のビューが異なるブラウザセッションに属する場合でさえ、恩恵を得る。確かに、一旦ユーザが領域をオンラインの間に見た後に、ユーザのブラウザで既にキャッシュに格納されたタイルのみが必要である限り、ユーザは、その同じ領域をオフラインの間に、見ることができる。

この効果を達成するために、クライアント側のスクリプトは、一実施の形態で、タイルの座標三重項のみによって決まるＵＲＬ（「Universal resource locator」）によってそれぞれのタイルを別々に識別する（例えば、http://somedomain.com/tiles?x=0&y=0&z=0）。一般的に、ウェブブラウザは、それぞれのタイルを含むＨＴＴＰ応答に含まれる期限切れ時間を使用することによって、および／または、ブラウザのキャッシュにあるタイルの直前に改変された時間をサーバ側上のタイルの直前に改変された時間と対比することによって、自身のキャッシュを管理する。これらの２つの方法の後者は、キャッシュに格納されたタイルが使用されるべき場合でさえいくぶん費用の掛かるＨＴＴＰリクエストを必要とするので、タイルを送信するＨＴＴＰサーバは、以下のトレードオフを前提として経験的に確定された非常に長い時間切れ期間を報告するように構成されてもよい。一方では、より長い期限切れ期間は、正しくキャッシュに格納されたタイルのために必要であるＨＴＴＰリクエストの数を最少限する傾向がある。他方では、より短い期限切れ期間は、大きい地図入力ラスタが変化する場合、新規のタイルをウェブブラウザへより早く発効させる（それは、実地面で、新規の道路建設を補正することに、またはラスタを作成する地図描画システムシステムへの改善を活用することに発生することがあろう）。

代替として、実装様態は、バージョン番号をタイルのＵＲＬへ加えてもよく（例えば、http://www.somedomain.com/tiles?x=0&y=0&z=0&v=1.0）、期限切れ日付をできる限り将来まで報告するようにタイルを送信するＨＴＴＰサーバを構成し、そして、新規のタイルが発効を必要とする場合のみ新規タイルのバージョン番号をブラウザ側のスクリプトへ送信する何らかの他の手段を用いてもよい。この代替のシステムは、既に正しくキャッシュに格納されたタイルのためにブラウザによって発行されるＨＴＴＰリクエストを最少限にする一方で、新規タイルがキャッシュに格納された古いタイルの代わりに使用されるべき場合に全面的な制御を与える。しかし、この代替は、ブラウザのキャッシュにおいて新規タイルが古いタイルを置き換えるものではないので、ブラウザ側でより多くのディスク容量を使用する傾向が確かにある。本発明の実施の形態は、タイルをサーバからウェブブラウザへ転送することにとりわけＨＴＴＰの使用に依拠しないことに注目されたい。ブラウザが対応している他の転送プロトコル、例えばＨＴＴＰＳまたはＦＴＰ等が、代わりに使用できる。当該技術に精通する者が認知するであろうように、それぞれの転送プロトコルは、僅かに異なった手法を要求してタイルをキャッシュに格納することがある。本発明の実施の形態は、また、最新のパンおよびズーム操作に基づいて発見的アルゴリズムを実装してもよく、近い将来に必要でありそうであるタイルを予測し、これらのタイルをブラウザのキャッシュへ転送することにアイドルタイムおよび／または帯域幅を使用する。代替として、アイドルタイムおよび/または帯域幅は、現在は可視でないタイルグリッドにおける位置を更新すること、および／またはユーザが単一レベルのズームの移行を要求することになるとすれば必要であろうタイルを要求することに専念してもよい。

図１４は、地図タイルをウェブブラウザへ送信し、タイルをウェブブラウザにローカルでキャッシュに格納するための一実施の形態のフローチャートを示す。ステップ１４００で、クライアントは場所の候補を受信する（例えば、ユーザは地図を作成するべき場所を図８に示すテキスト記入フィールド８２５内に記入し、そのあと図８の検索ボタン８３０を選択してもよい）。次に、ステップ１４０５で、クライアントのコンピュータデバイスは、場所の候補を場所サーバ（例えば、図１０に示す場所データサーバ１０００、図５に示す場所データサーバ５２０、または図７に示すサーバ７１０）へ送信する。場所サーバは次いで、場所の候補をステップ１４１０で解析し、場所データの生成の結果になる。ステップ１４１５で、クライアントは、この場所データを場所サーバから受信し、ステップ１４２０で、クライアントは、受信した場所データを用いてタイルリクエストを作成する。タイルリクエストにあるそれぞれのタイルについて、クライアントは、要求したタイルが既にローカルで格納されているか否かを判断する。具体的には、ステップ１４２５で、クライアントは、要求したタイルが既にローカルで格納されているか否かを判断する。

タイルが既にローカルで格納されている場合、ステップ１４３５で、クライアントはそのローカルメモリからタイルを取り出す。代替として、タイルが既にローカルで格納されていない場合、ステップ１４３０で、クライアントはタイルをサーバ（図５に示すタイルサーバ５１５等）から取り出す。ステップ１４４０で、タイルがローカルまたは遠隔のタイル記憶装置のいずれかから取り出されると、要求したタイルが表示される。次に、ステップ１４４５で、次のタイルリクエストが決定される。さらに多くのタイルがリクエスト内に残っている場合（ステップ１４５０で行われる判断）、プロセスのループはステップ１４２５へ戻り、ここで新規に要求したタイルが既にローカルで格納されているか否かに関して判断が行われる。代替として、それ以上タイルがリクエスト内に残っていない場合、プロセスはステップ１４５５で終了する。

多くのターゲットホスト技術は非同期のＨＴＴＰリクエストへのアクセスを供与していることに注目すべきである。この特徴は、クライアント側のスクリプトがパン移行中にタイルをタイルグリッドに配置することを容認し、そこでタイルが実際に到着する前にタイルグリッドの移動を開始し、従って、一時的に間違ったタイル（または、代替として、空きスペースつまり空白タイル）をユーザへ表示する。一般的に、所与の実装様態の特定の要件次第で、そのような非同期性は、地図を移動させる前に全ての新規のタイルが到着することを常に待つことに起因することがある非常に長い待ち時間にとって好ましいと見なされてもよい。幾つかの実施の形態では、非同期のリクエストを発行する前に、タイルグリッドにある古いタイルを地図の背景色と同一色である（そしておそらくだいたい常にブラウザのキャッシュにある）静的タイルで置き換えることが有益であることもある。代替として、より複雑な実装様態では、全ての新規のタイルの到着またはやや短い時間切れ期間の期限切れのいずれか（のどちらか早く発生すること）を待ってから地図の移動を開始する。かかる実装様態では、同一色のタイルは時間切れの事例のみに使用されることになろう。

オーバレイ
一実施の形態に従うと、基本の地図画像の域を超えた全ての追加の情報（例えば、ドライブ経路、特定の場所）は、オーバレイとして描画でき、クライアント側上で地図の上に配置できる。この手法は全ての追加の情報に使用でき、それは、サーバが要望に応じて特定の追加の情報でいずれの地図も描画する必要がないことを意味する。オーバレイは、例えば、場所マーカーおよび経路を表示すること、ならびに街路および特定の領域を強調することに使用できる。当該技術に精通する者が認知するであろうように、オーバレイは種々の方式で（例えば、画像またはベクターにより）実装されてもよい。例えば、クライアント側のJavaScriptが、ＨＴＭＬ要素を地図表示の上に配置してもよい。先に説明したコードの断片の観点で、全てのオーバレイ要素はmapDivに配置されてもよく、それによりそれらはmapDivが移動される場合に地図と共に自動的に移動する。これらのオーバレイ要素の幾つかは、ウェブページが最初に読み込まれる場合に、既にＨＴＭＬコード中に（style="display:none"で）あることがあり、その一方で、その他はJavaScriptコードにより後で追加されてもよい。

図１５は、ドライブ道案内をオーバレイとして地図画像上へ表示するために一実施の形態に従い使用されてもよいフローチャートを図示する。ステップ１５００で、クライアントは、ユーザから既に説明した様式でドライブ道案内を求めるリクエストを受信する。ステップ１５０５で、クライアントは、要求された旅程情報を場所サーバへ送信する。ステップ１５１０で、場所サーバは、フロントエンドサーバ機能の説明に関連して先に説明したように、旅程情報を解析する。ステップ１５１５で、クライアントは、先に説明したように、文章のおよび地理的な旅程データを場所サーバから受信する。ステップ１５２０で、クライアントは、オーバレイのドライブ道案内経路軌跡を地図画像上へ表示することに必要とされるベクターを決定する。ステップ１５２５で、クライアントは、先に説明したように、図１４のフローチャートに従って基本の地図画像を描画する（このステップが既に行われていない場合）。一実施の形態では、ステップ１５２８で、クライアントは次いで、ドライブ道案内経路軌跡をオーバレイとして基本の地図画像上へ描画する。別の実施の形態では、ステップ１５２８へ進行する代わりに、ステップ１５３０で、クライアントは、ステップ１５２０でクライアントによって計算されたベクター情報に基づいて、場所サーバから旅程画像オーバレイを要求する。この実施の形態では、ステップ１５３５で、場所サーバが、旅程画像を作成し、それをクライアントへ送信する。最後に、この実施の形態ではステップ１５４０で、クライアントが、最終的な旅程画像を地図画像上へ重ね合わせる。オーバレイのドライブ道案内を持つ例示的な表示した地図画像を図２６に示す。

幾つかの実施の形態では、特定のウェブブラウザ（例えば、Mozilla／Firefox）は、上記で説明したようなベクターグラフィックスを描画する能力がないことがある。そのような実装様態では、図１０に示すジオマップサーバ１０１０等の資源が、（例えば、１セットのドライブ道案内に関連するポリラインに対する）オーバレイのビットマップ画像を生成してよく、そこでブラウザは、この透明な画像を地図画像上へ複合してよい。この例ではブラウザがジオマップサーバ１０１０から直接的にこの画像を要求するために、リクエストはプロトコルバッファの代わりにＵＲＬを介している。線の幅および色は、ジオマップサーバ１０１０へのコマンド−線の選択肢として指定されてもよい。

パン操作
一実施の形態では、地図画像のパン操作は、以下のように実装されてもよい。第１に、ユーザが１つの地図ビュー（ｘ，ｙ，ｚ）から新規の地図ビュー（ｘ'，ｙ'，ｚ'）へ同じズームレベルでのパンを要求したと推定し、パンがｎフレームにわたり動画的にされるべきことを推定する（ここで、ｎ＝１は、古いビューから新規ビューへの切替えが単一ステップで行われることを示し、その一方で、ｎの高い値は切替えが滑らかな動画的のパンとして提供されるべきことを示す）。更に、２つの地図ビューが、ｘおよびｙ軸の両方に沿って、２つのビューの間の距離に加えてクリッピング形状のサイズがタイルグリッドのサイズより（画素で）小さいという意味で、タイルグリッドのサイズに比べて相互に「近い」ことを想定する。

上記の想定および定義を念頭に置いて、タイルグリッドの「下へ回転」の操作は、一番下の行を取り、それを一番上の行にすることと定義され、そこで残った位置がそれらの古い場所をクリッピング形状に対して保持するように、結果として得られるグリッドを配置する。同じように、「上へ回転」は一番上の行を一番下の行にすることと定義され、「左へ回転」は左の列を右の列にすること、そして最後に「右へ回転」は右の列を左の列にすること、と定義される。これらの回転操作は、タイルグリッドを移動させることが、そうしなければ共用部分条件に違反することになろう事例に使用される。勿論、同じ効果を（例えば、グリッドにあるそれぞれのタイルを１つの場所だけシフトすることで）達成できるであろう他の様式があるが、しかし上記の操作上の定義が効率的であると分かった。クライアント側のスクリプトは、従って、以下のように進行する。第１に、(dx,dy)=(x,y)-(x',y')とし、(a,b)をその時点でクリッピング形状の原点を含むタイルグリッドの位置とする。第２に、１とｎの間のいずれかの整数ｉについてi*(dx,dy)/nのオフセットだけタイルグリッドが移動された場合にクリッピング形状で共用することになろうそれぞれの位置(a+a',b+b')について、タイル(xx+a',yy+b',z)を位置((a+a')mod A,(b+b')mod B)に配置する。第３に、必要な場合、共用部分条件がタイルグリッドを(dx,dy)のオフセットだけ移動させることによって違反しなくなるまでタイルグリッドを回転させる。第４に、１とｎの間のそれぞれのｉについて、タイルグリッドを(dx,dy)/nのオフセットだけ移動させ、結果として得られるフレームを表示する。ホストシステムの効率次第で、フレーム間で幾らかの時間一時停止することが必要になることがある。このプロセスにおける第２および第３のステップの順番は逆にしてもよいことを当該技術に精通する者は認知するであろう。また、ｎが１に等しいと想定することによる第２ステップにおける僅かな緩和は、ほとんど正しい提供の結果になろう（とはいえ、幾つかの中間のフレームはパンが水平でも垂直でもない場合に少しのタイルを欠落することがある）ことに注目されたい。また、上記のプロセスは連続した地図画像に沿って滑らかなパンを提供することを当該技術に精通する者は、認知するであろう。

図１６は、一実施の形態に従い地図画像のパン操作を実行するためのフローチャートを表す。ステップ１６００において、クライアントは、（例えば、図８に示すような方向制御オブジェクト８１５の起動によって）パンイベントを示すコマンドをユーザから受信する。ステップ１６０５で、クライアントは、基調を成す地図タイルに対してクリッピングビューアを実質的に移動させる。そこで、ステップ１６１０で、クライアントは、パン操作の結果として新規に必要であるタイルの場所を決定する。これが決定されると、ステップ１６１５で、クライアントは、この場所データを用いて、タイルリクエストを作成する。最後に、ステップ１５２５で、クライアントは、図１４に示し、先に説明したプロセスに従い、必要とされるいずれのタイルも取得する。

図１７から図２１は、一実施の形態に従いクリッピング形状の幅の１／３だけ西へパンする例示的プロセスを示す。図１７は、先に説明したプロセスの第２ステップでタイルが更新される前の地図画像およびタイルグリッドの状態を描出し、その一方で、図１８は、この更新が完了した後の状態を表す。図１９は、先に説明した第３ステップに従い１つの「右へ回転」操作が実行された後の状態を描出し、その一方で、図２０は、第４ステップで数フレームが表示された後の状態を表す。最後に、図２１は、パン操作プロセスが完了した後の最終状態を表す。

より大きいグリッドは、上記のプロセスを用いて一般的により長いパンが滑らかに提供されることを容認することを当該技術に精通する者は認知するであろう。一実施の形態では、クリッピング形状のサイズの２倍より僅かに大きいグリッドを使用する実装様態の選定は、現在の地図ビューのサイズまでの滑らかなパンを容認する。タイルグリッドのサイズを増大させることなくより長いパンを実行するために、パン操作全体が、単純に一連のより小さいパン操作に分割されてもよいが、この手法は僅かに滑らかでない提供の結果になることがある。

上記のパン操作アルゴリズムは、動画の第１フレームでさえ提供する前に全ての必要なタイルを更新する。この手法は、ユーザがリクエストをする時間と地図が実際に開始する時間との間に少し待ち時間を導入することがある。これを克服するために、実装様態は、ｎ−フレームのパンを、たとえばｎ回の別々の１−フレームのパンに分割することを選んでもよい。しかし、ただこの技法のみでは、それぞれのフレームを作成する作業量は更新を必要とするタイルの数で大幅に変動することがあるので、滑らかでない提供の結果になることがある。より洗練された実装様態は、この問題を、将来フレームのために必要であるタイルを予測的に更新してフレームの間で更新を必要とするタイルの数を均等にすることによって克服する。

ズーム操作
一実施の形態では、「ズーム操作」は、２つのビュー（ｘ，ｙ，ｚ）と（ｘ'，ｙ'，ｚ'）との間の移行を称し、ここでｚ≠ｚ'であり、２つのビューに対応する緯／経値はクリッピング長方形のサイズと比べて接近している。以下の検討は、アンカーを含む画素が２つのビューのそれぞれにおいてクリッピング形状の同じ画素を占有するという意味で、緯／経「アンカー」の周りに「垂直」であるズーム操作に焦点を当てる。普通には、ズーム操作のアンカーは、クリッピング形状の中心であることもあろうが、しかしそれは、また、場所マーカー（例えば図８に示すマーカー８４５等) の緯／経、ユーザによって選択された画素に対応する緯／経、または地図画像内の他のどのような場所でもあり得よう。パン操作をズーム操作と組合せる移行は幾つかの実装様態で組合されてもよいことに注目すべきである。

一般的に、ズーム操作は、クリッピング形状で共用する各タイルが更新されなければならないので、タイル更新の観点でパン操作より高価な操作である。この理由のために、そして滑らかに動画的に行うズームは費用の掛かる画像の拡大縮小操作を必要とするために、一実施の形態は、先に説明した初期化ステップを単に実行することによって、全てのズーム操作を単一のフレームで実行する。

以下の検討は、一実施の形態に従いユーザへ滑らかに動画的に行うズーム操作を提供する手法を概説し、それは幾つかの例示的ホスト技術（例えば、FlashおよびJavaアプレット）において実装可能である。簡単にするために、２つのズームレベルｚとｚ'の間の拡大縮小係数差異が厳密に２であること、ｚ'＝ｚ＋１であること、そしてｎ動画フレームにわたる移行を提供することが望ましいことを想定する。この検討において、「最終フレーム」は、上記で説明した初期化ステップを用いて単一フレームで単にズーム操作することによって作成されることになるフレームを称する。更に、ｓ（拡大縮小係数）が２のｎ乗根に等しいとする。

これらの定義および想定を念頭に置いて、ズーム操作アルゴリズムの一実施の形態は、以下のように進行する。第１に、最終フレームが組立てられる（が、表示されない）。第２に、１とｎ−１の間のｉについて：（ａ）最終フレームのために必要であるタイルがｓ＾（ｎ−ｉ）の係数で拡大縮小される；（ｂ）拡大縮小されたタイルはアンカーが正しく配置されるように配置される；そして（ｃ）結果として得られるフレームが表示され、適切な場合一時停止が含まれる。第３に、最終フレームが表示される。

代替として、ｚ'＝ｚ−１の場合、現在のビューのタイルが、最終のビューのタイルの代わりに以下のように拡大縮小されてもよい。第１に、上記のように、最終フレームが組立てられる（が、しかし表示されない）。第２に、１とｎ−１の間のｉについて：（ａ）現在のビューのタイルがｓ^(ｉ) の係数で拡大縮小される；（ｂ）拡大縮小されたタイルはアンカーが正しく配置されるように配置される；そして（ｃ）最終フレームが表示され、適切な場合一時停止が含まれる。

上記の実装様態の両方の第２ステップ（パート（ａ））において、第２ステップのパート（ｂ）が実行された後にクリッピング形状を通して結局公表されるタイルのためにのみ拡大縮小が必要とされることに注目されたい。また、第２実装様態の第１ステップは第３ステップまで延期できることにも、注目されたい。これらの実装様態の両方において、同じ地理的領域をカバーするのにより高いズームレベルではより少ないタイルが必要であるので、全ての中間のフレームは、より高いズームレベルのタイルを用いて作成される。より込み入った代替の実装様態は、より低いズームレベルからのタイルを使用することによって、または現在および最終のフレームの両方からの拡大縮小されたタイルをアルファブレンドすることによって、中間フレームの幾つかを作成することを追求し、「モーフィング」と同様の効果を作成する。また、多数のズームレベルに及ぶズーム移行も、一連の単一レベルの移行として実装されてもよい。

図２２は、一実施の形態に従いズーム操作を実装するための例示的フローチャートを表す。ステップ２２００で、クライアントは、（例えば、図８に示すように、ズーム制御オブジェクト８２０の起動によって）ズーム動作イベントを受信する。ステップ２２０５で、クライアントは、ズームした表示の中心を決定する。そこで、ステップ２２１０で、クライアントは、決定された中心の場所データを用いて新規のズームレベルでタイルリクエストを作成する。最後に、クライアントは、図１４に関連して先に説明したプロセスに従いズームした地図を描画する。

スライド操作およびジャンプ操作
以下の検討は、ただ滑らかなズーム操作およびパン操作のみのためには遠過ぎる地図ビューの間の移行を考慮する。例えば、現在の地図は、カリフォルニア州バークリーにある街路を表示することがあるが、ユーザは、ニューヨーク州のダウンタウンのマンハッタンにある街路のナビゲーションショートカットを選択するか、またはビューを要求するかもしれない。この状況への２つの例示的手法が提供され、「スライド操作」および「ジャンプ操作」と命名される。

一実施の形態の「スライド操作」手法に従って、クライアント側のスクリプトは、最終ビューを組立て、（普通には別々のタイルグリッドを利用して）それを現在のビュー上へ古いビューに対して新規ビューの方向から滑らかにスライドさせる。代替として、一実施の形態の「ジャンプ操作」手法に従って、クライアント側のスクリプトは、最初に縮小し、そのあとパンし、そして最後に目標のビューをズーム戻しする。クライアント側のスクリプトは、最低のズームレベルへ縮小し、それぞれの特定の実装様態の要件にとってパンを（画素で）十分短くさせる最低のズームレベルでパンを導く。より洗練された実施の形態は、この「ボックス形状」の動き（すなわち、ズームで上昇、パン、ズームで降下）を滑らかな曲線形の動きに変換する。「ジャンプ操作」手法は、「スライド操作」手法が必要とするよりはるかに多大の数のタイルおよびより多くの演算資源を必要とすることを当該技術に精通する者は認知するであろう。

サイズ変更
主として地図ビューの周囲のウェブサイト次第で、ユーザは、地図ビューがサイズおよび／または形状を変更することを要求することがある。タイルグリッドのサイズをクリッピング形状のサイズに関係付ける仕方の実装様態の選定に依存して、この要求は、次にタイルグリッドのサイズ変更を余儀なくさせることがある。この操作のために幾多の可能な実装様態があり、以下を含むがそれに限定されない。現在ビューが（ｘ，ｙ，ｚ）であること、対応する画素がタイル（ｘｘ，ｙｙ，ｚ）に属すること、そして、クリッピング形状のサイズ変更はその原点の周りで行われるはずであることを想定する。そこで、第１ステップは、クリッピング形状をサイズ変更／形状変更することである。次に、必要な場合、タイルグリッドのサイズは、共用部分条件に違反しないために必要な最小サイズへ（例えば、複数の行を一番下へおよび／または複数の列を右へ加えることによって）増大および移動される。次に、（ａ，ｂ）が今はクリッピング形状の原点を含むタイルグリッドの位置であるとする。次のステップとして、クリッピング形状を共用するタイルグリッドにおけるそれぞれの位置（ａ＋ａ'、ｂ＋ｂ'）について、タイル（ｘｘ＋ａ'，ｙｙ＋ｂ'，ｚ）を配置する。次に、フレームが表示される。最後に、必要な場合、タイルグリッドのサイズは、タイルグリッドがかさねてクリッピング形状のサイズの少なくとも２倍であるように、（例えば、複数の行を一番下へおよび／または複数の列を右へ加えることによって）増大される。サイズ変更の移行は、先に説明したように、パンの移行を動画的に行うのと同じ技法を用いて動画的にできる。また、特定の実装様態のために所望の場合、タイルグリッドを増大させる最終ステップは、タイルグリッドのサイズを増大および移動させる当初のステップの中へ組合せてもよいことに注目されたい。原点は上記の検討では任意に選ばれたこと、およびこの条件が一般的に真であることは当てにできないことを当該技術に精通する者は認知するであろう。しかし、上記で説明したステップは、当該技術に精通する者によってこの追加の複雑さを説明するように容易に調整されてもよい。

場所マーカー
先に述べたように、一実施の形態に従う場所マーカーは、（情報ウィンドウ等の他のオブジェクトと並んで）、対応する陰影とともに地図画像上へオーバレイでき、それはそれらの相対的位置を識別することを容易にする。一実施の形態では、陰影が、あたかも場所マーカーが地図上に垂直に立っているかのように見えるように描画でき、陰影は４５°の角度で傾斜され、係数√２で引き伸ばされ、そして垂直面上へ後方に投影される。そのような陰影は、場所マーカーが三次元様式で地図上に配置されたように見えさせるようにでき、ユーザが場所マーカーで指向された場所をより正確な様式で識別する助けをし、そしてまた、多数のマーカーが相互に干渉することを防止する助けもする特徴である。加えて、場所マーカーは、地図画像上へ重ね合わされたアンチエイリアス処理されたマーカーを含むアルファチャネルを持つＰＮＧファイルによって表されてもよい。図２３は、本発明の一実施の形態に従い１セットの場所マーカーを地図画像上へ重ね合わせるための例示的フローチャートを表す。ステップ２３００で、クライアントは、ユーザから場所に基づく情報を求めるリクエストを受信する。そこで、ステップ２３０５で、クライアントは、リクエストを場所サーバへこれまでに説明した様式で送信する。ステップ２３１０で、場所サーバはリクエストを解析する。次に、ステップ２３１５で、クライアントは、場所に基づく情報を場所サーバから受信する。ステップ２３２０で、クライアントは、この情報を１セットの画素情報へ翻訳する。そこで、ステップ２３２５で、クライアントは、地図画像上へ重ね合わされるか、または他の方法で配置されるべきマーカーおよび陰影の画像を（ローカルまたは遠隔の場所サーバからのいずれかで）取り出す。ステップ２３３０および２３３５で（それらは特定の実装様態のために所望される場合には明瞭に逆にできる）、クライアントは、それぞれ陰影およびマーカーを地図画像上へ（例えば、それらを地図画像上へ重ね合わせることで）配置する。図２４は、本発明の態様に従う、「ニューヨークにある大きな寿司店」を求めるテキストフィールド８２５での例示的リクエストの結果を表示する、（「Ａ」から「Ｊ」と命名された）多数の重ね合わされた場所マーカーを持つ例示的地図表示のウェブページを表す。

重ね合わされた画像の別の例として、図２７は、本発明の態様に従う重ね合わされたドライブ道案内経路軌跡を持つ例示的地図表示のウェブページを表す。図２７は、所望の出発住所を示すための第１テキスト記入フィールド８２５、終着住所を示すための第２テキスト記入フィールド８２８、所望のドライブ道案内に対応する強調された重ね合わされた経路軌跡２７１０、対応する１セットの文章のドライブ道案内２７３０、ドライブ道案内の終着点を示す場所マーカー８４５およびその陰影８５５、ドライブ道案内の出発点を示す同様な場所マーカーおよびその陰影８５５、および、経路に沿った特定の選択された手引き(例えば、「モフェットＢｌｖｄ．出口を取る」）に対する詳細な地図ビュー２７２５を表示する情報ウィンドウ２７２０およびその陰影８５５を含む。同様に、図２８は、本発明の態様に従う重ね合わされた領域境界軌跡を持つ例示的地図表示のウェブページを表す。

図２９は、本発明の一実施の形態に従い地図画像上へ（図８に示す情報ウィンドウ８４０およびその陰影８５５等の）１セットの情報ウィンドウを重ね合わせるための例示的フローチャートを表す。ステップ２９００で、クライアントは、場所情報のユーザの選択を受信する（例えば、ドライブ道案内クエリの結果として生成されたドライブ手引きをユーザが選択する場合）。ステップ２９０５で、クライアントは、場所情報に基づいて対応するＨＴＭＬコードを作成する。例えば、ＨＴＭＬコードはＸＳＬＴ（Internet Explorerまたは他の市販のウェブブラウザで利用可能な共通のスクリプト言語）を用いて場所情報を含むＸＭＬコードをＨＴＭＬに変換することによって作成されてもよい。作成されたＨＴＭＬコードは次いで、図２６Ａに示すＨＴＭＬテーブル２６０５等のテーブルの中へ挿入されてもよい。そこで、ステップ２９１０で、クライアントは、その後に地図画像上へ重ね合わされるＨＴＭＬウィンドウの境界の固定の部分のために１セットの予め描画した区画（例えば、図２６Ａに示すように第１コーナー区画２６１０、第２コーナー区画２６１２、第３コーナー区画２６１４、第４コーナー区画２６１５、および指示区画２６２２）を取得する。ステップ２９１５で、クライアントは、これらの予め描画した区画を接続して情報ウィンドウの境界の非固定の部分を作成する。例えば、情報ウィンドウの外側境界は、図２６Ａに示すように、例えば、接続された線２６２０により等の予め描画した区画の間の線を生成することで確定されてもよい。そこで、ステップ２９２０で、下記で検討するように、クライアントは、その後に地図画像上へ重ね合わされる１セットの予め描画した区画を確定および取得し、情報ウィンドウの陰影画像の固定の部分を生成する。ステップ２９２２で、下記で、また、検討するように、クライアントは、予め描画した区画を接続して情報ウィンドウの陰影画像の残りを埋める。

図２６Ｂは、基素の構成要素と並んで、情報ウィンドウと共に使用するための（また、図８および２７で要素８５５として示す）情報ウィンドウの陰影２６２５の例を示す。陰影画像２６２５は、上記で説明したように作成された情報ウィンドウ２６００の動的サイズに比例して対応するように動的に作成されてもよい。陰影画像２６２５を動的に作成するための例示的方法は、図２６Ｂを参照して、以下のように進行してよい。陰影画像２６２５の高さは、情報ウィンドウ２６００の高さの半分として設定されてもよい。図２６Ｂに示すように、ＨＴＭＬテーブルの陰影２６２５のサイズは、陰影のぼやけた輪郭線（存在する場合）を含み、それが半分の高さで陰影を含むことができるように確定される。情報ウィンドウの角度付きの垂直線（例えば、線２６３５）は、等角図法に一致するように所定の角度、例えば、角度４５度でそれらを斜めにすることで作成されてもよい。例えば、オフセット線２６３５は、角度４５度に設定される。これらの角度付きの線は、クライアントまたはサーバのいずれかで、クリッピング長方形を用いて予め描画した角度付きの陰影線の必要とされる部分のみを表示することで作成されてもよい。クライアントは、また、陰影画像のコーナーおよび指示区画のための１セットの予め描画した区画を確定する。図２６Ｂでは、例えば、情報ウィンドウの陰影ボックスコーナー区画２６４０および情報ウィンドウの陰影指示区画２６４５が、サーバからまたはローカルでのいずれかで取得されてもよい。情報ウィンドウ２６００のサイズに基づいて陰影画像の境界を確定した後に、そして適切な予め描画した区画を取得しクリッピングした後に、そこで接続線の残りが確定され、描かれてもよい。

陰影画像は、また、図２６Ｂに示すような、陰影同様の外見を作成するように埋められてもよい。陰影同様の外見を更に向上させるために、情報ウィンドウの下部に最も近い陰影画像部分が、最も暗くおよび／または最も鮮明であってよく、その一方で、陰影画像の部分が情報ウィンドウの下部から遠く離れて配置されている埋め部を徐々に色を薄くするおよび／またはぼやけさせる。

図２９へ戻り参照すると、ステップ２９２５で、クライアントは、陰影を地図画像上へ重ね合わせる。最後に、ステップ２９３０で、クライアントは、情報ウィンドウを地図画像上へ重ね合わせる。図８、２６Ａ、２６Ｂおよび２７の例から分かるように、この方法は、デジタル地図上にその陰影と並んで表示される場合に、全体として三次元的に見える情報ウィンドウを作成する。選択肢で、三次元的外見は、情報ウィンドウが北から始まって南へ配置されるように多数のタイルウィンドウを配置することで向上させることがあり、それにより奥行きの感覚も提供される。情報ウィンドウを東から西へ配置すること等の他の選択肢も利用可能である。この方法は、また、２つ以上のマーカーを地図上に配置する場合に使用されてもよい。

図２５を参照すると、同様な技法が、場所マーカー２５００のための角度付き陰影２５０５を生成することに用いられてもよい。

図３０は、本発明の一実施の形態に従い地図画像表示ウィンドウをサイズ変更するための例示的フローチャートを表す。ステップ３０００で、クライアントは、地図画像表示ウィンドウのサイズでの変更の通知を受信する（例えば、ユーザによるウィンドウのサイズ変更動作の結果として）。そこで、ステップ３００５で、クライアントは地図画像ウィンドウの中心を決定する。次に、ステップ３０１０で、クライアントは、ウィンドウのサイズが増大されたか否かを判断する。そうである場合、ステップ３０２５で、クライアントは、新規の追加のスペースを埋めることに必要とされるかもしれない新規のいずれの地図タイルのＩＤを決定し、ステップ３０３０でクライアントは、これらの新規のタイルを、そのローカルキャッシュまたは遠隔サーバのいずれかから要求する。ステップ３０３５で、クライアントは、新規タイルをタイルテーブル配列に配置し、新規地図画像を表示する。代替として、ステップ３０１０でクライアントが、ウィンドウのサイズが減少されたと判断する場合、ステップ３０１５で、クライアントは、クリッピング形状ウィンドウのサイズを比例して低減する。最後に、ステップ３０２０で、クライアントは、クリッピング形状ウィンドウを地図画像の中心上に再度中心を合わせる。

高解像度印刷
従来のウェブ地図サイトから地図ビューを印刷すると、地図ビューが先端的なプリンタの解像度より１桁低いことが多い画面の解像度で提供されるので、一般的に粗悪な出力を作成する。しかし、幾つかのホスト技術は（一実施の形態で使用されたようなＤＨＴＭＬを含み）、印刷のために好適な解像度での地図タイルを使用する地図ビューの組立てを容易にする。従って、一実施の形態で地図画像の高品質ハードコピーを達成するために、地図ビューは、印刷解像度のタイルを用いて再組立てできる。一実施の形態はＨＴＭＬ ＩＭＧ要素を用いてタイルをタイルグリッドに配置するために、１２８×１２８画素のサイズで１つ（例えば、screen_tile.gif）、５１２×５１２画素のサイズでもう１つ（例えば、print_tile.gif）の同じ地図タイルの２つの画像が、それぞれ表示および印刷の目的に使用されてもよい。図３１は、本発明の一実施の形態に従い地図画像の高品質印刷のための例示的な１セットの様々な解像度の地図画像タイルを表す。図３１に示す第３画像は、第１画像の高解像度バージョンのように見えることを当該技術に精通する者は気が付くであろう。この所見を用いて、ユーザからの印刷リクエストに応答して、現在の地図ビューは、印刷−解像度のタイルを用いて再組立てされてもよく、優れた印刷出力を達成する。

この文書に説明および示されたフローチャートのステップを実装するためのソフトウェアおよび／またはハードウェアは、コンピュータデバイス５０３ならびに／もしくはサーバ５１０、５１５、および５２０とのどのような組合せ上でも、またはコンピュータデバイス５０３とネットワーク５０５との間で接続されているインターネットサービスプロバイダのサーバ等の図示されていない他のコンピュータデバイスもしくはサーバ上でも、実装されてもよい。その上、図示のブロックは、異なる順番で実行されてもよく、図示した厳密な順序で実行されることを必要としない。その上さらに、非依存の動作は並列して実装されてもよい。

上記で説明したような実施の形態の態様は、図に図示した実装様態において多くの様々な形体のソフトウェア、ファームウェア、およびハードウェアで実装されてもよいことも、当該技術で通常の技量の者に明白であろう。本発明の原理に整合する態様を実装することに使用される実際のソフトウェアコードまたは特化した制御ハードウェアは、本発明の限定とはならない。従って、実施の形態の幾つかの態様の作動および挙動は、特定のソフトウェアコードに関連することなく説明した当該技術で通常の技量の者が本明細書の説明に基づいて態様を実装するソフトウェアおよび制御ハードウェアを設計することをできるであろうことが理解される。更に、実施の形態の幾つかの部分は、１つ以上の機能を実行する「ロジック」として実装されてもよい。このロジックは、特定用途向け集積回路またはフィールドプログラマブルゲートアレー等のハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組合せを含んでいてもよい。

幾つかの例示的な実施の形態が、添付図面に示され、説明された。しかし、そのような実施の形態は単に例証的であり、制限的でないと理解されるものとする。種々の他の改変形態が当該技術に精通する者に思い浮かぶであろうために、本開示は、明示的に開示した特定の構造および編成に限定されてはならない。

５００ 分散型ネットワークシステム
５０３ コンピュータデバイス
５０５ ネットワーク
５１０ ウェブサーバ
５１５ タイルサーバ
５２０ 場所データサーバ

Claims (19)

1. 地理的場所の幾何学的特徴を表示する方法であって、
   ネットワークサーバによって、クライアント装置から与えられる、地理的場所が識別されていない検索クエリーに基づいて所定の範囲内で第１の地理的場所の識別子を決定するステップであって、前記検索クエリーを前記ネットワークサーバによって処理することによって前記第１の地理的場所の識別子を生成することを含む前記ステップと、
   前記ネットワークサーバによって、前記第１の地理的場所の識別子に関連する幾何学的特徴を決定するステップと、
   前記ネットワークサーバによって、前記幾何学的特徴及びクリッピング形状に基づいて第１のズームレベルを決定するステップと、
   前記ネットワークサーバによって、前記第１のズームレベルに少なくとも部分的に基づいて１セットの地図タイルを識別するステップと、
   前記クライアント装置において、前記１セットの地図タイルを前記クリッピング形状に関して表示するステップと、
   を備える方法。
2. 検索クエリーに基づいて所定の範囲内で第１の地理的場所の識別子を決定する前記ステップは、該検索クエリー中における、該第１の地理的場所の識別子を指定しているユーザ定義されたショートカットを識別するステップを備える請求項１に記載の方法。
3. 前記第１の地理的場所の識別子とは、番地、交差点又は興味のある地点の１つであり、且つ、前記幾何学的特徴とは或る地点である請求項１又は２に記載の方法。
4. 前記第１の地理的場所の識別子とは街路であり、且つ、前記幾何学的特徴とはポリラインである請求項１又は２に記載の方法。
5. 前記第１の地理的場所の識別子とは、都市、郡、国、首都圏、近隣、郵便番号又は州の１つであり、且つ、前記幾何学的特徴とはポリゴンである請求項１又は２に記載の方法。
6. 前記ネットワークサーバ及び前記クライアント装置の一方によって、前記第１の地理的場所の識別子に基づいて場所マーカーを生成するステップと、
   前記クライアント装置において、前記場所マーカーを前記１セットの地図タイル上に表示するステップ
   を更に備える請求項１乃至５の何れかに記載の方法。
7. 前記１セットの地図タイルを前記クリッピング形状に関して表示する前記ステップは、該１セットの地図タイルを前記クライアント装置のディスプレイ上に表示された１つの表示ウィンドウ上へスライドさせるステップを備える請求項１乃至６の何れかに記載の方法。
8. 前記１セットの地図タイルを前記クリッピング形状に関して表示する前記ステップが、
   前記クライアント装置によって、第１地図ビューを決定するステップと、
   前記クライアント装置によって、第２ズームレベルへ縮小するときに、前記第１地図ビューを表示するステップと、
   前記クライアント装置によって、前記第２ズームレベルで第２地図ビューへパンするステップであって、該第２地図ビューが前記幾何学的特徴を備える前記ステップと、
   前記クライアント装置によって、前記第１のズームレベルへ拡大するときに、該幾何学的特徴を表示するステップと
   を、更に備える請求項１乃至６の何れかに記載の方法。
9. 地理的場所マーカーを表示する方法であって、
   ネットワークサーバによって、クライアント装置から与えられる、地理的場所が識別されていない検索クエリーに基づいて所定の範囲内で第１の地理的場所の識別子を決定するステップであって、前記検索クエリーを前記ネットワークサーバによって処理することによって前記第１の地理的場所の識別子を生成することを含む前記ステップと、
   前記ネットワークサーバによって、前記第１の地理的場所の識別子に関連する幾何学的特徴を決定するステップと、
   前記ネットワークサーバによって、地図画像を描画するための１セットの地図タイルを識別するステップであって、前記幾何学的特徴に基づいてズームレベルを決定することを含む前記ステップと、
   前記ネットワークサーバ及び前記クライアント装置の一方によって、前記第１の地理的場所の識別子に基づいて場所マーカーを生成するステップと、
   前記クライアント装置によって、前記１セットの地図タイルをクリッピング形状に関して表示するステップと、
   前記クライアント装置において、前記場所マーカーを地図画像上に表示するステップであって、該場所マーカーを第１の対応する陰影とともに表示するステップと
   を備える方法。
10. 前記場所マーカーを第１の対応する陰影とともに表示する前記ステップは、前記場所マーカー及び該第１の対応する陰影の少なくとも一方を、第１オーバレイ内に描画するステップを備える請求項９に記載の方法。
11. 前記第１オーバレイは、画像からなる請求項１０に記載の方法。
12. 前記第１オーバレイは、少なくともベクターからなる請求項１０に記載の方法。
13. 前記第１の対応する陰影のサイズは前記場所マーカーのサイズに比例するものである請求項９乃至１２の何れかに記載の方法。
14. 前記第１の対応する陰影の高さは前記場所マーカーの高さの或る割合である請求項９乃至１２の何れかに記載の方法。
15. 前記第１の対応する陰影は前記場所マーカーに対して或る角度で表示されるものである請求項９乃至１４の何れかに記載の方法。
16. 前記第１の対応する陰影は、前記場所マーカーに最も近い第１領域で最も暗く、且つ、該場所マーカーから最も離れた第２領域で最も明るくなるものである請求項９乃至１５の何れかに記載の方法。
17. 前記ネットワークサーバによって、地理的場所が識別されていない検索クエリーに基づいて所定の範囲内で複数の地理的場所の識別子を決定するステップと、
    前記ネットワークサーバ及び前記クライアント装置の一方によって、前記複数の地理的場所の識別子に基づいて複数の場所マーカーを生成するステップと、
    前記クライアント装置において、前記複数の場所マーカーを複数の対応する陰影とともに前記地図画像上に表示するステップ
    を更に備える請求項９乃至１６の何れかに記載の方法。
18. 前記複数の場所マーカーは、複数の検索結果に関連付けて表示され、該複数の検索結果のうち少なくとも一部はウェブページへのリンクからなる請求項１７に記載の方法。
19. 前記クライアント装置において、前記場所マーカーについてのユーザの選択の受信に応じて情報ウィンドウを生成するステップと、
    前記クライアント装置において、前記地図画像上に前記場所マーカーに関連付けて前記情報ウィンドウを表示するステップであって、該情報ウィンドウを第２の対応する陰影とともに表示するステップ
    を、更に備える請求項９乃至１８の何れかに記載の方法。

Images