(57)【要約】マップ画像を処理するシステムはマップ画像を記憶するウェブマッピングサービス（ＷＭＳ）を有する。ＷＭＳプロキシは、クライアントのところでの表示のためのマップ画像についての要求をクライアントから受信するＷＭＳにより動作可能である。ＷＭＳプロキシは、マップ画像についての要求をマップタイルを得るための一連の要求に変換するタイルブローカモジュールを有する。キャッシュシステムはマップタイルを記憶する。タイルブローカモジュールは、キャッシュされたマップタイルがキャッシュに既に存在する場合に、キャッシュされたマップタイルを戻し、マップタイルが前記キャッシュから戻されない場合に、ＷＭＳからマップタイルを検索するように動作可能である。タイル構築モジュールは、要求されたフォーマット及び解像度でマップタイルからＷＭＳプロキシにおいてマップ画像を構築し、クライアントのところで再サンプリングすることなくクライアントのところでマップ画像を表示するために動作可能である。
2010517079.tif 000002
【特許請求の範囲】
【請求項１】
複数のマップ画像を処理するシステムであって：
複数のマップ画像を記憶するウェブマッピングサービス（ＷＭＳ）；並びに
クライアントのところでの表示のためのマップ画像についての要求を前記クライアントから受信するＷＭＳにより動作可能であるＷＭＳプロキシであって、
複数のマップタイルを記憶するキャッシュと、
前記マップ画像についての要求を複数のマップタイルを得るための一連の要求に変換するタイルブローカモジュールであって、該タイルブローカモジュールは、複数のキャッシュされたマップタイルがキャッシュに既に存在する場合に、前記複数のキャッシュされたマップタイルを戻し、複数のマップタイルが前記キャッシュから戻されない場合に、前記ＷＭＳから複数のマップタイルを検索するように動作可能である、タイルブローカモジュールと、
要求されたフォーマット及び解像度で前記複数のマップタイルから前記ＷＭＳプロキシにおいてマップ画像を構築し、前記クライアントのところで再サンプリングすることなく前記クライアントのところで前記マップ画像を表示するように動作可能であるタイル構築モジュールと、
を更に有する、ＷＭＳプロキシ；
を有するシステム。
【請求項２】
請求項１に記載のシステムであって、前記ＷＭＳがマップ画像を記憶している複数のサーバを更に有し、前記ＷＭＳプロキシにより動作可能である負荷分散モジュールと、前記複数のサーバ間で負荷分散するためのＷＭＳとを更に有する、システム。
【請求項３】
請求項２に記載のシステムであって、前記ＷＭＳプロキシは、前記ＷＭＳから検索される前記キャッシュにおいて複数のマップタイルを記憶するように動作可能である、システム。
【請求項４】
請求項１に記載のシステムであって、前記マップ構築モジュールは、複数のタイルをクロッピングし、モザイク化し、拡張することによりマップ画像を再構築するように動作可能である、システム。
【請求項５】
請求項４に記載のシステムであって、前記マップ構築モジュールは、全体的なモザイク及びクロッピングパラメータについて、クロップの原点位置及び目標位置並びにクロップの幅及び高さを用いて調整されるｘ及びｙ位置の詳細を調べる個別のタイルについてのタイル規格を構築するために動作可能である、システム。
【請求項６】
複数のマップ画像を処理する方法であって：
クライアントのところでの表示のためのマップ画像についての要求を前記クライアントからウェブマッピングサービス（ＷＭＳ）プロキシにおいて受信する段階；
前記マップ画像についての要求を複数のマップタイルを得るための一連の要求に変換する段階；
複数のキャッシュされたマップタイルがキャッシュにおいて既に存在する場合に、前記複数のキャッシュされたマップタイルを戻し、複数のマップタイルが前記キャッシュにおいて存在しない場合に、前記ＷＭＳから複数のマップタイルを検索する段階；
要求されたフォーマット及び解像度で前記複数のマップタイルからＷＭＳプロキシにおいてマップ画像を構築する段階；並びに
前記クライアントのところで再サンプリングすることなく前記クライアントのところで前記マップ画像を表示する段階；
を有する方法。
【請求項７】
請求項６に記載の方法であって、マップ画像を構築する前記段階は、複数のタイルをクロッピングし、モザイク化し、拡張する段階を有する、方法。
【請求項８】
請求項７に記載の方法であって、性能プリミティブ、オープンＧＬ／ＧＰＵ又はＪａｖａ処理を用いて複数のタイルをモザイク化し、クロッピングする段階を更に有する、方法。
【請求項９】
請求項６に記載の方法であって、前記キャッシュにおいて前記ＷＭＳから検索された複数のマップタイルを記憶する段階を更に有する、方法。
【請求項１０】
請求項６に記載の方法であって、前記ＷＭＳにおいて複数のサーバに複数のマップ画像を記憶し、前記複数のサーバ間で負荷分散する段階を更に有する、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像処理の分野に関し、特に、マッピングシステムで用いられるマップタイルから生成されるマップ画像を処理するシステム及び関連方法に関する。
【背景技術】
【０００２】
Ｇｏｏｇｌｅ  Ｅａｒｔｈ及びＭｉｃｒｏｓｏｆｔ  Ｖｉｒｔｕａｌ  Ｅａｒｔｈにより用いられる画像データベース等の古典的な大きなデータベースは、前処理するためにマップデータを必要とする。その結果、マップデータの１つの集合のみが、そのマップデータに対して１つのビューのみを伴って提供される。このことは、利用可能な新しいマップデータを迅速に作成する、又は異なる観点からマップデータを表示する、例えば、時間経過により変化するマップデータを表示する能力に制限をかける。
【０００３】
最近のシステムは、一部のキャッシュシステムを有することが可能なＷＭＳデータレイヤを用いるウェブマッピングサービス（ＷＭＳ）を用いる。殆どのシステムにおいては、拡張性及び性能は、付加画像サービスを追加すること及び種々の負荷分散技術を用いることにより改善されている。例えば、何れかのクライアントのようなユーザは、検索データベース及び情報データベース等の共有データベース及び他のＷＭＳサービスにより負荷分散されることが可能である１つ又はそれ以上のサービスとしてＷＭＳに対してインターネットにより接続されることが可能である。性能は、応答時間の間、像を前処理すること、即ち、データの流通をやりとりすることにより改善されることが可能である。一部のシステムは、クライアントがタイルをフェッチするように、それ故、クライアントのところで生じた過剰なマップデータ処理と共にクライアントに多くの負荷を負わせるように、タイルが予め規定された、クライアントのところでアセンブルされた多くのタイルを有する。
【発明の概要】
【課題を解決するための手段】
【０００４】
マップ画像を処理するシステムは、マップ画像を蓄積するためのウェブマッピングサービス（ＷＭＳ）を有する。ＷＭＳプロキシはＷＭＳにより動作可能であり、クライアントのところでの表示のためのマップ画像についての要求をクライアントから受信する。ＷＭＳプロキシは、マップ画像についての要求を、マップタイルを得るための一連の要求に変換するタイルブローカモジュールを有する。キャッシュはマップタイルを記憶する。タイルブローカモジュールは、キャッシュしたマップタイルがキャッシュ内に既に存在する場合に、キャッシュしたマップタイルを戻すように動作可能であり、マップタイルがキャッシュから戻されない場合に、ＷＭＳからマップタイルを検索する。タイル構築モジュールは、要求フォーマット及び解像度でマップタイルからＷＭＳプロキシにおいてマップ画像を構築し、クライアントのところで再サンプリングすることなくクライアントのところでマップ画像を表示するために動作可能である。
【０００５】
ＷＭＳは、マップ画像を記憶している複数のサーバにより生成されることが可能である。負荷分散モジュールは、それらの複数のサーバ間の負荷分散のためにＷＭＳプロキシ及びＷＭＳにより動作可能である。
【０００６】
他の特徴においては、ＷＭＳプロキシは、ＷＭＳから検索されたキャッシュ内のマップタイルを記憶するために動作可能である。マップ構築モジュールはまた、タイルをモザイク化する及びクロッピングすることによりマップ画像を再構築するために動作可能である。マップ構築モジュールは、全体のモザイクに関して調整されたｘ及びｙ位置を詳細化したタイル指定を構築し、パラメータをクロッピングするために動作可能である。マップ構築モジュールはまた、ハードウェア性能プリミティブ（ｐｅｒｆｏｒｍａｎｃｅ  ｐｒｉｍｉｔｉｖｅｓ）、オープンＧＬ／ＧＰＵ又はＪＡＶＡ処理として形成されることが可能である。
【０００７】
他の特徴においては、分散型２層キャッシュは、Ｊａｖａキャッシングシステム（ＪＣＳ）及び他の分散キャッシング機構に基づいてマップタイルを記憶する。方法の特徴についても説明する。
【０００８】
本発明の他の目的、特徴及び有利点については、添付図を参照して考慮するときに、以下に記載する本願の発明の詳細説明から明らかになる。
【図面の簡単な説明】
【０００９】
【図１Ａ】本発明の非制限的な実施例に従った、ＷＭＳプロキシを用いてマップ画像を処理するシステム及び方法で用いられる基本構成要素を示すブロック図である。
【図１Ｂ】基本構成要素を示すＷＭＳプロキシの詳細なブロック図である。
【図２】本発明の非制限的な実施例に従った、タイル及び要求画像を決定するタイルクロッピングを対する方法を示すマップ画像である。
【図３】本発明の非制限的な実施例に従った、タイル１によりアルゴリズムが開始するクロップパラメータ及びモザイク位置パラメータを決定する、タイルクロッピングに対する方法を示すマップ画像である。
【図４】本発明の非制限的な実施例に従った、Ｙ軸の前にＸ軸に従うタイル２によりアルゴリズムが継続する、クロップパラメータ及びモザイク位置パラメータを決定するタイルクロッピングに対する方法を示すマップ画像である。
【図５】本発明の非制限的な実施例に従った、右下のタイル従うタイル６によりアルゴリズムが終了する、クロップパラメータ及びモザイク位置パラメータを決定するタイルクロッピングに対する方法を示すマップ画像である。
【図６】本発明の非制限的な実施例に従った、ＷＭＳプロキシのタイルクエリマネージャ構成要素の動作におけるフローシーケンスを示すブロック図である。
【図７】本発明の非制限的な実施例に従った、用いられることが可能である２ティアキャッシュを示すブロック図である。
【図８】本発明の非制限的な実施例に従った、用いられることが可能であるマップ画像を処理するために用いられる基本構成要素を示す図１Ａに示すシステムに類似する他の実施形態のブロック図である。
【発明を実施するための形態】
【００１０】
以下、好適な実施形態を示す添付図を参照して、複数の実施形態について詳細に説明される。複数の異なる形式について示され、詳述される実施形態は、それらの実施形態に限定されるとして解釈されるべきでない。そうではなく、それらの実施形態は、開示が詳細で且つ完成したものであり、当業者が本発明の範囲を十分に理解できるように、提供されている。
【００１１】
本発明の非制限的な実施例に従った、複数のタイルにより形成されるマップ画像を処理するシステム及び方法は、データが前処理される必要があるＧｏｏｇｌｅ  Ｅａｒｔｈ及びＭｉｃｒｏｓｏｆｔ  Ｖｉｒｔｕａｌ  Ｅａｒｔｈ等の古典的な大きい画像データベースを用いる従来のマップ画像化処理における不利点を克服することができる。それらのシステムにおいては、データの１つの集合のみが、データに対する１つのみのビューと共に“提供され”、それにおいては、迅速に利用可能な新しいデータを作成し又は異なる観点からデータ、例えば、経時的に変化するデータをみるようにシステムの性能を制限される。古典的なウェブマッピングサービス（ＷＭＳ）により動作可能である従来のマッピングエンジンの一部は、当該技術分野において本来備わっている１つの状態のビューのために、解析的な課題を解決するには単に僅かに有利である。一部の改善されたマップシステムは、かなり小さい容量のサーバで異なる空間マップタイルを処理する。例えば、クライアントは、所望のマップスクリーン、例えば、タイル番号３０１２について必要な複数のマップタイルを検索する又は“フェッチ”する。それらのシステムは、ＯＧＣ  ＷＭＳ規格により動作するＯｐｅｎ  ＧＩＳ  Ｃｏｎｓｏｒｔｉｕｍの下で動作することが可能である。このＯＧＣ  ＷＭＳ規格はマップ提供空間における最初の相互運用性規格であるが、迅速なタイル化は可能でない。異なる解像度及び画素数でデータの異なるスケールを要求することが可能であり、ＷＭＳに対応するマップサーバは、そのピクチャをアセンブルする役割を担う。この種のシステムは、クライアントの負荷の一部を取り除くことができる。この種のシステムは、しかしながら、カスタム画像を作成するために用いられる処理資源と連携していて、多くのユーザがマップを要求する場合に、処理速度が遅くなる。そのようなシステムの長所は、しかしながら、データ範囲に亘ってクエリを可能にするＯＧＣ使用である。
【００１２】
本発明のシステム及び方法の非制限的な実施例に従って、クライアントは、ここで、ＷＭＳインタフェースと共に用いる高速且つオープン規格を有し、それ故、クライアントは最少処理と共に軽量化を維持することができ、マップタイルに関する大規模なデータ処理を必要としない。そのようなシステム及び方法は、時間経過と共にクエリを継続するフレキシビリティを有し、また、そのシステムに接続することが可能である動的で軽量さを備えたクライアントを支えることができる。
【００１３】
図１Ａは、本発明の非制限的な実施例に従ったシステム１０のブロック図であり、クライアント１２と、タイルブローカ及び他の構成要素としてのＷＭＳプロキシ１４と、ネットワークモジュール１６と、１つ又はそれ以上のマップサーバに対応する古典的ＷＭＳ１８と、ＷＭＳサーバのためのデータベースとしてのＷＭＳデータモジュール２０とを有する５つの基本的構成要素又はモジュールを示している。古典的ＷＭＳ１８、ネットワークモジュール１６及びＷＭＳプロキシ１４は、各々別個のサーバとして、又は１つのサーバにおいて異なる処理モジュールを有する１つのサーバとして構成されることが可能である。典型的には、ＷＭＳプロキシ１４は、ＷＭＳを構成する何れかのマップサーバとは別のサーバである。別個の論理ユニットとしてのＷＭＳプロキシ１４は、ネットワークモジュール及びＷＭＳサーバ１８とは別個のサーバである。別個のサーバとしてのＷＭＳプロキシ１４はインターネットに接続される必要はないことが理解される必要がある。ＷＭＳサーバ１８はまた、負荷分散モジュールを有するネットワークモジュールを介して負荷分散を可能にするように複数の別個のサーバ又はプロセッサから構成されることが可能である。
【００１４】
作動中、クライアント１２は画像モザイク等のマップを要求する。任意の処理ステップとしての負荷分散化３２が生じる可能性がある。別個の論理モジュールとして、典型的には、別個のサーバとしての役割を果たすＷＭＳプロキシ１４において、タイルブローカ３４は、マップ要求を一連のタイル化要求に変換する。キャッシュ３６は、既に存在する場合に、例えば、ＳＱＵＩＤ又はより小さいキャッシュプログラム等のインターネットキャッシュプログラムを用いることにより、キャッシュされたタイルを戻す。
【００１５】
キャッシュ３６、例えば、非限定的な実施例としてのＳＱＵＩＤは、典型的には、ＨＴＴＰデータオブジェクトを支援し、単独の処理、ノンブロッキング処理、入力／出力駆動処理において要求する、ウェブクライアントのための高性能プロキシキャッシングサーバである。メタデータ及びオブジェクトは、ＤＳＮルックアップを有するＲＡＭにおいてキャッシュされることが可能であり、ネガティブキャッシングセキュアソケットレイヤ（ＳＳＬ）拡張性アクセス制御及び十分な要求ロギングが支援される。
【００１６】
非制限的実施例として、何れかのインターネットオブジェクトキャッシングプログラム及び関連キャッシュが、ＨＴＴＰプロトコル、ＦＴＰプロトコル及びＧｏｐｈｅｒプロトコルを介して利用可能なデータとして要求されたインターネットオブジェクトを記憶するように用いられる。ＷｅｂブラウザはそのキャッシュをプロキシＨＴＴＰサーバとして用いることが可能である。
【００１７】
典型的な別個のサーバとしてのＷＭＳサーバ１８で、ＷＭＳはＧｅｔＭａｐ要求を処理し３８、適切なピラミッドレベルが決定される４０。データベースアクセスプログラムは、複数のデータベース４４ａ、４４ｂを有することが可能であるＷＭＳデータレイヤ４４に対して要求についての適切な画像を特定する４２。このとき、ＷＭＳは再サンプリングし、キャッシングのためにキャッシュ３６に戻されるタイルを有する入力画像４６をモザイク化する。ネットワークモジュール１６において、任意の負荷分散モジュール５０を備えることが可能である。ＷＭＳ１８は、負荷分散されることが可能である複数のサーバに対応する、それらのサーバを表す２つの大きいボックスで示されている複数のサーバ１８ａ、１８ｂにより構成されることが可能である。
【００１８】
ＷＭＳプロキシ１４は、ＷＭＳ１８に対するフロントエンドプロキシとして動作可能である。タイルがキャッシングのためにキャッシュに戻された後、タイルは、Ｉｎｔｅｌ社の性能プリミティブ又はオープンＧＬ／ＧＰＵを介してソフトウェア又はハードウェアを用いて、ＷＭＳプロキシ１４の一部としてマップ構築モジュールでモザイク化され、拡張される５２。クライアント１２についての再サンプリングは必要ない。一部の実施形態においては、Ｊａｖａキャッシングシステム（ＪＣＳ）を用いることが可能であり、好ましい。キャッシュ及びマップ構築モジュールは一緒に動作可能であり、メモリ管理、ディスクオーバーフロー並びにデフラグ処理、スレッドプール制御及び要素グループ化を提供することが可能である。そのモジュールは、メモリ、ディスク、側方領域及び遠方領域についての複合キャッシュである。そのモジュールは、管理のための最長未使用時間（ＬＲＵ）アルゴリズムを備えたメモリキャッシュを有することが可能である。キャッシングデータは、複数のサーバに対してキャッシングされることが可能である。
【００１９】
Ｉｎｔｅｌ社の性能プリミティブ（Ｐｅｒｆｏｒｍａｎｃｅ  Ｐｒｉｍｉｔｉｖｅｓ）は、性能最適化機能の適切なソフトウェアライブラリとしてのマルチメディア及びデータ処理のためのマルチコア電力を提供する。代替として、オープングラフィクスライブラリ（Ｏｐｅｎ  ＧＬ）が、三次元コンピュータグラフィックス及び二次元コンピュータグラフィックスについて、クロスランゲージアプリケーションプログラミングインタフェース及びクロスプラットフォームアプリケーションプログラミングインタフェース（ＡＰＩ）を規定する。
【００２０】
タイルがクロッピングされ、モザイク化され、拡張された後、マップはクライアント５４に表示される。この好適な実施形態においては、ＷＭＳプロキシ１４、ネットワーク１６及びＷＭＳ１８は、サーバでのタイルの調整の管理において限定される。一時的なファイルクリーニングは管理されることが可能である。更に、新しいコンテンツが付加されるとき、その領域についてのキャッシュはフラッシュされる。例えば、横方向１０００画素且つ縦方向１０００画素のあるフィールドの、例えば、サッカーボールのフィールドのサイズの、特定の画像が所望される場合、ＷＭＳプロキシ１４はその画像を所定のタイルに分けることが可能である。
【００２１】
この非制限的な実施例においては、４つのタイルがオリジナルのタイル化において必要であることが可能である。そのシステムは、データを４つの独立した要求に分け、それらの要求が既にキャッシュ内に存在するかどうかを判定する。例えば、画像は過去の何らかの他の理由のために溜められていることがある。キャッシュ３６は現時点で動作可能である。そのフィールドのタイルとしてのピクチャは、キャッシュにおいて１ｍ画素解像度に保たれることが可能であり、他のタイルは５ｍ画素解像度に保たれることが可能であり、更に他のタイルは２０ｍ画素解像度に保たれることが可能である。この実施例においては、クライアント１２は、そのフィールドの３ｍ画素解像度を好むかもしれない。４つのタイルが処理され、キャッシュにおいて１ｍ画素解像度以外にフェッチされる。マップ構築モジュール５２は、高速の処理速度で３ｍ画素解像度の低解像度になるように再サンプリングする。従って、そのシステム及び方法においては、異なるサイズにフェッチされることが可能であり、解像度は、全てのユーザの要求について高分解能に変化する。このタイル化スキームは、本発明の非制限的な実施例に従って、異なるスケールの固定された解像度のタイルに保ち、迅速により小さいスケールでそれらのタイルを再サンプリングする（ダウンサンプリングする）。例えば、Ｉｎｔｅｌ社の性能プリミティブにおける異なるライブラリが、その再サンプリングのために用いられることが可能である。
【００２２】
本発明の非制限的な実施例に従って、それらのタイルを再サンプリングし、正しい解像度にし直す機能能力とキャッシュとが組み合わされたタイルブローカ３４は、マップ画像化における動作速度を改善する。負荷分散３２、５０は、ＷＭＳ１８が複数のマップサーバ１８ａ、１８ｂを有する場合に、動作可能である。例えば、図１に示しているＷＭＳ１８は、各々が別個のプロセッサとしての２つのサーバ１８ａ、１８ｂを表している。その結果、上記の実施例における４つのタイルについての要求は、異なるプロセッサにおいて行き渡らせることが可能である。負荷分散は、キャッシュをポピュレートするのに役立つ。
【００２３】
本発明の非制限的な実施例に従って用いられることが可能であるＷＭＳプロキシ１４について、ここで詳述する。ＷＭＳプロキシ１４は、画像についての予約プロキシに動作的に類似している。ＷＭＳプロキシ１４は、画像要求を複数の共通のタイルに分け、高速キャッシュシステム３６にそれらの共通のタイルを記憶し、スケーリングモジュールとしてマップ構築モジュール５２を用いて要求されたフォーマットでタイルから画像を構築する。
【００２４】
そのアーキテクチャは２つのサーブレット、即ち、フロントエンド及びバックエンドを用い、異なるプロキシ構成要素への及びそれからの要求数を制御するように、キャッシュ接続及び同時スレッディングシステムを有することが可能である。
【００２５】
他の実施形態においては、図１Ｂに示すように、ＷＭＳプロキシを更にパターニングされたデザインに分割する。この実施形態の主な構成要素には、フロントエンドサーブレット（ＦＥＳ）６０、タイルクエリファクトリ（ＴＱＦ）６２、タイルクエリマネージャ（ＴＱＭ）６４及び画像マニピュレータコンポーネント（ＩＭＣ）６６がある。このデザインで操作される構成について説明する。Ｊａｖａ機能は、ＪＡＩ及びＡＷＴ  Ｊａｖａオブジェクトを有し、統合キャッシュ及び分散キャッシュとしてＪＣＳを用いる。
【００２６】
プログラミングは、構成クラスが正確な解像度レベル構成を可能にするシステムにおける一例であることを可能にする。非制限的な一実施例における解像度レベル調整は、１０倍程度メモリオーバーヘッドを減らすことが可能である。一実施形態においては、最大４８個の個別の１０００ｘ１０００画素のタイルが、まさに４タイルを呼び出すことにより最も効率的に処理されることが可能である画像を生成するように、呼び出されることが可能である。バッファリングされた画像のようなＡＷＴ  オブジェクトの処理において、４８個の個別の１０００ｘ１０００画素のタイルは、ヒープスタックメモリ過負荷のためにシステム障害をもたらす可能性がある。
【００２７】
他の実施形態においては、ＷＭＳプロキシ１４は、ｈｔｔｐ−ｇｅｔコマンドを呼び出し、サーバ、例えば、Ａｐａｃｈｅ−Ｔｏｍｃａｔサーバにおけるサーブレットとして可動する。複数の画像タイルがタイルモザイクに対して非対称に付加され、ＴＱＦ６２は、スレッドが終了したときに画像タイルを検索する。ＴＱＦ６２は、全体的なモザイク及びクロップパラメータに関して調整されたＸ／Ｙ位置を詳細に調べるタイル規格を構築することが可能である。そのタイル規格は、実行された可能性がある又はない何れかの同時スレッドの基準リストに戻ることが可能である。ＴＱＦ６２は、同時非対称スレッドを提示することが可能である。他のモジュール、即ち、タイル検索スレッド（ＴＲＴ）は、画像タイルの結果を戻し、そのタイル規格をとり、Ｊａｖａアドバンスドイメージングを用いてタイルをクロッピングするようにＩＭＣ６６を用いることが可能である。ＳＱＵＩＤ（リモートキャッシュ）スレッドプール及びＷＭＳスレッドプールをデータベースによりデータベースにより動作させることが可能である。Ｊａｖａキャッシングシステム（ＪＣＳ）スレッドプールは、そのデータベースにより動作可能である。
【００２８】
ＷＭＳプロキシサーブレットとしてのフロントエンドサーブレット（ＦＥＳ）６０はＷＭＳプロキシの開始点であることが可能である。そのフロントエンドサーブレット（ＦＥＳ）は、非制限的な一実施例において、Ｊａｖａサーブレット（Ｊ２ＥＥ）としてコード化され、Ａｐａｃｈｅ  Ｔｏｍｃａｔ  Ｖｅｒｓｉｏｎ  ５．５．１７を介して配備されることが可能である。このサーブレットの構造は、“要求を入れ、応答を出す処理（ｒｅｑｕｅｓｔ  ｉｎ，ｐｒｏｃｅｓｓ，  ｒｅｓｐｏｎｃｅ  ｏｕｔ）”として説明されることが可能である。ＦＥＳ６０はＷＭＳプロキシの１つの中心点であり、システムの輪郭を維持するが、真の処理作業の殆どは他の構成要素に従属される。次に示しているのは、非制限的な実施例として処理されるＦＥＳ要求を詳細に調べる擬似コードで書かれたアルゴリズムである
【数１】
2010517079.tif 000003
タイルクエリファクトリ（ＴＱＦ）６２は、要求されたウェブ環境変数からロードされたパラメータに基づいてタイルクエリオブジェクトを生成する。ＴＱＦ６２は、全クエリをそれぞれの共通タイルに分ける役割を果たし、クロップ及びモザイクの位置付けの詳細を調べるタイル規格を構築する。
【００２９】
タイル規格演算は、モザイク化処理に関してとられる分割統治方法を実施する。勿論、スケーリング、クロッピング、色変換及び位置登録を必要とするプレゼンテーションウィンドウでのタイルとして複数の画像を並列するように重ね合わせ及びモザイクを含む、異なる画像積算処理が行われることが可能である。クロッピング処理においては、グラフィックス処理機能は、画像の必要な部分を整える。この方法はまた、処理中にアクティブな各々のタイルの必要な部分のみをモニタすることによりメモリコストを軽減することができる。次に、方法、Ｔｉｌｅ  Ｑｕｅｒｙ  Ｆａｃｔｏｒｙ：：ｃｒｅａｔｅ  Ｑｕｅｒｉｅｓ（）におけるＴＱＦ処理の詳細を調べる、擬似コードで書かれた代表的なアルゴリズムの例を示す。
【数２】
2010517079.tif 000004
2010517079.tif 000005
2010517079.tif 000006
2010517079.tif 000007
2010517079.tif 000008
図２は、グリッドパターン（アレイ）に分割され、タイルを決定して画像を要求するように（モザイクへの付加に先行して）タイルクロッピングに分割統治方法を示すマップ画像である。
【００３０】
このマップ画像においては、中央に破線で示している矩形ブロックは要求されたクエリ領域を表している。τｎは所定の解像度レベルにおける共通タイルを表す。Ωｗは生の合成（モザイク）幅を表す。Ωｈは生の合成（モザイク）高さを表す。
【００３１】
図３は、グリッドパターンに分割され、クロップ及びモザイク位置パラメータを決定するように（モザイクに対する付加に先行して）タイルクロッピングに分割統治方法を示すマップ画像である。このアルゴリズムはタイル１（ｍｉｎＸ及びｍｉｎＹ）から開始する。
【００３２】
このマップ画像においては、陰変数はタイルのＸ位置＝０、タイルのＹ位置＝０である。定数はタイルの大きさ（Ｗ及びＨ）並びにパディング（Θ）である。タイル１（τ１）についてのタイルの規格は次のようである。
【数３】
2010517079.tif 000009
図４は、グリッドパターンに分割され、クロップ及びモザイク位置パラメータを決定するように（モザイクに対する付加に先行して）タイルクロッピングに分割統治方法を示すマップ画像である。このアルゴリズムは、Ｙ軸の前にＸ軸に従って次のタイル２に続けられる。
【００３３】
このマップ画像においては、陰変数はタイルのＸ位置＝１、タイルのＹ位置＝０である。定数はタイルの大きさ（Ｗ及びＨ）並びにパディング（Θ）である。タイル２（τ２）についてのタイルの規格は次のようである。
【数４】
2010517079.tif 000010
図５は、グリッドパターンに分割され、クロップ及びモザイク位置パラメータを決定するように（モザイクに対する付加に先行して）タイルクロッピングに分割統治方法を示すマップ画像である。このアルゴリズムは、右下のタイルとしてタイル６で終了する。
【００３４】
このマップ画像においては、陰変数はタイルのＸ位置＝２、タイルのＹ位置＝１である。定数はタイルの大きさ（Ｗ及びＨ）並びにパディング（Θ）である。タイル６（τ６）についてのタイルの規格は次のようである。
【数５】
2010517079.tif 000011
ＷＭＳプロキシのタイルクエリマネージャ（ＴＱＭ）６４は、複数のタイルクエリの結果を共に単独のタイルモザイクに入れる役割を果たす。ＴＱＭ６４は、現在実行しているクエリに対する基準のリストにより初期設定される。そのＴＱＭは、グループ化された非同期されたスレッドを介してそれらのクエリをモニタし、コーラーにそれが戻される前にそのタイルモザイクが構築されるまで、待機する。図６に示す図は、どのようにＴＱＭが生産し、検索されるタイルを待機するかを示している。
【００３５】
図６に示すように、そのシステムは種々のマップタイル８０を有し、タイル検索スレットグループ８２によりステップ１において初期設定される。ステップ２に示すリストにおける各々のスレッドについて、タイル検索スレッド８４が動作する。その処理におけるステップ３のように、タイルクエリが行われるまで、その処理は待機される。タイルモザイクは、終了したタイル検索スレッド（ステップ４ａ）からの第１の利用可能なクエリ情報を用いて準備できていない（即ち、初期設定されていない）場合、ＴＱＭを介して構築され、ＴＱＭ６４及びタイルモザイク８６により動作可能である。タイルの結果がタイルモザイクに付加され（ステップ４ｂ）、グループモニタにおけるカウントは、スレッドがステップ５において終了した信号に対して１だけ減算される。そのカウントがステップ６のように０に達するときに、ＴＱＭ６４は通知される。
【００３６】
画像マニピュレータ構成要素（ＩＭＣ）６６（図１Ｂ）は、代表的には、ユーティリティクラスである。ＩＭＣ６６が、画像処理機能を実行するように用いられる。ＩＭＣは、画像処理のためにＩｎｔｅｌ（登録商標）  Ｉｎｔｅｇｒａｔｅｄ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｐｒｉｍｉｔｉｖｅｓ（ＩＰＰ）を用いる。ＩＰＰは、有効な画像処理であるが、Ｊａｖａアプリケーションが非Ｊａｖａライブラリ及びコードにアクセスすることを可能にするようにデザインされた、ＪａｖａからＣ＋＋（等）へのブリッジのようなＪａｖａ  Ｎａｔｉｖｅ  Ｉｎｏｖａｔｉｏｎ（ＪＮＩ）のためにオーバーヘッドが比較的高い可能性がある。
【００３７】
ＩＰＰがもはや用いられないときに、ＪＮＩブリッジが除去される。
【００３８】
ＷＭＳプロキシ１４は、スケーリング機能及びクロッピング機能のためにＩＭＣ６６を用いる。画像変換及び分析は全て、ＪＡＩの拡張可能フレームワークにおいて利用可能である。画像保持のみならずスケーリング及びクロッピングのために、アーキテクチャは、画像処理の“プッシュ”モデルに従うＢｕｆｆｅｒｅｄＩｍａｇｅのようなＪａｖａのＡｂｓｔｒａｃｔ  Ｗｉｎｄｏｗ  Ｔｏｏｌｋｉｔ（ＡＷＴ）を取り下げる。画像は常に、何れかの処理コマンドが利用可能となる前に、メモリに完全にロードされる。ＡＷＴに代えて、そのベースラインは、Ｊａｖａ  ｎｏＧｒａｐｈｉｃｓ２Ｄ（登録商標）／ＪＡＩフレームワークのＲｅｎｄｅｒｅｄＩｍａｇｅインタフェースを用いることが可能である。
【００３９】
ＲｅｎｄｅｒｅｄＩｍａｇｅインタフェース（及び関連オブジェクトＲｅｎｄｅｒｅｄＯｐ／ＲｅｎｄｅｒａｂｌｅＯｐ）は画像処理の“プル”モデルに従う。理想的には、画像についての何れかの処理コマンドが、画像がメモリにロードされる前に、有向非巡回グラフ（ＤＡＧ）に付加される。この方法は、範囲内に不必要に残っている多くの画像オブジェクトの過剰な状態を伴わずに、メモリ空間の有効利用を可能にする。
【００４０】
次に、非制限的な実施例として、クロップ画像に対してＩＭＣ６６により用いられるコードの実施例を示す。ＰａｒａｍｅｔｅｒＢｌｏｃｋは殆どリストのようなホルダオブジェクトである。このクラスの適切な使用は、そのブロックが呼び出されるＪＡＩ処理のみに依存する。
【数６】
2010517079.tif 000012
次に、スケール画像に対してＩＭＣ６６により用いられるコードの実施例を示す。クロップ処理が呼び出される方法とスケール処理が呼び出される方法との間には類似性が存在する。スケール処理のＰａｒａｍｅｔｅｒＢｌｏｃｋは、クロップ処理のＰａｒａｍｅｔｅｒＢｌｏｃｋと異なる設定（カウント及びオブジェクトクラスにおいて）を有する。
【数７】
2010517079.tif 000013
ＷＭＳプロキシ１４の一部としての２層キャッシングが、図７のシステムブロック図に示しているように利用可能である。ＷＭＳプロキシアーキテクチャの一実施形態においては、ＷＭＳプロキシに近接して位置している画像タイルのキャッシングを有する。アクティブな最近の“熱い”画像タイルが、関連ＷＭＳシステムに直接進むことに比べて速い速度でキャッシュを介して利用可能である。しかしながら、最良の場合、ｈｔｔｐネットワーク呼び出しは、画像タイル検索の全体的なコストに含まれることが可能である。キャッシュに存在する個別の画像タイルを制御すること及び削除することは好ましいことである。全体のキャッシュが削除されるが、この広範な方法は、“熱い”画像の十分な制御にはなっていない。
【００４１】
Ｊａｖａキャッシングシステム（ＪＣＳ）は、Ａｐａｃｈｅ  ＪａｋａｒｔａプロジェクトによりＪａｖａに書き込まれた分散キャッシングシステムである。そのＪａｖａキャッシングシステム（ＪＣＳ）はＪａｖａに書き込まれていて、真のスタンドアロンキャッシュウェブアプリケーションではないため、ＪＣＳは、ｈｔｔｐネットワーク呼び出しを完全に取り除くＷＭＳプロキシ１４において実施されることが可能である。
【００４２】
ＪＣＳは、画像タイルに対するアクセスオーバーヘッドが略０である統合キャッシュとして実施されることが可能である。ＷＭＳプロキシキャッシュは、１ＧＢ乃至１００ＧＢの範囲内又はそれより大きい範囲にあり、ディスクキャッシュモードで実施されることが可能である。かなり大きいキャッシュディスク割り当て及びキャッシュデータにアクセスする大勢のユーザを有する（例えば、Ｎスケールシナリオ又は大きいユーザ負荷の場合）場合、ディスクのオブジェクトへのアクセス要求によりディスクが過負荷になることがかなりあり得る。このことにより、ＪＣＳキャッシュを損傷するばかりでなく、その後、ＷＭＳプロキシも損傷を受ける。
【００４３】
分散キャッシュアプリケーションに対するｈｔｔｐネットワーク呼び出しは、実際には有用であることが可能である。それ故、２層キャッシュアーキテクチャが、図７に示す非制限的な位置実施例において、ＷＭＳプロキシに対して実施されることが可能である。
【００４４】
ローカル統合キャッシュ（ＪＣＳ）がＷＭＳプロキシに付加される。ＪＣＳは、全体的なシステムコストに対するディスク空間割り当てに関して最良の性能に調整される。フェイルオーバキャッシュが、別個のキャッシュアプリケーションに、オリジナルのデザインのとおりに割り当てられる。この別個のキャッシュアプリケーションは、２層のキャッシュより大きい。また、用いられるキャッシュソフトウェア、例えば、ＪＣＳ、ＳＱＵＩＤ等は横方向に分布可能（他の機械においてサブキャッシュを有することができる）であるため、第２層は、何れかのＮスケールの要求に適合するように巧みにスケーリング可能になる。
【００４５】
それ故、統合ＪＣＳは“熱い”画像タイルリポジトリになり、第２層キャッシュ（現在はＳＱＵＩＤであるが、ＪＣＳであることが可能である）は“暖かい”画像タイルリポジトリになり、バックエンドは、新しい画像タイル検索及びキャッシュ記憶のための統合デザインとして、二重フェイルオーバの場合に、存在し続ける。
【００４６】
図７は、一連の９０台の参照番号を用いて２層キャッシュ方法の実施例を示すブロック図である。図示しているように、ＷＭＳプロキシ９０は、“フェイルオーバ”における第２層キャッシュ９２及び“フェイルオーバ”におけるＷＭＳ９４により動作可能である。ＷＭＳプロキシ９０は、ＪＣＳ９６及びディスクＲＡＭのようなローカルメモリ９８により動作可能である。第２層キャッシュ９２は、ディスク／ＲＡＭのような分散メモリ９９により動作可能であり、その分散メモリはまた、他の分散メモリ９９により動作可能である。
【００４７】
ここで、図８を参照するに、システムがサーバにおけるタイルの準備の管理に限定される他の実施形態を示している。参照番号は１００台から始まっている。図１Ａに示すシステムにおける構成要素及びモジュールに対する機能に類似する構成要素及びモジュールが、１００台から始まる共通の参照番号が与えられている。
【００４８】
そのシステムは、参照番号１００で示され、図１Ａに示しているシステムに記載している基本構成要素の多くを含んでいる。一時的なファイルクリーンアップが管理され、新しいコンテンツがＷＭＳ１１８に付加されたとき、キャッシュはフラッシュされる。このＷＭＳは、重要な拡張性の可能性のために実行される。クライアント１１２、ＷＭＳプロキシ１１４、ネットワーク１１６、古典的ＷＭＳ１１８及びデータ１２０の５つの基本的構成要素を示している。図１Ａの好適なシステムと異なるものは、クライアントがタイル１６０をキャッシュすることが可能であるかどうかの判定が行われることである。それが否定的な場合、再サンプリングされることなく、タイルはモザイク化され、クロッピングされ１６２、マップがクライアントに関して生成される１５４。それが肯定的な場合、タイルはクライアントにおいてアセンブルされ１６４、マップがクライアントに関して生成される１５４。任意の負荷バランサ１５０を有するネットワークオプションにおいては、同じ古典的ＷＭＳ１１８及びデータ１２０が維持されている。勿論、タイルは、キャッシングのためにキャッシュ１３６に戻される。
【図１Ａ】
2010517079.tif 000014
【図１Ｂ】
2010517079.tif 000015
【図２】
2010517079.tif 000016
【図３】
2010517079.tif 000017
【図４】
2010517079.tif 000018
【図５】
2010517079.tif 000019
【図６】
2010517079.tif 000020
【図７】
2010517079.tif 000021
【図８】
2010517079.tif 000022
【手続補正書】
【提出日】平成21年3月27日(2009.3.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のマップ画像を処理するシステムであって：
キャッシュシステムからより高速でより緊急性の高いアクセス速度でアクセスされるようになっているマップタイルを記憶するための分散キャッシュと、より低速でより緊急性の低い速度でアクセスされるようになっている他のマップタイルのフェイルオーバキャッシュ及び記憶のための分散メモリを有する第２層キャッシュとを有する複数のマップタイルを記憶する２層キャッシュアーキテクチャを有するキャッシュシステム；
複数のマップ画像を記憶するウェブマッピングサービス；
クライアントのところでの表示のためのマップ画像についての要求を前記クライアントから受信するウェブマッピングサービスにより動作可能であるウェブマッピングサービスプロキシであって、該ウェブマッピングサービスプロキシは、
前記マップ画像についての要求を複数のマップタイルを得るための一連の要求に変換するタイルブローカモジュールであって、該タイルブローカモジュールは、第２層キャッシュから複数の第１マップタイルを戻すことにより及び前記第２層キャッシュから複数のマップタイルを検索するフェイルオーバー中に前記キャッシュシステム内にキャッシュされた複数のマップタイルが既に存在する場合に、該キャッシュされた複数のマップタイルを戻し、複数のマップタイルが前記キャッシュシステムから戻されない場合に、前記ウェブマッピングサービスから複数のマップタイルを検索するように動作可能である、タイルブローカモジュールと、
要求されたフォーマット及び解像度で前記複数のマップタイルから前記ウェブマッピングサービスプロキシにおいてマップ画像を構築し、前記クライアントのところで再サンプリングすることなく前記クライアントのところで前記マップ画像を表示するように動作可能であるタイル構築モジュールと、
を更に有する、ウェブマッピングサービスプロキシ；
を有するシステム。
【請求項２】
請求項１に記載のシステムであって、前記ウェブマッピングサービスプロキシがマップ画像を記憶している複数のサーバを更に有し、前記ウェブマッピングサービスプロキシプロキシにより動作可能である負荷分散モジュールと、前記複数のサーバ間で負荷分散するためのウェブマッピングサービスとを更に有する、システム。
【請求項３】
請求項２に記載のシステムであって、前記ウェブマッピングサービスプロキシは、前記ウェブマッピングサービスから検索される前記キャッシュにおいて複数のマップタイルを記憶するように動作可能である、システム。
【請求項４】
請求項１に記載のシステムであって、前記マップ構築モジュールは、複数のタイルをクロッピングし、モザイク化し、拡張することによりマップ画像を再構築するように動作可能である、システム。
【請求項５】
請求項４に記載のシステムであって、前記マップ構築モジュールは、全体的なモザイク及びクロッピングパラメータについて、クロップの原点位置及び目標位置並びにクロップの幅及び高さを用いて調整されるｘ及びｙ位置の詳細を調べる個別のタイルについてのタイル規格を構築するために動作可能である、システム。
【請求項６】
複数のマップ画像を処理する方法であって：
クライアントのところでの表示のためのマップ画像についての要求を前記クライアントからウェブマッピングサービスプロキシにおいて受信する段階；
前記マップ画像についての要求を複数のマップタイルを得るための一連の要求に変換する段階；
複数のキャッシュされたマップタイルがキャッシュシステムにおいて既に存在する場合に、前記複数のキャッシュされたマップタイルを戻し、複数のマップタイルが前記キャッシュにおいて存在しない場合に、前記ウェブマッピングサービスから複数のマップタイルを検索する段階であって、複数のキャッシュされたマップタイルを前記戻す段階は、より緊急であるとみなされる複数のマップタイルを記憶している２層キャッシングアーキテクチャの分散キャッシュからより高速のアクセス速度でより緊急であるとみなされる複数のマップタイルにアクセスして該マップタイルを戻す手順と、複数の他のマップタイルにアクセスする又は該マップタイルを検索するフェイルオーバー中に分散メモリを有する第２層キャッシュに記憶されているより低速の速度の複数のマップタイルにアクセスする手順とを有する、段階；
要求されたフォーマット及び解像度で前記複数のマップタイルからウェブマッピングサービスプロキシにおいてマップ画像を構築する段階；並びに
前記クライアントのところで再サンプリングすることなく前記クライアントのところで前記マップ画像を表示する段階；
を有する方法。
【請求項７】
請求項６に記載の方法であって、マップ画像を構築する前記段階は、複数のタイルをクロッピングし、モザイク化し、拡張する段階を有する、方法。
【請求項８】
請求項７に記載の方法であって、性能プリミティブ、オープンＧＬ／ＧＰＵ又はＪａｖａ処理を用いて複数のタイルをモザイク化し、クロッピングする段階を更に有する、方法。
【請求項９】
請求項６に記載の方法であって、前記キャッシュにおいて前記ＷＭＳから検索された複数のマップタイルを記憶する段階を更に有する、方法。
【請求項１０】
請求項６に記載の方法であって、前記ウェブマッピングサービスにおいて複数のサーバに複数のマップ画像を記憶し、前記複数のサーバ間で負荷分散する段階を更に有する、方法。
【国際調査報告】
2010517079.tif 000023
2010517079.tif 000024