"車両に実装可能なデバイスと通信を行うように構成されたサーバシステムであって、車両のパラメータを示す車両データを受信する通信リソースと、気象データを取得し、前記気象データ及び前記車両データの両方に従って少なくとも1つの気象関連条件を決定するために、前記気象データ及び前記車両データを処理するように動作可能な処理リソースとを備えることを特徴とするサーバシステム。前記少なくとも1つの気象関連条件を決定する前記気象データ及び前記車両データの処理は、前記気象データを修正又は検証することを特徴とする請求項1に記載のサーバシステム。前記気象関連条件は、少なくとも1つの場所での気象条件及び道路の条件の少なくとも一方を含むことを特徴とする請求項1又は2に記載のサーバシステム。前記車両データは、前記車両の動作プロパティ、及び、前記車両での気象関連条件を含む環境条件の少なくとも一方を表すことを特徴とする請求項1乃至3の何れか1項に記載のサーバシステム。前記処理リソースは、前記気象データと、前記車両データとに基づき、前記気象関連条件を決定するために、統計モデルを適用するように構成され、前記統計モデルは、過去の車両データと、過去の気象データと、少なくとも1つの気象関連条件の過去の発生との間における関係を表すことを特徴とする請求項1乃至4の何れか1項に記載のサーバシステム。前記少なくとも1つの気象関連条件を決定する前記気象データ及び前記車両データの処理は、気象関連の警告を表す警告データを修正又は検証することを特徴とする請求項1乃至5の何れか1項に記載のサーバシステム。前記処理リソースは、所定の時間期間にわたる前記気象データ及び前記車両データの少なくとも一方の変動に従って前記警告データを生成、修正、又は検証するように構成されることを特徴とする請求項6に記載のサーバシステム。前記処理リソースは、所定の時間期間にわたる車両の過去の変動、所定の時間期間にわたる気象データの過去の変動、及び前記少なくとも1つの気象関連条件の過去の発生の間の関係を表す統計モデルを適用することによって、前記警告データを生成、修正、又は検証するように構成されることを特徴とする請求項6又は7に記載のサーバシステム。前記警告データは、前記気象関連の警告の開始、終了、又は期間を表す時刻データを含み、前記処理リソースは、前記車両データを監視し、前記車両データに従って前記時刻データの生成、検証、及び修正の少なくとも1つを行うように構成されることを特徴とする請求項6乃至8の何れか1項に記載のサーバシステム。前記気象関連データは、気象のエリアの境界を表し、前記処理リソースは、前記車両データに従って前記境界の場所の検証、及び修正の少なくとも1つを行うように構成されることを特徴とする請求項1乃至9の何れか1項に記載のサーバシステム。前記通信リソースは、前記車両データと場所とを関連付けるために、前記デバイス及び前記車両の少なくとも一方の場所を表す場所データを受信するように構成されることを特徴とする請求項1乃至10の何れか1項に記載のサーバシステム。前記車両データは、前記車両のドライビング動作を表し、前記処理リソースは、前記車両のドライビング動作が前記気象関連データと整合するかどうかを判定するように構成されることを特徴とする請求項1乃至11の何れか1項に記載のサーバシステム。前記車両データは、1つ以上のスリップイベントの有無を表すことを特徴とする請求項1乃至12の何れか1項に記載のサーバシステム。前記車両データは、雨センサ、気温センサ、加速度センサ、角度モーメントセンサ、ブレーキセンサ、速度センサ、超音波センサ、レーダセンサ、又は、フロントワイパー、ヘッドランプ、サイドライト、フォグランプ、アンチロックブレーキシステムABS、エアーコンディショニングシステム、ブレーキ、暖房システムの1つ以上のセンサ若しくはモニタリングユニット、の少なくとも1つから取得されるデータを含むことを特徴とする請求項1乃至13の何れか1項に記載のサーバシステム。前記処理リソースは、複数の車両に実装される複数のデバイスから前記車両データを受信するように構成されることを特徴とする請求項1乃至14の何れか1項に記載のサーバシステム。前記処理リソースは、前記車両データが前記気象データと整合しないエリアにおける、車両の数、及び、車両の割合の少なくとも一方に従って前記エリアにおける前記気象データを修正するように構成されることを特徴とする請求項15に記載のサーバシステム。前記処理リソースは、エリアの少なくとも1つの車両に実装された複数のデバイスから受信した車両データに従って前記エリアにおける気象関連の警告を生成又は修正し、他のデバイスの場所に従って前記他のデバイスに前記気象関連の警告を選択的に送信し、前記他のデバイスは、前記エリアに存在することを特徴とする請求項1乃至16の何れか1項に記載のサーバシステム。前記車両データは、第1の車両システムから取得される第1の車両データと、該第1の車両システムとは異なる第2の車両システムから取得される第2の車両データとを含み、前記処理リソースは、イベントが発生したかどうかを前記第1及び第2の車両データから判定するように構成されることを特徴とする請求項1乃至17の何れか1項に記載のサーバシステム。前記イベントは、スリップイベントであり、前記第1の車両システムは、専用の車両スリップ検知システムを備え、前記第2の車両システムは、加速度センサ、角度モーメントセンサ、力センサ、ステアリングセンサ、及びブレーキングセンサの少なくとも1つを備えることを特徴とする請求項18に記載のサーバシステム。前記車両に実装可能なデバイスは、携帯ナビゲーションデバイス、又は、内蔵の車両ナビゲーションデバイスであることを特徴とする請求項1乃至19の何れか1項に記載のサーバシステム。車両に実装可能なデバイスと通信する方法であって、前記車両のパラメータを示す車両データをサーバで受信するステップと、前記サーバで気象データを取得するステップと、前記気象データ及び前記車両データの両方に従って少なくとも1つの気象関連条件を決定するために前記気象データ及び前記車両データを処理するステップとを含むことを特徴とする方法。請求項21に記載の方法の各ステップを実行可能なコンピュータで読み取り可能なプログラム。移動デバイスからデータを取得し、気象関連条件を判定する、例えば、取得したデータを用いて気象データを検証又は修正するシステムを図1に示す。システムは、複数のポータブルデバイス、例えばPND200a~200eと通信するように動作可能であるサーバ150を備える。分かりやすくするために、5つのデバイス200a~200eのみが示されるが、実際には数千以上のデバイスがサーバ150と通信していてもよいことが理解されるだろう。図1の実施形態において、デバイス200a~200eは、自身の位置を決定するために全地球即位システムGPS技術を使用し、ナビゲーション又はマッピング動作を実行できる車両搭載型のPNDである。デバイス200a~200eは、PNDであることに限定されず、例えば移動電話機又はポータブルコンピュータであるナビゲーション機能性を有するあらゆる適切な種類のデバイスであってもよい。サーバ150は、メモリ156に動作可能に接続されたプロセッサ154を含む。動作中、サーバメモリ156に格納されたソフトウェアは、プロセッサ154により読み出され、プロセッサ154が種々の処理又は通信機能を実行できるようにするソフトウェアモジュール又は他のソフトウェアコンポーネントをロードする。図1の実施形態において、ソフトウェアモジュールは、気象データ処理モジュール170を含む。気象データ処理モジュールの動作については、以下に更に詳細に説明する。サーバ150は、大容量データ記憶装置160に更に動作可能に接続される。大容量記憶装置160は、ナビゲーションデータの記憶部を含み、サーバ150とは別個のデバイスであるか又はサーバ150に内蔵される。大容量データ記憶装置160は、デバイス200a~200eからのプローブデータを格納するために使用される。サーバ150は、例えば専用の気象フィードを提供する第三者ウェブサイト又は気象通信センターである気象データの少なくとも1つの送信元180と動作可能に通信している。あるいは又はそれに加えて、気象データの少なくとも1つの送信元は、気象センサ、降雨レーダ又はモデル計算を実行するコンピュータを含むことができる。サーバ150は、あらゆる適切な通信チャネルを介して、例えばインターネット接続、専用有線接続又は専用無線接続を介して、気象データの少なくとも1つの送信元と通信する。サーバ150は、要望に応じて、複数の送信元からの正確な局地気象情報降水量、気温、風の状態及び暴風又は道路凍結等の地域の荒天警報に関する現在の情報/予報情報を含むがこれらに限定されないを収集及び融合できる。プロセッサ154は、通信チャネル152を介して、例えば送信機162及び受信機164を介して、デバイス200a~200eに対して情報を送受信するように動作可能である。送出及び受信された信号は、データ及び/又は他の伝播信号を含んでもよい。送信機162及び受信機164は、ナビゲーションシステムの通信設計において使用された通信要件及び通信技術に従って選択又は設計されてもよい。尚、送信機162及び受信機164の機能は、単一の送受信機に組み合わされてもよい。ナビゲーションデバイス200a~200eの正常な動作過程において、それらデバイスからのGPSデータは、例えばポータブルナビゲーションデバイス自体に含まれるデータロガーモジュールの形態であるロギングデバイスにプローブデータとして定期的に記録される例えば、あるシステムの場合は5秒毎。デバイス200a~200eから受信したプローブデータを受信及び処理すると共に、サーバ150は、例えばデジタル地図データ例えば、受信したプローブデータを考慮して更新されたデジタル地図データ、ソフトウェアアップグレード又は交通若しくは他の更新の形式でデータをデバイス200a~200eに提供できる。図1の実施形態の通信チャネル152はインターネット接続を含んでもよいが、あらゆる適切なデータチャネルの形態が使用可能である。通信チャネル152は、特定の通信技術に限定されない。チャネル152は種々の技術を使用するいくつかの通信リンクを含んでもよい。例えば通信チャネル152は、電気通信、光通信及び/又は電磁通信のためにパスを提供するように構成される。従って、通信チャネル152は、電気回路、ワイヤ及び同軸ケーブル等の電気導体、光ファイバケーブル、変換器、無線周波数RF波、大気又は空所のうちの1つ又はそれらの組み合わせを含むが、それらに限定されない。更に通信チャネル152は、例えばルータ、中継器、バッファ、送信機及び受信機等の中間デバイスを含むことができる。1つの構成例において、通信チャネル152は電話及びコンピュータネットワークを含む。更に通信チャネル152は、マイクロ波周波数通信等の無線通信、例えば赤外線通信、無線周波数通信に対応できてもよい。あるいは又はそれに加えて、通信チャネル152は衛星通信に対応できる。通信チャネル152を介して送信された通信信号は、所定の通信技術に対して要求又は要望される可能性があるような信号を含むが、これに限定されない。例えば信号は、時分割多元接続TDMA、周波数分割多元接続FDMA、符号分割多元接続CDMA、汎ヨーロッパデジタル移動通信システムGSM登録商標等のセルラ通信技術において使用されるように構成されてもよい。デジタル信号及びアナログ信号の双方とも、通信チャネル152を介して送信可能である。これらの信号は、変調、暗号化及び/又は圧縮されてもよい。一実施形態におけるナビゲーションデバイス200を図2に示す。尚、ナビゲーションデバイス200のブロック図は、ナビゲーションデバイスの全ての構成要素を含むわけではなく、多くの構成要素の例を表すだけである。ナビゲーションデバイス200は筐体不図示内に配置される。ナビゲーションデバイス200は、プロセッサ202を含む処理リソースを含み、プロセッサ202は、入力デバイス204及び例えば表示画面206であるディスプレイデバイスに結合される。ここで入力デバイス204は単数で参照されるが、入力デバイス204がキーボードデバイス、音声入力デバイス、タッチパネル及び/又は情報を入力するのに利用される他のあらゆる既知の入力デバイスを含む1つ又は複数の入力デバイスを表すことは当業者には理解されるべきである。同様に、表示画面206は、例えば液晶ディスプレイLCD等のあらゆる種類の表示画面を含むことができる。1つの構成において、タッチパネル及び表示画面206は、ユーザが複数の表示選択肢のうちの1つを選択するか又は複数の仮想又はソフトボタンのうちの1つを有効にするために表示画面206の一部分にタッチするだけでよいように、タッチパネルスクリーンを介する情報の入力直接入力、メニュー選択等による及び情報の表示の双方を可能にするタッチパッド又はタッチスクリーン入力を含む一体型入力表示デバイスを提供するように一体化される。この点に関して、プロセッサ202は、タッチスクリーンと共に動作するグラフィカルユーザインタフェースGUIをサポートする。ナビゲーションデバイス200において、プロセッサ202は、接続210を介して入力デバイス204に動作可能に接続され且つ入力デバイス204から入力情報を受信でき、各出力接続212を介して表示画面206及び出力デバイス208のうちの少なくとも一方に動作可能に接続されて情報を出力する。ナビゲーションデバイス200は、例えば可聴出力デバイス例えば、スピーカである出力デバイス208を含んでもよい。出力デバイス208は、ナビゲーションデバイス200のユーザに対して可聴情報を生成できるため、入力デバイス204は、入力音声コマンドを受信するためのマイク及びソフトウェアを更に含むことができることが同様に理解されるべきである。また、ナビゲーションデバイス200は、例えばオーディオ入出力デバイス等のあらゆる追加の入力デバイス204及び/又はあらゆる追加の出力デバイスを含むことができる。プロセッサ202は、接続216を介してメモリ214に動作可能に接続され、接続220を介して入出力I/Oポート218との間で情報を送受信するように更に構成される。ここで、I/Oポート218は、ナビゲーションデバイス200の外部のI/Oデバイス222に接続可能である。外部I/Oデバイス222は、例えばイヤホン等の外部リスニングデバイスを含んでもよいが、これに限定されない。更にI/Oデバイス222への接続は、例えばイヤホン又はヘッドフォンへの接続のため及び/又は移動電話機への接続のためのハンズフリー動作及び/又は音声起動動作のために、カーステレオユニット等の他のあらゆる外部装置への有線接続又は無線接続であってもよい。移動電話機接続は、例えばナビゲーションデバイス200とインターネット又は他のあらゆるネットワークとの間のデータ接続を確立するため、並びに/あるいは例えばインターネット又は他のネットワークを介するサーバへの接続を確立するために使用される。次に添付の図面の図3を参照すると、デバイス200の内部フラッシュメモリ不図示は、機能ハードウェアコンポーネント254による実行のために記憶装置214からオペレーティングシステム250及びアプリケーションソフトウェア252をロードするためにプロセッサ202により実行可能なブートローダプログラムを格納し、これによりアプリケーションソフトウェア252が実行可能である環境が提供される。オペレーティングシステム250は、機能ハードウェアコンポーネントを制御し、アプリケーションソフトウェア252と機能ハードウェアコンポーネント254との間に常駐する。アプリケーションソフトウェア252は、例えば地図閲覧、経路計画、ナビゲーション機能及びそれらと関連付けられた他のあらゆる機能であるナビゲーションデバイス200の中核機能をサポートするGUIを含む動作環境を提供する。アプリケーションソフトウェア252は、経路を計画でき、既知の技術を使用して経路の各セグメントの予想移動速度に基づいて目的地への予想到着時刻を決定できる。デジタル地図の道路又は他の主要道路の各セグメントの予想移動速度は速度データとしてデバイス200に格納され、必要に応じてアクセスされる。速度データは、サーバ150からの速度データ更新データを介して更新される。アプリケーションソフトウェア252は、少なくとも1つのセンサによって実行される測定を表すデータを受信し処理し、これによりセンサ生成データを取得するデータ処理モジュール260と、データロギングモジュール262とを含む。処理モジュール260及びデータロギングモジュール262の動作の詳細については後述する。ナビゲーションデバイス200は、車両に配置されたドッキングステーションへドッキングさせることができる。例えば、ナビゲーションデバイス200は、例えば、吸着カップを用いて、車両のダッシュボード又はウィンドウに固定されるアームに配置されてもよい。図4を参照すると、車両にドッキングされると、ナビゲーションデバイス200は、車両の少なくとも1つの電子データバス300と通信可能となる。ナビゲーションデバイス00は、ドッキングステーションでの直接接続か、又は、無線接続かのいずれかを介して、インタフェース部301の手段によりバス300と通信してもよい。例えば、インタフェース部301は、車両の無線インタフェース例えば、Bluetooth登録商標インタフェースを備える。データバス300は、車両の種々のセンサモジュール302と、制御又はモニタリングモジュール304との間で信号を伝達し、当該種々のモジュールが通信することを許容する。モジュール302、304は、車両の制御動作又はモニタリング動作における車両のシステムの一部を形成してもよい。一例として、制御又はモニタリングモジュールは、エンジン制御部ECU304a、トラクション制御モジュール304b、サスペンション及びスタビリティ制御モジュール304c、ヘッドランプ制御モジュール304d、フロントワイパー制御モジュール304e、フォグランプモジュール304f、アンチロックブレーキシステム304g、送信制御モジュール304h、ブレーキモジュール304i、及び気候制御モジュール304jを含む。一例として、センサモジュールは、降雨センサ302a、ステアリング位置センサ302b、光センサ302c、外部環境気温センサ302d、1つ以上の送信及びエンジン性能センサ302e、少なくとも1つの角度モーメントセンサモジュール302f、1つ以上の車両速度センサ302g、レーダモジュール302h、及び超音波モジュール302iを含む。特定の車両が制御モジュール、モニタリングモジュール、及びセンサモジュールの任意の組み合わせを有することができることは理解されるであろう。代替的に又は追加的に、車両は、車両のステータス又は性能の任意の適切な形態を測定するか、又は、車両が対象となる任意の適切な環境条件を測定するための、種々の制御モジュール、モニタリングモジュール、及びセンサモジュールの少なくとも1つを含んでもよい。データバス300は、種々のモジュール間の情報転送や質問又はモジュールからの情報の受信を可能にする。データバス300は、配信通信ネットワークを実装するために自動車産業において広く使用される制御エリアネットワークバスCAN-busプロトコルなどの、確立されたデータバスプロトコルに従って動作してもよい。センサモジュール302の少なくとも1つは、代替的に又は追加的に、バス300を介して、専用の直接接続不図示を介して各制御モジュール304と通信を行ってもよい。そのような直接接続は、例えば、センターからの連続した信号が制御モジュールによって必要とされる場合、又は、信号が安全なデータパスを介して送信される必要がある場合に使用されうる。センサ信号がバス300から利用されるだけでなく、本実施形態によって使用されるデータはバス300及びインタフェース部301の少なくとも一方を介して直接的に又は間接的に取得可能である。代替の実施形態において、車両は、拡張されたフローティングカーデータxFCD機能を備える。xFCDインタフェースがデバイス200の代わりに或いはデバイス200とともに設けられる。xFCDインタフェースは、車両の不可欠な部分として製造業者によって提供される専用のインタフェースであってもよい。そのような代替の実施形態において、種々のモジュール302、304からのデータは、車両の現在の位置とともにxFCDインタフェースによって直接的にサーバに送信されてもよい。或いは、デバイス200が車両のxFCDインタフェースと通信し、データを取得するために使用されるxFCDインタフェースを含んでもよい。ユーザがナビゲーションデバイス200の電源を投入すると、デバイス200は、GPSフィックスを取得し、ナビゲーションデバイス200の現在地を計算する既知の方法で。ユーザは、ナビゲーションデバイス200が配置されると決定されるローカル環境を疑似3次元で示し且つローカル環境の下のディスプレイの領域において一連の制御及び状態メッセージを示すディスプレイが提示される。ローカル環境のディスプレイをタッチすることにより、ナビゲーションデバイス200はアイコンにより表される一連の仮想又はソフトボタンを表示するように切り替え、これにより、ユーザはナビゲートしたい目的地を入力し且つナビゲーションデバイス200の制御又はディスプレイ上のデータの表示に関連する他の種々の機能を実行できる。ナビゲーションデバイス200の動作中、例えば車両の動作中において、ステータスデータ又はセンサ出力センサから生成されたデータなどの車両データを取得するために、センサ、制御又はモニタリングモジュール302、304からのデータがデバイス200によって取得されて処理され、その後、サーバ150に送信されることが本実施形態の特徴である。車両データは、各イベントのイベントデータを含むことができる。サーバ150は、少なくとも1つの気象関連条件を決定するため、例えば、気象データの検証又は修正を行うため、或いは、気象の警告の検証、修正、又は生成を行うために、多数のデバイスから受信されうる、車両データを使用する。このように、システムは、気象予報から取得されるよりも正確性又は分解能の高い気象関連情報を提供することができる、個々の車両の測定結果や動作を考慮することができる。車両データを考慮する車両の動作については、以下で詳細に説明する。まず、車両に実装された単一のデバイス200によって処理データ及びロギングデータについて以下に説明する。図5は、図1、2、4の実施形態における1つの動作モードを図示したフローチャートである。本実施形態の特徴は、車両に設けられたセンサ、制御又はモニタリングシステムから取得するデータであり、例えば、車両の通常の動作中に1つ以上のモジュール302、304からのデータであり、局所的な気象条件を測定するか又は推測するために使用されうる。このように、PND200の処理リソースにおける処理モジュール260は、図5の段階400に示すように、モジュール302、304の1つ以上から受信されるデータをモニタリングする。異なる車両内蔵のセンサ、制御システム又はモニタリングシステムから得られる種々のパラメータの広範囲の何れかが、センサ、制御システム又はモニタリングシステムの本体の目的を意図していない場合であっても、局所的な気象条件に関する情報を決定するために使用される。図5の動作モードにおいて、処理モジュール260は、例えば、ジャイロスコープ、加速度メータ、及び全てのホイールからのホイール速度から受信されるデータをモニタリング監視する。処理の段階402において、処理モジュール260は、センサ間の不整合がホイールスリップとして警告を与えるべきであるかどうかを決定するために、受信データを処理する。当該不整合は、車の動力や動的モデルに基づいて判定される。単一のスリップの所定の種別は、ホイール速度の不整合のみから判定される。サイドのコンポーネントは、ジャイロスコープ、動的モデル動力モデル、及び理想的な可能な限り間接的な力測定を必要とする。図5の実施形態では、スリップスケールが、道路スリップ条件又は、接着条件にスリップイベントをマッピングするように定義されている。実際の全ての関連ケースでは、道路条件の測定は、単一の数値で表現することができ、例えば、0から1の間のスケールである。ここで、0は車両のホイールに対してゼロの摩擦力の極端な例を示し、1は、理想的な乾燥した表面の他の極端な例を示す。本目的においては、種々の種別のホイール、種々の種別の路面極端でなければ、道路接触領域当たりの種々の圧力、及び接触摩擦と動的摩擦との間の差異の効果これらは、大体2つに満たない要因により異なることが想定されるは、我々がゼロに近い車依存のスリップスケールと懸念しているように、実際には無視される。処理モジュール260は、GPSデータ、角度モーメント、及び速度データの少なくとも1つを処理し、スリップスケールに従ってスリップ値を決定する。スリップスケールは、テスト車両を用いて、前もって行われた多くの測定に対して調整されうる。次に段階404において、ロギングモジュール262は、デバイス200の場所及び車両の場所を表す場所データとともに、算出されたスリップ値を格納する。スリップ値は、気象条件の指標、例えば、道路の凍結又は水たまりの存在を提供することができる。他の実施形態において、処理モジュール260は、スリップ値と、閾値とを比較し、比較結果に基づきスリップ又は未スリップを示すバイナリのスリップデータを決定する。この場合、スリップ値よりもむしろバイナリスリップデータがロギングモジュール262によって格納される。段階400乃至404でのデータの読み取り、処理、格納は、例えば5秒ごとに定期的に繰り返して実行される。続いてログデータはサーバ150に送信される。当該データは、当該データが事後統計解析に使用される場合に、無線接続を介して、例えば5分ごとに定期的に送信されてもよく、或いは、デバイス200が車両から取り除かれ、例えば、PCへ接続されたドッキングステーションを介してインターネットへ接続された際に送信されてもよい。イベントベースの送信アプローチも使用されてもよく、当該データ例えば、以下の任意のフィルタリングプロセスが行われたデータが興味が有り、可能性のあるイベントを表すと思われる場合にのみ送信されてもよい。いくつかのケースにおいて、そのようなスリップイベントが検知されることに応じて、スリップイベントを表すデータのみがサーバ150へ送信され、送信されるデータ量を低減する。図5は、スリップイベントに関連するデータのモニタリング及び格納に関して説明している。代替の実施形態において、データが気象関連パラメータを表す、又は、気象関連パラメータを決定するために使用されうるのであれば、車両センサ又は他のデバイスから任意の適切なデータが処理され格納されうる。例えば、代替の実施形態又は動作モードにおいて、モジュール260は、フロントワイパー304a、降雨センサ302a、光センサ302c、気温センサ302d、ヘッドランプ制御モジュール304d、ブレーキモジュール304i、フォグランプ制御モジュール304f、レーダモジュール302h、及び超音波モジュール302iの少なくとも1つからデータを受信する。受信データストリームは、モジュール260により処理され、ロギングモジュール262により記録される。いくつかのケースにおいて、モジュール260による処理は、単にデータをロギングモジュール262に転送する処理を含む。他のケースにおいて、モジュール260によって追加の処理が実行される。例えば、モジュール260は、特定のイベントが発生したかどうかを判定するためにデータを処理することができ、その後、ロギングモジュール262は、イベントの発生又は未発生を表すイベントデータを格納する。例えば、モジュール260は、平均気温が0度又はいくつかの閾値を下回る場合には、少なくとも所定の期間ごとに例えば、1分ごとに、気温をモニタリングして低温イベントデータを生成してもよい。他の例において、モジュール260は、フロントワイパーの動作をモニタリングし、フロントワイパーが所定の期間の間例えば、1分の所定の閾値部分例えば、75よりも長く動作していれば降雨イベントデータを生成してもよい。イベントデータ、他のステータス、又はセンサ出力データは、サーバ150へ送信されるのに続いてロギングモジュール262によって格納される。ロギングモジュール262は、また、車両データを取得する時間に車両の場所を表す場所データを格納し、場所データと車両データとを関連付ける。場所データは、また、サーバ150へ送信される。多くの実施形態において、例えば速度データを含んでもよいいくつかの種々の種別の車両データは、場所データとともに記録され、サーバ150へ提供される。データ転送の要件を低減するために、例えばデータ及びイベントの記録前後の何れかにおいてモジュール260によって、データ及びイベントの知的フィルタリングがデバイスに直接実装されうる。そのようなフィルタリングは、例えば、通常のブレーキアプリケーション又は特定の急加速中における転送されてくるホイールのスリッピングなどの共通イベントを防止することができる。異なるフィルタリング処理は、種々の種別のイベント、例えば、滑りやすい路面、降雨、道路上の障害や渋滞などのイベントを対象とする。我々が滑りやすい道路条件に起因するスリップイベントのみに興味がある場合、フィルタリングの目的は、例えば急加速又は急ブレーキなどの他の要因から発生するときは単純に説明されうるスリップイベントであって、滑りやすい路面を示す必要がないスリップイベントを抑えることである。種々の異なるイベント滑りやすい道路条件のみではないと関連付けられたフィルタリング処理の一例について以下の段落で説明する。1つのフィルタリング処理は、過度の加速度に起因するよりもむしろ道路又は他の条件に起因する真のスリップを示すように、低直線加速度、所定レベル未満のアクセルペダルの動作と関連付けられるスリップイベントを検知するために角度モーメントフィルタを適用するステップを含む。他のフィルタリング処理は、高加速又は減速が通常の道路条件を示す測定された角度モーメントと整合するイベントを検知するために角度モーメント分析を用いるステップを含む。さらに他のフィルタリング処理は、信号の横断又は通路の横断後者においては、通常の平凡な交通シナリオとしてもっともらしい加速のみの際のもっともらしい加速又は減速を除去するために、現在の位置、デジタル地図データ、及び加速又は減速データを相互に関連付けるステップを含む。さらに他のフィルタリング処理は、ブレーキングイベントが障害の存在に関連付けられるかどうかを判定するために、超音波距離センサからの測定とブレーキングイベントとを相互に関連付けるステップを含む。さらに他のフィルタリング処理は、降雨よりもむしろ、ワイパーの操作、及び洗浄液のアプリケーションによる検知された水の存在の少なくとも一方を識別することができる、外部の水センサの動作、洗浄液のアプリケーション、及びフロントワイパーの動作とを相互に関連付けるステップを含む。スリップイベントの検出に関連して上述したように、モジュール260は、1つ以上のセンサ、制御又はモニタリングモジュールから受信されるデータに基づき、イベントの発生又は未発生を決定するように動作可能である。いくつかの車両では、製造業者は、特定のイベントが発生するかどうかえお自動的に決定するシステムを備え、そのようなイベントの発生を表すイベント信号がCANバスから読み出される。例えば、いくつかの製造業者は、CANバスからのスリップイベントを表すイベント信号の読出しを許容するスリップ検知システムを有する。所定の車両における製造業者のスリップ検知システムは、スリップが発生するか発生しないかを表す解釈又は閾値に基づいている。検知システムが有益な情報を配信しうるため、それは製造業者のスリップ検知システムからのデータを使用するのに役立つ。製造業者は車両の動的なプロパティを認識しており、製造業者のみがアクセス可能な場所に直接力センサ又は角度モーメントセンサなどの高機能な感覚システムを実装することができる。製造業者のシステムは製造業者の特定のキャリブレーションに基づくものであるため、デバイス200のモジュール260が製造業者の専用のスリップ検知システムからのデータを検証又はキャリブレーションするために、専用のスリップ検知システムと他のセンサからの出力とを合成することはいくつかの実施形態における特徴である。製造業者のスリップ検知システムは、適切な解釈可能な情報であって、路面に平行して道路に対して車両の力を判定するために解釈されうる又は表す情報を配信できれば、路面の滑りの改善されキャリブレーションされた測定全体に寄与することができる。特定の有用な専用のスリップ検知システムの一例は、レギュラーインターバル例えば、ミリ秒のオーダのインターバルでの力又は角度モーメントデータと、瞬間的なスリップあり/なしを示す出力データとを、可能な限りスリップ距離とともに発行することである。他の有用なシステムは、スリップ距離とともにスリップイベント信号と、スリップイベント後の最小の力又は角度モーメントデータを発行することである。上記2つのシステムの両方は、所定の力又は角度モーメントの閾値及び距離の閾値を下回る場合にのみ指標データを出力するようにしてもよく、これにより、極端なドライバの動作による明らかなスリップを無視することができる。有用な専用のスリップ検知システムの他の例は、標準の距離インターバル例えば、キロメータごとで、スリップイベント又はゆっくり蓄積された小さいスリップ又は連続した複数のスリップを介してヘディング不一致を表すいくつかの測定を含む数値を発行することであるか、或いは、ABSが起動しているかどうかを示す信号を出力し、より好ましくはさらに角度モーメント情報を配信することである。横向きのスリップ又はスピンは、ABSシステムのみからでは判定できないが、動的な不一致の探索により検知されることに注意しなければならない。それぞれの専用スリップ検知システムが各ホイールごとに区別してデータを提供するのであれば、ここでは最も有用である。上述したように、製造業者の専用のスリップ検知システムからの出力は、所定のキャリブレーションされたスケールに従ってスリップイベントが発生したか否かを確実に判定するために、他のシステムからの出力、例えば、力又は角度モーメントデータ、GPSデータ及び速度データと合成して処理されうる。異なるシステムからのデータを合成するために3つの異なるアプローチについて説明する。それらのシステムは、システムA例えば、製造業者の専用のスリップ検知システムと、システムB例えば、他のセンサからのスリップの有無、又はCANバスを介して取得される制御システムデータを判定するモジュール260として参照される。第1のアプローチにおいて、2つのシステムA、Bのそれぞれは、可能な限り重要な結合可能密度で、バイナリデータスリップ有り/無しを生成する。単純な論理AND操作は、システムA,Bの両方がスリップイベントを示した場合にのみ発生するモジュール260によって判定されるスリップイベントと、2つのソースからのデータを合成する最もダイレクトなアプローチであろう。しかしながら、システムA及びシステムBからの結果が全ての状況下で偽ポジティブ及び偽ネガティブの等しい可能性からは連帯して独立しているということが想定されるであろう。当該想定は、多くのケースにおいて実際に正しいことはないであろう。完全な検知を行う4つの理想のケースがある。-システムAが常に正しい特異性及び感度=1。-システムBが常に正しい特異性及び感度=1。-システムAがスリップ有りを検知する場合は間違っていなく、システムBがスリップ無しを検知する場合は間違っていない。-システムBがスリップ有りを検知する場合は間違っていなく、システムAがスリップ無しを検知する場合は間違っていない。さらに2つの可能な中間ケースがある。-システムAがスリップ有りを検知する場合はほぼ間違っていなく、システムBがスリップ無しを検知する場合はほぼ間違っていない。-システムBがスリップ有りを検知する場合はほぼ間違っていなく、システムAがスリップ無しを検知する場合はほぼ間違っていない。実際に、問題になっている車両やシステムに依存する全ての4つのケース間ではシームレスにシフトすることができる。特定の車両の種別及びシステムの種別において、キャリブレーション手続きは、テスト車両を用いて実行される。可能であれば、テストに使用されるハードウェア/ソフトウェアは、個々の動作と、システムA及びB両方の結果に対する結合の可能性とを決定するために、全ての現実的で関連のあるスリップほぼスリップシナリオに対してデータを測定する。テストから得られるキャリブレーションデータから導出されるモデルがその後デバイス200に提供され、当該デバイス200で格納される。理論的には、エラー動作がスリップシナリオに依存するであろうために、上記シチュエーションは複雑になりうる。複雑なケースにおいて、測定されたパラメータは、力、速度、現在の曲り、及び遠心力の規模や、例えば、ますっぐなのか横向きなのかその両方なのか、加速に起因したスリップなのか、ブレーキに起因したスリップなのかを示すスリップの種別である。スリップが有るのか無いのかの決定者を判定するために、2つのシステムA及びBからの出力の合成は、以下の表1に示すように、空間の各ポイントが感度-特異性テーブルによって表される多次元のパラメータベクトル空間の関数である。実際に、最終的なパラメータ空間は、適当な数の感度-特異性テーブルをもたらす少しの変数と、変数当たりの少しのインターバルを含むであろう。スリップが有ったか無かったかに関する決定的でない結果それ自身が有用な情報を表すを決定者が与える閾値パラメータ以下での選択は、操作者の優先事項及びリスクマネジメント基準に基づいて判定されうる。一般的に、ここでは、偽ネガティブスリップ無しの結果による潜在的なダメージは、偽ポジティブスリップ有りの結果よりも大きい。システムA及びシステムBからのデータに基づきスリップが有るかスリップが無いかを判定する第2のアプローチは、連続した測定と、加重決定処理とを用いる。閾値ベースのバイナリ決定処理スリップの有り/無しに使用される適切なパラメータは、ホイールスリップを起こさせるの必要な道路と並行の力である。これは、そのような力が1つの数字で表され、必要であればモデル解釈可能な物理量であるため、特に有用である。実際には、我々は、ノイズレベルより十分に上であり、かつ、スリップの共通理解を反映する、ホイール当たりのスリップ距離の適当な閾値を使用する。このアプローチは、製造業者の専用のスリップ検知システムからの出力が道路と並行の力を含むか、又は、当該出力が道路と並行の力を判定するために使用されることを必要とする。2つの道路に平行な力の検知システムシステムA及びシステムBが技術的に同等であり、かつ、同等の期待値を配信するが、共同の独立した相互に関係の無いノイズがあることが想定されるのであれば、真値に最も近似し、且つ不偏な値は、以下の数式によって推定される。f=1/2fAfBここで、fA及びfBは、2つのシステムA及びシステムBによって測定される値である。この推定は、実際には完全には正しくないであろう。測定値fA及びfBの統計プロパティは、前述のパラメータベクトルスリップシナリオに依存するであろう。例えば、低い力での急カーブにおいて、システムAは、高い統計精度例えば、再現性を有するものの、大幅に真値から過大評価するかもしれない、或いは、高い統計スプレッドを有するものの不偏の期待値を配信するかもしれない。実際には、本実施形態では第2のケースを扱うことを想定している。車両の特定の種別及びシステムの特定の種別に関して、キャリブレーション手続きがテスト車両を用いて実行される。テストにおいて、ハードウェア/ソフトウェアは、現実的な関連のある全てのスリップ及びほぼスリップに対するデータを適切な回数のシナリオで測定する。この回数は、力値fA及びfBの統計スプレッドと、スリップの有無に関する正しい決定と誤った決定との割合とに依存する。回数Nのシナリオは、必要統計精度1/sqrtNに依存して繰り返される。ここで、Nは最も発生しづらいイベントの数となる。続く分析は各システムの加重要因a及びbと関連付けられる。f=1/abafAbfBここで、a及びbは、上述したパラメータ空間の関数であり、例えば、力のパラメータ、カーブ、速度、ブレーキ/アクセスのレベル量及び任意の適切なパラメータを含む。第1のアプローチの場合のように、最終的なパラメータ空間は、変数当たりの少しの変数及び少しのインターバルのみを含むであろう。システムからのより信頼できないデータ高い統計スプレッドの場合低いa及びb、当該決定は、有用な情報を表す、スリップ有り/なしよりもむしろ、結論の無い結果を与えるかもしれない。各システムA及びBは、力の測定値評価値fA及びfBとともに、スリップ有り、スリップ無しを表すイベントデータを提供する。スリップ有り/スリップ無しの信頼性は、力値評価値fA及びfBと、格納されたa及びbの値とを用いて決定される。続いて発生するスリップイベント又は長いスリップイベントは、異なる時間での一連の評価され、測定された力を提供することができる。1つのスリップイベントから次のスリップイベントへのスリップ閾値の力の一貫性は、特定の車の現在の道路条件の測定の総合的な信頼性を判定するために使用されうる。テストから決定されるパラメータ空間の複数のパラメータの関数としてa及びbの値を表すキャリブレーションデータは、デバイス200へ連続的に提供され、格納される。運転中において、スリップ有り又はスリップ無しを表すイベントデータ、及び力fA又はfBの測定値又は評価値は、システムA及びシステムBから取得される。モジュール260は、モデルを用いて、スリップが有ったか又は無かったかを判定し、或いは、データに基づき結論のない結果を提供する。第3のアプローチにおいて、一般的な統計メソッドを用いて融合分類が行われる。当該アプローチにおいて、単一のシステムA及びBのバイナリ決定スリップ有り又はスリップ無し、力値fA及びfB、所定の期間にわたる力値の各標準偏差、DfA及びDfB、及び追加の利用可能なパラメータ例えば、限定はしないが、カーブ、遠心力、速度、ブレーキ/アクセルに基づいて、システムA及びBの何れかによって検知されるスリップイベントが本当にスリップイベントである可能性は、限定はしないが、多次元線形分類、多次元線形判別、支援ベクトルマシン、ニューラルネットワーク、期待値最大に基づくクラスタリングアルゴリズム、又は決定木を含む、一般的な統計アルゴリズム及び方法を用いてモデル化されうる。第1の2つのアプローチで使用される同様の方法において、統計アルゴリズム及び方法は、各システムで区別した可能性よりもより堅固な分類を目的とし、全てのイベントに対して個々のスリップ条件の誤判別の可能性を最小化するために、意味のある方法でシステムA及びBの決定を融合するために使用されうる。一方、上述した種別のより高度な一般的なアプローチは、原則として、数少ない単純化した仮定を作成し、より少ない事前知識のみを必要とし、第1の1つのアプローチよりもより良い分類性能を提供する可能性を有する。一方、それらは、上述したようなテスト車両を用いて実行されるキャリブレーション測定から導出される利用可能なトレーニングデータの十分な量をより重く必要とし、またデバイス200でより精密なソフトウェア機能を必要とする。ハイブリッドのアプローチにおいて、第2のアプローチの加重機能a及びbは、第3のアプローチに関連して記載された種類の統計モデル化アプローチを用いて判定される。これは、必要な統計分析及び生成されたモデルの複雑性を低減し、デバイスの機能を単純化し、且つ包括的なキャリブレーションデータへの依存を軽減することができる。3つのアプローチのそれぞれで必要とされるキャリブレーションは、種々の速度でのブレーキやアクセス、カーブ又は他のパラメータの値におけるすべての要望されるシナリオ通じて実行されるコンピュータ化されたドライバを用いて自動化された方法で実行されうる。収集されたデータは、多次元のパラメータ空間に対応するデータ構造で保存される。1つ以上の所望のアプローチに従ってシステムA及びBからのデータを融合又は合成する融合/合成モデル及び関連するキャリブレーションデータがデバイス200で格納される。いくつかの実施形態において、複数のモデル及びキャリブレーションのセットがデバイス200で格納され、異なるモデルは、異なる製造業者からの複数のデバイスに特定される。そのようないくつかの実施形態において、デバイス200は、接続された車の製造業者又は、局所的なスリップ検知機能を自動的に検知し、適切なモデルを選択する。キャリブレーション測定及びモデル生成が検知された車両又はシステムに対して実行されない場合、より単純なデフォルトモデルが使用される。モジュール260が2つのシステムA及びBからのデータに基づいてスリップイベントがあったか否かを判定すると、スリップがあったかどうかを表すスリップイベントデータを生成する。上述したように、スリップイベントデータは、データロギングモジュール262によって記録され、その後サーバ150へ提供される。異なるソースからのデータの合成についてスリップ検知システムに関連して説明したが、説明したアプローチは、任意の適切なソース、例えば、任意の適切なセンサ又はイベント検知システムからのデータを合成するために使用されてもよい。上述したように、デバイス200は、ステータス又はセンサ出力データをサーバ150へ提供する。サーバ150は、少なくとも気象関連条件を決定するため、例えば、気象データを検証又は修正するために受信したデータを使用する。詳細については図6が提供するフローチャートを用いて説明する。第1段階の処理において、サーバ150は、気象関連データ、例えば、気象データソース180からの気象データを受信する。1つのモデルの動作において、サーバ150は、気象データソース180から、定期的に、例えば15分ごとに現在の気象データを受信する。一般に現在の気象データは、最新の測定気象データと、未来の時間、例えば未来の3時間の間の15分間隔の予報気象条件を表す予報気象データセットとを含む気象データセットを含む。各気象データセットは、各々が領域の各場所における気象条件例えば、降雨量を表す複数のデータ点を含んでもよい。いくつかの例において、データ点は、領域にわたる等間隔の点に対応してもよい。いくつかの実施形態において、あらゆる適切なデータ形式が使用可能であるが、気象データはテキストデータ又はXMLデータの形式である。いくつかの例において、気象データセットは、特定の時間における領域の気象条件を表す画像を表示するために使用される気象データのフレームを含むか又はそれを生成するために使用される。いくつかの動作モードにおいて、サーバ150は、各々が1つの特定の時間における異なる気象条件例えば、降雨量、気温、風速を表す複数の気象データセットを受信してもよい。段階152において、サーバ150はまた、車両内臓のデバイス、例えば、上述したPNDデバイスなどから車両データを受信する。サーバ150は、大抵、多くのデバイス、例えば、複数のPNDデバイスからのデータを受信する。気象データ処理モジュール170は、位置依存の車両データと、受信した位置依存の気象データとを関連付け、これにより気象データを検証又は修正する。このように、不確かな外部ソースからの情報は、検証又は修正され、気象の警告は生成され、修正され、及び特定のエリアでよりフォーカスされるかの少なくとも1つが行われる。気象データと局所的な車両データとの融合は、実質的に制限された信頼性内のソースから情報を有効にし、気象条件、例えば、豪雨や凍結の位置特定をより改善するために使用され、さもなければ対応するセンサが備え付けられた道路の類似の程度に局所化されうる。上述したように、ステータス又はセンサ出力データの多くの異なる種別は、デバイス、例えば、デバイス200によって提供される。モジュール170によって実行されるデータの処理と、関連付け又は他の統計手続きとは、データの特定の種別問題のあるアプリケーションに依存して検証されうる。動作の1つのモードにおいて、気象データ処理モジュール170は、多くの車両デバイスから受信されるステータス又はセンサ出力データによって表されるように、場所及び時間の関数として、フロントワイパーの動作量、降雨センサデータ、及び昼間のヘッドライト起動を判定する。例えば、種々の他の環境パラメータ又はトラフィックパラメータも表すことができるモデルに基づき、特定の場所及び時間間隔における、フロントワイパーの動作量、降雨センサデータ、及び昼間のヘッドライト起動の少なくとも1つが降水がある、例えば、降雨があることを提案するのであれば、モジュールは、モデルに基づく場所及び時間で降水がある、例えば、降雨があることを決定する。単純なケースにおいて、モデルは、フロントワイパーの動作、降雨センサデータ、及びヘッドライトの起動を閾値と比較することを単に含んでもよい。その後、モジュール170は、各場所に対して、雨の実際の若しくは予測の有無又は他の降水を示す気象データと、後述する閾値手続きでの受信した車両データから決定される降水の有無とを比較する。特定の場所において、気象データが当該期間の間は降水がないであろうことを示すものの、車両データがフロントワイパーの動作、ヘッドライトの起動及び雨センサデータからのデータ降雨又は他の降水があることを示す場合、モジュール170は、気象データを当該場所において、降水があることを示すように修正する。閾値は、所定の気象条件の存在を確実に示すために、所定の時間間隔内で超えるべき必要のある特定の領域又は特定の場所からを起源とする、指標イベント例えば、フロントワイパーの動作、ヘッドライトの起動、又は雨の存在を示す雨センサデータの数に基づき定義されうる。特定のケースで使用される閾値は、問題となる気象条件の本質及び重大性に依存することができる。例えば、より高い閾値は、豪雨の有無を判定するために使用されることができ、より低い閾値は、小雨の有無を判定するために使用されることができる。閾値は、気象条件を示すデータを生成できる適切に装備された車両の評価された数にも依存することができる。利用可能な車両の数は、現在の交通密度、例えば、車両間の距離を示す車両超音波及びレーダセンサデータから、同様に、Tom-TomIQ経路システムで使用されるような、時間分解された道路指定の履歴交通統計から得られる交通密度についての情報に基づいて決定されてもよい。本実施形態において、閾値と多くの車両又はイベントを比較する処理は、車両例えば車両の数と比較される又はイベント例えば、可能性のあるイベントの数と比較されるの割合と、ここで示される閾値とを比較する処理を等しく含む。所定の気象条件の有無を示すために必要な閾値を定義するのに使用されるモデルが判定されうる。或いは、全ての収集されたイベントデータ、他のデータ、又は、センサ出力データは、過去の外部の気象データ、他の関連パラメータ、及び事後検証された気象条件とそれらのデータと関連付けることにより、履歴のデータベースに格納され、統計的に分析される。そのような過去の統計分析を用いることによって、所定のシチュエーションにおける必要な閾値を計算するモデルは、外れる予報の可能性を最小限にするように、生成されうる。データベースが成長するにつれて、統計分析は、生成されたモデルを継続的に改善するために、定期的に繰り返し行われる。十分な量の履歴データ及び領域データを収集するために、モデルは、例えば、時刻、季節、領域種別例えば、沿岸、山、砂漠、街に、又は特定の領域例えば、濃霧の可能性のある領域に依存しうる。いくつかの実施形態において、修正又は検証された気象データは移動デバイス、例えば、PND200a乃至200eへ送信され、アプリケーション又は処理に関連する任意の所望の気象のために見られるか又は使用されうる。多くのケースにおいて、PND又は他の移動デバイスへの送信パスは、資源された帯域幅であり、PND又は他の移動デバイスへ送信されるデータの量は、制限されることが望ましい。これは、気象予報の更新のように、例えば15分ごとの間隔でデータの大量送信が行われる、気象データの送信に関する特定のケースである。いくつかの実施形態において、サーバ150は、気象データソース180から受信される気象データを処理し、気象データが特定のエリアに対する荒天を示すのであれば、気象の警告を生成するように構成される。気象の警告の生成は、気象の警告が車両データと整合することを保障するために、車両データに従って実行されうる。いくつかのケースにおいて、気象の警告は、車両データの全体に基づいて生成されうる。問題となる気象条件の種類に従って、同一の車両からのデータから識別されるいくつかの異なるイベントの整合、又は、複数の車両からのデータから複数の類似したイベントの整合は、特定の気象条件指標を強化し、これにより、対応する警告のトリガとなる。同一の又は異なる車両からのデータによって示される複数のイベントの融合、及び外部のソース、例えば、データソース180からの気象データとの相互関連は、特定の状況例えば、ガレージ又はトンネルにおける車両の存在、又は車両の暖房の効果によって信頼のない車両センサデータに依存する比較において、気象の警告のロバスト性をより改善することができる。図7は、嵐の警告が発生しているドイツのエリア600、602、604、608他の同様のエリアを示す。サーバ150は、受信した気象データに基づき、嵐の警告のエリアを判定し、それらのエリアを表す気象の警告データを、PND又は他の移動デバイス、例えばデバイス200へ送信する。動作の1つのモデルにおいて、サーバ150は、定期的に気象警告データを含み、一般的には領域内の全てのナビゲーションデバイスへ送信する。本実施形態の変形例において、個々の車両又は複数の車両によって報告される特定のイベントに応じて、追加の専用の気象関連の警告、例えば、路面上の氷、非常に厳しい荒天は、それらの現在の位置及び経路が警告が着雪関連するであろうことを示すオリジナルの個別の車両又は複数の車両付近における全ての接続された車両へ送信する。サーバ150は、影響のある車両が気象関連のデータを、定期的な気象の警告の送信局所化された警告も含んでよいがを介するよりも早く受信するように、優先的な基準での局所化された警告などを配信するように構成される。受信した気象警告のデータは、経路を適合しETAを修正するために、デバイス、例えば、デバイス200a乃至200eによって使用される。各ケースにおいて、サーバ150から送信される気象警告のデータは、気象警告の開始時刻、終了時刻又は継続期間を表す時間データを含むことができる。少なくとも1つの気象関連条件の判定、例えば、気象データの検証又は修正において、デバイスから受信される車両データの使用については既に上述している。図7のケースにおいて、そのようなデータは、気象の警告が適用されるエリアの判定、修正又は検証を行うために、そのようなデータが使用されるうる。上記データは、また気象警告の期間を修正又は検証するために使用されうる。いくつかの実施形態において、サーバ150は、気象データなどの外部情報と合成して、車両から受信される車両データによって表される所定の気象関連のイベントの有無を分析することによって、気象の警告の寿命を判定する。例えば、サーバ150は、道路の特定の凍結の警告終了するために、ソース180からの気象データによって示され、車両から受信されるステータス又はセンサ出力データから決定される正常に戻る平均車両速度と認められる、領域の気温の上昇と、所定の時間間隔でのホイールスリップイベントの有無とを関連付けてもよい。サーバ150はまた、古い道路に沿った降雨の警告を描画するために、例えば、気象データソース180からの最近の及び予報の降雨レーダ情報と、特定の道路に沿った車両におけるライト起動のないフロントワイパーの動作とを関連付けてもよい。瞬間的な車両データ及び気象データに基づくよりもむしろ、所定時間にわたる車両データ及び気象データの変動に基づく気象警告の分析を行うことによって、気象の警告の正確性やその期間は、改善されるであろう。例えば、非常に寒い条件が発生したと判定され、多くスリップイベントの検知により気象警告が発行される場合、当該気象警告は、スリップイベントの数が減少しても、気象データが気温が上がっていないことを示せば、気性警告は維持される。この場合、スリップイベントの減少は、っ問えばドライバがより注意深く例えば、気象警告によって運転したことに起因するものであるかもしれない。気象警告の正確性は、所定期間にわたる車両データ及び気象データの少なくとも一方の過去変動と、特定の気象条件の発生との間の関係を示す統計モデルを提供することよってさらに増大されうる。気象条件の種別に依存して、サーバ150は、気象警告を終了するか否かを判定する才に、気象条件に関連する特定の気象警告の現在の継続時間とともに問題となる気象条件の典型的な継続時間の既存の情報を使用することができる。いくつかの実施形態において、サーバ150は、車両からのデータによって表される個々のイベントの不足だけでなく、警告を終了するために所定の逆の意味示すイベントの存在も必要としない。いくつかの実施形態において、車両から受信されるステータス又はセンサ出力データに基づき、閾値は、警告がサーバ150によって廃止されるべきと判定される前に、認識されたイベント発生割合が低下する下での時間間隔の中で、個々のイベントの数で定義される。そのような閾値は、第1の場所での警告を発行するために定義された閾値と等しい必要はなく、代わりにそれよりも低くてもよい。そのような閾値は、通常、自然のかつ過酷な気象条件に、警告の継続時間に、外部気象ソースから抽出された影響のあるパラメータの値及び信頼性に、且つ、問題のある道路又はエリアでの現在の潜在的なイベントソースすなわち、適切に装備された車両の評価された数に関する情報に依存する。警告をキャンセルするための予め定義された閾値基準が満たされた後に、いくつかの実施形態において、サーバ150は、問題のある気象条件の本質に、且つ、気象条件を示してもよい任意の他のパラメータに依存して警告の遅延として参照されうる、継続期間に対する警告を維持する。警告パラメータ及び他のパラメータの年齢への閾値及び警告遅延の依存関係は、発見的に決定されることができるが、より高度な改良において、改善されたパラメータについての履歴データが履歴の存続期間、事後検証された気象の警告と相互に関連付けられる、オフライン統計分析からも得られる。モデル生成処理は、利用可能なデータが増大するに従って繰り返し行われる。気象の警告を生成又は除去する閾値を決定するための十分な量の履歴データ及び局所的なデータを収集することや、当該モデルは、同様に、時刻、シーズン、領域種別に基づくことができ、或いは、個別の領域に特定されてもよい。車両データ、例えば、車両から受信されるステータス又はセンサ出力データの使用は、気象データ及び気象の警告の検証、修正又は生成において説明された。そのようなデータは、交通の状況を気象条件と関連付けるための統計手続きにおいて使用されうる。そのような手続きの一例は、種々の道路セグメントに沿った運行の速度での気象条件の効果の決定に関する。図1の実施形態の変形例において、サーバ150は、速度プロファイルでの気象条件の効果を決定するために相互に関連する手続きにおいて、デバイス200などの車両内蔵デバイスからの履歴車両データを使用する。第1段階の手続きにおいて、サーバ150は、ある長い期間、例えば1年にわたるデジタル地図により表された領域の気象条件を表す履歴気象データを取得する。サーバ150は、データ記憶部160に格納され且つデジタル地図により表された道路又は他の主要道路における車両の移動を表す大量のプローブデータにアクセスできる。プローブデータは、例えば時間ビン毎の個々の道路セグメントに沿う平均車両速度、時間ビン毎の個々の道路セグメントにおける交通密度例えば、ナビゲーションデバイスの外挿及び正規化された密度から取得されるか、あるいは車両の前後に配置された超音波距離検出器から取得される、道路セグメント及び時間ビンの各々に対する速度の統計的分布、並びに個々の道路セグメント及び時間ビンに対する渋滞の確率のうちの1つ以上を取得するために処理される。この場合、プローブデータは、車両データ、例えば、車両内蔵のデバイスから取得されたステータス又はセンサ出力データであり、特定の気象条件を表すか若しくは特定の気象条件を関連付けれる車両データも含む。個々の車両から得られるそのような気象関連データは、上述したような、例えば、スリップイベント、フォグランプの動作、フロントワイパーの動作、気温測定若しくは降雨検知を表すデータ、又は、任意の他の適切なパラメータを含むことができる。気象データは、例えば雨、あられ又は雪等が降ること又はその降水量、風速、風向、凍結の有無又は凍結量、積雪の有無又は積雪量、地表水の発生又はその量、霧の有無又は霧の量、視界レベル、並びに気温のうちの1つ以上である1つ以上の種々の気象種別を表せる。あらゆる適切な送信元から取得された気象データ、例えば政府又は民間の機関により維持された公式の気象レコード。複数の送信元からの気象データが使用されてもよい。いくつかの実施形態において、適切に装備された個々の車両から取得された気象関連データも使用できる。サーバ150は、気象に依存する速度平均及びそれらの重要性の統計的に重要な測定を可能にするために気象データ及びプローブデータの非常に大きなアーカイブにアクセスできる。サーバ150は、デジタル地図の道路又は他の主要道路の種々のセグメントの平均速度の変動と各気象条件の変動とを互いに関連付ける相関技術を適用する。モデル化モジュール170は、要望に応じて、気象条件と、ステータス又はセンサ出力データなどの取得した車両データとの統計的な相関、同様に、例えば渋滞の確率、運転者の経路の好み又は他のあらゆる交通関連パラメータとの統計的な相関を導出できる。サーバ150は、速度プロファイル及び気象の影響を計算するためにオフライン統計解析を提供する。気象条件に対する感度に基づく種々の道路種別の分類は、相関手順を実行する際に有用であることが分かっている。例えば降水強度のみでは、全ての道路に対する平均速度変更を与えるある代数式のパラメータとしては不十分であることが多い。降水量の影響は、局地交通の例及び道路のレイアウトによっては非線形的であり且つ不連続である可能性がある。1つの動作モードにおいて、各道路セグメントは、複数の道路種別の分類子のうちの1つに分類される例えば、5個の種々の道路種別の分類子が使用されてもよい。各分類子は、1つ以上の特性、例えば幅、車線数、路面の種類、通常の状態の平均速度又は交通量、都心又は地方、交通の分岐点又は信号機までの近接度を有する道路を表してもよい。トムトム社TomTomInternationalB.V.が自身の製品において使用するような機能道路分類FRCは道路分類子として使用されてもよい。各道路セグメントは、その道路セグメントのプロパティの演繹的な評価に基づいて分類子を割り当てられてもよく、あるいは気象条件によりどのようにセグメントの速度プロパティが変動するかの演繹的決定に基づいて分類子を割り当てられてもよい。2番目の例において、各分類子は、少なくとも1つの気象条件に対する各感度レベルを表してもよい。使用される分類の数及び種類は、気象条件に対する種々のセグメントの異なる反応の数及び交通に対する重要度に依存し、一般に分類の数が多いほどデバイスに送信される必要があるデータ量は多いため、チャネル152を介してデバイス200a~200eにデータを送信するための帯域幅の制限にも依存しうる。1つの動作モードにおいて、各道路セグメントの分類を表す分類データは、デバイス200a~200eへ送信され、デジタル地図データとして格納される。各分類に対して、種々の種類及びレベルの気象条件に対する反応は、その分類の各セグメントの速度データとその道路セグメントにおける気象条件を表す対応する気象データとを互いに関連付けることにより決定される。一般に反応は、気象により低下されない速度プロファイルに対する速度の変更を表す。混雑の推定は、一般に、自由走行速度の偏差として時間に依存する速度プロファイルを介して暗示される。相関処理は時間に依存する処理であり、日又は週の同一時間に対して取得された気象データ及び速度データを互いに関連付け、これにより特定のセグメントに対する平均速度の日毎又は週毎の予想される変動を考慮に入れる。相関処理は、ある期間にわたる気象条件の変動、並びに速度又は他の移動条件の関連した変化を考慮に入れることができる。例えば相関処理は、ある期間にわたる気温又は他の気象条件の所定の変動に対して、1つ又は複数の所定の道路セグメント、あるいは所定の道路の分類の種別に対する積雪又は凍結がなくなったか又は除去されたことが分かるまでの速さを決定できる。例えば特定の気温の上昇を仮定して、ある道路に対して積雪及び凍結が他の道路より速くなくなると予想される可能性があることが分かるだろう。多くの道路セグメントに対する大量の履歴データを仮定すると、そのような複数パラメータの相関は相対的に正確に決定される。相関処理は、1つ以上の種類及び荒天レベルの気象条件に応答して、平均速度の予想変更を表す道路セグメントの分類の種類の各々に対して気象反応データが生成される結果となりうる。道路セグメントの分類の種類の各々に対する荒天に伴う速度の変動は、例えば速度変更が特定の荒天程度と共に指数関数的に変動する指数関数モデルである量的モデルを使用して効果的にモデル化されることが分かっている。気象反応データは、既知のフィッティング技術を使用して選択されたモデルにフィッティングされる。相関処理及びフィッティング処理は、計算コストがかかり、いくつかの動作モードにおいて、3~6ヶ月毎にだけ繰り返されるか、あるいは交通エンジニア又は他のオペレータが結果に影響を及ぼす変化が起きたと考えた時にのみ繰り返される。2つの量の相関についての参照は、1つの量の変動と他の量の変動との間で任意の関係が確立することを参照してもよい。上記相関は履歴データに基づいてもよい。上述した詳細な説明において説明した実施形態はGPSを参照したが、ナビゲーションデバイスは、GPSの代わりに又は実際にはGPSに加えてあらゆる種類の位置検知技術を利用してもよい。例えばナビゲーションデバイスは、欧州のGalileoシステム等の他のグローバルナビゲーション衛星システムを利用してもよい。同様に、実施形態は衛星を用いたシステムを使用することに限定されず、地上ビーコン、慣性センサ又はデバイスが地理的場所を決定できるようにする他のどんな種類のシステムを使用しても容易に機能できる。本明細書で説明した実施形態において、特定の機能性はサーバにおいて提供されるものとして説明され、他の機能性は例えばPND又は他の移動デバイスであるデバイスにおいて提供されるものとしてされる。その一方で、別の実施形態においては、説明した機能性のいずれもサーバ又はデバイスで提供可能である。例えば、サーバがナビゲーションデバイスとして動作してもよいいくつかの実施形態では、ほぼ全て機能性はサーバにおいて提供される。他の実施形態において、ほぼ全ての機能性は、気象データ又は他のデータをサーバからではなくデータ送信元から直接受信してもよいデバイスにおいて提供される。本発明の別の実施形態は、コンピュータシステムと共に使用するコンピュータプログラムとして実現可能であり、コンピュータプログラムは、例えばディスケット、CD-ROM、ROM又は固定ディスク等の有形データ記録媒体に格納される一連のコンピュータ命令であるか、あるいは例えばマイクロ波又は赤外線である無線媒体又は有形の媒体を介して送信されるコンピュータデータ信号において具現化される一連のコンピュータ命令である。一連のコンピュータ命令は上述の機能性の全て又は一部を構成でき、半導体メモリ素子、磁気メモリ素子、光メモリ素子又は他のメモリ素子等のあらゆる揮発性又は不揮発性メモリ素子に更に格納できる。本明細書において特定のモジュールを説明したが、別の実施形態において、それらモジュールの1つ以上の機能性は単一のモジュール又は他の構成要素により提供されるか、あるいは単一のモジュールにより提供される機能性は2つ以上のモジュール又は他の構成要素の組み合わせにより提供される。好適な実施形態は、特定の機能性をソフトウェアにより実現するが、その機能性はハードウェアでのみ例えば、1つ以上のASIC特定用途向け集積回路により同様に実現可能であり、あるいは実際はハードウェア及びソフトウェアの組み合わせにより実現可能であることも当業者にはよく理解されるだろう。そのため、本発明の範囲は、ソフトウェアで実現されることのみに限定されると解釈されるべきではない。本発明は単なる例として説明され、本発明の範囲内でその詳細が変更されてよいことが理解されるだろう。説明、並びに請求項及び図面必要に応じてにおいて開示される各特徴は、個別に又はあらゆる適切な組み合わせで提供されてもよい。最後に、添付の請求の範囲は本明細書で説明した特徴の特定の組み合わせを記載するが、本発明の範囲は、以下に請求される特定の組み合わせに限定されず、特定の組み合わせが添付の請求の範囲に特に記載されているか否かに関わらず、本明細書で開示された特徴又は実施形態のどんな組み合わせも含む。"