特許 6771858 非ラスター地図データの修正を利用した地図画像の描画

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6771858

(24)【登録日】2020年10月2日

(45)【発行日】2020年10月21日

(54)【発明の名称】非ラスター地図データの修正を利用した地図画像の描画

(51)【国際特許分類】

   G09B 29/00 20060101AFI20201012BHJP

   G01C 21/26 20060101ALI20201012BHJP

   G06T 11/60 20060101ALI20201012BHJP

【ＦＩ】

   G09B29/00 Z

   G01C21/26 A

   G06T11/60 300

【請求項の数】9

【全頁数】20

(21)【出願番号】特願2014-532094(P2014-532094)

(86)(22)【出願日】2012年9月25日

(65)【公表番号】特表2015-501439(P2015-501439A)

(43)【公表日】2015年1月15日

(86)【国際出願番号】US2012057104

(87)【国際公開番号】WO2013049054

(87)【国際公開日】20130404

【審査請求日】2015年8月6日

【審判番号】不服2017-15796(P2017-15796/J1)

【審判請求日】2017年10月25日

(31)【優先権主張番号】13/244,741

(32)【優先日】2011年9月26日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502208397

【氏名又は名称】グーグル エルエルシー

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】マウラー， ジェニファー

(72)【発明者】

【氏名】イーガン， ショーン

【合議体】

【審判長】 尾崎 淳史

【審判官】 吉村 尚

【審判官】 藤本 義仁

(56)【参考文献】

【文献】 特開２００４−１５７０１３（ＪＰ，Ａ）

【文献】 ＦＯＬＬＩＮ Ｊ−Ｍ ｅｔ ａｌ．，”Ｍｕｌｔｉ−ｒｅｓｏｌｕｔｉｏｎ ｅｘｔｅｎｓｉｏｎ ｆｏｒ ｔｒａｎｓｍｉｓｓｉｏｎ ｏｆ ｇｅｏｄａｔａ ｉｎ ａ ｍｏｂｉｌｅ ｃｏｎｔｅｘｔ”，「ＣＯＭＰＵＴＥＲＳ ＡＮＤ ＧＥＯＳＣＩＥＮＣＥＳ」，Ｅｌｓｅｖｉｅｒ Ｌｔｄ．，２００５．０３，Ｖｏｌ．３１，Ｎｏ．２，ｐ．１７９−１８８

【文献】 青木大我，”「Ｇｏｏｇｌｅ Ｍａｐｓ」で陰影付きの地形図が表示可能に”，［ｏｎｌｉｎｅ］，２００７年１１月２８日，株式会社インプレス，Ｉｎｔｅｒｎｅｔ Ｗａｔｃｈ，＜ＵＲＬ： ｈｔｔｐ：／／ｉｎｔｅｒｎｅｔ．ｗａｔｃｈ．ｉｍｐｒｅｓｓ．ｃｏ．ｊｐ／ｃｄａ／ｎｅｗｓ／２００７／１１／２８／１７６６２．ｈｔｍｌ＞

【文献】 鈴木一生，”Ｇｏｏｇｌｅマップで路線図”，［ｏｎｌｉｎｅ］，２００９年４月３日，グーグル株式会社， Ｇｏｏｇｌｅ Ｊａｐａｎ Ｂｌｏｇ，＜ＵＲＬ： ｈｔｔｐ：／／ｊａｐａｎ．ｇｏｏｇｌｅｂｌｏｇ．ｃｏｍ／２００９／０４／ｇｏｏｇｌｅ＿０３．ｈｔｍｌ＞

(58)【調査した分野】（Int.Cl.，ＤＢ名）

G09B 29/00

G01C 21/00-36

G06T 11/00-80

(57)【特許請求の範囲】

【請求項1】

通信ネットワークを介してクライアントデバイスに地図データを地図サーバによって提供するための方法であって、
指定された地理的領域に対応する地図データの提供に対する要求を前記クライアントデバイスから受信することと、
前記指定された地理的領域のための第１の地図画像を、前記クライアントデバイスのところで描画して表示するための第１の複数のベクトル記述子であって、その各々が、ベクトルグラフィックス形式に従ってそれぞれの地図要素の形状を示す、複数のベクトル記述子を生成することと、
前記第１の複数のベクトル記述子が、前記通信ネットワークを介して前記クライアントデバイスに送信されるようにすることと、
前記第１の複数のベクトル記述子が前記クライアントデバイスに送信された後に、前記指定された地理的領域に対する第２の地図画像が前記クライアントデバイスのところで同じズームレベルで描画されるべきとする指示を前記クライアントデバイスから受信することであって、前記第２の地図画像が前記第１の地図画像とは異なり、前記第２の地図画像が第２の複数のベクトル記述子に対応する、指示を受信することと、
前記第１の複数のベクトル記述子と前記第２の複数のベクトル記述子との差異を前記地図サーバにおいて決定することと、
決定した前記差異に基づいて、前記第２の地図画像のみにおいて描画されるそれぞれの地図要素に各々が対応する１つ以上のベクトル記述子の集合を示す修正指示を生成することと、
前記第１の複数のベクトル記述子および前記修正指示を用いて前記第２の地図画像を描画して表示するために、前記通信ネットワークを介して前記クライアントデバイスに対して前記修正指示が送信されるようにすることと、を含む、方法。

【請求項2】

前記修正指示の生成が、
前記第２の地図画像のみにおいて描画される地図要素を識別することと、
前記識別された地図要素に対応するベクトル記述子を、前記修正指示の中に提供することと、
前記識別された地図要素が前記提供されたベクトル記述子を用いて描画されることを示すための追加指示を、前記修正指示の中に提供することと、を含む、請求項１に記載の方法。

【請求項3】

前記修正指示の生成が、前記識別された地図要素に対応する深さ指示を、前記修正指示の中に提供することを更に含み、前記深さ指示が、前記識別された地図要素が少なくとも１つの他の地図要素も含む地理的領域の内部で描画される順序を示し、前記識別された地図要素および前記少なくとも１つの他の地図要素が重なり合い、前記少なくとも１つの他の地図要素が深さ指示を備える、請求項２に記載の方法。

【請求項4】

前記修正指示の生成が、
前記第１の地図画像のみにおいて描画される地図要素を識別することであって、前記識別された地図要素が、前記第１の地図画像を描画するために前記クライアントデバイスに送信された前記第１の複数のベクトル記述子のうちの少なくとも１つに対応する、地図要素を識別することと、
前記識別された地図要素に対応する前記第１の複数のベクトル記述子のうちの１つを識別するために、識別子を、前記修正指示の中に提供することと、
前記識別された地図要素が描画されないことを前記クライアントデバイスに示すために、除去指示を、前記修正指示の中に提供することと、を更に含む、請求項１に記載の方法。

【請求項5】

前記修正指示の生成が、
１つ以上の重なり合う地図要素に対する第１の深さのところで前記第１の地図画像の一部として描画される地図要素を識別することと、
前記識別された地図要素に対応する第２の深さの指示を、前記修正指示の中に提供することと、
前記識別された地図要素の深さが前記第１の深さから前記第２の深さに変更されるべきことを示す深さ変更指示を、前記修正指示の中に提供することと、を更に含む、請求項１に記載の方法。

【請求項6】

通信ネットワーク中で動作するコンピューティングデバイスであって、
一又は複数のプロセッサと、
前記通信ネットワークを介しての通信のためのネットワークインターフェースと、
前記プロセッサに連結された表示デバイスと、
前記一又は複数のプロセッサに連結され、前記一又は複数のプロセッサで実行される命令を記憶するメモリと、を備え、
前記命令は、前記コンピューティングデバイスに、
選択された地理的領域に対応する地図データの提供に対する要求を、前記ネットワークインターフェースを介して送信し、
第１の地図画像を前記表示デバイス上に表示させるために、その要求に応答して前記ネットワークインターフェースを介して受信した非ラスター形式の複数のベクトル記述子を用いて前記第１の地図画像を描画し、
前記選択された地理的領域に対応する修正データの提供に対する要求を、前記ネットワークインターフェースを介して送信し、
第２の地図画像を前記表示デバイス上に表示させるために、前記複数のベクトル記述子および前記修正データを用いて前記第２の地図画像を描画することを実行させ、
前記修正データが、前記第２の地図画像のみにおいて描画される地図要素のベクトル記述子を、前記非ラスター形式の一種であるベクトルグラフィックス形式で含む、コンピューティングデバイス。

【請求項7】

前記命令は、前記コンピューティングデバイスが、
第１の地図タイプが選択されたという通知を前記コンピューティングデバイスのユーザインターフェースから受信し、
前記第１の地図タイプの選択に応答して、前記選択された地理的領域に対応する地図データの提供に対する要求を、前記ネットワークインターフェースを介して地図サーバに送信し、
前記第１の地図タイプとは異なる第２の地図タイプが選択されたという通知を前記ユーザインターフェースから受信し、
前記第２の地図タイプの選択に応答して、前記選択された地理的領域に対応する修正データの提供に対する要求を、前記ネットワークインターフェースを介して前記地図サーバに送信する命令を含む、
請求項６に記載のコンピューティングデバイス。

【請求項8】

前記第１の地図タイプおよび前記第２の地図タイプの各々が、基本図、地形図、路線図、および道路交通現況図のうちの１つから選択される、請求項７に記載のコンピューティングデバイス。

【請求項9】

前記修正データが、
前記第１の地図画像のみにおいて描画される地図要素を識別するための識別子と、
前記識別された地図要素が描画されないことを前記コンピューティングデバイスに示すための除去指示と
を含む、請求項６に記載のコンピューティングデバイス。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、電子地図表示システムなどの地図描画システムに関し、より具体的には、地図画像が、非ラスター形式で提供された地図データを用いて描画される地図描画システムに関する。

【背景技術】

【0002】

本明細書に提供される背景の説明は、一般的に、開示の文脈を提示するためのものである。この発明の背景というセクションに記載されている範囲内での現在指名されている発明者の業績と、出願時において先行技術であるとは認められ得ない記述の態様とは、明示黙示を問わず、本開示に対する先行技術とは認められない。

【0003】

今日、地理的領域の地図は、携帯電話、カーナビシステム、手持ち式全地球測位システム（ＧＰＳ）ユニット、およびコンピュータを含む広範囲にわたるデバイス上で実行されるソフトウエアアプリケーションによって表示され得る。このアプリケーションおよび／またはユーザの嗜好次第で、地図は、地形データ、街路データ、都市交通情報、交通情報などを表示し得る。更に、一部のアプリケーションは、地図を対話モードで表示し、これにより、ユーザは、様々な制御装置（ラジオボタン、スクロールバーなど）を用いて、例えば、ズームレベルを変更したり、新たな位置に対して「カメラ」をパンしたりし得る。ユーザはまた、場合によっては、ある情報の表示を選択したり選択解除したりし得る。例えば、ユーザは、適切な制御装置を動作させて、自転車トレイルの表示をオンにし得る。

【0004】

地図画像を描画するために、デバイスは一般的に、専用のサーバからラスター画像を受信する。例えば、地図サーバは、インターネット上で動作して、指定された地理的領域に対する画像を、ポータブルネットワークグラフィックス（ＰＮＧ）形式で様々なクライアントデバイスに提供し得る。ラスター画像はクライアントデバイスで描画するには比較的容易であるとはいえ、ラスター画像データは一般的には、広範囲の地図のための多量の記憶スペースを必要とする。また、ラスター画像をクライアントデバイスのところで効率的に操作することは困難である。例えば、選択された領域をズームインするためには、新しいラスター画像データをサーバから取ってくるか、さもなければ、利用可能なラスター画像データを、品質を大幅に犠牲にして拡大するかである。

【発明の概要】

【0005】

ある実施形態では、クライアントデバイスに地図データを提供するためのコンピュータ実装方法が、選択された地理的領域のための第１の地図画像を、クライアントデバイスのところで描画するためのいくつかのベクトル記述子であって、その各々が、ベクトルグラフィックス形式に従ってそれぞれの地図要素の形状を示す、ベクトル記述子を生成することを含む。本方法は、ベクトル記述子が、通信ネットワークを介してクライアントデバイスに送信されるようにすることと、選択された地理的領域に対する第２の地図画像がクライアントデバイスのところで描画されるべきとする指示であって、第２の地図画像が第１の地図画像とは異なる、指示を受信することと、第１の地図画像および第２の地図画像の双方ではなくて一方において描画されるそれぞれの地図要素に各々が対応する１つ以上のベクトル記述子の集合を示す修正指示を生成することと、ベクトル記述子の少なくとも一部およびこの修正指示を用いて第２の地図画像を描画するために、通信ネットワークを介してクライアントデバイスに対して修正指示が送信されるようにすることと、を含む。

【0006】

別の実施形態では、有形の非一時的なコンピュータ読み取り可能媒体が、命令を記憶するが、これらの命令は、１つ以上のプロセッサによって実行されるときに、この１つ以上のプロセッサに対して、選択された地理的領域に対して地図データを非ラスター形式で発生させるが、この地図データは、クライアントデバイスのところで解釈可能であり、これにより第１の地図画像をラスター形式で生成し、この地図データを、通信ネットワークを介してクライアントデバイスに対して送信させる。更に、これらの命令は、１つ以上のプロセッサによって実行されるときに、この１つ以上のプロセッサに対して、選択された地理的領域に対する第２の地図画像がクライアントデバイスのところで描画されるべきとする指示を、クライアントデバイスから受信させ、第１の地図画像を第２の地図画像に変換するために、地図データに対する１つ以上の修正を記述する修正指示を生成させ、地図データおよび修正指示の少なくとも一部を用いて、第２の地図画像をラスター形式でクライアントデバイスのところで描画するために、修正指示を、通信ネットワークを介してクライアントデバイスに送信する。

【0007】

別の実施形態では、地図画像を生成するための、コンピューティングデバイスにおける方法は、選択された地理的領域のための第１の地図画像を描画するためのいくつかのベクトル記述子であって、各々がベクトルグラフィックス形式に従ってそれぞれの地図要素の形状を示すベクトル記述子を、通信ネットワークを介して受信することと、第１の地図画像を、これらの複数のベクトル記述子を用いて描画することと、を含む。本方法はまた、選択された地理的領域のための第２の地図画像を描画するための複数のベクトル記述子の修正を示す修正指示を、通信ネットワークを介して受信することと、選択された地理的領域に対する第２の地図画像を、ベクトル記述子のうちの少なくとも一部および修正指示を用いて描画することと、を含む。

【0008】

更に別の実施形態では、通信ネットワーク中で動作するコンピューティングデバイスは、プロセッサと、プロセッサに連結されたメモリと、通信ネットワークを介しての通信のためのネットワークインターフェースと、メモリに記憶されたいくつかのルーチンと、を含む。第１のルーチンは、プロセッサで実行されて、選択された地理的領域に対応する地図データに対する要求を、ネットワークインターフェースを介して送信させる。第２のルーチンは、プロセッサで実行されて、要求に応答してネットワークインターフェースを介して受信された複数のベクトル記述子を用いて第１の地図画像を描画するが、これら複数のベクトル記述子は非ラスター形式にある。第３のルーチンは、プロセッサで実行されて、選択された地理的領域に対応する修正データに対する要求を、ネットワークインターフェースを介して送信させる。第４のルーチンは、プロセッサで実行されて、複数のベクトル記述子のうちの少なくとも一部および修正データを用いて第２の地図画像を描画する。

【図面の簡単な説明】

【0009】

【図1】ある実施形態に従って、サーバが、地図データをクライアントデバイスに提供して、地図画像を描画し、次いで、修正データを提供して、同じ地理的領域に対する別の地図画像を、最初に提供された地図データの一部または全部と、修正データとを用いて描画するシステムのブロック図である。

【図2】図１のシステム中で動作し得る、クライアントデバイスのところである地理的領域に対応する２つの地図画像を描画するための、情報の例示の交換を図示する相互作用図である。

【図3】図１のシステムに実装され得る、以前に提供された地図データと共に追加の地図特徴部を描画するための、クライアントデバイスに対する情報の例示の転送を図示する相互作用図である。

【図4】図１のシステムに実装され得る、以前に提供された地図データに含まれる地図特徴部の属性を修正するための、クライアントデバイスに対する情報の例示の転送を図示する相互作用図である。

【図5】図１のシステムに実装され得る、以前に提供された地図データに含まれる地図特徴部を除去するための、クライアントデバイスに対する情報の例示の転送を図示する相互作用図である。

【図6】図１のシステムに実装され得る、複数の地図要素と関連付けられ、かつ以前に提供された地図データに含まれる地図特徴部を修正するための、クライアントデバイスに対する情報の例示の転送を図示する相互作用図である。

【図7】図１のシステム中で動作し得る地図サーバのところで、いくつかの地図画像に対する地図データを生成するための例示の方法のフロー図である。

【図8】図１のシステム中で動作し得る地図サーバのところで、以前に提供された地図データの修正の記述を生成するための例示の方法のフロー図である。

【図9】図１のシステム中で動作し得るクライアントデバイスのところで、地図画像を描画するための例示の方法のフロー図である。

【図10A】は、図１のシステム中で動作するクライアントデバイスのところで表示され得る例示の基本図である。

【図10B】ユーザが、図１０Ａの基本図を表示するクライアントデバイスのところで、路線図タイプを対話型のユーザインターフェースを介して選択した後で表示され得る例示の路線図である。

【発明を実施するための形態】

【0010】

以下に検討するシステムおよび方法の実施形態において、地図サーバは、地図画像を描画するための地図データをクライアントデバイスに対して効率的に提供する。一部の実施形態によれば、地図サーバは、あるエリアまたは地理的領域に対応する第１の地図画像（例えば、基本図画像）を描画するために、地図データをクライアントデバイスに提供した後で、同じエリアに対応する第２の、そして異なった地図画像（例えば、道路交通現況図）を描画するために、修正データをクライアントデバイスに提供する。クライアントデバイスは次に、第１の地図画像を描画するために以前に提供された地図データと、修正データとを用いて第２の地図画像を描画し得るが、地図サーバは、必ずしも、第１の地図画像および第２の地図画像の双方を描画するに際して用いられる地図データをクライアントデバイスに対して２回以上提供する必要はない。シナリオ次第で、修正データは、以前に提供された地図データに対する１つ以上の追加、以前に提供された地図データの１つのまたはいくつかの部分の削除、または以前に提供された地図データの１つのまたはいくつかの部分の修正を含み得る。

【0011】

ある実施形態では、地図サーバは、地図データを非ラスター形式で提供し、クライアントは、この地図データの一部または全部を解釈して、第１の地図画像および第２の地図画像をそれぞれのラスター画像として生成する。地図データは更に、個々のまたは集団的な地図要素と一緒に表示される地図ラベルを指定するためにテキストデータを含み得る。第１の地図画像を描画するために、クライアントデバイスは、通信ネットワークを介して地図サーバから地図データを要求し得るが、地図サーバはこれに応答して、地図コンテンツを記述する地図データを、ベクトルグラフィックス形式で提供し得る。この地図データは、様々な幾何学的形状を（例えば、点および点を接続する経路の数学的記述を用いて）指定し、道路、建物、公園、水域などの様々な地図要素を描画するためにこれらの形状をどのように位置付けすべきかを示し得る。例えば、線セグメントのラスター画像を形成する各々の画素を指定するのではなくて、線セグメントのベクトルベース記述が、線セグメントの２つの端点を指定して、これら２つの端点が直線で接続されることを示し得る。地図要素のベクトルベース記述は、本明細書では、ベクトル記述子または単にベクトルと呼ばれ得るが、１つまたはいくつかのベクトル記述子の集合は、ベクトルデータと呼ばれ得る。更に、一部のシナリオにおける個々の地図要素（例えば、建物）またはいくつかの地図要素の集団（例えば、建物、公園、自転車専用通路、および大学の構内の歩行者専用通路）は、地図特徴部（または単に特徴部）を画定し得る。ある実施形態では、地図特徴部は、地図サーバおよび地図クライアントが識別目的で利用し得る固有の識別子を割り当てられる。一般に、地図特徴部は、１つ以上のベクトル記述子を用いて記述され得る。

【0012】

クライアントデバイスは、例えば、第１の地図画像および第２の地図画像を描画するための地図データを、それぞれのユーザ指令に応答して要求し得る。これらのユーザ指令は、異なった地図タイプ、異なったズームレベルなどの選択を示し得る。ある例示のシナリオによれば、ユーザは、地理的領域と、基本図タイプ、例えば、道路、街路、主要な目印などを図示する地図のタイプと、を選択する。クライアントデバイスは、地図画像を描画するための要求を生成して、この要求を地図サーバに送信し、地図サーバは、これに応答して、地図データをベクトルグラフィックス形式（または、クライアントデバイスのところでラスター画像を描画する目的に適した他の非ラスター形式）で提供する。この地図データは、いくつかのベクトル記述子と、場合によっては、スタイルデータ、ラベルデータなどの追加のデータとを含み得る。より具体的には、ラベルデータは、情報交換用米国標準コード（ＡＳＣＩＩ）形式、ユニコード形式または他のなんらかの適切な文字形式で文字を含み得る。クライアントデバイスは次に、地図データを解釈して、地図画像を描画して、地図画像を表示デバイス上に表示する。上記のシナリオを継続するためには、ユーザは次に、同じ地理的領域に対する路線図を選択し得るが、クライアントデバイスは、これに応答して、路線図に対応する新しい地図画像が生成されるとの指示を生成して、この指示を地図サーバに送信し得る。１つの実装例によれば、クライアントデバイスは、この新しいタイプの地図データに対する要求（例えば、「領域Ｒの路線図の地図データを提供せよ」）を生成し、地図サーバは、クライアントデバイスとの以前の通信をチェックして、どの種類の地図データが、以前にクライアントデバイスに送られたか、したがって、ここで既に利用可能であるかを決定する。別の実装例では、クライアントデバイスは、新しいタイプの地図データを要求する（例えば、「自分が、同じズームレベルで領域Ｒの基本図に対する地図データを既に有していることを考えれば、領域Ｒの路線図に対する地図データを提供せよ」）ことに加えて、選択された領域に対するどの種類の地図データがクライアントデバイスのところで既に利用可能であるかを指定する。地図サーバは、この場合、たとえ存在するとしても、どの地図データがクライアントデバイスに対して以前に送られたかを知る必要はない。より一般的には、地図サーバとクライアントデバイスとの間のトランザクションの履歴は、地図サーバおよび／またはクライアントデバイスによって維持される。

【0013】

地図サーバは次に、どの地図要素およびラベルを、クライアントデバイスのところで既に利用可能な地図データに対して追加しなければならないか、これから除去しなければならないか、その中で修正しなければならないかを決定し得る。例えば、地図サーバは、ある領域およびあるズームレベルに対する基本図が、どのように、同じ領域および同じズームレベルに対する路線図と異なるか決定し、適切な修正指示を生成し得る。例えば、この修正指示は、基本図画像には含まれない地下鉄路線を描画するためのベクトル記述子を含み得る。地図サーバは次に、修正指示をクライアントデバイスに提供して、基本図画像を描画するための地図データと修正データを少なくとも部分的に用いて路線図画像を描画する。

【0014】

地図画像を描画するための地図データが効率的にクライアントデバイスに提供されるこれらおよび他の例示のシナリオは、添付図面を参照して更に検討される。図の一部は、他の要素をより明瞭に示す目的でのある要素の省略によって簡略化されている。一部の図における要素のこのような省略は、対応する明細書中で明示的に描写され得る場合を除き、例示の実施形態のどれにおいても特定の要素の存在や不在を必ずしも示すものではない。

【0015】

図１を参照すると、地図データを転送するための技法は、システム１０の中で実装され得る。ある実施形態では、システム１０は、地図サーバ１２と、ネットワーク１６を介して地図サーバ１２に通信可能に連結されるクライアントデバイス１４と、地図サーバ１２に通信可能に連結される地図データベース１８と、を含む。ネットワーク１６は、インターネットなどの広域ネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、または他のなんらかの適切なタイプのネットワークであり得る。実施形態次第で、地図データベース１８は、図１に図示するように、ネットワーク１６を介して、または別の通信リンクを介して地図サーバ１２に連結され得る。簡略化のために、地図サーバ１２、クライアントデバイス１４、および地図データベース１８の１つの例だけが、図１に図示されている。しかしながら、システム１０が、２つ以上の地図サーバ１２、２つ以上のクライアントデバイス１４、および／または２つ以上の地図データベース１８を含み得る。

【0016】

地図サーバ１２は、プロセッサ２０と、例えば、プロセッサ２０上で直接的に（例えば、コンパイルされたコードとして）または間接的に（例えば、プロセッサ２０上で実行される別のアプリケーションによって解釈されるスクリプトとして）実行可能であり得るコンピュータ命令という形態で地図コントローラ３０を記憶するコンピュータ読み取り可能メモリ２２と、を含み得る。コンピュータ読み取り可能メモリ２２は、コンピュータ命令と、コンピュータ命令が実行時間に動作する際に基づくデータとを記憶する揮発性メモリ（例えば、ランダムアクセスメモリ、すなわちＲＡＭ）と、ある実施形態では、例えばハードディスクなどの持続性メモリと、を含み得る。ある実施形態では、地図コントローラ３０は、クライアントデバイス１４に対して地図コンテンツとして提供される１つ以上の地図要素を含む、様々な地図要素および／または地図特徴部に対するベクトルデータを生成する動的特徴部コントローラ３２を含む。動的特徴部コントローラ３２はまた、ある地図画像の同じ地理的エリアに対応する別の地図画像に対するベクトルベース記述の相違を決定し、適切な修正指示を生成し、この修正指示をクライアントデバイス１２に提供するように構成し得る。言い換えれば、ある地図画像の完全なベクトルベース記述を提供するのではなくて、動的特徴部コントローラ３２は、別の地図画像の以前に提供されたベクトルベース記述の修正の記述を効果的に提供することが可能である。

【0017】

修正指示を生成するために、動的特徴部コントローラ３２は、ある実施形態に従って、ある地図画像に対応するベクトルデータの直列化された表現を、別の地図画像に対応するベクトルデータの直列化された表現と比較する。例えば、動的特徴部コントローラ３２は、ズームレベルＺにおける領域Ｒの基本図に対するベクトルデータを要求し、これに応答して、地図サーバ１８は、一連のベクトル記述子Ｖ₁、Ｖ₂、Ｖ₅、・・・、Ｖ_Nを提供し得る。別のときに、動的特徴部コントローラ３２は、ズームレベルＺにおける領域Ｒの路線図に対するベクトルデータを要求し、地図サーバ１８は、これに応答して、一連のベクトル記述子Ｖ₁、Ｖ₃、・・・、Ｖ_Lを提供し得る。ベクトル記述子のこれら２つの集合に基づいて、動的特徴部コントローラ３２は、ズームレベルＺにおける領域Ｒに対して、（ｉ）基本図および路線図の双方がベクトル記述子Ｖ₁に対応する地図要素を含むことと、（ｉｉ）ベクトル記述子Ｖ₂およびＶ₅に対応する地図要素を基本図は含むが路線図は含まないことと、（ｉｉｉ）ベクトル記述子Ｖ₃に対応する地図要素を路線図は含むが基本図は含まないことと、を決定する。動的特徴部コントローラ３２は、基本図画像を描画するために以前に提供されたベクトルデータを用いて路線図画像を生成するために、ベクトル記述子Ｖ₃が、この以前に提供されたベクトルデータに追加され、一方、ベクトル記述子Ｖ₂およびＶ₅が、この以前に提供されたベクトルデータから除去されることを示す修正指示を生成し得る。より具体的には、動的特徴部コントローラ３２は、各々が動作（例えば、追加、除去）および動作対象（例えば、ベクトル記述子、地図特徴部、または地図要素）を識別する、１つ以上の追加指示および１つ以上の除去指示を含む修正指示を生成し得る。

【0018】

更に、一部の実施形態では、動的特徴部コントローラ３２は、第１の地図画像および第２の地図画像の双方を生成するときにある地図要素が描画されるとはいえ、この地図要素の１つ以上のプロパティを修正して、第２の地図画像を描画する際にこの地図要素を再使用しなければならないことを決定し得る。例えば、一部または全部の地図要素が、これらの地図要素を、同じエリア中の部分的にまたは完全に重なり合う他の地図要素に対して位置付けることを示すそれぞれの深さ値と関連付けられ得る。より具体的な例として、道路のセグメントを描き、かつベクトル記述子Ｖ_iに対応する地図要素は、基本図画像の中では深さＤ₁のところで描画され得るが、路線図画像の中では深さＤ₂のところで描画され得る。このシナリオにおいて、動的特徴部コントローラ３２は、クライアントデバイス１４に以前に提供されたベクトル記述子Ｖ_iと関連付けられた深さは深さＤ₂に更新されるべきであることを示す修正指示を生成し得る。

【0019】

また更に、ベクトルデータに加えて、動的特徴部コントローラ３２は、追加されたまたは修正された地図特徴部に対するラベルデータを、修正指示の一部としてまたは、代替例では、個別の指示として提供し得る。ラベルデータは、なんらかの適切な形式での文字と、一部の実装例では、対応するラベルが属する地図特徴部または地図特徴部のグループの識別子と、を含み得る。

【0020】

一部の実施形態では、ベクトルデータに加えて、地図コントローラ３０は、どのようにベクトルデータを描画すべきであるかを示すスタイルデータを提供し得る。より特定的には、スタイルデータは、線の太さ（例えば、画素の中の幅）、線の色、１つ以上の充填色などの特徴またはプロパティを記述し得る。ある実施形態では、スタイルデータは、ベクトルデータに適用され得る様々な視覚スタイルに対して提供される。地図サーバはまた、どの視覚スタイルをクライアントデバイスは地図要素の様々なベクトルベースの記述（本明細書ではベクトル記述子または単にベクトルとも呼ばれる）に適用すべきであるかを指定し得る。更に、一部の実施形態では、地図サーバは、どの視覚スタイルが、地形、路線、交通、自転車トレイルなどの特定の地図タイプに対する地図要素のベクトルベースの記述に当てはまるかを示す。この目的のために、各々がそれぞれの固有の識別子によって識別されるいくつかのスタイルが、定義され得る。

【0021】

地図コントローラ３０は、ある地理的領域およびズームレベルに対する、ベクトルデータなどの地図データを非ラスター形式でクライアントデバイス１４に対して、実施形態次第で１つの電子メッセージまたは一連の電子メッセージの中で提供し得る。更に、ある実施形態では、地図コントローラ３０は、地図データを地図タイル記述子の集合として生成し、これにより各々の地図タイル記述子が、地図タイル、すなわちある大きさ（例えば、２５６画素Ｘ２５６画素）の地図画像の一部を記述するようにする。個々の地図タイルによって表される地理的領域の大きさは、この地図タイルが関連付けられる相手側のズームレベルによって異なり得るため、より低いズームレベルでの１つの地図タイルは、より高いズームレベルでの１つの地図タイルよりも大きい地理的エリアを図示する。地図コントローラ３０は、ベクトルグラフィックス形式に従って各々の地図タイル記述子を生成し、図１のクライアントデバイス１４などのクライアントデバイスは、各々のタイルに対するラスター画像を局所的に生成し得る。

【0022】

図１を引き続き参照すると、クライアントデバイス１４は、命令を実行するプロセッサ５０と、命令およびデータを記憶するメモリ５２とを含み得る。クライアントデバイス１４はまた、それぞれ、入力デバイス５４と、ユーザからの入力を受信してユーザに出力を提供する出力デバイス５６と、を含み得る。入力デバイス５４は、キーボード、マウス、およびタッチ画面のうちの１つ以上を含み、出力デバイス５６は、例えば、タッチ画面や「通常」の（出力だけの）画面などの表示装置またはモニターデバイスを含み得る。クライアントデバイス１４は、デバイスドライバ、オペレーティングシステム（ＯＳ）イベントハンドラなどの様々なソフトウエアコンポーネントを含んで、入力デバイス５４および出力デバイス５６を制御し、これにより、対話型ユーザインターフェースを実装し得る。更に、プロセッサ５０上で実行されるソフトウエアアプリケーションは、これらのソフトウエアコンポーネントを利用して、アプリケーション特有のユーザインターフェースを提供する。

【0023】

実施形態次第で、クライアントデバイス１４は、デスクトップコンピュータ、ラップトップコンピュータ、またはタブレットＰＣなどのパソコン、ワークステーション、スマートフォンなどの携帯式通信デバイス、または他のいずれかの適切なコンピューティングデバイスであり得る。ある実施形態では、クライアントデバイス１４は、ある計算機能および／または記憶機能を別のコンピューティングデバイスに依存するいわゆるシンクライアントである。例えば、１つのこのような実施形態では、メモリ５２は、ＲＡＭなどの揮発性メモリだけを含み、持続性メモリを有するプログラムおよび／または記憶ユニットは、クライアントデバイス１４の外部にある。別の実施形態では、メモリ５２は、揮発性メモリコンポーネントと持続性メモリコンポーネントとの双方を含む。

【0024】

ブラウザアプリケーション６０は、プロセッサ５０上で実行されるコンピュータ読み取り可能命令の集合を含み得る。一般に、ブラウザアプリケーション６０は、テキスト、画像、埋込みビデオなどのコンテンツと、ハイパーテキストマークアップ言語（ＨＴＭＬ）などのマークアップ言語での命令とを含むウエブページにアクセスして、マークアップ言語での命令に従って出力デバイス５６上にこれらのコンテンツを描画する。この目的のために、ブラウザアプリケーション６０は、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）に適合するデータパケットを生成して処理するための機能を実装し、ＨＴＭＬコンテンツを解析し、セキュア・ソケット・レイヤー（ＳＳＬ）プロトコルに従ってデータを符号化し、デジタル証明書などを要求して検証し、かつウエブページデータをナビゲートし、描画し、管理することに関連する様々なユーザ指令を受信するためのユーザインターフェース機能を実施する。一部の実施形態では、ブラウザアプリケーション６０は、ウエブページに提供されているスクリプト言語（例えば、ｊａｖａｓｃｒｉｐｔ）で命令を解釈するように構成されている。

【0025】

動的地図描画エンジン６２は、ブラウザアプリケーション６０のコンポーネントとして実行され得る。しかしながら、地図描画エンジン６２に類似したソフトウエアモジュールが、独立型アプリケーションとしてまたは別のアプリケーションのコンポーネントとして実行され得る実施形態もある。実施形態次第で、動的地図描画エンジン６２は、プラグイン（例えば、ブラウザアプリケーション６０の機能性を拡張してプロセッサ５０上で実行されるコンパイルされた命令の集合）、スクリプト（例えば、実行時にブラウザアプリケーション６０によって解釈されるスクリプト言語での命令の集合）、または別の適切なソフトウエアコンポーネントであり得る。１つの例示のシナリオにおいては、動的地図描画エンジン６２は、は、クライアントデバイス１４を動作させているユーザが、対話型埋込み地図を含むウエブページを訪問するときにダウンロードされる。より具体的には、ウエブページは、オンラインの地図サーバへの第１のハイパーリンクおよびある地理的位置と、この第１のハイパーリンクに従ってこのオンライン地図サーバから受信された地図データを描画するために必要とされる動的地図描画エンジン６２のコピーへの第２のハイパーリンクと、を含み得る。

【0026】

動的地図描画エンジン６２は、例えば、ブラウザアプリケーション６０のユーザインターフェースを介して対話型制御を提供し得る。対話型制御は、ユーザが、地理的領域もしくはエリア、地図タイプ（例えば、基本図、道路交通現況図、路線図）、ズームレベルなどを選択することを可能とし得る。ある例示のシナリオにおいては、ユーザは最初に、地理的領域の基本図を要求し、次に同じ領域の別のタイプの地図を要求する。動的地図描画エンジン６２は、ユーザ指令に応答して、地図データをベクトルグラフィックス形式で要求して受信し得る。

【0027】

動作中、動的地図描画エンジン６２は、ベクトルデータ（および、一部の実施形態では、スタイルデータ）を地図サーバ１２から受信し、対応する地図画像を受信したベクトルデータを用いて描画し、かつこの地図画像を、ブラウザアプリケーション６０によって割り当てられたある領域の内部に表示させる。例えば、ブラウザアプリケーション６０は、地図画像を表示するためのＨＴＭＬ５のカンバス要素を作成し得る。動的地図描画エンジン６２はまた、別の地図画像を描画するための受信されたベクトルデータに対する１つ以上の修正を示す修正指示を、地図サーバ１２から受信し得る。

【0028】

簡単にするために、クライアントデバイス１４は、１つのプロセッサ５０で図示されている。しかしながら、クライアントデバイス１４は、他の実施形態では、例えば、出力デバイス５６での画像描画を容易にするように構成されたグラフィックス処理ユニット（ＧＰＵ）などの追加の処理ユニット（図示せず）を含み得る。更に、ある実施形態では、ブラウザアプリケーション６０は、効率的に地図画像を描画するためのグラフィックス機能のライブラリを利用し得る。例えば、メモリ５２は、ブラウザアプリケーション６０を含む、クライアント１４で実行される様々なアプリケーションがアプリケーションプログラミングインターフェース（ＡＰＩ）を介してアクセスし得るグラフィックスを描画するための機能を有する、ＯｐｅｎＧＬ（登録商標）ライブラリまたはＤｉｒｅｃｔ３Ｄ（登録商標）ライブラリなどのプラグインを記憶し得る。別の実施形態では、メモリ５２は、例えばＷｅｂＧＬなどのブラウザアプリケーションにとって特に適切なプラグインを記憶する。また、一部の実施形態では、メモリ５２は、出力デバイス５６を介して画像の効率的な描画を可能とする更なるソフトウエアコンポーネントを記憶する。例えば、メモリ５２は、Ａｄｏｂｅ（登録商標）Ｆｌａｓｈ（登録商標）プラグインまたはＯ３Ｄプラグインを記憶し得る。

【0029】

一般に、動的地図描画エンジン６２はいずれかの適切なアプリケーションで動作することが可能であることが分かっている。例えば、クライアントデバイス７０は、動的地図描画エンジン６２がマッピングアプリケーション７４で動作する、例えばスマートフォンなどの携帯デバイスであり得る。ブラウザアプリケーション６０に類似して、マッピングアプリケーション７４は、メモリ７２に記憶され、かつクライアントデバイス７０（図示せず）の１つ以上のプロセッサで実行可能な命令の集合を含み得る。一部の実施形態では、マッピングアプリケーション７４は、クライアントデバイス７０で実行されるブラウザアプリケーションによって（例えば、対応するブラウザＡＰＩを介して）提供されるネットワーク機能を利用する。別の実装例では、マッピングアプリケーション７４は、地図サーバ１２にアクセスするためにＴＣＰ、ＩＰ、ＨＴＴＰなどをサポートする通信スタックなどの少なくとも部分的なブラウザ機能性を含む。

【0030】

次に、図１のシステムまたは類似の環境の中での地図サーバおよびクライアントデバイスの動作をより良く解説するために、いくつかのシナリオを、図２〜６に図示する相互作用図を参照して考える。特に、ある領域の２つの地図画像を描画するための地図サーバとクライアントデバイスとの間での情報の例示の交換を、図２を参照して検討し、その後で、いくつかの具体的なシナリオを検討するが、これらのシナリオとは、追加の地図要素を描画するための修正指示を提供すること（図３）、地図特徴部または地図要素が描画される深さを修正するための修正指示を提供すること（図４）、以前に提供された地図データに含まれる地図特徴部または地図要素を除去するための修正指示を提供すること（図５）、いくつかの地図要素と関連付けられた複合した地図特徴部を修正するための修正指示を提供すること（図６）、である。

【0031】

図２を参照すると、例示のメッセージ交換１００には、（図１のクライアント１４などの）クライアントデバイスに含まれるまたは別様に関連付けられたユーザインターフェース１０２と、クライアントデバイスで動作する動的地図描画エンジン１０４と、（図１の地図サーバ１２などの）サーバ１０６と、に関連する。戻って図１を参照すると、ユーザインターフェースはブラウザ６０によって提供され、一方、動的地図描画エンジン１０４およびサーバ１０６は、それぞれコンポーネント６２および１２に実装され得る。

【0032】

ユーザ指令に応答して、ユーザインターフェース１０２は、ある領域Ｒ₁の地図データに対する要求１１０を生成して、この要求を動的地図描画エンジン１０４に提供する。要求１１０は、例えば、コンポーネント１０２および１０４がその内部に実装されるクライアントデバイスの内部で電子メッセージとして送信され得る。動的地図描画エンジン１０４は次に、基本地図データに対する要求１１２を送信し得るが、この要求は、通信ネットワークを介してサーバ１０６に送信される。要求１１２は、全地球測位サービス（ＧＰＳ）座標を用いて、または他のなんらかの適切な仕方で領域Ｒ₁を指定し得る。更に、要求１１２は、基本図を描画するために地図データが要求されていることを指定するために、地図タイプ指示を含み得る。また更に、一部の実施形態では、要求１０２は、領域Ｒ₁のなんらかのベクトルベースの地図データが、コンポーネント１０２および１０４を実装するクライアントデバイスのところで既に利用可能であるかどうかを示す。

【0033】

要求１１２に応答して、サーバ１０６は、基本図画像を描画するための地図データをベクトルグラフィックス形式などの非ラスター形式で含む応答１１４を生成し得る。ある例示のシナリオによれば、応答１１４は以前に提供されたどのベクトルデータにも依存しない領域Ｒ₁の基本図画像のベクトルベースの記述を含む。言い換えれば、応答１１４は、領域Ｒ₁の基本図画像の完全な記述を含む。応答１１４は、１つまたはいくつかのタイル記述子Ｔ₁、Ｔ₂、・・・Ｔ_Nなどのなんらかの適切な方法で編成された地図データを含み得る。一般に、地図データは、１つのタイルを含む任意の数のタイルに対して提供され得る。各々のタイル毎に、応答１１２は、様々な特徴部Ｆ₁、Ｆ₂、などを記述し得るが、これらの各々は、適切なベクトルグラフィックス形式に従った１つまたはいくつかのベクトル記述子を用いて指定され得る（上記したように、特徴部は、１つの地図要素または地図要素のグループと関連付けられ得る）。特徴部は、建物などの単純な地図要素またはより複雑な地図要素集団に対応し得る。一部の実施形態では、応答１１４は、将来の識別に用いられる地図特徴部のための固有の識別子を提供し得る。一部の実施形態における応答１１４は、地図要素の様々な視覚属性を指定するスタイルデータを更に含む。

【0034】

動的地図描画エンジン１０４は、基本図画像を描画し、基本図画像をユーザインターフェース１０２に提供して対応するイベント１１６を生成し、受信した地図データ（および、利用可能であるときは、スタイルデータ）を将来の使用のためにメモリに記憶し得る。ある実施形態では、動的地図描画エンジン１０４は、地図データは基本図と関連付けられているとの指示を更に記憶する。

【0035】

図２のシナリオでは、ユーザは後に、地理座標を変更することなく地図タイプを基本図から路線図に変更することを判断して、ユーザインターフェース１０２を介して適切な制御装置を起動する。これに応答して、ユーザインターフェース１０２は、路線図データに対する要求１２０を生成して、要求１２０を動的地図描画エンジン１０４に発送し、このエンジンは次に、クライアントデバイスのところで違った地図画像が描画されようとしているとの指示１２１をサーバ１０６に提供する。ある実施形態では、指示１２１は、要求１１２に類似した路線図データに対する要求である。別の実施形態では、指示１２１は、路線図画像を描画するために、以前に提供された地図データを修正するための修正データを具体的に要求する。

【0036】

ある実施形態では、サーバ１０６は、修正指示を一連の電子メッセージ１２２₁、・・・１２２_Nとしてクライアントデバイスに提供する。しかしながら、別の実施形態ではこの修正指示は、１つのメッセージとして提供される。メッセージ１２２₁、・・・１２２_Nの各々は、対応するタイルＴ₁、・・・Ｔ_Nに対するベクトルデータをどのように修正するかの指示を含み得る。しかしながら、一部のシナリオでは、応答１１４に記述されたタイルＴ₁、・・・Ｔ_Nのうちの一部だけが修正される。例えば、ある水域を描写する地図タイルは、基本図の一部としてまたは路線図の一部として表示されるときに同じ外観を有し得る。

【0037】

修正される各々のタイルに対して、メッセージ１２２_iは、１つ以上の修正記述子Ｍ₁、Ｍ₂、・・・Ｍ_Mを提供し得る。一般的に、修正記述子は、以前に提供された地図データに追加されるべき地図要素のベクトル記述子を指定したり、以前に提供された地図データの中の除去されるべき地図要素を識別したり、以前に提供された地図データの中の地図要素のプロパティの新しい値を指定したりする。ある実施形態では、修正記述子Ｍ₁、Ｍ₂、・・・Ｍ_Mの各々が、追加、削除、修正、深さ修正などの実行されるべき動作を識別し、かつ追加される地図特徴部または地図要素に対するベクトル記述子、除去される地図特徴部または地図要素の識別子などの１つ以上の動作対象またはパラメータを含む。

【0038】

メッセージ１２２₁、・・・１２２_Nを受信すると、動的地図描画エンジン１０４は、要求された路線図画像のためのタイルを、応答１１４の中に提供されたベクトルデータの一部または全部と、メッセージ１２２₁、・・・１２２_Nの中に提供された修正指示と、を用いて描画する。より具体的には、動的地図描画エンジン１０４は、メッセージ１２２₁、・・・１２２_Nに従って修正された以前に提供されたベクトル記述子を解釈して、ラスター路線図画像を描画し、かつイベント１２６を生成して、この路線図画像を、ユーザインターフェース１０２を介して描画させ得る。動的地図描画エンジン１０４はまた、修正された地図データをメモリに記憶する。ある実施形態では、動的地図描画エンジン１０４は、最初に提供された地図データと修正されたデータとの双方を、バージョンの異なった地図データとして記憶する。

【0039】

図３に示す例示のメッセージ交換１５０の間、地図サーバ１０６は、追加の地図特徴部のベクトル記述子を、動的地図描画エンジン１０４に対してそれぞれのメッセージ１５２₁、・・・１５２_Nを介して提供する。これらの追加の地図特徴部は、以前に提供された地図データの一部または全部と共に使用されて、ユーザインターフェース１０２および動的地図描画エンジン１０４を実装するクライアントデバイスのところで新しい地図画像を描画する。ある実施形態では、メッセージ１５２₁、・・・１５２_Nは、ある地図タイルに対する追加を記述する。メッセージ１５２₁、・・・１５２_Nが、どの特定のタイルとも関連付けられない実施形態もある。

【0040】

メッセージ１５２₁、・・・１５２_Nの各々は、１つ以上の地図要素を有する地図特徴部の、ベクトルグラフィックス形式または他の適切な非ラスター形式での、記述を含み得る。メッセージ１５２はまた、対応する地図特徴部が、ほぼ同じ位置に配置された別の地図特徴部または要素に対してどのように描画されるかを指定する深さ指示を含み得る。例えば、メッセージ１５２₁、・・・１５２_Nのうちの１つを介して追加された新しい地図特徴部は、鉄道線路のあるセグメントであり得るし、以前に提供されたのは、道路のあるセグメントである地図特徴部であり得る。この新しい地図特徴部および以前に提供された地図特徴部のそれぞれの深さ指示次第で、鉄道線路のこのセグメントは、これらの鉄道線路と道路が交差する点における道路のセグメントの上または下に描画され得る。

【0041】

メッセージ１５２₁、・・・１５２_Nを受信すると、動的地図描画エンジン１０４は、新しい地図画像を描画し、かつイベント１５６を生成して、この新しい地図画像をユーザインターフェース１０２のところで表示させ得る。ある実施形態では、動的地図描画エンジン１０４はまた、増加した地図データを地図データの新しいバージョンとしてメモリに記憶する。

【0042】

図４を参照すると、サーバ１０６が、以前に提供された地図データに含まれるある地図特徴部が、新しい深さのところで新しい地図画像の中に描画されたと決定するときに、例示のメッセージ交換２００が発生し得る。サーバ１０６は、固有の特徴部識別子によって識別された地図特徴部に対して、この地図特徴部が描画される新しい深さを示す修正指示２０２を生成して、動的地図描画エンジン１０４に送信する。別の実施形態では、修正指示２０２は、いくつかの地図特徴部または要素の新しい深さ値を示す。修正指示２０２を受信すると、動的地図描画エンジン１０４は、修正指示２０２を考慮して新しい地図画像を描画し、かつイベント２０４を生成して、この新しい地図画像を、ユーザインターフェース１０２のところで表示させ得る。

【0043】

更に、サーバ１０６が、以前に提供された地図データに含まれるある地図特徴部が、新しい地図画像の中に描画されていないと決定するときに、図５の例示のメッセージ交換２５０が発生し得る。サーバ１０６は、例えば、固有の特徴部識別子を用いて地図特徴部を識別する修正指示２５２を生成して、動的地図描画エンジン１０４に送信する。別の実施形態では、修正指示２５２は、個々の地図要素をこの地図要素の適切な識別子を用いて識別する。更に、一部の実施形態では、修正指示２５２は、除去されるべきいくつかの地図特徴部または要素を識別する。修正指示２５２を受信すると、動的地図描画エンジン１０４は、修正指示２５２を考慮して新しい地図画像を描画し、かつイベント２５４を生成して、この新しい地図画像を、ユーザインターフェース１０２のところで表示させ得る。

【0044】

図６は、サーバ１０６が、いつくかのサブ特徴部または要素を有する複合した地図特徴部を修正するために修正データを動的地図描画エンジン１０４に提供している間での例示のメッセージ交換３００を図示する。例えば、地図特徴部Ｆ₁は、サブ特徴部Ｆ_1-1、Ｆ₁ー2、Ｆ1ー₃、Ｆ1ー₄、およびＦ1ー₅を含み得る。地図特徴部Ｆ₁を基本図の一部として描画するときには、サブ特徴部Ｆ_1-1、Ｆ1ー₂、Ｆ1ー₃、Ｆ1ー₄、およびＦ_1-5の各々が用いられ得る。しかしながら、地図特徴部Ｆ₁を路線図の一部として描画するときには、地図特徴部Ｆ₁は、サブ特徴部Ｆ_1-1およびＦ1ー₂だけと共に描画され得る。ある実施形態では、サーバ１０６は、地図特徴部Ｆ₁が除去されるべきであることを示すメッセージ３０２を生成する。図５を参照して検討した例示のシナリオに類似して、メッセージ３０２は、地図特徴部Ｆ₁の固有の識別子を含み得る。サーバ１０６は次に、それぞれサブ特徴部Ｆ1ー₁およびＦ1ー₅を追加するためにメッセージ３０４および３０６を生成する。図３の例示のシナリオに類似して、メッセージ３０４および３０６は、対応する地図特徴部の記述をベクトルグラフィックス形式などの非ラスター形式で含み得る。メッセージ３０２、３０４、および３０６を受信すると、動的地図描画エンジン１０４は、地図特徴部Ｆ₁の新しいバージョンを持つ新しい地図画像を描画し、かつイベント３１０を生成して、この新しい地図画像を、ユーザインターフェース１０２のところで表示させる。

【0045】

次に、図１のシステムまたは類似の環境で動作するコンピューティングデバイスに実装され得るいくつかの例示の方法を、図７〜９を参照して検討する。これらの方法は、なんらかの適切なプログラミング言語で開発されたコンピュータプログラムとして実装されて、（１つまたはいくつかのハードディスクドライブなどの）有形の非一時的なコンピュータ読み取り可能媒体に記憶され、かつ１つまたはいくつかのプロセッサで実行可能であり得る。例えば、図７および８の方法は、地図サーバ１２に実行され、図９の方法は、クライアントデバイス１４に実装され得る。図７〜９の方法はサーバまたはパソコン（ＰＣ）などの個々のコンピュータで実行可能であるとはいえ、これらの方法の少なくとも一部を例えば、クラウドコンピューティング環境でいくつかのコンピュータを用いて分散式に実装することも可能である。

【0046】

図７を参照すると、いくつかの地図画像のための地図データを生成するための例示の方法３５０が、例えば、地図サーバ１２の地図コントローラ３０またはサーバ１０６の類似のコンポーネントに実装され得る。ある実施形態によれば、ある領域の第１の地図画像を描画するためのベクトル記述子がブロック３５２で生成される。これらのベクトル記述子は、ベクトルグラフィックス形式に適合し、かつそれぞれの地図要素を記述し得る。一部の実施形態では、ベクトル記述子は、各々が１つ以上の地図要素を含む地図特徴部に従ってグループ化され得る。更に、一部の実施形態では、ベクトル記述子は、ベクトルデータ、テキストベースのラベルデータ、アイコン、または、道路シールドなどの記号を効率的に描画するまたは再描画するためのスタイルデータをこれまた含む非ラスター地図データの一部として提供され得る。

【0047】

次に、ブロック３５４で、ベクトル記述子は、クライアントデバイスに提供される。例えば、ベクトル記述子は、１つまたはいくつかの電子メッセージとして、例えば、図１のネットワーク１６などの通信ネットワークを介して送信され得る。

【0048】

ブロック３５６で、同じ領域の第２の地図画像を描画するためのデータに対する要求が受信される。一部のシナリオでは、この要求は、図２の相互作用図に図示するように、クライアントデバイスのところでユーザが異なった地図タイプを選択することに応答して送信される。以前に提出されたベクトル記述子に対する１つまたはいくつかの修正の記述を含む修正指示が、ブロック３５８で生成されて、ブロック３６０でクライアントデバイスに提供される。

【0049】

別のシナリオでは、ブロック３５６で受信された要求は、同じ領域および同じ地図タイプに対応する地図画像が描画される新しいズームレベルをユーザが選択することに応答して送信される。例えば、ブロック３５２で生成されたベクトル記述子は、地理的領域Ｒの基本図タイプのズームレベルＺ₁にあるいくつかのタイルを記述し得る。ブロック３５６でユーザがズームレベルＺ₂を選択し、データに対する適切な要求が発行された後で、それぞれブロック３５８および３６０で、修正指示が生成されて、クライアントデバイスに提供され得る。クライアントデバイスは、以前に提供されたベクトル記述子に対して、この修正指示に従って追加、除去、または修正し、かつこれらのベクトル記述子の一部または全部を再スケーリングして、対応する地図要素をズームレベルＺ₂で描画し得る。より具体的な例として、ブロック３５４で提供されたベクトル記述子は、ズームレベルＺ₁での公園のベクトルベースの記述を含み、また、この公園の同じベクトルベースの記述を用いて、ズームレベルＺ₂での公園を修正された地図画像の一部として再描画し得る。

【0050】

図８を参照すると、以前に提供された地図データの修正の記述を生成するための例示の方法４００は、例えば、地図サーバ１２の地図コントローラ３０またはサーバ１０６の類似のコンポーネントに実装され得る。ある実施形態では、方法４００のステップの一部は、上述した方法３５０のブロック３５６〜３６０で実行される。

【0051】

ブロック４０２で、地図画像がクライアントデバイスのところで更新されるとの指示が受信される。ブロック４０４で、以前に提供されたベクトル記述子に対する追加が識別され、対応する記述が生成される。ブロック４０６で、以前に提供されたベクトル記述子の一部の削除が識別され、対応する修正の記述が生成される。上述したように、一部のシナリオでのある地図特徴部の修正は、サブ特徴部の一部の削除および追加として表される。ベクトルデータに対する修正の記述などの修正指示は、１つの電子メッセージまたはいくつかの電子メッセージでクライアントデバイス４０８に送信される。

【0052】

図９は、例えば、動的地図描画エンジン６２または１０４に実装され得る地図画像を描画するための例示の方法４５０のフロー図である。ブロック４５２で、あるエリアまたは領域のベクトル記述子が受信され、ブロック４５４で、第１の地図画像が、受信されたベクトル記述子を用いて描画される。この目的のため、受信されたベクトルデータが解釈されて、ラスター画像を生成する。

【0053】

次に、ブロック４５６で、第２の地図画像を描画するための要求が、例えば、ブラウザアプリケーションのインターフェースなどのユーザインターフェースから受信される。この第２の地図画像は、上述したように、同じ領域に対するものであるが、違った地図タイプやズームレベルに対応したものであり得る。ブロック４５２で受信されたベクトル記述子に対する１つ以上の修正の記述などの修正指示が、ブロック４５８で受信される。この第２の地図画像は次に、ブロック４５２で受信されたベクトル記述子の一部または全部と、ブロック４５８で受信された修正の記述とを用いて描画される。上記したように、一般にベクトルデータに対する修正は、深さの追加、削除、修正、変更などを含み得る。

【0054】

上記した技法の例示の応用を更に解説するために、同じ地理的領域に対応する図１０Ａおよび図１０Ｂの地図を、それぞれ基本図タイプおよび路線図タイプに従って表示する。図１０Ａに示す基本図の地図画像５００は、道路および公園などの複数の地図要素の描画５００を含み得る。図１０Ｂに図示するように、路線図の地図画像は、地図画像５００の地図要素と、地図画像５００の対応する部分に重ね合わされた地下鉄路線５０４とを含み得る。実施形態次第で、地下鉄路線５０４は、１つの地図特徴部または、各々が路線のそれぞれのセクションに対応するいくつかの画像特徴部として定義され得る。更に、地下鉄記号５０６は、地図画像５００のある部分の上に描画され得る。実施形態次第で、地下鉄記号５０６は、例えば、追加された地図特徴部もしくは要素として、ラベルとして、またはアイコンとして提供され得る。ある実施形態では、地下鉄記号５０６は、ラスター形式の標準の地下鉄記号を標準のアイコンを生成するサーバから取ってくるために用いられることが可能な統一資源位置指定子（ＵＲＬ）として指定される。

【0055】

図１０Ｂの地図画像を図１０Ａの地図画像がクライアントデバイスのところで描画された後でこのクライアントデバイスのところで生成するために、地図サーバは、地下鉄路線５０４に対応する１つ以上の地図特徴部をベクトル形式で記述する修正指示だけを提供し得る。ある実施形態では、この修正指示はまた、深さ指示を提供して、地下鉄路線５０４を、図１０Ａの地図画像に示す道路の上に表示させる。更に、ある実施形態では、修正指示は、地下鉄記号５０６の記述をラベルまたはアイコンとして更に含む。

【0056】

次の更なる考慮は、前述の検討に当てはまる。本明細書全体にわたって、複数の例は、１つの例として説明されたコンポーネント、動作、または構造を実現し得る。１つ以上の方法の個々の動作は、個別の動作として図示され、説明されているが、これら個別の動作のうちの１つ以上は、同時に実行され得るし、これらの動作が図示される順序で実行されることを要求するものはなにもない。例示の構成で個別のコンポーネントとして提示される構造および機能性は、組み合わされた構造またはコンポーネントとして実現され得る。同様に、１つのコンポーネントとして提示される構造および機能性は、個別のコンポーネントとして実現され得る。これらおよび他の変更、修正、追加、および改良は、本明細書の主題の範囲に入る。

【0057】

ある実施形態は、本明細書では、ロジックまたは複数のコンポーネント、モジュール、またはメカニズムを含むものとして説明されている。モジュールは、ソフトウエアモジュール（例えば、機械読み取り可能媒体上でまたは送信信号中で実現される符号）またはハードウエアモジュールを構成する。ハードウエアモジュールは、ある動作を実行することが可能な有形のユニットであり、かつある方法で構成または配置され得る。例示の実施形態では、１つ以上のコンピュータシステム（例えば、独立型、クライアント、またはサーバコンピュータシステム）または、コンピュータシステム（例えば、プロセッサまたはプロセッサのグループ）の１つ以上のハードウエアモジュールは、本明細書に説明するある動作を実行するために動作するハードウエアモジュールとして、ソフトウエア（例えば、アプリケーションまたはアプリケーション部分）によって構成され得る。

【0058】

別様の記載がない限り、「処理」、「計算」、「算出」、「決定」、「提示」、「表示」または類似物などの単語を用いた本明細書中の検討は、１つ以上のメモリ（例えば、揮発性メモリ、不揮発性メモリ、またはこれらの組み合わせ）、レジスタ、または、情報を受信する、記憶する、送信する、または表示する他の機械コンポーネントの内部で物理的（例えば、電子的、磁気的、または光学的）な量として表されるデータを操作または変換する機械（例えば、コンピュータ）の動作またはプロセスに言及し得る。

【0059】

本明細書で用いられる、「一実施形態（ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ）」または「実施形態（ａｎ ｅｍｂｏｄｉｍｅｎｔ）」に対するいかなる言及も、その実施形態に関連して説明される特定の部品、特徴部、構造、または特徴が少なくとも１つの実施形態に含まれることを意味する。明細書中での様々な箇所における「一実施形態において」という語句の出現は、必ずしも全てが、同じ実施形態に対する言及であるとは限らない。

【0060】

一部の実施形態は、「連結された」および「接続された」という表現をこれらの派生語と共に用いて説明され得る。例えば、一部の実施形態は、２つ以上の部品が直接的な物理的または電気的に接触していることを示すために「連結された」という用語を用いて説明され得る。しかしながら、「連結された」という用語はまた、２つ以上の部品が互いに直接的には接触していないが、それでも、互いに協動または相互作用することを意味し得る。実施形態は、この文脈には限られない。

【0061】

本明細書で用いられる、「含む（ｃｏｍｐｒｉｓｅｓ）」、「含む（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、「有する（ｈａｓ）」、「有する（ｈａｖｉｎｇ）」という用語またはこれらの他のなんらかの変化語は、非排他的な包含を範囲に含むことを意図される。例えば、部品のリストを備えるプロセス、方法、品物、または装置は、必ずしもこれらの部品に限られることはなく、明示的にはリストされていないまたはこのようなプロセス、方法、品物、または装置に固有の他の部品を含み得る。更に、明示的に反対に記載されていない限り、「または」は、包括的な「または」であり、排他的な「または」ではない。例えば、条件ＡまたはＢは、次のうちのどれかによって満足される：Ａは真（または存在する）でＢは偽（または存在しない）である、Ａは偽（または存在しない）でＢは真（または存在する）である、ならびにＡおよびＢは双方とも真（存在する）である。

【0062】

加えて、「ａ」または「ａｎ」の使用を用いて、本明細書中の実施形態の部品およびコンポーネントを説明する。これは単に便利性のためおよび、本発明の一般的な意味を与えるためになされたものである。この説明は、１つまたは少なくとも１つを含むものと読まれるべきであり、明瞭に別様であることが意味されない限り、単数形は複数形も含む。

【0063】

本開示を読めば、当業者は、本明細書中の開示された原理によって地図データを生成するためのシステムおよびプロセスのための更に他の代替の構造および機能的設計を理解されるであろう。したがって、特定の実施形態および応用例を図示し、説明したが、開示された実施形態は、本明細書に開示する正確な構造およびコンポーネントに限られないことを理解すべきである。当業者には明らかであろう様々な修正、変更および変形は、添付の特許請求の範囲に定義された精神および範囲から逸脱することなく、明細書に開示された本方法および装置の構成、動作および詳細に対してなされ得る。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10A】

【図10B】