JP7086180B2 - デジタルマップの動的リスタイリング - Google Patents

Description

本開示は、対話型デジタルマップに関し、より詳細には、ナビゲーションルートに関係するマップ特徴をデジタルマップ上で動的にリスタイリングすることに関する。

本明細書で提供する背景技術の説明は、本開示のコンテキストを概括的に提示することを目的とする。この背景技術のセクションで説明する限り、現在指名されている発明者の作業ならびに出願の時点で先行技術として特に資格が与えられない可能性がある説明の態様は、明示的にも暗示的にも本開示に対する先行技術として認められない。

様々な地理的アプリケーションがコンピューティングデバイス上に表示する対話型デジタルマップは、概して、道路、国および町の輪郭、水域、建物、関心ポイント(POI)など、多数の地理的特徴またはマップ特徴を示す。これらの地理的特徴またはマップ特徴のうちのいくつかは、状況によって異なって示されることがある。たとえば、通常青線で示される道路は、渋滞を示すために赤でレンダリングされることがあり、または国境は、地理的クエリに応じて強調表示されることがある。

加えて、様々な地理的アプリケーションは、段階的なナビゲーション順路(navigation directions)を生成する。一般に、サーバは、ナビゲーションルートが強調表示される画像を生成する。サーバはまた、目的地を示すためのピンのロケーションを指定する。通信ネットワークを介して余剰データが送信されることを要求することに加えて、この手法は、しばしば、強調表示を生じさせ、ピンが重要なマップ特徴をあいまいにする。

デジタルマップディスプレイ内にナビゲーションルートを提示するために、動的マッピングシステムは、たとえば、道路、建物、公園、水域、POIなどの様々なマップ特徴に対して「最小」、「標準」、および「リッチ」など、複数の視覚的スタイルを利用する。ナビゲーションルートを示すために、動的マッピングシステムは、異なる視覚的スタイルを用いてマップ特徴をレンダリングすることによって、これらの特徴のセットを強調表示することができる。たとえば、マップ特徴の第1のセットは、目的地に対応する建物とともに、ナビゲーションルート内に含まれるいくつかの道路セグメントを含み得る。それに応じて、動的マッピングシステムは、より高い詳細レベル(LOD:level of detail)または視覚的特徴における他の差異を含み得るリッチスタイルで道路セグメントおよび建物をレンダリングする。たとえば、リッチスタイルの場合、システムは、中央に境界線を有する太線および境界線の両側に破線の2つのセットを用いて、道路セグメントをレンダリングし得る。システムは、立方体オブジェクトまたは矩形プリズム型オブジェクトなど、3次元(3D)または2.5Dオブジェクトとして建物をレンダリングし得る。

加えて、動的マッピングシステムは、いくつかの実施形態では、ナビゲーションルートに関係しないデジタルマップディスプレイ内のマップ特徴の第2のセットを識別する。システムは、ナビゲーションルートに関係しないマップ特徴の第2のセットを強調表示解除し、リッチスタイルでレンダリングされたマップ特徴の第1のセットとの対比を示すために、より低い詳細レベルを含み得る最小スタイルでマップ特徴の第2のセットをレンダリングし得る。たとえば、最小スタイルの場合、システムは、細線を用いて道路セグメントをレンダリングし得る。システムは、細線を用いて2次元の正方形または矩形オブジェクトとして建物をレンダリングし得る。

さらに、システムは、デフォルト詳細レベルを含み得る標準スタイルでデジタルマップディスプレイ内にマップ特徴の第3のセットをレンダリングし得る。たとえば、標準スタイルの場合、システムは、最小スタイルで使用される細線よりも太く、リッチスタイルで使用される太線よりも細い中間線を用いて道路セグメントをレンダリングし得る。システムは、建物が***して見えるように、最小スタイルで建物をレンダリングするために使用される線よりも太い線を用い、かつ影を用いて、2次元の正方形または矩形オブジェクトとして建物をレンダリングし得る。

このように、システムは、ピンまたはオーバーレイアイコンを用いてナビゲーションルートの目的地を示す必要がなく、代わりに、目的地をリッチスタイルで強調表示することができる。その上、サーバは、ナビゲーションルートを強調表示するためにオーバーレイを生成する必要がなく、代わりに、サーバは、異なる視覚的スタイルでいくつかのマップ特徴をレンダリングする命令をクライアントデバイスに単に提供することができるか、別の実装形態では、ナビゲーションルートの記述をクライアントデバイスに単に提供することができ、クライアントデバイスは、次に、ナビゲーションルートの受信された記述に基づいて、強調表示するためのマップ特徴を選択することができる。

本開示の技法の1つの例示的な実施形態は、ナビゲーション順路をデジタルマップ上に示すための方法である。この方法は、地理的エリアのデジタルマップ内に含まれるマップ特徴をデフォルト詳細レベルで提供することを含む、デジタルマップを生成するステップと、地理的エリア内に位置する目的地までのナビゲーションルートを取得するステップとを含む。この方法は、地理的エリア内に位置しナビゲーションルートに関係する物理的エンティティに対応する第1の複数のマップ特徴を識別するステップと、第1の複数のマップ特徴を高い詳細レベルで再レンダリングするステップを含む、修正されたデジタルマップを生成するステップであって、修正されたデジタルマップが、高い詳細レベルよりも低い詳細レベルで表示されるマップ特徴を含む、生成するステップとをさらに含む。

本開示の技法の別の例示的な実施形態は、ナビゲーション順路をデジタルマップ上に示すためのサーバデバイスである。このサーバデバイスは、1つまたは複数のプロセッサと、1つまたは複数のプロセッサに結合され、命令を記憶した非一時的コンピュータ可読メモリとを含む。これらの命令は、1つまたは複数のプロセッサによって実行されると、サーバデバイスに、地理的エリアのデジタルマップ内に含まれるマップ特徴をデフォルト詳細レベルで提供することを含む、デジタルマップを生成することと、地理的エリア内に位置する目的地までのナビゲーションルートを取得することとを行わせる。これらの命令はさらに、サーバデバイスに、地理的エリア内に位置しナビゲーションルートに関係する物理的エンティティに対応する第1の複数のマップ特徴を識別することと、第1の複数のマップ特徴を高い詳細レベルで再レンダリングすることを含む、修正されたデジタルマップを生成することであって、修正されたデジタルマップが、高い詳細レベルよりも低い詳細レベルで表示されるマップ特徴を含む、生成することとを行わせる。

本開示の技法のさらなる例示的な実施形態は、ナビゲーション順路をデジタルマップ上に示すためのクライアントデバイスである。このクライアントデバイスは、1つまたは複数のプロセッサと、1つまたは複数のプロセッサに結合され、命令を記憶した非一時的コンピュータ可読メモリとを含む。これらの命令は、1つまたは複数のプロセッサによって実行されると、クライアントデバイスに、デフォルト詳細レベルで提示されるマップ特徴を含む地理的エリアのデジタルマップを表示させ、地理的エリア内に位置する目的地までのナビゲーション順路の要求を受信させる。これらの命令はさらに、クライアントデバイスに、地理的エリア内に位置し目的地までのナビゲーションルートに関係する物理的エンティティに対応する第1の複数のマップ特徴の記述を取得させ、第1の複数のマップ特徴を高い詳細レベルでデジタルマップ内に表示させ、他のマップ特徴を高い詳細レベルよりも低い詳細レベルでデジタルマップ内に表示させる。

マップ特徴を動的にリスタイリングするための技法が実装され得る、1つの例示的なシステムのブロック図である。 図1の動的マッピングシステムがマップ特徴をレンダリングするために利用し得る視覚的スタイルをグラフによって示す、1つの例示的なスタイルテーブルである。 リッチスタイルでレンダリングされたナビゲーションルートに関係するマップ特徴を備えたナビゲーションルートを含む、1つの例示的なマップディスプレイを示す図である。 標準スタイルでレンダリングされたマップ特徴を備えた別の例示的なマップディスプレイを示す図である。 リッチスタイルでレンダリングされたいくつかのマップ特徴と、最小スタイルでレンダリングされる他のマップ特徴とを備えたさらに別の例示的なマップディスプレイを示す図である。 サーバデバイス内で実装され得る、ナビゲーション順路をデジタルマップ上に提供するための1つの例示的な方法の流れ図である。 クライアントデバイス内で実装され得る、ナビゲーション順路をデジタルマップ上に示すための1つの例示的な方法の流れ図である。

概説
本開示は、クライアントデバイスおよび/またはネットワークサーバによって、一定のマップ特徴の視覚化を選択的に修正することによって、デジタルマップを効率的に再生成するための技法を提供する。これは、新しい画像を生成するか、またはナビゲーションルートを強調表示するためにオーバーレイを提供する必要性、ならびにロケーションを指定するためにピンまたは他のオーバーレイアイコンを提供する必要性をなくす。本開示は、マップ特徴の視覚化を選択的に修正し、それにより、帯域幅要件および処理オーバーヘッドを低減するために特に効率的な機構を提供する。

具体的には、このシステムは、道路、建物、公園、水域、POIなど、様々なマップ特徴に対して複数の視覚的スタイル、たとえば、「最小」、「標準」、および「リッチ」を利用し得る。これらの視覚的スタイルは、ベクトルグラフィックスフォーマット(vector graphics format)で、または点およびそれらの点を結ぶ経路の数学的記述を使用して幾何学的形状を指定するための別の好適なフォーマットで定義されるマップ特徴のジオメトリに適用され得る。便宜上、そのようなフォーマットのうちのいずれか1つに適合するデータは、「ベクトルデータ」と呼ばれる。より具体的には、ベクトルデータは、様々な幾何学的形状を(たとえば、数学的記述を使用して)指定し、様々なマップ特徴をレンダリングするためにこれらの形状がどのように配置されるべきかを指示することができ、スタイルデータは、ベクトルデータに適用され得る様々な視覚的スタイルに対して、線の太さ(たとえば、本明細書で「pt」と呼ばれる画素の幅)、線の色、1つまたは複数の塗りつぶしの色(fill color)、1つまたは複数の形状またはフラフィックス、影の色、影の濃度などとして、そのような視覚的特性または属性を記述することができる。ネットワークサーバおよび/またはクライアントデバイスは、異なる視覚的スタイルを一定のマップ特徴に選択的に適用して、ナビゲーションルートまたはマップ特徴のセットを強調表示および強調表示解除することができる。いくつかの実施形態では、ネットワークサーバは、クライアントデバイスがマップ特徴の様々なベクトルベースの記述(本明細書でベクトル記述子または単にベクトルとも呼ばれる)に対してどの視覚的スタイルを適用すべきかを指定することもできる。

より詳細な例として、サーバは、ナビゲーションルート内に含まれる道路セグメントを視覚的に強調表示し、ナビゲーションルート内にない道路セグメントを強調表示解除し、残りの特徴をデフォルト(標準)詳細レベルで残すようにクライアントデバイスに命令することができる。サーバは、探索クエリに応じてマップ特徴のセットを視覚的に強調表示するようにクライアントデバイスに命令することもできる。ナビゲーションルートまたは探索クエリに関係するマップ特徴のセットは、概して、1つまたは複数のタイプ(たとえば、道路セグメント、建物、公園)のうちの一定の数の特徴、ならびに関連するラベルを含み得る。

1つの例示的な実施形態では、クライアントデバイスは、デジタルマップ内に含まれるマップ特徴に関する複数の視覚的スタイルに関する定義をネットワークサーバから受信し、ローカルメモリ内に記憶する。クライアントデバイスは、一定の地理的エリアに関するマップ特徴のすべてを、当初、標準スタイルで表示することができる。ナビゲーションルートを示すために、サーバは、クライアントデバイスがどのマップ特徴をリッチスタイルで再レンダリングすべきか、また(場合によっては)クライアントデバイスがどのマップ特徴を最小スタイルで再レンダリングすべきかを指定する。

別の例示的な実施形態では、サーバは、当初、標準スタイルのみと併せてマップ特徴を提供する。ナビゲーションルートを示すために、サーバは、この場合、様々なマップ特徴に対するリッチスタイルの記述、ならびに、どのマップ特徴がこれらのスタイルで再レンダリングされるべきかを示す指示を提供する。

例示的なハードウェア構成要素およびソフトウェア構成要素
図1を参照すると、上記で概説した技法が実装され得る、1つの例示的な通信システムは、クライアントコンピューティングデバイス10(本明細書において「クライアントデバイス」とも呼ばれる)を含む。クライアントデバイス10は、たとえば、スマートフォンまたはタブレットコンピュータなど、ポータブルデバイスであり得る。クライアントデバイス10は、ラップトップコンピュータ、デスクトップコンピュータ、または携帯情報端末(PDA)であってもよい。クライアントデバイス10は、第4世代セルラーネットワークまたは第3世代セルラーネットワーク(それぞれ、4Gまたは3G)など、ワイヤードまたはワイヤレスの通信ネットワーク32を介して、様々なコンテンツプロバイダ、サーバなどと通信することもできる。クライアントデバイス10は、タッチスクリーンなどのディスプレイ28を含み得る。ディスプレイは、テキスト入力を入力するためのソフトウェアキーボードを含み得る。加えて、クライアントデバイス10は、グラフィックス処理装置(GPU)16、1つまたは複数のプロセッサまたはCPU12、GPSモジュール14、メモリ20、および3Gセルラーネットワーク、4Gセルラーネットワーク、または任意の他の好適なネットワークを介してデータを送信および受信するためのセルラー通信ユニット18を含む。

メモリ20は、たとえば、オペレーティングシステム24、および動的マップレンダリングエンジン26の命令をマッピングアプリケーション22の一部として記憶し得る。動的マップレンダリングエンジン26は、マップ特徴をスタイリングするためのスタイルテーブル42などのスタイルデータを受信し、デジタルマップディスプレイ内に記憶することができる。さらに、動的マップレンダリングエンジン26は、目的地までのナビゲーション順路(navigation directions)をスタイルコントローラ38から受信することができ、ここで、ナビゲーション順路は、ナビゲーションルートに関係するマップ特徴の第1のセットを含む。動的マップレンダリングエンジン26は、スタイルデータ内に含まれるスタイルのうちの1つに従って、マップ特徴の第1のセットをレンダリングし得る。ともに、動的マップレンダリングエンジン26およびスタイルコントローラ38は、動的マッピングシステムを形成し得る。

ソフトウェア構成要素22、24、および26は、コンパイルされた命令および/または命令を実行時に解釈可能な任意の好適なプログラミング言語で含み得る。いずれの場合も、ソフトウェア構成要素22、24、および26は、1つまたは複数のプロセッサ12上で実行する。

マッピングアプリケーション22は、概して、異なるそれぞれのオペレーティングシステムに対する異なるバージョンで提供され得る。たとえば、クライアントデバイス10のメーカは、Android(商標)プラットフォーム用のマッピングアプリケーション22を含むSoftware Development Kit(SDK)、iOS(商標)プラットフォーム用の別のSDKなどを提供することができる。

クライアントデバイス10は、長距離ワイヤレス通信リンク(たとえば、セルラーリンク)を介してインターネットなどの広域通信ネットワーク32に対するアクセスを有する。クライアントデバイス10は、セルラー通信ユニット18を介して通信ネットワーク32にアクセスすることができる。図1の例示的な構成では、クライアントデバイス10は、ナビゲーションデータを提供するナビゲーションサーバ33、および(たとえば、ベクトルグラフィックスフォーマットで)マップデータを生成するマップデータサーバ36と通信する。

いくつかの実装形態では、マップデータサーバ36は、メモリ37と1つまたは複数のプロセッサ39とを含む。メモリ37は、有形の非一時的メモリであってよく、ランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、フラッシュメモリ、他のタイプの永続メモリなどを含めて、任意のタイプの好適なメモリモジュールを含み得る。メモリ37は、いくつかの視覚的スタイルを生成し、視覚的スタイルを動的マップレンダリングエンジン26に、たとえば、スタイルテーブル64内に提供するスタイルコントローラ38を構成するプロセッサ39上に実行可能な命令を記憶する。

スタイルコントローラ38は、様々なスタイルに関する視覚的特性を指示するスタイルテーブル64を利用し、いくつかの実施形態では、それを管理し得る。スタイルテーブル64として使用され得るスタイルテーブルの1つの例示的な実装形態については、図2を参照してより詳細に論じる。一実施形態では、スタイルコントローラ38は、スタイルのうちのどれがクライアントデバイス10において様々なマップ特徴に適用されるべきかを判定するためにスタイルテーブル64を使用し、クライアントデバイス10に対して適切な指示を生成する。

いくつかの実施形態では、ユーザは、マッピングアプリケーション22を介して地理的エリアに関するマップデータを要求する。それに応じて、クライアントデバイス10は、その要求をマップデータサーバ36に提供し、マップデータサーバ36は、次に、地理的エリアに関するマップデータをマップデータベース40から取り出す。マップデータは、いくつかのマップ特徴を含んでよく、これらのマップ特徴は、たとえば、道路、建物、公園、POI、水域、町の境界、および他の地理的エンティティを表す2次元形状および3次元形状であり得る。スタイルコントローラ38はまた、マップ特徴に適用されることになる視覚的スタイルの記述を、たとえばスタイルテーブル64から取り出す。

スタイルコントローラ38は、次いで、視覚的スタイルの記述をマップデータとともにクライアントデバイス10に提供し、動的マップレンダリングエンジン26は、それぞれの視覚的スタイルに従って、マップ特徴をレンダリングし、レンダリングされたマップ特徴を含むデジタルマップディスプレイを提示する。いくつかの実施形態では、スタイルコントローラ38は、マップ特徴をレンダリングするために使用されるデフォルト視覚的スタイルを提供する。たとえば、スタイルコントローラ38は、デフォルト詳細レベルに対応する標準スタイルを動的マップレンダリングエンジン26に提供し、動的マップレンダリングエンジン26は、標準スタイルに従って、マップ特徴の各々をレンダリングする。

他の実施形態では、スタイルコントローラ38は、いくつかの視覚的スタイル(たとえば、最小スタイル、標準スタイル、およびリッチスタイル)の記述を動的マップレンダリングエンジン26に提供し、動的マップレンダリングエンジン26は、各マップ特徴をレンダリングするための適切なスタイルを判定する。さらに他の実施形態では、スタイルコントローラ38は、いくつかの視覚的スタイル(たとえば、最小スタイル、標準スタイル、およびリッチスタイル)の記述を、マップ特徴の各々に適用するための視覚的スタイルの指示とともに動的マップレンダリングエンジン26に提供する。たとえば、スタイルコントローラ38は、各マップ特徴をスタイリングする命令を提供すること(たとえば、ナビゲーションルートに関係するマップ特徴の第1のセットをリッチスタイルでレンダリングすること、ナビゲーションルートに関係しないマップ特徴の第2のセットを最小スタイルでレンダリングすることなど)が可能である。

マッピングアプリケーション22を介してマップデータサーバ36に提供された、目的地までのナビゲーション順路の要求に応じて、スタイルコントローラ38は、目的地までのナビゲーションルートをナビゲーションサーバ33から取り出すか、またはオフラインデータを使用して局所的にナビゲーションルートを生成する。次いで、スタイルコントローラ38は、ナビゲーションルートに沿った道路セグメントのセット、目的地に対応する建物、POIなど、地理的エリア内に位置しナビゲーションルートに関係する物理的エンティティに対応するマップ特徴の各々を識別する。次いで、スタイルコントローラ38は、ナビゲーションルートに関係するマップ特徴の記述をマップ特徴の第1のセットとしてクライアントデバイス10に提供する。たとえば、マップ特徴の記述は、道路ジオメトリの記述を含み得る。いくつかの実施形態では、動的マップレンダリングエンジン26は、次いで、リッチスタイルを使用してマップ特徴の第1のセットを再レンダリングすることによって、修正されたデジタルマップを生成する。

他の実施形態では、スタイルコントローラ38は、リッチスタイルに関するスタイルデータおよび/またはリッチスタイルを使用してマップ特徴の第1のセットを再レンダリングするための動的マップレンダリングエンジン26に対する命令とともに、ナビゲーションルートに関係するマップ特徴をマップ特徴の第1のセットとしてクライアントデバイス10に提供する。

修正されたデジタルマップは、リッチスタイルに対応する高い詳細レベルよりも低い詳細レベルで表示されるマップ特徴も含む。より具体的には、いくつかの実施形態では、スタイルコントローラ38は、ナビゲーションルートに関係しないマップ特徴をマップ特徴の第2のセットとしてクライアントデバイス10に提供する。動的マップレンダリングエンジン26は、次いで、最小スタイルを使用して、マップ特徴の第2のセットを再レンダリングし、標準スタイルを使用して、残りのマップ特徴を再レンダリングすることによって、修正されたデジタルマップを生成する。具体的には、ナビゲーション順路の要求は、スタイルデータがクライアントデバイス10においてすでに利用可能であるスタイル(たとえば、スタイルテーブル内に記憶されたスタイル)を指定し得る。クライアントデバイス10がリッチスタイルまたは最小スタイルに関するスタイルデータをまだ受信していない場合、マップデータサーバ36は、対応するスタイルデータを提供する。

他の実施形態では、動的マップレンダリングエンジン26は、最小スタイルを使用して、デジタルマップディスプレイ内に含まれ、マップ特徴の第1のセット内にないマップ特徴の各々を再レンダリングする。さらに他の実施形態では、スタイルコントローラ38は、最小スタイルに関するスタイルデータおよび/または最小スタイルを使用してマップ特徴の第2のセットを再レンダリングするための動的マップレンダリングエンジン26に対する命令とともに、ナビゲーションルートに関係しないマップ特徴をマップ特徴(たとえば、ナビゲーションルートに関係するマップ特徴のしきい距離内のマップ特徴)の第2のセットとしてクライアントデバイス10に提供する。また別の実施形態では、スタイルコントローラ38は、適切なスタイルに従ってマップ特徴の各々をレンダリングし、レンダリングされたマップ特徴をクライアントデバイス10に、たとえば、ラスタ画像の形で提供する。

スタイルコントローラ38および/または動的マップレンダリングエンジン26は、任意の好適な距離および/または関連性ベースの方式に従って、ナビゲーションルートまたは探索クエリに関係するマップ特徴を識別することができる。たとえば、ナビゲーションルートの生成時に、スタイルコントローラ38は、ナビゲーションルートを構成する道路セグメント、およびそのルートから一定の距離(たとえば、20メートル)範囲内の各構造(たとえば、建物、橋、トンネル)を識別し、リッチスタイルを使用してレンダリングされることになるマップ特徴のセット内に識別された道路セグメントおよび構造を含めることができる。場合によっては、スタイルコントローラ38は、そのルートから一定の距離(たとえば、50メートル)範囲内の(サイズ、視程、近くの構造との色の対比の点で測定された)一定のしきい値***のマップ特徴ランドマークをマップ特徴のこのセット内に含めることもできる。さらに、場合によっては、スタイルコントローラ38は、一定のしきい値人気の関心ポイントをマップ特徴のこのセット内に含めることができる。

さらに、スタイルコントローラ38および/または動的マップレンダリングエンジン26は、クライアントデバイス10の現在のロケーションまたは別の好適な信号に基づいて、デジタルマップ上で強調表示されることになるマップ特徴のセットのコンテンツを動的に変更することができる。より具体的な例として、動的マップレンダリングエンジン26は、リッチスタイルを使用して、ナビゲーションルートに沿って移動しているクライアントデバイス10の現在のロケーションの一定の半径内にマップ特徴をレンダリングし、標準スタイルを使用して、ナビゲーションルートの他の部分に関連するマップ特徴をレンダリングし、最小スタイルを使用して、ナビゲーションルートに関係しないマップ特徴をレンダリングすることができる。このようにして、クライアントデバイス10は、そのルートに沿って非常に詳細なマップ特徴の「バブル」内で移動するように見える。

メモリ37、または別のサーバ内のメモリは、マップデータを生成する、またはナビゲーション順路を生成することをナビゲーションサーバ33に求める、命令を記憶することもできる。

より一般的には、クライアントデバイス10は、任意の数の好適なサーバと通信し得る。たとえば、別の実施形態では、提案サーバ34は、部分的なユーザ入力に基づいて提案を生成し、トラフィックデータサーバは、ルートに沿った最新交通情報を提供し、天候データサーバは、天候データおよび/または警告を提供する、などである。

簡潔にするために、図1は、データベースの単なる一例としてマップデータベース40を示している。しかしながら、いくつかの実装形態によるマップデータベース40は、異なる情報を各々が記憶する、1つまたは複数のデータベースのグループを含む。加えて、図1は、サーバの単なる一例としてマップデータサーバ36を示している。しかしながら、いくつかの実装形態によるマップデータサーバ36は、1つまたは複数のプロセッサを各々が備え、他のマップデータサーバとは無関係に動作することが可能な、1つまたは複数のマップデータサーバのグループを含む。そのようなグループ内で動作しているマップデータサーバは、クライアントデバイス10からの要求を、個々に(たとえば、可用性に基づいて)、要求の処理に関連する1つの動作が1つのマップデータサーバ上で実行され、同じ要求の処理に関連する別の動作が別のマップデータサーバ上で実行される分散様式で、または任意の他の好適な技法に従って、処理することができる。この議論のために、「マップデータ」という用語は、個々のマップデータサーバまたは2つ以上のマップデータサーバのグループを指すことがある。

図2は、様々なタイプのマップ特徴に関する視覚的スタイルをグラフで示す1つの例示的なスタイルテーブル200を示す。より具体的には、この例におけるスタイルテーブル200は、3つの視覚的スタイル、すなわち、最小スタイル210、標準スタイル220、およびリッチスタイル230を含む。特定の視覚的スタイルに対して、スタイルテーブル200は、マップ特徴の各タイプに関する視覚的属性または構成パラメータのセットを含む。たとえば、最小スタイル210の場合、建物210aに関する構成パラメータのセットは、(たとえば、1ptの線の太さを有する)細線を備えた2次元の正方形オブジェクトを含む。最小スタイルの建物210aに関する塗りつぶしの色は白であり、輪郭色はライトグレーであり、影はない。標準スタイル220の場合、建物220aに関する構成パラメータのセットは、(たとえば、2ptの線の太さを有する)より太い線を備えた2次元の正方形オブジェクトを含む。標準スタイルの建物220aに関する塗りつぶしの色は白であり、輪郭色はライトグレーであり、ライトグレーの影がある。リッチスタイル230の場合、建物230aに関する構成パラメータのセットは、3次元の立方体または矩形のプリズム型グラフィックであり、上面に三角形を有し、白である塗りつぶしの色、ライトグレーの輪郭色、標準スタイルの建物220aよりも大きい、濃い影を有する。

別の例では、最小スタイル210の場合、道路210bに関する構成パラメータのセットは、ダークグレーの線の色を有する(たとえば、1ptの線の太さを有する)細線を含む。標準スタイル220の場合、道路220bに関する構成パラメータのセットは、ダークグレーの線の色を有する(たとえば、3ptの線の太さを有する)より太い線を含む。リッチスタイル230の場合、道路230bに関する構成パラメータのセットは、中央に白い境界線があり、境界線の両側に白の破線の2つのセットがあり、ダークグレーである塗りつぶしの色を有する、(たとえば、5ptの線の太さを有する)さらに太いライングラフィックを含む。

例示的なスタイルテーブル200に示すように、リッチスタイル230は、最高詳細レベルを有し、標準スタイル220は、中程度またはデフォルトの詳細レベルを有し、最小スタイル210は、低い詳細レベルを有する。このように、デジタルマップディスプレイは、リッチスタイル230のマップ特徴(たとえば、ナビゲーションルートに関係するマップ特徴)を強調表示し、最小スタイル210のマップ特徴を強調表示解除するために、リッチスタイル230でレンダリングされたマップ特徴と最小スタイル210またはさらに標準スタイル220でレンダリングされたマップ特徴との間に著しい対比を提示する。スタイルテーブル200は建物および道路を含む2つのタイプのマップ特徴に関する視覚的スタイルを示すが、これらはスタイルテーブル200内に含まれ得る例示的なマップ特徴タイプにすぎない。スタイルテーブル200は、公園、POI、水域、町の境界、および他の地理的エンティティなど、追加のマップ特徴タイプに関する視覚的スタイルを含んでもよい。さらに、各視覚的スタイルに関する構成パラメータのセットおよびマップ特徴タイプは、構成パラメータの1つの例示的なセットにすぎない。マップ特徴タイプおよび視覚的スタイル(たとえば、最小スタイルの建物)は、特定のマップ特徴タイプに関して、最小スタイルが最低詳細レベルを有し、標準スタイルが中程度またはデフォルトの詳細レベルを有し、リッチスタイルが最高の詳細レベルを有するように、任意の好適な構成パラメータを含み得る。構成パラメータのセットは、たとえば、特定の線の太さ、特定の塗りつぶしの色、特定の輪郭色、特定の形状またはグラフィック、特定の影の色、特定の影の濃度などを含み得る。

したがって、いくつかの実装形態では、最小スタイル、標準スタイル、およびリッチスタイルの記述は、OpenGLなどのグラフィックスパイプラインが同じジオメトリに適用される視覚的属性(たとえば、色、線の太さ、ストロークタイプ)の記述のみを含む。他の実装形態では、最小スタイル、標準スタイル、およびリッチスタイルの記述は、より簡単なスタイルでレンダリングされるマップ特徴に追加されることになる追加のジオメトリの記述を対応する視覚的属性とともに含む。

いくつかの実施形態では、図1に示したスタイルコントローラ38は、各視覚的スタイルに関する構成パラメータのセットおよびマップ特徴タイプを含むスタイルテーブル200を生成し、適切な視覚的スタイルに従ってマップ特徴をレンダリングするためにスタイルテーブル200を動的マップレンダリングエンジン26に提供する。たとえば、動的マップレンダリングエンジン26は、ナビゲーションルートなしにマップ特徴を標準スタイル220でデジタルマップ内にレンダリングするように構成され得る。表示すべきナビゲーションルートが存在するとき、動的マップレンダリングエンジン26は、ナビゲーションルートに関係するマップ特徴をリッチスタイル230でデジタルマップ内にレンダリングし、ナビゲーションルートに関係しないマップ特徴を最小スタイル210でレンダリングするように構成され得る。他の実施形態では、ナビゲーションルートが存在するとき、動的マップレンダリングエンジン26は、ナビゲーションルートに関係するマップ特徴をリッチスタイル230でデジタルマップ内にレンダリングし、ナビゲーションルートに関係するマップ特徴のしきい距離内のマップ特徴を最小スタイル210でレンダリングし、残りのマップ特徴を標準スタイル220でレンダリングするように構成され得る。さらに他の実施形態では、スタイルコントローラ38は、各マップ特徴をデジタルマップ内にレンダリングするための適切な視覚的スタイルを記述する命令を動的マップレンダリングエンジン26に提供し得る。

例示的なマップディスプレイ
図3は、Fancy Pizzaレストランを含む建物310である目的地までのナビゲーションルート304a、304bを含む1つの例示的なマップディスプレイ300を示す。マッピングアプリケーション22は、クライアントデバイス10のディスプレイ28を介して例示的なマップディスプレイ300を提示することができる。この例では、ナビゲーションルートは、Fancy Pizzaレストランを含む建物310までユーザをナビゲートするための道路セグメント304a、304bを含む。したがって、動的マッピングシステムは、ナビゲーションルートに関係するマップ特徴として、道路セグメント304a、304b、および建物310を識別する。動的マッピングシステムは、これらの特徴を、図2に示したようにリッチスタイル230でレンダリングする。この例では、動的マッピングシステムは、道路セグメント312および公園308など、残りのマップ特徴を、図2でも示したように最小スタイル210でレンダリングする。マップディスプレイ300は、ナビゲーションルートに沿ったユーザの現在のロケーション302の指示、およびそのルートに沿った交通を示すオーバーレイ306も含む。クライアントデバイス10はナビゲーションルートに対応するオーバーレイをデジタルマップ上に表示しないが、トラフィックデータなどの他の情報は、リッチスタイル230でレンダリングされる道路セグメント304aの部分を赤色でオーバーレイするなど、強調表示で示されてよい。

図4は、ナビゲーションルートを含まない別の例示的なマップディスプレイ400を示す。たとえば、マッピングアプリケーション22は、ユーザが、マッピングアプリケーション22を開始するとき、または特定の地理的エリアを閲覧するためのデジタルマップをパンするときまたはそこにズームするとき、ディスプレイ28を介してマップディスプレイ400を提示することができる。例示的なマップディスプレイ400では、道路セグメント402a、402b、408、建物406、および公園404などのマップ特徴は、図2に示したように、標準スタイル220で出現する。たとえば、図3において最小スタイル210で提示された公園308と比較して、公園404は、濃い緑の塗りつぶしの色、より太い線、およびより濃い輪郭色を有する。その上、図3において最小スタイル210で提示された道路セグメント312と比較して、道路セグメント408は、より太い線を有する。さらに、図3においてリッチスタイル230で提示された建物310と比較して、建物406は、3次元ではなく2次元であり、より小さな、薄い影を有する。

図5は、ナビゲーションルートを含まないさらに別の例示的なマップディスプレイ500を示す。例示的なマップディスプレイ500では、動的マッピングシステムは、公園504をリッチスタイル230で提示し、残りのマップ特徴502a、502b、506、508は、図2に示したように最小スタイル210である。たとえば、動的マッピングシステムは、ユーザがマッピングアプリケーション22内の探索結果として公園504を選択するとき、ディスプレイ28を介してマップディスプレイ500を提示することができる。動的マッピングシステムは、次いで、公園のロケーションにおいてデジタルマップ上にピンを提示する代わりに、公園504をリッチスタイル230でレンダリングする。加えて、動的マッピングシステムは、公園504がユーザに身近なロケーションであり、インジケータ510によって示されるようにユーザの現在のロケーションのしきい距離内にあるとき、ユーザのカレンダーによれば、ユーザが公園504において近く予定されている試合またはイベントがあるとき、またはマップディスプレイ500内で公園504を強調表示する何らかの他の好適な理由があるとき、マップディスプレイ500を生成することができる。いずれの場合も、標準スタイル220で提示される公園404と比較して、公園504は、緑の矩形オブジェクトではなく、サッカーフィールドグラフィックを含む。

マップ特徴を動的にリスタイリングするための例示的な方法
図6は、デジタルマップ上にナビゲーション順路を提供するための1つの例示的な方法600の流れ図を示す。この方法は、コンピュータ可読メモリ上に記憶され、サーバデバイス36の1つまたは複数のプロセッサにおいて実行可能な命令のセット内で実装され得る。たとえば、この方法は、スタイルコントローラ38によって実装され得る。

ブロック602において、たとえば、クライアントデバイス10上で動作しているマッピングアプリケーション22から地理的エリアに関するマップデータに対する要求を受信する。その要求に応じて、地理的エリアに関するマップデータが、たとえば、図1に示したようなマップデータベース40から取り出される。マップデータは、いくつかのマップ特徴を含んでよく、これらのマップ特徴は、たとえば、道路、建物、POI、公園、水域、町の境界、および他の地理的エンティティを表す、2次元形状および3次元形状であってよい。いくつかの実施形態では、マップ特徴は各々、ベクトルグラフィックスフォーマットで、または点および点を結ぶ経路の数学的記述を使用して幾何学的形状を指定するための別の好適なフォーマットで記述されるジオメトリを有し得る。ベクトルデータは、概して、クライアントデバイスが、歪みなしに、形状をスケーリングし、回転させ、場合によっては、それに対して動作することを可能にする。たとえば、ラインセグメントのラスタ画像を構成する各画素を指定するのではなく、ベクトルデータは、ラインセグメントの2つの終点の座標を指定し、それらの2つの終点が直線によって結ばれていることを指示し得る。いずれの場合も、サーバデバイス36は、地理的エリア内のマップ特徴をクライアントデバイス10に提供する(ブロック604において)。

地理的エリア内のマップ特徴をクライアントデバイス10に提供することに加えて、マップデータサーバ36は、マップ特徴に適用可能な視覚的スタイルを生成し、視覚的スタイルの記述をクライアントデバイス10に提供する(ブロック606)。たとえば、マップデータサーバ36は、3つの視覚的スタイル、すなわち、最小スタイル、標準スタイル、およびリッチスタイルを生成することができる。各視覚的スタイルは、いくつかのマップ特徴タイプ(たとえば、道路、建物、POI、公園、水域、町の境界、他の地理的エンティティなど)の各々に対する構成パラメータのセットを含み得る。構成パラメータのセットは、たとえば、特定の線の太さ、特定の塗りつぶしの色、特定の輪郭色、特定の形状またはグラフィック、特定の影の色、特定の影の濃度などを含み得る。視覚的スタイルは、図2に示したスタイルテーブル200と同様のスタイルテーブル内でクライアントデバイス10に提供され得る。したがって、クライアントデバイス10は、適用可能な視覚的スタイルに従って、マップ特徴をレンダリングするためにスタイルテーブルのローカルコピーを記憶する。

各マップ特徴に関して、クライアントデバイス10は、マップ特徴に関するジオメトリ、および構成パラメータの特定のセットを有するマップ特徴をレンダリングするための視覚的スタイルを受信することができる。たとえば、道路セグメントの場合、クライアントデバイス10は、直線によって結ばれたラインセグメントの2つの終点の座標を受信することができる。標準スタイルの場合、クライアントデバイス10は、3ptの線の太さおよびダークグレーの線の色を含む、道路セグメントに関する構成パラメータのセットを受信することができる。

クライアントデバイス10は、次いで、ラインセグメントが、特定の色、幅などを含む、適用可能な視覚的スタイルで表示されるように、スタイルデータを指定されたラインセグメントに適宜に適用することができる。別の例として、ベクトルデータは、三角形の外形を指定することができ、対応するスタイルデータは、外形線の色、外形線の幅、および三角形の内部領域の色を指定することができる。言い換えれば、マップデータサーバ36からラスタ画像を受信するのではなく、クライアントデバイス10は、ディスプレイ28上にマップ画像を描写する命令を受信し、ラスタマップ画像を生成する命令を実行することができる。場合によっては、しかしながら、ベクトルデータは、ベクトルフォーマットで容易に表すことができない一定のコンポーネント要素としてラスタ画像を含んでもよい。

いくつかの実施形態では、マップデータサーバ36は、各マップ特徴をスタイリングする命令をクライアントデバイス10に提供し、クライアントデバイス10は、それらのそれぞれのスタイルに従って、マップ特徴をマップディスプレイ内にレンダリングする。他の実施形態では、マップデータサーバ36は、特定のマップ特徴に適用可能な視覚的スタイルのみを提供する。たとえば、デジタルマップがナビゲーションルートを含まないとき、マップ特徴は、標準スタイルでレンダリングされてよく、マップデータサーバ36は、標準スタイルのみをクライアントデバイス10に提供する。

いずれの場合も、ブロック608において、目的地までのナビゲーション順路の要求を、たとえば、クライアントデバイス10上で動作しているマッピングアプリケーション22から受信する。ナビゲーション順路の要求に応じて、マップデータサーバ36は、目的地までのナビゲーションルートをナビゲーションサーバ33から取り出す。マップデータサーバ36は、次いで、ナビゲーションルートに沿った道路セグメントのセット、目的地に対応する建物など、ナビゲーションルートに関係するマップ特徴の各々を識別する(ブロック610)。

次いで、マップデータサーバ36は、ナビゲーションルートに関係するマップ特徴をマップ特徴の第1のセットとしてクライアントデバイス10に提供する(ブロック612)。たとえば、マップデータサーバ36は、クライアントデバイス10に前に送信され、マッピングアプリケーション22によってデジタルマップ内に提示されたマップ特徴の指示またはそれらに対する参照を提供することができる。より具体的には、各マップ特徴は、マップ特徴を一意に識別する特徴IDを有し得る。マップ特徴の記述を再度クライアントデバイス10に送信するのではなく、マップデータサーバ36は、マップ特徴の第1のセット内に含まれたマップ特徴に対する参照として特徴IDを提供することができる。いくつかの実施形態では、クライアントデバイス10は、次いで、リッチスタイルを使用してマップ特徴の第1のセットを再レンダリングする。

他の実施形態では、マップデータサーバ36は、リッチスタイルに関するスタイルデータとともに(ブロック614)および/またはリッチスタイルを使用してマップ特徴の第1のセットを再レンダリングするためのクライアントデバイス10に対する命令とともに、ナビゲーションルートに関係するマップ特徴をマップ特徴の第1のセットとしてクライアントデバイス10に提供する。具体的には、ナビゲーション順路の要求は、たとえば、クライアントデバイス10において利用不可能なスタイルを含めることによって明示的に、またはクライアントデバイスにおいてすでに利用可能なスタイル(たとえば、スタイルテーブル内に記憶されたスタイル)のリストを提供することによって暗示的に、スタイルを指定することができる。クライアントデバイス10がリッチスタイルに関するスタイルデータを受信していない場合、マップデータサーバ36は、対応するスタイルデータを提供する。

また、いくつかの実施形態では、マップデータサーバ36は、ナビゲーションルートに関係しないマップ特徴をマップ特徴の第2のセットとしてクライアントデバイス10に提供する。たとえば、マップデータサーバ36は、前に提供され、マッピングアプリケーション22によってデジタルマップ内に提示されたマップ特徴の指示またはそれらに対する参照を提供することができる。より具体的には、各マップ特徴は、マップ特徴を一意に識別する特徴IDを有し得る。マップ特徴をクライアントデバイス10に再度提供するのではなく、マップデータサーバ36は、マップ特徴の第2のセット内に含まれたマップ特徴に対する参照として特徴IDを提供することができる。クライアントデバイスは、次いで、最小スタイルを使用して、マップ特徴の第2のセットを再レンダリングし、標準スタイルを使用して、残りのマップ特徴を再レンダリングする。他の実施形態では、クライアントデバイス10は、最小スタイルを使用して、デジタルマップディスプレイ内に含まれ、マップ特徴の第1のセット内にないマップ特徴の各々を再レンダリングする。さらに他の実施形態では、マップデータサーバ36は、最小スタイルに関するスタイルデータとともに(ブロック614)および/または最小スタイルを使用してマップ特徴の第2のセットを再レンダリングするためのクライアントデバイス10に対する命令とともに、ナビゲーションルートに関係しないマップ特徴をマップ特徴の第2のセットとしてクライアントデバイス10に提供する。

他の実施形態では、マップデータサーバ36は、適切なスタイルに従って、マップ特徴の各々をレンダリングする。マップデータサーバ36は、次いで、マップタイル、すなわち、レンダリングされたマップ特徴を含む、一定のサイズ(たとえば、256×256画素)のマップ画像の一部分をクライアントデバイス10に提供する。

図7は、ナビゲーション順路をデジタルマップ上に示すための1つの例示的な方法700の流れ図を示す。この方法は、コンピュータ可読メモリ上に記憶され、クライアントデバイス10の1つまたは複数のプロセッサにおいて実行可能な命令のセット内で実装され得る。たとえば、この方法は、動的マップレンダリングエンジン26によって実装され得る。

ブロック702において、クライアントデバイス10は、道路、建物、POI、公園、水域、町の境界、および他の地理的エンティティを表す2次元形状または3次元形状であり得る、いくつかのマップ特徴を含む地理的エリアのデジタルマップを提示する。デジタルマップを提示するために、クライアントデバイス10は、ベクトルグラフィックスフォーマットで、または点およびそれらの点を結ぶ経路の数学的記述を使用して幾何学的形状を指定するための別の好適なフォーマットで記述される、マップ特徴の各々に関するジオメトリをサーバデバイスから受信することができる。他の実施形態では、クライアントデバイス10は、クライアントデバイスにおいて局所的に記憶されたオフラインマップデータからマップ特徴の各々に関するジオメトリを取り出す。

クライアントデバイス10は、マップ特徴に適用可能な視覚的スタイルの記述をサーバデバイスからやはり受信することができ(ブロック704)、ここで、各視覚的スタイルは、いくつかのマップ特徴タイプの各々に関する構成パラメータのセットを含む。たとえば、視覚的スタイルは、最小スタイル、標準スタイル、およびリッチスタイルを含み得る。各スタイルは、道路、建物、POI、公園、水域、町の境界、他の地理的エンティティなどに関する構成パラメータの異なるセットを有し得る。いくつかの実施形態では、クライアントデバイス10は、スタイルの各々、およびマップ特徴をレンダリングするための構成パラメータを含むスタイルテーブルを受信して記憶する。他の実施形態では、クライアントデバイス10は、デフォルト詳細レベルの標準スタイルなど、特定のスタイルに関する構成パラメータを受信し、デジタルマップをレンダリングするために、その特定のスタイルをマップ特徴に適用する(ブロック706)。

次いで、ブロック708において、目的地までのナビゲーション順路の要求を受信する。クライアントデバイス10は、マッピングアプリケーション22によって提示されるユーザ制御を介してその要求を受信することができる。たとえば、マッピングアプリケーション22を使用して、ユーザは、目的地を入力し、ユーザの現在のロケーションから目的地までの方向を要求するユーザ制御を選択する。クライアントデバイス10は、次いで、目的地までのナビゲーションルートを取得する。ナビゲーションルートは、ナビゲーションサーバ33から取得されてよく、またはクライアントデバイス10が、局所的に記憶されたオフラインナビゲーション順路を取り出してもよい。いずれの場合も、ナビゲーションルートに沿った道路セグメントのセット、目的地に対応する建物など、ナビゲーションルートに関係するマップ特徴の第1のセットを識別する(ブロック710)。マップ特徴の第1のセットは、ブロック702において提示されるデジタルマップ内に含まれるマップ特徴のサブセットであり得る。

クライアントデバイス10は、次いで、リッチスタイルを高い詳細レベルでマップ特徴の第1のセットに適用する(ブロック712)。クライアントデバイス10は、マップ特徴が標準スタイルからリッチスタイルまたは最小スタイルに再レンダリングされるように、最小スタイルを低い詳細レベルでデジタルマップ内の残りのマップ特徴にやはり適用し得る(ブロック714)。また、いくつかの実施形態では、クライアントデバイス10は、ナビゲーションルートに関係しないが、ナビゲーションルートに関係するマップ特徴のしきい距離内のマップ特徴の第2のセットを取得する。クライアントデバイス10は、次いで、最小スタイルをマップ特徴の第2のセットに適用し、標準スタイルをデジタルマップ内の残りのマップ特徴に適用する。

いくつかの実施形態では、マップデータサーバ36は、マップ特徴の第1または第2のセットをクライアントデバイス10に提供する。たとえば、マップデータサーバ36は、前に提供され、マッピングアプリケーションによってデジタルマップ内に提示されたマップ特徴の指示またはそれらに対する参照を提供することができる。より具体的には、各マップ特徴は、マップ特徴を一意に識別する特徴IDを有し得る。マップ特徴をクライアントデバイス10に再度提供するのではなく、マップデータサーバ36は、マップ特徴の第1または第2のセット内に含まれたマップ特徴の参照として特徴IDを提供することができる。いくつかの実施形態では、クライアントデバイス10は、次いで、リッチスタイルを使用して、マップ特徴の第1のセットを再レンダリングし、最小スタイルを使用して、マップ特徴の第2のセットを再レンダリングする。他の実施形態では、マップデータサーバ36は、リッチスタイルに関するスタイルデータとともに、マップ特徴の第1のセットをクライアントデバイスに提供し、最小スタイルに関するスタイルデータとともに、マップ特徴の第2のセットをクライアントデバイスに提供し、かつ/またはリッチスタイルを使用して、マップ特徴の第1のセットを再レンダリングし、最小スタイルを使用して、マップ特徴の第2のセットを再レンダリングするためクライアントデバイス10に対する命令を提供する。

追加要件
以下の追加の要件が前述の議論に適用される。本明細書を通して、複数の事例が、単一の事例として説明する構成要素、動作、または構造を実装することがある。1つまたは複数の方法の個々の動作を別個の動作として示し、説明しているが、個々の動作のうちの1つまたは複数は、同時に実行されてよく、示した順序で実行されることを必要とするものはない。例示的な構成において別個の構成要素として提示した構造および機能は、組み合わされた構造または構成要素として実装されてよい。同様に、単一の構成要素として提示した構造および機能は、別個の構成要素として実装されてよい。これらのおよび他の改変、修正、追加、および改善は、本開示の主題の範囲に該当する。

加えて、いくつかの実施形態は、本明細書において、論理またはいくつかの構成要素、モジュール、または機構を含むとして説明されている。モジュールは、ソフトウェアモジュール(たとえば、機械可読媒体上に記憶されるコード)またはハードウェアモジュールのいずれかを構成し得る。ハードウェアモジュールは、いくつかの動作を実行することが可能な有形ユニットであり、一定の様式で構成または配置され得る。例示的な実施形態では、1つまたは複数のコンピュータシステム(たとえば、スタンドアロン、クライアントコンピュータプログラムまたはサーバコンピュータシステム)またはコンピュータシステムの1つまたは複数のハードウェアモジュール(たとえば、プロセッサまたはプロセッサのグループ)は、本明細書で説明したようないくつかの動作を実行するように動作するハードウェアモジュールとしてソフトウェア(たとえば、アプリケーションまたはアプリケーション部分)によって構成され得る。

様々な実施形態では、ハードウェアモジュールは、機械的にまたは電子的に実装され得る。たとえば、ハードウェアモジュールは、いくつかの動作を実行するように(たとえば、フィールドプログラマブルゲートアレイ(FPGA)または特定用途向け集積回路(ASIC)などの専用プロセッサとして)永続的に構成される専用の回路または論理を含み得る。ハードウェアモジュールは、いくつかの動作を実行するようにソフトウェアによって一時的に構成される(たとえば、汎用プロセッサまたは他のプログラマブルプロセッサ内に包含されるような)プログラマブル論理またはプログラマブル回路を含んでもよい。ハードウェアモジュールを機械的に、専用に永続的に構成された回路内で、または一時的に構成された(たとえば、ソフトウェアによって構成された)回路内で実装する判定は、コスト要件および時間要件によって行われ得ることを諒解されよう。

したがって、ハードウェアという用語は、有形エンティティを包含し、本明細書で説明した、いくつかの様式で動作するように、またはいくつかの動作を実行するように、物理的に構築された、永続的に構成された(たとえば、ハードワイヤード)、または一時的に構成された(たとえば、プログラムされた)エンティティであると理解されるべきである。本明細書で使用する「ハードウェア実装モジュール」は、ハードウェアモジュールを指す。ハードウェアモジュールが一時的に構成される(たとえば、プログラムされる)実施形態を考慮すると、ハードウェアモジュールは各々、いずれかのある時点で構成またはインスタンス化されなくてよい。たとえば、ハードウェアモジュールが、ソフトウェアを使用して構成される汎用プロセッサを含む場合、汎用プロセッサは、異なる時点でそれぞれの異なるハードウェアモジュールとして構成され得る。ソフトウェアは、それに応じて、たとえば、ある時点で特定のハードウェアモジュールを構成し、異なる時点で異なるハードウェアモジュールを構成するようにプロセッサを構成し得る。

ハードウェアモジュールは、他のハードウェアに情報を提供し、他のハードウェアから情報を受信することができる。したがって、説明したハードウェアモジュールは、通信可能に結合されていると見なされ得る。そのようなハードウェアモジュールが複数同時に存在する場合、通信は、ハードウェアモジュールを接続する(たとえば、適切な回路およびバスを介した)信号送信を通して達成され得る。複数のハードウェアモジュールが異なる時点で構成またはインスタンス化される実施形態では、そのようなハードウェアモジュール同士の間の通信は、たとえば、複数のハードウェアモジュールがアクセスを有するメモリ構造内の情報の記憶および取出しを通して達成され得る。たとえば、1つのハードウェアモジュールは、動作を実行し、そのハードウェアモジュールが通信可能に結合されたメモリデバイス内にその動作の出力を記憶することができる。次いで、さらなるハードウェアモジュールが、後の時点で、メモリデバイスにアクセスして、記憶された出力を取り出して処理することができる。ハードウェアモジュールは、入力デバイスまたは出力デバイスとの通信を開始することもでき、リソース(たとえば、情報の収集物)に対して動作し得る。

方法600および700は、非一時的コンピュータ可読記憶媒体内に記憶され、コンピューティングデバイス(たとえば、サーバデバイス、パーソナルコンピュータ、スマートフォン、タブレットコンピュータ、スマートウォッチ、モバイルコンピューティングデバイス、または本明細書で説明した他のクライアントコンピューティングデバイス)のプロセッサを使用して実行される有形コンピュータ実行可能命令の形で、1つまたは複数の機能ブロック、モジュール、個々の機能またはルーチンを含み得る。方法600および700は、任意のバックエンドサーバ(たとえば、マップデータサーバ、ナビゲーションサーバ、または本明細書で説明したような、任意の他のタイプのサーバコンピューティングデバイス)の部分、たとえば、例示的な環境のクライアントコンピューティングデバイスモジュール、または、そのような環境の外部のモジュールの部分として含まれてよい。これらの図は、説明を容易にするために他の図を参照して説明されているが、方法600および700は、他のオブジェクトおよびユーザインターフェースとともに利用され得る。さらに、上記の説明は、方法600および700のステップが特定のデバイス(サーバデバイス36およびクライアントデバイス10など)によって実行されるとして説明しているが、これは、単に例示のためである。方法600および700のブロックは、1つまたは複数のデバイスまたはその環境の他の部分によって実行され得る。

本明細書で説明した例示的な方法の様々な動作は、関連動作を実行するように(たとえば、ソフトウェアによって)一時的に構成されるか、または永続的に構成された1つまたは複数のプロセッサによって少なくとも部分的に実行され得る。一時的に構成されるか、または永続的に構成されるかにかかわらず、そのようなプロセッサは、1つまたは複数の動作または機能を実行するように動作するプロセッサ実装モジュールを構成し得る。本明細書で参照するモジュールは、いくつかの例示的な実施形態では、プロセッサ実装モジュールを含み得る。

同様に、本明細書で説明する方法またはルーチンは、少なくとも部分的にプロセッサ実装され得る。たとえば、方法の動作のうちの少なくともいくつかは、1つまたは複数のプロセッサまたはプロセッサ実装ハードウェアモジュールによって実行され得る。動作のうちのいくつかの性能は、単一のマシン内にのみ存在するのではなく、いくつかのマシンにわたって展開される、1つまたは複数のプロセッサの間で分散されてよい。いくつかの例示的な実施形態では、1つまたは複数のプロセッサは、単一のロケーション内に(たとえば、ホーム環境内に、オフィス環境内に、またはサーバファームとして)位置してよく、他の実施形態では、プロセッサは、いくつかのロケーションにわたって分散されてよい。

1つまたは複数のプロセッサは、「クラウドコンピューティング」環境内でまたはSaaSとして、関連動作の性能をサポートするように動作することもできる。たとえば、上記で指示したように、動作のうちの少なくともいくつかは、(プロセッサを含むマシンの例として)コンピュータのグループによって実行されてよく、これらの動作は、ネットワーク(たとえば、インターネット)を介して、かつ1つまたは複数の適切なインターフェース(たとえば、API)を介してアクセス可能である。

またさらに、これらの図は、単なる例示のために、例示的な環境のいくつかの実施形態を示している。本明細書で説明した原理から逸脱せずに、本明細書で示した構造および方法の代替実施形態が採用され得ることを当業者は続く議論から容易に認識されよう。

本開示を読むと、本明細書で開示した原理を通して、マップ特徴を動的にリスタイリングするためのさらに追加の代替的な構造設計および機能設計を当業者は理解されよう。したがって、特定の実施形態および適用例を示し、説明したが、開示した実施形態は、本明細書で開示するまさにその構造および構成要素に限定されないことを理解されたい。添付の特許請求の範囲で定義する趣旨および範囲から逸脱せずに、本明細書で開示した方法および装置の配置、動作、および詳細に対して、当業者に明らかになるであろう様々な修正、変更、および改変が行われ得る。

10 クライアントコンピューティングデバイス、クライアントデバイス
12 プロセッサまたはCPU
14 GPSモジュール
16 グラフィックス処理装置(GPU)
18 セルラー通信ユニット
20 メモリ
22 マッピングアプリケーション、ソフトウェア構成要素
24 オペレーティングシステム、ソフトウェア構成要素
26 動的マップレンダリングエンジン、ソフトウェア構成要素
28 ディスプレイ
32 通信ネットワーク、広域通信ネットワーク
33 ナビゲーションサーバ
34 提案サーバ
36 マップデータサーバ、サーバデバイス
37 メモリ
38 スタイルコントローラ
39 プロセッサ
40 マップデータベース
42 スタイルテーブル
64 スタイルテーブル
200 スタイルテーブル
210 最小スタイル
210a 建物
210b 道路
220 標準スタイル
220a 建物
220b 道路
230 リッチスタイル
230a 建物
230b 道路
300 マップディスプレイ
302 ユーザの現在のロケーション
304a ナビゲーションルート、道路セグメント
304b ナビゲーションルート、道路セグメント
306 オーバーレイ
308 公園
310 建物
312 道路セグメント
400 マップディスプレイ
402a 道路セグメント
402b 道路セグメント
404 公園
406 建物
408 道路セグメント
500 マップディスプレイ
502a マップ特徴
502b マップ特徴
504 公園
506 マップ特徴
508 マップ特徴
600 方法
700 方法

Claims (20)

1. ナビゲーション順路をデジタルマップ上に示すための方法であって、
   1つまたは複数のプロセッサによって、前記デジタルマップを生成するステップであって、前記デジタルマップの生成が、地理的エリアのデジタルマップ内に含まれるマップ特徴をデフォルト詳細レベルで提供することを含む、ステップと、
   前記1つまたは複数のプロセッサによって、前記地理的エリア内に位置する目的地までのナビゲーションルートを取得するステップと、
   前記1つまたは複数のプロセッサによって、前記地理的エリア内に位置し前記ナビゲーションルートに関係する物理的エンティティに対応する第1の複数のマップ特徴を識別するステップと、
   前記1つまたは複数のプロセッサによって、修正されたデジタルマップを生成するステップであって、前記修正されたデジタルマップの生成が、前記第1の複数のマップ特徴を高い詳細レベルで再レンダリングすることを含み、前記修正されたデジタルマップが、低い詳細レベルで表示される第2の複数のマップ特徴を含み、前記第2の複数のマップ特徴が、前記ナビゲーションルートに関係しない物理的エンティティに対応し、前記デフォルト詳細レベルが、前記低い詳細レベルよりも高く、前記高い詳細レベルが、前記デフォルト詳細レベルよりも高く、前記低い詳細レベル、前記デフォルト詳細レベル、および前記高い詳細レベルの各々が、異なる視覚的スタイルに対応し、前記視覚的スタイルは、線の太さ、塗りつぶしの色、輪郭色、形状またはグラフィック、影の色、および影の濃度のうちの少なくとも1つを表示するための構成パラメータを含む、生成するステップと
   を含む、方法。
2. 前記第1の複数のマップ特徴が、前記ナビゲーションルート内に含まれる道路セグメントを含む、請求項1に記載の方法。
3. 前記1つまたは複数のプロセッサによって、前記ナビゲーションルート内に含まれない道路セグメントに対応する第2の複数のマップ特徴を識別するステップ
   をさらに含み、
   前記修正されたデジタルマップを生成するステップが、前記1つまたは複数のプロセッサによって、前記第2の複数のマップ特徴を前記低い詳細レベルで再レンダリングするステップを含む、請求項2に記載の方法。
4. 前記第1の複数のマップ特徴が、前記目的地に対応する建物をさらに含む、請求項2に記載の方法。
5. 前記ナビゲーションルートに対応するオーバーレイを前記デジタルマップ上に表示しないステップを含む、請求項1に記載の方法。
6. 道路ジオメトリの記述、および前記道路ジオメトリに適用可能な複数の視覚的スタイルのそれぞれの記述をネットワークサーバからクライアントデバイスに送信するステップであって、前記複数の視覚的スタイルが、前記低い詳細レベルに対応する、送信するステップをさらに含み、
   前記修正されたデジタルマップを生成するステップが、前記前に送信された視覚的スタイルのうちのどれが前記第1の複数のマップ特徴に適用されることになるかを示す指示を前記ネットワークサーバから前記クライアントデバイスに送信するステップを含む、請求項1に記載の方法。
7. 前記地理的エリアのマップデータに対する要求に応じて、前記地理的エリア内のマップ特徴の記述、および前記道路ジオメトリに適用可能な前記複数の視覚的スタイルのそれぞれの記述を前記ネットワークサーバから前記クライアントデバイスに送信するステップであって、前記複数の視覚的スタイルが、前記マップ特徴を前記デフォルト詳細レベルでレンダリングするための、前記低い詳細レベル、前記デフォルト詳細レベル、および前記高い詳細レベルに対応する、送信するステップと、
   前記目的地までのナビゲーション順路の要求に応じて、前記地理的エリア内に位置し前記ナビゲーションルートに関係する物理的エンティティに対応する前記第1の複数のマップ特徴の記述であって、前記第1の複数のマップ特徴を前記高い詳細レベルでレンダリングし、前記地理的エリア内の残りのマップ特徴を前記低い詳細レベルでレンダリングするための前記第1の複数のマップ特徴の記述を前記ネットワークサーバから前記クライアントデバイスに送信するステップと
   をさらに含む、請求項6に記載の方法。
8. 前記目的地に対応するオーバーレイアイコンを前記デジタルマップ上に表示しないステップを含む、請求項1に記載の方法。
9. ナビゲーション順路をデジタルマップ上に示すためのサーバデバイスであって、
   1つまたは複数のプロセッサと、
   前記1つまたは複数のプロセッサに結合され、命令を記憶した非一時的コンピュータ可読メモリと
   を含み、前記命令が、前記1つまたは複数のプロセッサによって実行されると、前記サーバデバイスに、
   前記デジタルマップを生成することであって、当該生成することが、地理的エリアのデジタルマップ内に含まれるマップ特徴をデフォルト詳細レベルで提供することを含む、生成することと、
   前記地理的エリア内に位置する目的地までのナビゲーションルートを取得することと、
   前記地理的エリア内に位置し前記ナビゲーションルートに関係する物理的エンティティに対応する第1の複数のマップ特徴を識別することと、
   修正されたデジタルマップを生成することであって、当該生成することが、前記第1の複数のマップ特徴を高い詳細レベルで再レンダリングすることを含み、前記修正されたデジタルマップが、低い詳細レベルで表示される第2の複数のマップ特徴を含み、前記第2の複数のマップ特徴が、前記ナビゲーションルートに関係しない物理的エンティティに対応し、前記デフォルト詳細レベルが、前記低い詳細レベルよりも高く、前記高い詳細レベルが、前記デフォルト詳細レベルよりも高く、前記低い詳細レベル、前記デフォルト詳細レベル、および前記高い詳細レベルの各々が、異なる視覚的スタイルに対応し、前記視覚的スタイルは、線の太さ、塗りつぶしの色、輪郭色、形状またはグラフィック、影の色、および影の濃度のうちの少なくとも1つを表示するための構成パラメータを含む、生成することと
   を行わせる、サーバデバイス。
10. 前記第1の複数のマップ特徴が、前記ナビゲーションルート内に含まれた道路セグメントを含む、請求項9に記載のサーバデバイス。
11. 前記命令がさらに、前記サーバデバイスに、
    前記ナビゲーションルート内に含まれない道路セグメントに対応する第2の複数のマップ特徴を識別させ、
    前記第2の複数のマップ特徴を前記低い詳細レベルで再レンダリングさせる、請求項10に記載のサーバデバイス。
12. 前記第1の複数のマップ特徴が、前記目的地に対応する建物をさらに含む、請求項10に記載のサーバデバイス。
13. 前記命令がさらに、前記サーバデバイスに、
    道路ジオメトリの記述、および前記道路ジオメトリに適用可能な複数の視覚的スタイルのそれぞれの記述をクライアントデバイスに送信することであって、前記複数の視覚的スタイルが、前記低い詳細レベルに対応する、送信することと、
    前記前に送信された視覚的スタイルのうちのどれが前記第1の複数のマップ特徴に適用されることになるかを示す指示を前記クライアントデバイスに送信することと
    を行わせる、請求項9に記載のサーバデバイス。
14. 前記命令がさらに、前記サーバデバイスに、
    前記地理的エリアのマップデータに対する要求に応じて、前記地理的エリア内のマップ特徴の記述、および前記道路ジオメトリに適用可能な前記複数の視覚的スタイルのそれぞれの記述を前記クライアントデバイスに送信することであって、前記複数の視覚的スタイルが、前記マップ特徴を前記デフォルト詳細レベルでレンダリングするための、前記低い詳細レベル、前記デフォルト詳細レベル、および前記高い詳細レベルに対応する、送信することと、
    前記目的地までのナビゲーション順路の要求に応じて、前記地理的エリア内に位置し前記ナビゲーションルートに関係する物理的エンティティに対応する前記第1の複数のマップ特徴の記述であって、前記第1の複数のマップ特徴を前記高い詳細レベルでレンダリングし前記地理的エリア内の残りのマップ特徴を前記低い詳細レベルでレンダリングするための前記第1の複数のマップ特徴の記述を前記クライアントデバイスに送信することと
    を行わせる、請求項13に記載のサーバデバイス。
15. ナビゲーション順路をデジタルマップ上に示すためのクライアントデバイスであって、
    1つまたは複数のプロセッサと、
    前記1つまたは複数のプロセッサに結合され、命令を記憶した非一時的コンピュータ可読メモリと
    を含み、前記命令が、前記1つまたは複数のプロセッサによって実行されると、前記クライアントデバイスに、
    デフォルト詳細レベルで提示されるマップ特徴を含む地理的エリアのデジタルマップを表示することと、
    前記地理的エリア内に位置する目的地までのナビゲーション順路の要求を受信することと、
    前記地理的エリア内に位置し前記目的地までのナビゲーションルートに関係する物理的エンティティに対応する第1の複数のマップ特徴の記述を取得することと、
    前記第1の複数のマップ特徴を高い詳細レベルで前記デジタルマップ内に表示することと、
    他のマップ特徴を低い詳細レベルで前記デジタルマップ内に表示することであって、前記他のマップ特徴が、前記ナビゲーションルートに関係しない物理的エンティティに対応し、前記デフォルト詳細レベルが、前記低い詳細レベルよりも高く、前記高い詳細レベルが、前記デフォルト詳細レベルよりも高く、前記低い詳細レベル、前記デフォルト詳細レベル、および前記高い詳細レベルの各々が、異なる視覚的スタイルに対応し、前記視覚的スタイルは、線の太さ、塗りつぶしの色、輪郭色、形状またはグラフィック、影の色、および影の濃度のうちの少なくとも1つを表示するための構成パラメータを含む、表示することと
    を行わせる、クライアントデバイス。
16. 前記第1の複数のマップ特徴が、前記ナビゲーションルート内に含まれる道路セグメントを含む、請求項15に記載のクライアントデバイス。
17. 前記デジタルマップ内の前記他のマップ特徴が、前記低い詳細レベルで表示される、請求項15に記載のクライアントデバイス。
18. 前記第1の複数のマップ特徴が、前記目的地に対応する建物を含む、請求項15に記載のクライアントデバイス。
19. 前記命令がさらに、前記クライアントデバイスに、
    前記地理的エリア内のマップ特徴の記述、および複数の視覚的スタイルのそれぞれの記述をサーバデバイスから受信することであって、前記複数の視覚的スタイルが、前記低い詳細レベルに対応する、受信することと、
    前記地理的エリア内のマップ特徴の前記受信された記述、および前記デフォルト詳細レベルの前記受信された記述に従って、前記デジタルマップを表示することと
    を行わせる、請求項15に記載のクライアントデバイス。
20. 前記命令がさらに、前記クライアントデバイスに、
    前記目的地までのナビゲーション順路に対する前記要求の受信に応じて、前記第1の複数のマップ特徴に対応する道路ジオメトリの記述、および前記送信された視覚的スタイルのうちのどれが前記第1の複数のマップ特徴に適用されることになるかを示す指示を前記サーバデバイスから受信させる、請求項19に記載のクライアントデバイス。

Images