JP2014160490A - デジタルマッピングシステムにおけるタイルの生成と供給 - Google Patents

Abstract

【課題】種々の処理環境（例えば、サーバまたはその他のコンピュータデバイス）が採用できる見た目に美しい地図の効率的なオンライン供給を可能にするデジタルのタイルベースマッピング技法を提供する。
【解決手段】地図ラベルが地図ファイルの境界を横断する場合のような、地図ラベルおよび他のかかる特徴を取り扱う画像タイルベースのデジタルマッピングシステムが、オフラインセッション中に地図タイルを生成し、これらタイルの選択されたセットを要求された場合にクライアントへ供給するよう構成されている。
【選択図】図１

Description

関連出願の相互参照
この出願は、２００５年２月７日出願の米国仮特許出願第（未通知）号で表題「デジタルマッピングシステムにおいてタイルを生成するための方法および装置」＜弁理士整理番号１５９１６４−０００８（Ｐ００５Ｚ）＞、２００４年５月３日出願の第６０／５６７，９４６号、および２００４年３月２２日出願の第６０／５５５，５０１号の利益を主張する。加えて、この出願は２００５年２月５日出願の米国特許出願第（未通知）号で表題「デジタルマッピングシステム」＜弁理士整理番号１５９１６４−０００５（Ｐ００４）＞の一部継続出願である。加えて、この出願は２００５年３月２３日出願の米国特許出願第（未通知）号で表題「サブ画素ビットマップを使用するグラフィックスの生成、格納、および表示」＜弁理士整理番号２４２０７−１０２１７＞に関連する。これら出願のそれぞれはその全体を引用して本明細書に組み込む。

本発明は、マッピングシステムに関し、より詳細にはデジタル環境におけるマッピングシステムに関する。

コンピュータ化したマッピングシステムは、地理的場所についての情報を検索、識別、および発見するために開発されてきた。かかるコンピュータ化したマッピングシステムの１つの形体は、旅行計画インターネットウェブサイトを含んでいる。５千万を超える月毎の固有ユーザにより、かかる地図サイトは、非常に人気のある供与である。かかるサイトの例は、ＡＯＬ社のMapQuest、ヤフー社のTelcontar社ベースの地図、およびマイクロソフト社のMapPoint.netスイートを含む。かかるサイトは全て、これから説明するような、共通のモデルにならって動作する。

ウェブユーザが新規の地図ビューを（例えば、郵便住所を記入することで、または現在の地図ビューの付近にあるナビゲーションリンクをクリックすることで）求める場合、ユーザのウェブブラウザは、新規地図ビューの境界を示すリクエストをウェブサーバへ送る。ウェブサーバは、次に対応するベクターベースの地図データをデータベースから抽出し、地図のビットマップ画像を作図する。サーバは、そこでビットマップをユーザのウェブブラウザが対応している画像フォーマットへ変換し、画像を、時にはＨＴＭＬに埋め込んで、それが表示できるようにユーザのウェブブラウザへ返す。

他の地図ウェブサイト、例えば英国のMultiMapsおよびオーストラリアのWhereIs等は、代わりにラスタベースの地図データベースを利用する。これらの事例では、ベクターを抽出し、地図画像を作図することは必要でない。むしろ、これらの機能は、大きい予め描画した画像の適切な一部を単に抽出することに置き換えられる。

ベクターベースであろうとラスタベースであろうと、これらの既存のシステムは、普通には非常に劣悪な性能を示す。とりわけ、結果として得られる地図は、小さく動きが遅い傾向がある。例えば、既存の地図ビューを西へ、ビューの幅の、例えば５０％だけパンする簡単なタスクを考える。従来のシステムは、普通には全く新規の画像を生成し、新規の画像をサーバからユーザのブラウザへ送信する。かかるシステムは、新規と古い地図ビューの間の５０％の重複を認知し生かすことができないので、無駄が多い。ベクターベースの場合において、リアルタイムでベクターから地図画像を生成する必要がある追加様態は、一般的に読み難く、専門的な外観と雰囲気に欠ける地図の結果となる傾向があり、それによってユーザの体験を損ねている。

他のベンダは、そのユーザがダウンロードしてインストールするカスタムソフトウェアを書くことを選んだ。この後者の手法はユーザの体験に劇的な改善を招くことができるとはいえ、ユーザのコンピュータ上にソフトウェアをインストールする必要性は、広範囲に及ぶ受入を阻害するかもしれない。

従って、必要なのは、見た目に美しい地図の効率的なオンライン配信を容易にするデジタルマッピング（地図作成）技法である。

本発明の１つの実施の形態は、タイルベースのデジタルマッピングシステムのための地図タイルを生成するためのシステムを提供する。システムは、デジタル地図画像を生成するための地図ペインターモジュール、デジタル地図画像から地図タイルを生成するためのタイル作成手段、およびタイル作成手段によって生成される地図タイルを格納するためのタイル記憶装置を含む。１つのかかる実施の形態では、地図ペインターモジュールは、デジタル地図画像が生成される所与の領域に対する地理的データを要求および受信するよう動作可能である。ここでは、地図ペインターモジュールによってアクセス可能である地図データ記憶装置は、所与の領域に対する１セット以上の地理的データを格納するために使用できる。地図データ記憶装置は、例えば、１セットのリッチマッピングフォーマット（ＲＭＦ）ファイルを含んでいてもよい。１つの特定の構成では、遠隔マッピングエンジン（ＲＭＥ）ライブラリが、地図ペインターモジュールが地理的データにアクセスすることを容認するアプリケーションプログラムインタフェースを有する。

タイル作成手段は、例えば、地図タイルが生成されるべき領域およびズームレベルを定義する構成ファイルに従い動作してもよい。構成ファイルは更に、使用する地理的データセットの少なくとも１セットおよびラベル配置情報を含む地図の作成方法を定義してもよい。タイル作成手段は、地図ペインターモジュールを使用して構成ファイルに定義された領域に対するデジタル地図画像を生成できる。１つの特定の実施の形態では、タイル作成手段は、構成ファイルに定義された大きい領域をより小さい領域へ分割するよう成され、地図ペインターモジュールを使用してこれらのより小さい領域に対するデジタル地図画像を生成する。タイル作成手段は更に、生成された地図タイルを所望の画像フォーマット（例えば、サブ画素ビットマップ、ＧＩＦ、ＰＮＧ、ＴＩＦＦ、またはＪＰＥＧ）にコード化し、フォーマット付の地図タイルを格納するように構成されてもよい。システムは、更に、ユーザからの地図リクエストに応答して、タイル記憶装置に格納された地図タイルを供給するように構成される地図タイル供給システムを含んでいてもよい。

本発明の別の実施の形態は、ユーザからの地図リクエストに応答して地図タイルを供給するように構成された地図タイル供給システムを提供する。システムは、ユーザによって要求された１つ以上の地図タイルを供給するための複数のフロントエンドタイルサーバを含む。リクエストディストリビュータが、複数のフロントエンドタイルサーバ間で地図タイルに対するリクエストを分配するために使用される。また、システムに含まれるのは、複数のバックエンドタイルサーバであり、複数のフロントエンドタイルサーバと通信可能に結合されている。各バックエンドタイルサーバは、（例えば、ディスク上でローカルにあるか、またはネットワーク上の）地図タイルへのアクセスを有し、要求された地図タイルを対応するフロントエンドタイルサーバへ提供するよう構成される。

フロントエンドタイルサーバの少なくとも１つは、１つ以上の単色地図タイルを識別するよう構成でき、バックエンドタイルサーバの１つからこれらの単色地図タイルを要求する必要なく、単色地図タイルを供給するよう構成される。１つのかかる実施の形態では、１つ以上の単色地図タイルが、少なくとも１つのフロントエンドタイルサーバに含まれたメモリキャッシュに格納され、それによってこれらの単色地図タイルを供給することに関連するディスクアクセスに対する必要性を低減する。別のかかる実施の形態では、ユーザは、コンピュータデバイスを使用して少なくとも１つのフロントエンドタイルサーバと通信しており、少なくとも１つのフロントエンドタイルサーバは、コンピュータデバイスにローカルで利用可能である単色地図タイルをコンピュータデバイスに使用させ、それによりかかるタイルは供給される必要がない。

地図タイルのそれぞれは、例えば、地図タイルのＮ・Ｎブロックに関連でき、地図タイルが要求されるたびに、Ｎ・Ｎブロックに対応する全てのＮ²タイルが供給できる。Ｎ²タイルの全てがキャッシュに格納できてもよい。他の実施の形態では、地図タイルは、例えば、地図タイルのＮ・Ｍブロックに関連させる（すなわち、ブロックは正方形である必要はない）。バックエンドサーバの数は、各バックエンドサーバが地図タイルの特定サブセットを供給することに使用できるようにしてもよい。ここでは、各バックエンドサーバは、その対応するサブセットの全てまたは一部をキャッシュに格納する能力があってもよい。各バックエンドタイルサーバは、地図タイルのサブセットの供給専用であり、各フロントエンドタイルサーバは、地図タイルに対するユーザリクエストを満足させることに使用する適切なバックエンドサーバを識別するように構成できる。１つのかかる実施の形態では、各フロントエンドタイルサーバは、適切な地図タイル座標に基づくハッシュ関数を使用して、バックエンドサーバを識別する。バックエンドタイルサーバは、どのサブセットを供給しているかを知る必要はないことに留意されたい、それは展開を簡略化できる。

バックエンドタイルサーバがその地図タイルの負荷の供給に利用不可であることに応答して、各フロントエンドタイルサーバは、その負荷を残りのバックエンドタイルサーバ間で分配するよう構成できる。１つのかかる実施の形態では、各フロントエンドタイルサーバは、地図タイル座標に基づくハッシュ関数および試行カウンタを使用して、負荷を分配する。システムは更に、地図タイルを生成するための、タイル作成手段を含む地図タイル生成システムを含んでいてもよい。生成された地図タイルを格納するためのタイル記憶装置も、備えることができ、フロントエンドサーバおよび／またはバックエンドサーバのキャッシュで利用可能ではない地図タイルがタイル記憶装置からアクセスできる。

本発明の別の実施の形態は、タイルベースのデジタルマッピング方法を提供する。方法は、デジタル地図画像から地図タイルを生成すること、地図タイルを格納すること、およびユーザの地図リクエストに応答して地図タイルの１つ以上を供給することを含む。方法は更に、ユーザのコンピュータデバイスにローカルで利用可能である単色地図タイルを識別することを含んでいてもよい。方法は更に、デジタル地図画像を生成することを含み、それは地図タイルが生成されるべき領域およびズームレベルを定義することを含む。デジタル地図画像を生成することは、例えば、使用する地理的データセットの少なくとも１セットおよびラベル配置情報を含む地図の作成方法を定義することを含んでいてもよい。地図タイルを格納することは、生成された地図タイルを所望の画像フォーマットにコード化すること、およびフォーマット付の地図タイルを格納することを含んでいてもよい。地図タイルの１つ以上を供給することは、供給された地図タイルをキャッシュに格納することを含んでいてもよい。

１つの特定の実施の形態では、デジタル地図画像から地図タイルを生成することは、作図されるべき領域、および各領域が作図される必要がある種々のズームレベルを識別すること；領域を様々なズームレベルで必要に応じてサブ領域に分割し、それによりそれぞれのサブ領域が利用可能なメモリ内で予め描画でき；各サブ領域を所与のズームレベルで予め描画すること；予め描画した各サブ領域を描画領域に分割し、それにより各描画が利用可能なメモリ内で描画でき；描画領域を描画し、結果として得られた画像を地図タイルに切り分けること；を含んでいてもよい。１つのかかる事例では、ズームレベルでのサブ領域のそれぞれがタスクを表し、それにより領域およびズームレベルによって定義されたタスクの一覧表を提供し、並列処理がこれらのタスクを実行することへ適用される。別のかかる事例では、要求しているユーザへ表示されるべき地図は解像度を有し、描画は表示されるべき地図の解像度よりＮ倍大きい解像度で行われ（例えば、Ｎ＞＝２）、描画によって生成されたビットマップは、タイルをサブ画素ビットマップとして生成するための入力として使用される。

本発明の別の実施の形態は、デジタル地図タイルをデジタル地図データから生成するための方法を提供する。方法は、作図されるべき領域および各領域が作図される必要がある種々のズームレベルを識別することを含む。方法は、領域を様々なズームレベルで必要に応じてサブ領域に分割し、それによりそれぞれのサブ領域は利用可能なメモリ内で予め描画できることに続く。方法は、各サブ領域を所与のズームレベルで予め描画すること、次いで予め描画した各サブ領域を描画領域に分割し、それによりそれぞれの描画領域は利用可能なメモリ内で描画できることに続く。方法は、画像を生成するように描画領域を描画すること、そして画像を地図タイルに分割することに続く。各サブ領域を予め描画することは、例えば、地理的データセットの少なくとも１セットおよびデジタル地図画像の構築方法ついての命令の表現にアクセスすることを含んでいてもよい。命令は、例として、構成ファイルに表すことができる。サブ領域は、それぞれが各ズームレベルに対する所定の固定サイズを有することができる。１つの特定の実施の形態では、予め描画する決定は、問題のある特徴がサブ領域の間の境界線を横断することを防止する。代替で、別の実施の形態では、予め描画する決定は、特徴がサブ領域の間の境界線を横断することを容認する。かかる事例では、境界線を横断する特徴に関連した２つの整列するサブ領域は、同時に予め描画されることを容認されない。予め描画する決定は、格納でき、その結果それらは（特徴がサブ領域の間の境界線を横断することを可能にする）その後の予め描画するタスクに使用できる。

本明細書に説明した特徴および利点は、全てを包括したのでなく、とりわけ、多くの追加の特徴および利点が、図および説明を勘案して当該技術に精通する者に明白であろう。その上、明細書に使用した言葉は、読み易さおよび解説的目的のために主に選択されており、発明の主題の範囲を限定しないことに留意されたい。

本発明の１つの実施の形態に従って構成されたタイルベースのデジタルマッピングシステムのブロック図である。

図１のシステムに採用できる処理環境のブロック図である。

本発明の１つの実施の形態に従ってデジタルマッピングシステムのための地図タイルを生成するために構成されたシステムのブロック図である。

地図ラベルが地図タイルの境界を横断するタイルベースのマッピングシステムのシナリオを示す。

地図ラベルが地図タイルの境界を横断するタイルベースのマッピングシステムのシナリオを示す。

本発明の実施の形態に従って、図４および図５に示すシナリオに対する解決策を示し、ここでは地図ラベルは地図タイルの境界を横断することを容認されない。

本発明の実施の形態に従って、図４および図５に示すシナリオに対する別の解決策を示し、ここでは地図タイルの境界を横断する地図ラベルは２つの部分にわたり作図される。 本発明の実施の形態に従って構成された地図タイル供給システムのブロック図である。

見た目に美しい地図の効率的なオンライン供給を可能にするデジタルのタイルベースマッピング技法が開示される。１つの特定の実施の形態では、画像タイルベースのデジタルマッピングシステムが、オフラインセッション中に地図タイルを生成し、これらのタイルの選択されたセットを要求された場合にクライアントへ供給するよう構成されている。また、提供されるのは、タイルベースのマッピングシステムにおいて、例えば、地図ラベルまたは他の特徴が地図タイルの境界を横断する場合のような、地図ラベルおよび他のかかる特徴を取り扱うことに対する解決策である。種々の処理環境（例えば、サーバまたはその他のコンピュータデバイス）が、システムで採用できる。

本明細書に説明した機能は、コンピュータプログラム命令によって実現されてもよい。これらの命令は、コンピュータまたはその他の処理環境の中へ読み込まれてマシンを生成でき、それにより命令は本発明の種々の実施の形態に従ってタイルベースのマッピング技法を実践するよう実行される。これらのコンピュータプログラム命令はまた、製品を提供するようプロセッサ可読媒体内にコード化されてもよい。数多くのどのようなプログラミング言語またはその組み合わせ（例えば、Ｃ、Ｃ＋＋、ＨＴＭＬ）も、コンピュータプログラム命令を実装することに使用できる。本発明の他の実施の形態は、特設のハードウェア、例えばフィールドプログラマブルゲートアレー(ＦＰＧＡ)または特定用途向け集積回路（ＡＳＩＣ）技術等によって実装できる。同様に、この開示に照らして明白であろうように、ハードウェアおよびソフトウェアの組み合わせは、本発明の他の実施の形態を実装することに使用できる。

システムの概観
図１は、本発明の１つの実施の形態に従って構成されたタイルベースのデジタルマッピングシステムのブロック図である。図示のように、システムは、ネットワーク１０５へ接続されたコンピュータデバイス１０３を含む。種々の供給システムもまた、ウェブ供給システム１１０、タイル供給システム１１５、および場所データ供給システム１２０を含むネットワーク１０５へ接続さる。他のコンピュータデバイス（不図示）も、ネットワーク１０５経由で供給システム１１０、１１５、および１２０と通信してもよい。

コンピュータデバイス１０３は、演算するために構成されたどのような種類のデバイスであってもよく、例えばパーソナルコンピュータまたはラップトップ、携帯電話、携帯型情報端末、車両に配置されるナビゲーションシステム、携帯式ＧＰＳシステム等である。コンピュータデバイス１０３は、ユーザがネットワーク１０５上で他のデバイスおよびシステムとインタフェースおよび通信することを容認するブラウザ（または他の同様なアプリケーション）を含む。ブラウザの例は、マイクロソフト社Internet Explorerブラウザ、ネットスケープ社Navigatorブラウザ、Mozilla Firefoxブラウザ、PalmSource社Web Browser、またはネットワーク１０５と通信する能力のあるいずれか他の閲覧もしくはアプリケーションソフトウェアを含む。一般的に言うと、コンピュータデバイス１０３は、ユーザがネットワーク１０５経由で供給システム１１０、１１５、および１２０にアクセスすることを容認するどのようなデバイスであってもよい。

ウェブ供給システム１１０は、総体的システムの一部であり、それは初期のＨＴＭＬ（ハイパーテキスト記述言語）、画像、スクリプト言語（例えば、JavaScript、JScript、Visual Basic Script）、ＸＳＬＴ（拡張性スタイル言語変換）および、コンピュータデバイス１０３上のブラウザによって使用される他の静的要素を配信する。この供給システム１１０は、負荷分散スキームの下で動作する１つ以上のサーバを含んでいてもよく、各サーバ（またはサーバの組み合わせ）はコンピュータデバイス１０３に応答し、それと対話するように構成されることに留意されたい。ウェブ供給システム１１０は、この開示に照らして明白であろうように、従来の技術で実現できる。

タイル供給システム１１５は、総体的システムの一部であり、コンピュータデバイス１０３からのリクエストに応答して個々の地図タイルを配信することを担当し、各タイルは、例えば、総体的タイルベースの地図へ座標付けるｘ，ｙおよびｚ値によって一意的に定義される。他のタイル識別スキームも同じく使用できる。供給システム１１５は、負荷分散スキームの下で動作する１つ以上のサーバを含んでいてもよく、各サーバ（またはサーバの組み合わせ）はコンピュータデバイス１０３に応答し、それと対話するように構成される。タイル供給システム１１５に関連したアーキテクチャおよび機能性の例は、図８を参照して更に検討する。

場所データ供給システム１２０は、種々の形体の場所データをコンピュータデバイス１０３へ配信する総体的システムの一部である。その機能は、例えば、番地の地理的場所を見出すこと、ドライブ道案内を生成およびフォーマット化すること、およびクエリーに対する場所特定の結果を検索すること（例えば、グーグル社のLocal Searchサービスのような）を含む。他のサービスもまた、提供されてもよい。一般的に、ユーザが検索文字列を記入する場合、それはコンピュータデバイス１０３によってリクエスト内へ入れられ、ネットワーク１０５経由で場所データ供給システム１２０へ送られる。場所データ供給システム１２０は次いで、リクエストの求める内容を決定し、種々のサブシステム、例えばジオコーダ、ルート指定エンジン、および個所の検索索引等からの適切なデータとともに、コンピュータデバイス１０３がユーザへデータを提示することに使用できるフォーマットで（例えば、ブラウザ経由で）応答する。

ネットワーク１０５は、ローカルエリアネットワーク（例えば、イントラネット）、広域ネットワーク（例えば、インターネット）、またはその幾つかの組み合わせ等のどのような種類の通信ネットワークであってもよい。代替で、ネットワーク１０５は、コンピュータデバイス１０３と供給システム１１０、１１５、および１２０との間の直接的接続であってもよい。一般的に、コンピュータデバイス１０３、ネットワーク１０５、および／または供給システム１１０、１１５、および１２０は、多種多様な通信プロトコルを使用して、どのような種類の有線または無線の接続経由で通信してもよい。

図２は、図１のシステムに採用できる処理環境のブロック図である。例として、コンピュータデバイス１０３、供給システム１１０、１１５、および１２０に含まれたいずれかのサーバは、図示の処理環境を使用して構成できる。幾多の他の処理環境も同じく使用でき、本発明はどのような１つのかかる実施の形態に限定される意図ではない。図２はただ単に１つの可能性のある例として提供される。

図示のように、処理環境のこの例は、バス２００、１つ以上のプロセッサ２０５、主メモリ２１０、読出専用メモリ（ＲＯＭ）２１５、記憶装置２２０、１つ以上の入力デバイス２２５、１つ以上の出力デバイス２３０、および通信インタフェース２３５を含む。バス２００は、処理環境の構成要素の間での通信を許容する１つ以上の導線を含んでもよく、従来のバス技術を使用して実現できる。

プロセッサ２０５は、命令を解釈して実行するどのような種類の従来のプロセッサ、マイクロプロセッサ、または処理ロジックを含んでもよい。主メモリ２１０は、プロセッサ２０５による実行のための情報および命令を格納するランダムアクセスメモリ（ＲＡＭ）または別の種類の動的記憶装置を含んでいてもよい。ＲＯＭ２１５は、プロセッサ２０５による使用のための情報および命令を格納する従来のＲＯＭ装置または別の種類の不揮発性記憶装置を含んでいてもよい。記憶装置２２０は、例えば、磁気および／または光学記録媒体およびその対応する駆動部を含んでいてもよい。主メモリ２１０は、一般にアクセスされるデータ（例えば、地図タイル）を一時的に格納するためのキャッシュメモリも含んでもよいことに留意されたい。かかるキャッシュは、データを求めるリクエストが受信されるたびに記憶装置２２０にアクセスする必要性を解消することになり、それによって処理時間を低減する。

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

１つの実施の形態の操作では、コンピュータデバイス１０３が、タイル供給システム１１５に格納されている地図情報を要求する。（タイル供給システム１１５に含まれる）フロントエンドサーバは、コンピュータデバイス１０３または「クライアント側」によって発信されたクエリーに、クライアント側のブラウザによってアクセスされる（例えば、JavaScriptまたは別のスクリプト言語での）命令を含むウェブページを返すことによって応答する。このようにして、クライアントのコンピュータデバイス１０３は、必要に応じてタイル供給システム１１５から地図タイルを要求し、タイル供給システムは要求された地図画像に関連したタイルを供給する。要求された地図画像は次いで、要求された地図画像を形成する１セットのタイルをウェブブラウザ中で一緒に組み合わせることによってコンピュータデバイス１０３で表示される。地図タイルは「予め描画」できるが、それは、図３を参照して検討するオフラインフェーズ中に地図タイルが生成されることを意味する。

ユーザのウェブブラウザ上で大きいラスタ画像のいずれかのサブ領域ビューを地図画像として再現するために、所望のビューを一緒にカバーする最少セットのタイルのみを使用するブラウザ側のスクリプトが使用できる。従って、ユーザは地図の供給されたセクションを見ることができ、そこで見ている地図のセクションを（例えば、入力デバイス２２５のカーソルを使用して地図を１方向にドラッグすることによって）変更し、それによって、その時点でブラウザのウィンドウ内の新規の地図の場所を埋める新規の地図タイルを供給させる。効果としては、要望どうりに拡大／縮小でき、更に新規の場所へ適応できる仮想的にエンドレスな地図である。本発明の実施の形態に従って構成されたタイルベースのデジタルマッピングシステムによって可能となったこの特徴だけでなく、その他も前もって組み込んだ特許出願で表題「デジタルマッピングシステム」で更に詳細に検討されている。どのような所与の実現様態についても、タイルのサイズは、以下のトレードオフを前提として、経験的に確定できる：（１）より大きいタイルは所与のビューを生成することに必要なタイルの合計サイズを（画素およびバイトの両方で）増大させる傾向がある；その一方で、（２）より小さいタイルは所与のビューを生成することに必要な別々のリクエスト（例えば、ＨＴＴＰリクエスト）の数を増大させる傾向がある。

代替で、サーバ側（例えば、タイル供給システム１１５）上のタイルのデータベースを使用するのでなく、それぞれのタイルは、http://<domain>/7/-18/1/-145_12_7.gif等の一意のＵＲＬを使用してアクセス可能な別々のファイルに格納でき、ここではこの例でのディレクトリパス 7/-18/1 は、この事例では単に(-145,12,7) に等しいタイル座標だけによって決まる。簡略化するために、それぞれのズームレベルｚの第１タイルは、タイルの左上画素が座標（０，０，ｚ）を有するように配置できる。この設定は、それぞれのタイルへの一意の座標三重項の割り当てを、タイルの左上画素の画素のｘおよびｙ座標をそれぞれタイルの幅および高さで整数除算することによって容易にする。従って、幾つかの実施の形態では、緯度/経度の座標、画素の（ｘ，ｙ，ｚ）座標およびタイルの（ｘ，ｙ，ｚ）座標の合計３つの座標系が利用されることに留意されたい。座標系のこの特定の選定は、本発明を限定する意図ではなく、幾つかの実施の形態で使用されるアルゴリズムを説明することで補助するように選択された。一般的に、どのような一貫性のある座標系または指標付け方式もここでは使用できる。次に、それぞれの画素は一意のタイルに属し、その座標は容易に演算できる。

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

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

タイル生成
図３は、本発明の１つの実施の形態に従ってデジタルマッピングシステムのための地図タイルを生成するために構成されたシステムのブロック図である。

先に述べたように、地図システムによってカバーされた領域全体の１セットの大きい連続した予め描画したラスタ画像が、ユーザに透過であるオフラインプロセスで生成できる。かかる１セットのラスタ画像が、例えば、街路のレベルから国のレベルまでの範囲に及ぶズームレベルのそれぞれについて提供される。これらの大きい画像は、その後タイルに切り分けられ、タイルはそこで適切な画像フォーマット（例えば、ＧＩＦ）にコード化される。図３に示すシステムの目的は、所与の１セットの領域およびズームレベルをカバーする完全な１セットのタイルを生成することである。

一般的に、地図タイルが作成され得る地図画像を生成するプロセスは、予め描画することと、描画することの２つの論理的プロセスに分割できる。予め描画するプロセスでは、地図の作図の仕方についての決定が、利用可能な地図データおよび構成データに基づいて成される。描画プロセスでは、実際の地図作成が、ビットマップ画像を生成すること、または地図作成をベクターベースのフォーマットで定義することのいずれかによって行われる。両プロセスのために、スピードが高度に望まれる。コンピュータによるデバイスまたは他の好適な処理環境のメモリ内でプロセスを実践することが、充分なスピードを達成する１つの方法である。

１つの実施の形態において、予め描画するプロセスは、全ての必要な地図データ（地図画像が作図できる地理的データセット）、およびメモリ内での地図の構築方法についての決定の表現へのアクセスを有する。この決定は、例えば、構成ファイル中に表現できる。描画プロセスは、作図されるべきものの定義と一緒に、ビットマップがメモリ内で作図されるようにしてもよい。幾つかの（しかし全てではない）事例では、予め描画するプロセスは、利用可能なメモリ量の関係で描画プロセスよりずっと大きい領域をカバーできる。

例えば、米国およびカナダの大陸全体をカバーするために、数億ものタイルが必要であるかもしれず、タイルのための合計ファイルサイズは数百ギガバイト程度もデータである。要望に応じて基調を成すデータから地図画像を作図する代わりに、地図全体がセクション（タイル）で予め作図され、適切なタイルが必要である場合にクライアントへ送られる。結局ユーザのウェブブラウザ上で組み立てられ、表示されるそれぞれのタイルベースの地図画像は、大きい既定のラスタ画像の１つのサブ領域（普通には長方形の形状にされる）に一致する。大きい領域に対するタイル生成を本明細書で検討する。

タイル生成プロセスは、タイル作成手段３０５を実行することで開始される。領域を作図するために、タイル作成手段３０５は地図ペインターモジュール３１０を使用して画像を生成する。地図ペインターモジュール３１０は、所与の領域に対する地理的データを市販のＲＭＥ（遠隔マッピングエンジン）ライブラリ３１５を通して入手し、ＲＭＥライブラリは地図ペインターモジュール３１０が地図データ記憶装置３２０へアクセスすることを容認するアプリケーションプログラムインタフェース（ＡＰＩ）を採用する。代替の実施の形態では、地図ペインターモジュール３１０は地図データ記憶装置に直接的にアクセスするように構成でき、それによって市販のＲＭＥライブラリ３１５の必要性を解消することに留意されたい。いずれにしても、地図ペインターモジュール３１０は作図モジュールとして動作し、ここではグラフィックスライブラリは、所望の外見を持つビットマップを生成することに使用できる。ビットマップ地図画像をアンチエイリアス処理させるために、これは、グラフィックスライブラリによって、または地図画像を要望より高い解像度で作図することによって、次いで適切な方法（例えばバイリニアまたはバイキュービック再サンプリング等）で画像を縮小するか、サブ画素ビットマップを生成する能力のあるソフトウェアへの入力としてより高い解像度のビットマップを使用することによって行うことができる。１つの特定のかかる実施の形態は、マイクロソフト社のＧＤＩ／ＧＤＩ＋を４倍の解像度で使用して地図画像を作図し、次いでそれぞれの５１２・５１２画素領域を１つの１２８・１２８サブ画素のビットマップタイルに変換することによってサブ画素ビットマップを生成する。

タイル記憶装置３００は、タイル作成手段３０５によって生成されたタイルが保存される場所である。１つの実施の形態では、記憶装置３００は、簡単なディスクに基づく記憶システムとして実現されるが、それは大量のデータを効率的に受信および格納する能力のあるどのようなシステムであってもよかろう。通常のファイルシステムは、多大の数の小さいファイルを取り扱う場合に非効率的になることが多いから、タイルは複合ファイルに格納してもよい。１つの特定の実施の形態では、（予め組み込んだ米国仮特許出願第６０／５５５，５０１号で検討したように）タイルは、サブ画素ビットマップとして格納されるが、どのようなビットマップまたはベクターベースのフォーマットも代わりに使用できよう。一旦地図タイルがタイル記憶装置３００に格納されると、地図タイルは、要求しているクライアントへタイルを供給するデジタルマッピングシステムに対して最適化されてもよい様式で、タイルを（複数のブロックでまたは一時に１つで）読出し、それらをキャッシュに格納するプロセスに利用できる。

タイル作成手段３０５は、構成ファイルで開始でき、構成ファイルは、タイルが生成されるべき領域およびズームレベル、使用するデータセット、および（例えば、色の明細、種々の特徴に対する外見、ラベルの配置等により）地図の作成方法を定義する。構成ファイルは、地図データ記憶装置３２０に存在しない手で配置したラベル等の追加のデータも含むことができる。１つの実施の形態では、構成ファイルは、タイル作成手段３０５が（地図ペインターモジュール３１０を使用して）地図画像を作図することに必要である全ての構成データを含む、拡張性文書記述言語（ＸＭＬ）でフォーマットされたテキストファイルとして実現される。この開示に照らして明白であろうように、タイル作成手段３０５を実行するための他のフォーマットおよび解決策も同じく使用できよう。

明らかにしたように、タイル作成手段３０５は、地図ペインターモジュール３１０を使用して構成ファイルに定義された領域についての地図画像を作図する。１つの特定の場合には、地図の作図は、興味のある点（ＰＯＩ）および住所等の地理的特徴、道路と鉄道線路、都市、公園等の特徴の点、線、および領域を定義するベクターデータから目標の領域（例えば、米国中西部もしくはサンフランシスコ市、またはどこか他の地理的領域）のビットマップ画像を生成するプロセスである。領域が大きい場合、地図ペインターモジュール３１０が作図し、作図した地図画像全体をメモリに格納することは非実用的であり、そのためタイル作成手段３０５は、領域をより小さい領域に分割でき、これらを一時に１つ作図できる。大きい領域に対するタイル生成を、本明細書で更に検討する。作図されている領域が単一の連続的な画像を構成することが望ましいから、この分割は問題につながり得る。何故なら、領域の異なる部分に対しての作図決定がこれらの部分の間の境界線で位置合わせしないことがあるからである。

１つの解決策は、図６を参照して更に検討するが、ラベルおよびその他の問題のある特徴に現在作図されている領域の内側でのみ全面的に作図されるように強制することである。この解決策は部分的に作図したラベルを防止するが、かかる特徴を配置するための可能性の範囲を限定するため、境界線に沿った地図画像の品質を低下させることがある。例として、２つの別々に作図された領域の間のような境界線を横断する道路には、別々に作図されたのでなければラベルが配置されたであろうよりずっと接近して、同じラベルが境界線の両側に配置されることがあろう。別の解決策は、図７を参照して更に検討するが、問題のある特徴を境界線に沿って配置するための決定を保存し、そこでそれに続く領域を作図する場合にこれらの決定を配慮することである。これは特徴を不都合な方式で境界線の両側に配置することを単に回避するように行われてもよいし、または特徴が境界線と無関係に配置されることを容認することもある（例えば、かかる特徴が境界線を横断することを容認することにより）。

領域を作図するために、タイル作成手段３０５は、地図ペインターモジュール３１０を使用でき、地図ペインターモジュール３１０へ作図されるべき領域、所望の縮尺比、含まれるべき地理的データセット、作図すべき特徴、およびかかる特徴の作図の仕方についての妥当な情報を中継する。応答では、地図ペインターモジュール３１０は対応するデジタル地図画像を返し、地図画像は、タイル作成手段３０５によってタイルに変えられ、サブ画素ビットマップ（もしくはいずれかのビットマップまたはベクターベースのフォーマット）等の所望のフォーマットでタイル記憶装置３００に格納される。

１つの特定の実施の形態では、１２８・１２８画素のタイルサイズが使用され、タイルはＧＩＦフォーマットで格納される。他の実施の形態は、２５６・２５６画素のタイルサイズを使用してもよく、ＧＩＦ、ＰＮＧ、ＴＩＦＦ、またはＪＰＥＧフォーマットのいずれかで格納される。それぞれの特定の実現様態の要件次第で、他のタイルサイズおよび画像格納フォーマットも、使用されてもよい。これらのタイルは一般的に規則正しい長方形のグリッドを形成し、この性質は１つの実施の形態でシステム実現を容易にする。しかし、クライアント側（例えば、コンピュータデバイス１０３）上での組み立てを容認するどのような形状およびサイズのタイルへの大きいラスタ画像のどのような他の分割も、また、本発明の効果を達成するために使用されてもよいことに留意されたい。

これまでに検討したように、ＲＭＥライブラリ３１５は、ＲＭＦ（リッチマッピングフォーマット）ファイルからのデータを照会することに使用できる市販の１つのソフトウェアである。ＲＭＥライブラリ３１５は、２つ以上の項目の地理的関係を関与させる情報を要求する空間的クエリーに対応している。クエリーの例は、「所与の領域内で該当する地図特徴は何か？」または「所与の領域内で該当する一定の閾値より高い優先レベルを有する地図特徴は何か？」である。空間的クエリーの結果は、地図画像そして究極的に地図タイルを生成することに使用される。ＲＭＦファイルは、他の地図フォーマットをＲＭＦへコンパイルすることで生成される。このプロセスの恩恵は、ＲＭＦファイルにコンパイルできるあらゆる種類の地図データファイルフォーマットが、ＲＭＥライブラリ３１５を通して一貫性のある様式で照会できることにある。ファイルフォーマットおよびライブラリのどのような組み合わせも説明したシステムに使用できるが、唯一の要件は、所与の領域に対する地理的データを入手するために地図ペインターモジュール３１０が使用できるサービスが存在することに留意されたい。

地図データ記憶装置３２０は、ディスク上に格納された地理的地図データであり、それはＲＭＥライブラリ３１５によってアクセスされる。１つの実施の形態では、格納された地図データは、Telcontar社（デジタル地図およびナビゲーション情報の商用プロバイダ）によって１セットのＲＭＦ（リッチ地図フォーマット）ファイルにコンパイルされた市販のNavTechデータを備える。ＲＭＦは、空間的クエリーの処理のために最適化された従来の地図データフォーマットである。従って、一旦空間的にフォーマットされたデータセットにある項目が見付かると、すぐ近くの他の項目も比較的容易に見付けられる。しかし、地図データを記憶装置３２０内で編成することには、順次または層状等の多くの他の方式が存在することに留意されたい。使用する厳密なファイル／データセットは、タイル作成手段３０５の実行を制御することに使用した構成ファイルによって定義できる。どのような出所の地図データもここで置換でき、ＲＭＥライブラリ３１５および地図データ記憶装置３２０は、地図ペインターモジュール３１０が使用できるＡＰＩを持つ１つのシステムであることができよう。代替で、ＲＭＥライブラリ３１５およびＡＰＩの機能性は、地図ペインターモジュール３１０の中へ統合されてもよい。他の構成が本明細書の開示に照らして明白であろう。

大きい領域に対するタイル生成
先に指摘したように、予め描画するプロセスは、（幾つかの事例では）利用可能なメモリ量の関係で描画プロセスよりずっと大きい領域をカバーできる。図３のシステムによって実践されるタイル生成プロセスへの改良が、大きい領域（例えば、米国およびカナダの大陸）についてタイル生成を実施可能にするように成され得る。１つの実施の形態では、構成ファイルで定義された全てのタイルの生成のためのプロセスは、以下のとおりに進行する。

第１に、タイル作成手段３０５は、作図される必要がある全ての領域および作図される必要がある種々のズームレベルを調べて、領域を様々なズームレベルで必要であるサブ領域に分割し、それによりそれぞれのサブ領域は所与のメモリ量で予め描画できる。決定は所与の領域に対する実際のデータに基づくことができる。代替で、このステップをできる限り短くするために、サブ領域に対する固定のサイズ、またはそれぞれのズームレベルに対する固定のサイズが使用できる。ズームレベルでのサブ領域のそれぞれが、それ自体のタスクになり、領域およびズームレベルで定義され、一覧表に格納され、そして多大の数のタイル作成手段３０５がこれらのタスクを実行することへ適用できる（例えば、並列処理を使用して）。

これらのサブ領域の間の境界線を横切る問題を回避するために、予め描画するプロセスは、問題のある特徴がこれらの境界線を横断しないことを確実でき、それによってそれぞれのサブ領域が予め描画されることを可能にし、その後に独立して全面的に描画される（図６）。代替で、１つの予め描画するプロセス中に成された決定が保存でき、それでそれらはその後の予め描画タスクにおいてアクセスでき、それにより特徴はサブ領域の間の境界線を横断できる（図７）。これは、２つの整列するサブ領域を同時に予め描画されることを回避するため、幾らかの調整を必要とする（多数のタイル作成手段３０５が配所される並列処理スキームを想定して）。

タイル作成手段３０５がタスクの１つを一覧表から取る場合に、それは、サブ領域をタスクによって定義されたズームレベルで予め描画し、次いでサブ領域を利用可能なメモリ内で描画するのに足りる小さい描画領域に分割する。タイル作成手段３０５は、そこで一時に１つの描画領域を描画することへ進行し、結果として得られる画像をタイルに切り分け、そしてタイルをタイル記憶装置３００に収納する。１つの特定の実施の形態では、描画は、要望の解像度の４倍で行われ、結果として得られるビットマップは、タイルをサブ画素ビットマップとして生成するための入力として使用されるが、他のサイズおよびフォーマットが、所望の出力次第で使用できる。それらの配置についての全ての決定は予め描画するプロセス中に行われるので、ラベル等の特徴は描画領域の間の境界線を横断できることに留意されたい。サブ領域がメモリ内で予め描画されおよび描画されることの両方で十分に小さくされる場合、ラベル等の特徴を配置する上で制約を強いる境界線との間の距離は少なく、結果として得られる地図は、一般的に品質が劣ることにも留意されたい。

（例えば、タイルの境界線を横切る）途切れた特徴のない連続的な地図を描出するタイルを生成するための既に述べた方策に加えて、特徴の配置についての決定は、一定の半径の外側のどのようなものもラベルの配置に影響することがないような方式で、その半径内の地図データのみに基づいて成されることができる。かかるシステムでは、予め描画され描画されている領域がサブ領域を越えた（サブ領域の外側の半径までの）地図データにアクセスできる限り、ラベル等の特徴が横断することができない境界線を識別する必要はないかもしれない。予め描画するコードの充分な改良および十分に大きい半径により、かかるシステムは、これまでに説明した方法と比べても品質において遜色ない結果を生成できるかもしれない。都市または湖等の領域をラベル付ける場合、予め描画するプロセスは、地図データから特徴全体を読み込むことができ、ラベルを配置する処を決定する特徴のみを使用できる。これは、かかるラベルまたは同様な特徴の配置についての決定は、隣接のサブ領域についても同じであることを意味し、それでこれらの特徴は境界線を横断することを容認され得る。

タイルベースのマッピングシステムの課題と解決策
以下は、図４から図７を参照して、これまでに説明した連続性技法の適用例を解説する。

マッピングシステムの実施の形態は大きい領域（例えば、国、大陸、または地球でさえもの規模）を扱うことがあるから、一時に全面的領域のビットマップへのアクセスを有することは、実用的でないことがある。この課題に対処するために、これまでに明らかにしたように、全面的領域をより小さいサブ領域に分割し、一時に１つのサブ領域に対するタイルを生成することが望ましいことがある。全面的地図画像の中にエラーを導入することなくこれを行うために、１つの実施の形態はタイルおよびサブ領域にわたる連続性の課題に対処する。図４は、普通のラベル配置問題を示し、ここでは地図ラベル（「Main Street」）が地図タイルの境界（サブ領域の境界線と称する）を横断し、その一方で、図５は、それぞれのサブ領域が独立して作図される場合に出現することがある問題を示す。

図６は、本発明の実施の形態に従って、図４および図５に示す問題に対する解決策を示し、ここでは地図ラベルは地図タイルの境界を横断することを容認されない。この手法は、サブ領域の間の境界線を横切る問題を引起すことができよう特徴が予め描画するプロセス中に配置されることを確実にし、それにより地図におけるエラーを解消するかそうでなければ低減する。

例として、道路または鉄道線路に対する名前ラベルは、予め描画するプロセス中に配置され、そのため、それらはこれらのサブ領域の境界線を横断せず、最終的な地図が（例えば、図５に示すような）一部のみそこにあるラベルを持たないことを確実にする。都市または湖等の領域に対するラベルは、かかる特徴の形状のみに依存して配置できる。これは、かかるラベルを配置するために、特徴の一部が他のサブ領域にある場合でさえ、ラベル付けされる特徴全体が取り出されなくてはならず、ラベルが全面的領域の形状に基づいて配置されなくてはならない。重なり合ったラベルの出現を最少限にすることを追求するシステムでは、領域ラベルは、道路および鉄道線路等の他の特徴に対するラベルの前に配置されるべきであり、それによりこれらの他の特徴が１つのサブ領域において領域ラベルに影響を及ぼすことはない。何故なら、これらの影響は隣接するサブ領域での地図を作図している作図プロセスへは不明であろうし、それ故に領域ラベルの厳密な同一の配置はもはや保証されないからである。

図７は、本発明の別の実施の形態に従って、図４および図５に示す問題に対する解決策を示し、ここでは地図タイルの境界を横断する地図ラベルは２つの部分にわたり作図される。この解決策は、それぞれのサブ領域に対する予め描画するプロセス中に成された決定を格納し、同じ特徴（またはその一部分）を含む領域だけでなく、これまでに作図した領域における特徴およびラベルの配置についての情報に基づいて特徴およびラベルを移動させるかもしれない隣接する領域を作図するためのその後のプロセスへ決定を利用可能にすることによって実現できる。

かかる事例では、地図作成モジュール(例えば、図３に示す地図ペインターモジュール３１０)は、サブ領域の境界線を考慮することなくラベルを（例えば、道路上に）配置できる。これは、かかる境界線を横断するラベルが、隣接するサブ領域に対する作図プロセスに保存され利用可能であるためである。隣接するサブ領域は、横断しているラベルの配置に関する情報を受信し、その配置をそれ自体として使用し、それによりラベルは再度作図され、隣接するサブ領域にあるラベルの一部はその場所につき生成されたタイルに含まれる。この手法は、サブ領域の境界線の異なる側のタイルが境界線を横切って延びる特徴およびラベルを有することができる性質を容易にし、それによって特徴およびラベルの配置のプロセスがサブ領域の境界線を無視することを容認する。

同じ手法が、経路標識および領域ラベルの配置へ適用できる（そしてそれはラベル付けされている領域全体を調べるという以前に述べた方法と組み合わされてもよい）。道路へ割り当てられた高低（高さで順番付けた）を有する交差する道路の作図の仕方に関する予め描画する決定は、同様に行うことができる。かかる高低を持つ道路の事例では、１セットの交差する道路を取巻く領域が、それが隣接する道路と独立していると見なされるような方式で確定され、この領域に対する決定が行われ、保存され、そのため、その決定は隣接するサブ領域、特に、高低に関して隔離されていると見られる領域と共用しているサブ領域の作図のために利用可能である。

種々の市販ベンダから入手可能な地図データは、適用範囲と品質で大いに異なることが多い。高品質である地図を達成するために、多数の出所からのデータを組み合わせることが必要なことがある。例えば、１つのセットのデータは空港領域および空港の滑走路の最も詳細な輪郭線を有することがあるであろうし、その一方で、別のセットは空港ラベルが配置できる箇所および空港の行き帰りのドライブ道案内を生成するために使用されるべき個所についての情報を有することがあろう。多数の地図データセットの長所を生かすために、地図ペインターモジュール３１０は、ただ１つのセットのデータだけからでなく、様々なセットの情報を様々な出所から取得するように構成されてもよい。

多数のズームレベルでタイルとして利用可能な大きい連続的な地図という概念は、地図領域が多数の国および大陸でさえもカバーする場合にも魅力的である。重ねて、かかるシステムは、作図している地図をサブ領域に分割すること、および様々な国について利用可能な地図タイルセットにアクセスすることについてこれまでに説明した方法を使用して実現されてもよい。これは、例えば、ただ米国の地図だけの代わりに、北アメリカ大陸全体または地球全体でさえにも対するあらゆる種類のズームレベルで単一の切れ目のない地図が生成できることを意味する。

タイル供給
タイル供給は、この開示に照らして明白であろうように、多数の方式で実現できる。１つの手法は、それぞれのタイルにファイル名を与え、それを個々のファイルとして格納する。タイルは、そこでサーバ上に収納でき、サーバはローカルでまたはネットワークの上でリクエストによってタイルを利用可能にする。ウェブベースのシステムについて、このサーバは、それぞれのタイルを緯度、経度、およびズームレベルに従い名前付けるＨＴＴＰサーバであってもよい。この手法は、特にタイルの数が非常に多くなり得るので、供給システムに幾らかの負担をかけることがある。

供給システムが多大の数のタイルによって引起された負担を軽減するように組み立てできる多くの方式が存在する。例えば、地図タイルを求めるリクエストを受信するシステムは、全面的なセットのタイルまたはそのサブセットをそれぞれが含む１つ以上の効率的な記憶媒体（例えば、ローカルキャッシュ）へのアクセスを有していてもよく、次いで記憶媒体からタイルを取り出し、それをリクエストに応答して中継することができる。

図８は、本発明の実施の形態に従って構成された地図タイル供給システムのブロック図である。この構成の例は、図１のタイル供給システム１１５を実現することに使用できるが、記憶装置システムの一部が故障した場合にシステムを良好に応答させようと努め、大きいセットのタイルおよび大量のトラフィックを取り扱うこともできる。

図示のように、タイル供給システムは、タイルフロントエンド（ＴＦＥ）およびタイルバックエンド（ＴＢＥ）の２種類のタイルサーバを含む。これらのサーバは内部ネットワークまたは他の媒体の上で通信してもよい。システムの外側から（例えば、外部ネットワーク経由で）来るタイルに対するリクエストは、負荷分散スキームを実現するリクエスト分配サブシステムによりＴＦＥ間で均等に分配される。関与したＴＦＥは、そこで適切なＴＢＥから地図タイルを要求し、それを要求している当事者へ返す。

１つの可能性のある実施の形態では、タイルの全ては、それぞれのＴＢＥのディスク記憶装置設備（例えば、記憶装置２２０、それは、タイル記憶装置３００であってもよい）に格納されてもよい。ここでは、ディスク記憶装置設備が使用され、タイルがＴＦＥによって要求されるたびに、タイルを含む８・８ブロックにある６４タイルの残りもディスクから読出され、それがＴＢＥのメモリキャッシュ（例えば、主メモリ２１０）にあるとかなり予期できる。この実施の形態はタイルの８・８ブロックを使用し、それにより合計６４の隣接するタイルを同じズームレベルで提供できる。他の実施の形態は、他のブロック寸法（例えば、Ｎ・ＮまたはＭ・Ｎ）を使用できる。

従って、同じＴＢＥからの同じ８・８ブロックにあるタイルに対するその後のどのようなリクエストも、８・８ブロックがより最近のリクエストによってメモリキャッシュから排除されていなければ、ディスクアクセスの必要性なく、従って、より効率的に取り扱いできる。排除された場合、要求されたタイルはディスクから読出しでき、８・８ブロックは、再度メモリキャッシュに収納されてもよい。従って、ＴＢＥのメモリキャッシュのサイズと頻繁にアクセスされるタイルに対するリクエストの量との間のバランスが配慮される場合、リクエストは高い比率でメモリキャッシュから取り扱いでき、それぞれのＴＢＥをより効率的にする。

１つの実施の形態では、ＴＦＥは、ＴＢＥ間でリクエストを分配することに使用されてよく、それにより不当に数多くのＴＢＥを使用することなく、できる限りメモリキャッシュからのように供給間で合理的にバランスを取る方式で機能してよく、その一方で、なお全面的なタイルセットを効率的に供給できる。メモリキャッシュから供給するタイルの比率を増大させるために、ＴＦＥの全てに所与のタイル（例えば、または８・８セットのタイル）に対するリクエストを同じＴＢＥへ向けさせることが望ましいことがあるか、および／または、ＴＢＥ上の負荷が均等に分配されることが望ましいことがあり、それによりそれぞれのＴＢＥからより全面的に便益を得る。

例として、２０のＴＢＥがあり、それぞれが総体的地図の１／２０をキャッシュに格納する能力があることを想定する。従って、地図データを求めるどのような１つのリクエストも対応するＴＢＥによってキャッシュメモリを使用して処理できよう。１つのＴＢＥが故障した場合、その負荷は残存する１９のＴＢＥ間で分配できる。かかる事例では、それぞれの残存するＴＢＥのキャッシュメモリは、故障したＴＢＥの負荷のその分担を含むように（「学習」の期間の後に）結局増えることになろう。

これらの機能は、１つの実施の形態でそれぞれのＴＦＥ上で同じハッシュ関数を使用することで実現されてもよい。ハッシュ関数は、所与のタイルを要求するＴＢＥの番号を返す（または、その番号を演算することに使用できる）。１つの実施の形態でタイルは８・８のブロックでメモリに格納されているから、ブロックにあるそれぞれのタイルは同じＴＢＥから要求されるべきである。この実現様態では、それぞれのタイルは、緯度および経度に基づいたｘおよびｙ値、ならびにタイルが作図されたズームレベルを表すｚ値で順次に番号付けられてよい。１つの実施の形態では、ブロックは、同様に、ブロックが含むタイルのｘおよびｙ値の対のいずれもにつき８で整数除算した結果にそのｘおよびｙが等しくなるように番号付けられてもよい。従って、ハッシュ関数は、１つの実施の形態で、Hash(x div 8, y div 8, z)と記述できる。Hash(x div 8, y div 8, z) MOD Nで、ＮはシステムにあるＴＢＥの数であるので、ハッシュ関数によって返される値は、そこで、使用するＴＢＥに対応する番号を計算することに使用されてもよい。

このハッシュ関数手法は、一旦システムが適度のサイズに達して、個々のタイル間での負荷の分配の仕方についての知見がない場合に、タイル供給システム上で負荷を均等に分配する補助を行ってもよい。しかし、この手法は、ＴＢＥの１つが機能を停止した場合にシステムを支障なく機能させる課題に対処しない。

この課題に対処するために、１つの実施の形態で別の入力、具体的には、ＴＢＥからタイルを取り出すときに成される試行回数が、ハッシュ関数へ加えられてよい。この実施の形態では、ハッシュ関数は、Hash(x div 8, y div 8, z, #attempts)と記述されてもよい。従って、ＴＦＥがタイルをＴＢＥから取り出すその第１試行で失敗した場合、ＴＦＥは、#attemptの開始値（例えば、０または１）へ１を加えることで#attemptを増大させてよく、そこでハッシュ関数を再度実行させてもよく、ここではタイルに対してＴＦＥを次のＴＢＥに行かせる。このプロセスは、タイルが取り出しされるか、#attemptが事前設定の閾値、普通にはシステムにあるＴＢＥの数より大幅に大きい数に到達するまで繰り返されてもよい。

この手法は数多くの利点を提供する。具体的には、ＴＢＥが止まった場合、通常ならそれが供給するタイルは、ハッシュ関数によって分配され、残存するＴＢＥによって代わりに供給されることになる。これはＴＦＥまたはＴＢＥの間の連絡なしに起こり得る、そして総体的システムの応答時間にほとんど影響を与えないこともある。更にシステムを強化するために、１つの実施の形態で、システム内を動き回る失敗したリクエストの数を限定するように、ＴＦＥは、故障したＴＢＥへのリクエストを短時間の間スキップするか、または故障したＴＢＥへのリクエストの固定数をスキップするか、またはその幾つかの組み合わせをすることがある。

システムは、また、多数のＴＢＥの故障も取り扱うことがあり、短い遅滞の後に、ＴＢＥが再度作働を開始した後にまたは置き換えられた後に、故障したＴＢＥの使用を開始することもある（以前に述べた失敗したリクエストを低減するための時間法または計数法が実現された場合）。また、例えば、合計Ｎ台のＴＢＥを持つシステムは、これらのＴＢＥのＭ台が故障した場合、失敗した試行によって引起された応答時間の少しの増大を除き、一定時間の後に安定化し、Ｎ−Ｍ台のＴＢＥのみでシステムとして機能できる。負荷分散スキームを持つ多くのフェイルオーバーは、ここに説明した原理に基づいて明白であろう。

地図描画プロセスで生成されたタイルは、単一色を有するタイルの比率を多く含むことがある。普通には、この状況は、水域、陸地、公園、都市、構内、および他のかかる領域のために使用される色で発生することがある。同じ単一の色を自体の中に有するタイルは同一であるから、ＴＢＥ上で必要である記憶量は、１つの実施の形態でこれらのタイルを個々に格納しないことで大いに低減されることがある。幾つかの実現様態では、これは、そうでなければ必要とされる記憶スペースの９０＋％を節約することがある。

１つの実施の形態でシステムがこれらの単色タイルを供給できるようにするために、作成されたそれぞれのタイルについての情報を含む指標が作成されてもよい（例えば、タイルは、通常のタイル、特定色の単色タイル、破損したタイル、または行方不明のタイルであるかもしれない）。かかる指標は、１つの実現様態でＴＦＥに格納されてよく、単色タイルが要求される場合にはいつもＴＦＥがクライアントへ正しい色のタイルを送ることを容認する。これらの汎用の単色タイルは、ＴＦＥ上のメモリキャッシュに（例えば、主メモリ２１０に）格納されてもよく、それらの供給をできる限り効率的にする。指標は、また、ＴＢＥマシン上に格納されてもよく、その事例では汎用のタイルはＴＢＥからＴＦＥへ配信され、そこで要求している当事者へ中継されることになろう。

別の実施の形態では、単色タイルに関する情報は、全面的に、地図領域の一部のためか、または単一タイルのため、のいずれかでクライアント側に存在してもよい。指標がシステムの供給部分に存在する場合、供給部分は情報を求めるリクエストに応答してもよく、そしてクライアントは、クライアントが現在表示している領域に対する情報を単に要求し、情報を使用して単色タイルを要求することを回避する。別の実施の形態は、ＴＦＥが（またはＴＦＥを通してＴＢＥが）、タイルを求めるリクエストに、タイルで、ではなくて、要求されたタイルがある種の色のみを含み、従って受信する側の汎用タイルで置き換えできるという情報を返すことで応答することを容認する。いずれのかかる事例でも、ＴＢＥまたはＴＦＥは、遠隔のコンピュータデバイスにローカルで利用可能である単色地図タイルを使用させ、それによりかかるタイルは供給される必要がない。この開示に照らして明白であろうように、作図された地図中のフルセットのタイル内の単色タイルについての知見に基づいて最適化を実現する幾つかの方式が存在する。

本発明の実施の形態の前述の説明は、図示と説明の目的で提示された。網羅的であることや、開示したまさにその形態に本発明を限定することは意図していない。多くの改変および変形が、この開示に照らして可能である。本発明の範囲は、この詳細な説明によってではなく、この文書に添付の特許請求の範囲によって限定されることを意図している。

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

Claims (10)

1. １以上のサーバーコンピュータによって実行される、タイルベースのデジタルマッピング方法であって、
   デジタル地図画像から地図タイルを生成することと、
   前記地図タイルを格納することと、
   ユーザの地図リクエストに応答して、前記地図タイルの１つ以上を供給することと、
   を備え、
   前記地図タイルの１つ以上を供給することは、ユーザのコンピュータデバイスがローカルに利用可能な２種類以上の単色地図タイルを識別することと、該ユーザのコンピュータデバイスがローカルに利用可能な該単色地図タイルは供給しないようにすることを含むことを特徴とする方法。
2. 地図タイルが生成されるべき領域およびズームレベルを定義することを含む前記デジタル地図画像を生成することを、更に備える請求項１の方法。
3. 前記デジタル地図画像を生成することは、更に、使用する地理的データセットの少なくとも１セット、およびラベル配置情報を含む地図の作成方法を定義することを含む、請求項２の方法。
4. 前記地図タイルを格納することは、前記生成された地図タイルを所望の画像フォーマットにコード化することと、前記フォーマット付の地図タイルを格納することとを含む、請求項１の方法。
5. 前記所望の画像フォーマットは、サブ画素ビットマップである、請求項４の方法。
6. 前記地図タイルの１つ以上を供給することは、前記供給された地図タイルをキャッシュに格納することを含む、請求項１の方法。
7. デジタル地図画像から地図タイルを生成することは、
   作図されるべき領域、および各領域が作図される必要がある種々のズームレベルを特定することと、
   前記特定された領域を前記特定された種々のズームレベルで必要に応じてサブ領域に分割することと、該分割は、各サブ領域が利用可能なメモリ内で予め描画され得るようになされるものであり、
   前記各サブ領域を所与のズームレベルで予め描画することと、
   前記予め描画した各サブ領域を描画領域に分割することと、該分割は、各描画領域が前記利用可能なメモリ内で描画され得るようになされるものであり、
   前記描画領域を描画し、結果として得られた画像を地図タイルに分割することと、
   を含む請求項１の方法。
8. ズームレベルでの前記サブ領域のそれぞれは、タスクを表し、それにより領域およびズームレベルによって定義されるタスクの一覧表を提供し、並列処理がこれらのタスクを実行することへ適用される、請求項７の方法。
9. 前記要求しているユーザへ表示されるべき前記地図は解像度を有し、前記描画は表示されるべき前記地図の前記解像度よりＮ倍大きい解像度で行われ、前記描画によって生成されるビットマップはタイルをサブ画素ビットマップとして生成するための入力として使用される、請求項７の方法。
10. 地図タイルをデジタル地図画像から生成することは、
    作図されるべき領域を特定することと、
    前記領域をサブ領域に分割することと、該分割は、それぞれのサブ領域が利用可能なメモリ内で予め描画され得るようになされるものであり、
    前記各サブ領域を予め描画することと、
    前記予め描画した各サブ領域を描画領域に分割することと、該分割は、各描画領域が前記利用可能なメモリ内で描画され得るようになされるものであり、
    前記描画領域を描画することと、
    を含む請求項１の方法。

Images