JP2007017192A - 歩行者用経路探索装置 - Google Patents

Abstract

【課題】 歩行者用の経路探索装置において、歩行者の多様な要望に即した経路を探索可能とする。
【解決手段】 経路探索装置としてのサーバ２００は、ノード・リンクで歩行者の通路を表したネットワークデータベースを用いて経路探索を行う。ユーザは端末としての携帯電話１００から出発地、目的地という条件に加えて、性別、年齢などのユーザ属性、急勾配の経路に対する許容度、屋根などの周辺施設の有無に対する要望などを経路探索条件として指定する。経路探索装置は、これらの経路探索条件を考慮したコストを各リンクに対して算出し、算出されたコストを用いて経路探索を行う。予め設定されたコストではなく、ユーザの要望を反映させたコストを新たに算出する方法を採るため、ユーザの要望をより柔軟にコストに反映させることが可能となり、ユーザの要望に即した経路を探索することが可能となる。
【選択図】 図１

Description

本発明は、歩行者用に経路探索を行う経路探索装置に関する。

歩行者を対象として、指定された出発地から目的地までの経路を探索する経路探索装置が提案されている。歩行能力には個人差があるため、例えば多少急勾配の上り坂であっても距離が短い方が良いという要望や、逆に急勾配の上り坂は疲労しやすいためできるだけ避けたいという要望など、歩行者によって相反する要望が出されることがある。こうした要望は、坂の勾配に関するものだけではない。例えば、車いすの利用者にとっては、多少遠回りであっても、階段を避け、スロープやエレベータを利用する経路を案内して欲しいという要望がある。案内される経路に対する要望は、歩行能力に基づくもののみならず、交通量の少ない経路が良いとか、夜間でも明るく安全に通行できる経路が良いなど、経路の安全性に基づくものもある。更に、雨天には屋根がついている方が好ましいとか、地下街のように空調の整った経路が好ましいなど、利便性や快適性に基づく要望もある。

従来、歩行者を対象とする経路探索装置において、こうした多様な要望に応えるための技術が種々提案されている。例えば、特許文献１は、エレベータやエスカレータなどの施設の存否に応じて、ダイクストラ法による経路探索で用いられる「コスト」を修正することによって、ユーザの要望に応じた経路探索を実現する技術を開示している。特許文献２は、交通機関の使い分けを含めて目的地までの経路を探索、案内する装置を開示しており、交通機関の使い分け条件をユーザの性別その他の属性情報に基づいて設定するという技術を開示している。特許文献３は、経路探索に使用するコストを予め複数種類設定しておき、これらをユーザの要望に基づいて使い分ける技術を開示している。

特開２００２−１８３８７８号公報 特開２００２−２９６０７０号公報 特開２００３−１２１１９１号公報

しかし、歩行者の要望は非常に多彩である。従来技術では、予め用意されたコストを修正して用いたり、予め用意された複数種類のコストを使い分けたりする方法を採るため、経路探索の条件設定には限りがあり、多様な要望に十分応えることができてはいなかった。

一方、従来技術において多様な要望に十分応えようとすれば、コストを修正するための設定項目が過多となったり、予め用意しておくべきコストの種類が過大となったりするおそれがあった。この結果、ユーザの利便性を大きく損ねたり、多大なコストを記憶しておくための多大な容量が必要となったりするなどの別の課題を招くおそれがあった。

本発明は、これらの課題を解決し、歩行者用の経路探索装置において、ユーザの利便性の極端な悪化を回避し、システムの肥大化を抑制しつつ、より多様な要望に応え得る技術を提供することを目的とする。

本発明は、歩行者の経路探索を行う経路探索装置として構成することができる。経路探索装置は、歩行者の通路をノード、リンクで表したデータ、これらのノード、リンクの形状および通行規制の少なくとも一部を表す複数項目の属性とを格納したネットワークデータを用いて経路探索を行う。属性には、例えば、通路の距離、幅、勾配、舗装／非舗装の別などの形状や状態に関するもの、ガードレール、屋根、街灯の有無やエスカレータ、エレベータの有無など施設に関するものが含まれる。もちろん、属性は、これらの全てを含んでいる必要はないし、逆にここで例示した以外の情報を含んでいても良い。

経路探索装置は経路探索で用いるコストの算出に使用すべき属性の指定、および属性とコストとの関係の少なくとも一部を含む「算出条件」を入力する。属性とコストとの関係とは、例えば、属性に基づいてコストを算出する際の変換係数や置換マップなどが該当する。算出条件は、上述の指定または関係を直接的に表すものであってもよいし、中間的な情報を介して間接的に表すものであってもよい。経路探索装置は、こうして指定された算出条件に基づき、属性に応じて、リンクおよびノードについてのコストを算出し、経路探索を行う。本発明では、上述の算出条件は、複数項目の属性のうち少なくとも一部について変更が許容されている。

本発明の経路探索装置によれば、経路探索に要するコストを属性に基づいて算出することができる。そして、この算出のための条件、即ち算出条件は、可変である。従って、非常に多様な算出条件に基づいてコストを算出可能であり、結果として多様な要望に応え得る経路探索を実現することができる。

上述の算出条件は、複数項目の属性全てについて変更可能としてもよい。こうすることにより、例えば、リンクの距離のみは必ずコスト算出に使用しなくてはならないなどの制約を回避することができ、更に多様な算出条件に基づいてコストが算出可能となる。

コストを算出するための算出条件は、上述の通り、コストの算出に使用すべき属性の指定、および属性とコストとの関係を、中間的な情報を介して間接的に表すものであってもよい。この中間的な情報としては、例えば、歩行者属性、即ち性別、年齢その他の歩行者の属性、および所要時間優先や安全性優先その他の経路探索方法についての希望の少なくとも一部についての指定を用いることができる。この場合には、予めこの歩行者属性と算出条件を規定するパラメータの少なくとも一部との対応関係を経路探索装置に記憶させておき、ユーザから指定された歩行者属性に基づいてこの対応関係を参照することでコストを算出する方法を採ることができる。

算出条件を各属性に対応するパラメータで表した場合、複数のパラメータ間には、歩行者の属性等に応じて連動するものが存在する場合がある。上述の態様によれば、歩行者の属性等の中間的な情報を介在させることによって、連動する複数のパラメータ、ひいては算出条件を効率的に指定することが可能となる。

ユーザの要望は経路探索を行う状況に応じて変化することを考えると、コストを算出するための条件は、経路探索を行う度に指定するようにしてもよい。また、歩行者からの指示に応じて、算出条件を予め設定し、ユーザデータベースとして登録可能としてもよい。この場合には、経路探索装置は、ユーザデータベースに予め登録された算出条件を用いてコストを算出することができるとともに、経路探索時には算出条件の指定を省略できるため、利便性を向上させることができる。この場合、複数種類の算出条件を登録可能とし、この中から経路探索時にユーザが指定した算出条件を用いて経路探索を行うようにすれば、更に利便性を向上させることができる。

経路には、歩行用の通路のみならず、種々の交通手段を含めても良い。例えば、自家用車、タクシーでの移動用の道路、バス路線、電車による移動、飛行機の航空路、船舶の航路などを通路に含めても良い。これらを通路に含める場合には、移動手段に応じた属性を設定すればよい。例えば、電車については、特急、快速、普通などの種別や、女性専用車両の有無、座席指定の有無などを含めることができる。また、飛行機については、航空会社や、機体の種類などを含めることができる。これらに基づいてコストを算出する際には、例えば、ユーザが自動車に酔いやすい場合には、自動車での移動に対するコストが高くなるよう設定したり、高所恐怖症その他の理由により飛行機を好まないユーザに対しては航空路のコストが高くなるように設定したりすることができる。

更に、これらの移動手段については、ユーザからの指定以外に外部からの情報を取り込んで、コスト算出に反映させることも可能である。例えば、車両での移動手段に対して、渋滞や工事などの交通情報を提供しているサーバから情報を取得し、通行に支障がある道路のコストを高くするようにしてもよい。また、飛行機その他の交通機関については、悪天候などに起因する遅れなどの運行状況を提供するサーバから情報を取得し、運行状況に応じてコストを変更するようにしてもよい。

属性からコストを算出するための算出条件は、必ずしも全てをユーザが指定する必要はなく、一部を経路探索装置が自動的に設定してもよい。また、条件によっては、算出条件の一部についてユーザの指定と反する設定を用いるようにしてもよい。一例として、属性にリンクの距離が含まれている場合、経路探索の出発地および目的地の間の距離が所定値以下の時には、コストに対する距離による寄与分をそうでない時よりも低減させるようにしてもよい。

歩行者を対象とする経路探索では、出発地と目的地が比較的近接している時がある。かかる場合には、探索される経路間の距離の差は比較的小さいため、できるだけ短い距離の経路を要望しているユーザに対して、他の経路よりも距離の長い経路を提示したとしても、ユーザの要望に大きく反する可能性は低い。逆に、屋根付きが好ましいなどの要望があるユーザに対して、距離は短いが屋根がついていない経路を提示すると、ユーザの要望に大きく反する可能性がある。上述の態様によれば、比較的近距離での経路探索時には、距離による寄与分を低減させることによって、結果として、よりユーザの要望にかなった経路を提示することが可能となる。

寄与分の低減には、距離を全くコストに反映させない態様も含まれる。かかる態様においては、距離を反映させずに算出されたコストによっては経路が一義的に決まらなかった場合には、距離を反映させて算出したコストを用いて再度、経路探索を行うようにしてもよい。

以上で説明した経路探索装置は、算出条件は、属性のいずれに対しても変更が許容されていた。本発明は、かかる特徴に代えて、またはかかる特徴と共に、次に示す特徴を備えるよう構成してもよい。

第２の経路探索装置は、歩行者の属性および希望の少なくとも一方と、算出条件を規定するパラメータの少なくとも一部との対応関係を予め記憶しておく。そして、この対応関係で設定されるパラメータについては、歩行者の属性および経路探索方法についての希望の少なくとも一部についての指定を受け付ける。経路探索装置は、上述の対応関係を参照して算出条件を設定することが可能である。この態様によれば、上述の対応関係に対応するパラメータについては指定を省略できるため、経路探索装置の利便性が向上する。

第２の経路探索装置においては、歩行者の属性および経路探索方法についての希望の少なくとも一部についての指定を予めユーザデータベースとして登録しておき、経路探索時には、ユーザデータベースの登録内容では設定不能なパラメータについての入力を受け付けるようにしてもよい。こうすることで、経路探索時の入力を必要最小限に抑制することができ、利便性を向上させることができる。

経路探索時には、ユーザデータベースに登録された内容を、ユーザが必要に応じて変更できる形式で提示してもよい。こうすることで、ユーザデータベースに拘束されることなく、経路探索を行うことが可能となるため、更に利便性を向上させることができる。

本発明は上述した特徴を全て備えている必要はなく、一部を省略したり、適宜、組み合わせたりして構成することが可能である。本発明は、上述の経路探索装置としての態様に限らず、コンピュータによって経路探索を行う経路探索方法として構成することもできる。また、かかる経路探索方法を実現するためのコンピュータプログラムとして構成してもよいし、このようなコンピュータプログラムを記録した記録媒体として構成してもよい。ここで、記録媒体としては、フレキシブルディスクやＣＤ−ＲＯＭ、光磁気ディスク、ＩＣカード、ＲＯＭカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置等、コンピュータが読取り可能な種々の媒体を利用できる。

本発明の実施例について以下の順序で説明する。
Ａ．装置構成：
Ｂ．ネットワークデータの構造：
Ｃ．ユーザデータベースの構造：
Ｄ．コスト算出方法：
Ｅ．ユーザ属性登録処理：
Ｆ．経路探索処理：
Ｇ．効果および変形例：

Ａ．装置構成：
図１は実施例としての経路案内システムの概略構成を示す説明図である。経路案内システムは、経路探索装置としての機能を提供するサーバ２００と、その端末装置として機能する携帯電話１００を備えている。各ユーザが、携帯電話１００を操作して、経路探索の条件を設定すると、この条件はサーバ２００に送信される。サーバ２００は、この条件に基づき、歩行者を案内するための経路探索を行い、ユーザの移動に合わせて結果を携帯電話１００に提供し、経路案内を行う。本実施例の経路案内システムは、歩行者たるユーザの歩行能力や経路に対する要望を受け、これに沿った経路を探索、案内する機能を有している。

サーバ２００および携帯電話１００はインターネットなどのネットワークＩＮＴで接続されている。図中では、携帯電話１００が２台接続された例を示したが、携帯電話１００は任意の台数、接続可能である。ネットワークＩＮＴ上には、経路探索装置２００の他、種々のサーバが接続されている。本実施例では、これらのサーバとして、気象情報を提供するサーバ３００が接続されている場合を例にとって説明する。

図中に、携帯電話１００およびサーバ２００の機能ブロックを併せて示した。携帯電話１００には、ＣＰＵおよびメモリを内蔵した制御ユニットが搭載されており、これらの機能ブロックは、ＣＰＵが所定のプログラムを実行することでソフトウェア的に構成される。サーバ２００の機能ブロックも同様に、所定のプログラムをインストールすることで、ソフトウェア的に構成される。携帯電話１００およびサーバ２００における機能ブロックの少なくとも一部は、ハードウェア的に構成することも可能である。

携帯電話１００では、図示する各機能ブロックが主制御部１１０の制御下で、それぞれ次の機能を実現する。通信部１２０は、ネットワーク経由でのサーバ２００との通信を制御する。携帯電話１００からサーバ２００に対して送信する情報には、例えば、歩行者の性別その他の属性（ユーザ自身の属性という意味で、以下、「ユーザ属性」と呼ぶ）を登録したり、経路探索の出発地、目的地を指定するためのコマンドが含まれる。サーバ２００から携帯電話１００に送信する情報には、これらの情報を登録するためのインタフェース画面や、経路探索結果などが含まれる。

ＧＰＳ１３０は、全地球測位システム（Global Positioning System)を利用して、携帯電話１００の現在位置を検出する。時刻管理部１６０は、現在時刻を出力する「時計」である。表示制御部１５０は、携帯電話１００のディスプレイの表示を制御する。コマンド入力部１４０は、ユーザによるキー等の操作内容を入力する。これらの機能ブロックにより、携帯電話１００は、経路案内システムの端末装置として要求されるユーザインタフェースを提供することができる。

サーバ２００では、主制御部２１０の制御下で各機能ブロックが動作する。通信部２２０は、ネットワーク経由での携帯電話１００との通信を制御する。ユーザＤＢ管理部２３０は、ユーザＤＢ２３２の管理、即ちユーザＤＢ２３２に新たなデータを登録したり、ユーザＤＢ２３２の検索を行ったりする。ユーザＤＢ２３２は、後述する通りユーザ属性等を記録したデータベースであり、経路探索時に参照される。

ネットワークＤＢ２１２は、歩行者が通行できる通路をノード・リンクという形式で表したネットワークデータを格納するデータベースである。リンクとは、通路を線分または折れ線で表したデータである。ノードとは、リンクの交点、端点、または属性変化点である。

ネットワークＤＢ２１２には、ノード・リンクの幾何学的なデータの他、属性２１２Ｐも記憶されている。属性には、例えば、リンクの属性として、通路の距離、幅、勾配、舗装／非舗装の別などの形状や状態に関するもの、ガードレール、屋根、街灯の有無やエスカレータ、エレベータの有無など施設に関するものが含まれる。ノードの属性としては、例えば、横断禁止などの通行規制に関する情報や、横断歩道、踏切、エレベータなどの平均待ち時間などが挙げられる。属性は、ここに例示したものを全て備えている必要はなく、また、ここに例示したもの以外の情報を含めても良い。ただし、実施例では、属性２１２Ｐには、経路探索に用いるコストデータを含めてはいない。

コスト算出部２５０は、経路探索に用いるコストを算出する。コストの算出には、ユーザＤＢ２３２に登録されたユーザ属性情報およびネットワークＤＢ２１２に登録された属性２１２Ｐを用いる。本実施例では、属性２１２Ｐを用いた所定の演算式によってコストを算出するものとした。この演算式で用いられる係数は、係数テーブル２５０ｔとして予め設定されており、ユーザ属性などに応じて変化する。属性からコストを算出する方法については、後述する。コストの算出には気象情報が必要となる場合もある。かかる場合には、サーバ２００は、ネットワークＩＮＴを介してサーバ３００にアクセスし、必要な気象情報を取得する。

経路探索部２４０は、ダイクストラ法を利用して、指定された出発地から目的地までの経路探索を行う。経路探索結果は、ネットワークＩＮＴを介して携帯電話１００に提供される。ネットワークＤＢ２１２には、経路案内に使用する電子地図を表示するための描画データを含めても良い。

Ｂ．ネットワークデータの構造：
図２はネットワークデータの構造を示す説明図である。上方の図に示す通り、ネットワークデータは、通路を、リンクＬ１，Ｌ２，Ｌ３やノードＮ１〜Ｎ４などによって表したデータである。各リンクは、交差点または地図の端点でノードによって分断される。また、交差点以外にも、ノードＮ３のように階段から平坦な道に属性が変化するような点でも分断される。

図の下方に、ネットワークデータの格納状態を模式的に示した。ノードの情報としては、まず、ノード番号およびノードの位置情報としての緯度経度が挙げられる。また、ノードの属性情報も関連づけて格納される。この図では、横断歩道の有無、信号の有無および種別、ノード付近に存在する目印、またはランドマークの種類などを属性情報として記憶している例を示した。

リンクの情報としては、まず、リンク番号、およびリンク形状を示す経由点が挙げられる。リンク形状は、リンクの各経由点の緯度経度によって表される。その他、リンクの属性として、舗装の有無や階段、エスカレータ、エレベータなどの種別情報、道路の距離および幅、勾配などの情報が格納されている。また、屋根の有無、街灯の有無、周辺施設の種類などの情報も格納されている。更に、この例では、人通りの時間変化も属性情報として格納するものとした。先に説明した通り、図２に示した属性情報は例示に過ぎない。

Ｃ．ユーザデータベースの構造：
図３はユーザＤＢ２３２のデータ構造を示す説明図である。ユーザＤＢ２３２に格納される情報としては、ユーザＩＤ、ユーザの氏名、住所、連絡先（図中の例ではメールアドレス）などの個人情報が挙げられる。また、経路探索に活用される情報として、性別、生年月日、および経路探索に関するユーザの要望事項が格納されている。図中の例では、要望事項として、階段・段差の許容度、上り坂に対する勾配の許容範囲、安全性に対する要望を例示した。この他の要望事項を含めても良いし、この中の一部を省略等しても差し支えない。

本実施例の経路案内システムは、経路探索条件をユーザが種々カスタマイズして登録することが可能である。図中では、グループ１〜３の３通りの探索条件が登録されている例を示した。グループ１の探索条件は、ユーザが「仕事」用に設定した条件であり、「時間優先」モード、即ち所要時間が最短となる経路を探索するモードが指定されている。また、屋根がある経路を選択する必要性は低く設定されている。

グループ２の探索条件は「遊び」用に設定されたものであり、「繁華街優先」モード、即ち図２で示した人通りが多い道路を優先的に選択するモードが設定されている。また、屋根付きの経路を選択する要望が高く、周辺設備として飲食店や百貨店などを優先的に探索する設定となっている。

グループ３の探索条件は、このユーザにとっての「汎用」の設定であり、特に他の条件を指定しない時には、この設定が「デフォルト」として使用されるようになっている。この設定では、所要時間係数（Ｃ２）の値や、安全性係数（Ｃ４）で用いられる性別補正、年齢補正の値が直接指定されている。これらの係数は、経路探索時のコスト算出に使用される値である。具体的意味については後述する。

上述した通り、本実施例のユーザデータベース２３２は、複数の探索条件を登録可能となっている。これらの探索条件は、グループ１、２のような項目で設定することもできれば、コスト算出に使用される係数を直接指定することもできる。図示したのは例示に過ぎず、カスタマイズして登録可能なグループ数、登録内容については任意に設定可能である。

Ｄ．コスト算出方法：
図４はコスト算出方法を示す説明図である。本実施例では、コストを、距離（Ｃ１）、所要時間係数（Ｃ２）、困難正係数（Ｃ３）、安全性係数（Ｃ４）、周辺設備係数（Ｃ５）、わかり易さ係数（Ｃ６）などの各係数の積で求めるものとした。図示した係数の一部を省略してもよいし、これ以外の係数を用いても良い。また、これらの係数とは別に、コストに加算される項目を設けても良い。加算項目となる要素としては、例えば、ノードにおける右左折の数や、横断歩道その他による待ち時間などを用いることができる。このコストは、ダイクストラ法による経路探索で使用されるものであるから、コストが小さい方が経路として適していることになる。

距離（Ｃ１）は、各リンクの距離である。ネットワークＤＢに登録された距離を直接用いるようにしてもよいし、リンク長さに対して勾配に応じた補正を考慮して通路に沿った実距離を用いるようにしてもよい。ここでは、ネットワークＤＢに登録されたリンク距離を用いるものとして説明をする。

距離（Ｃ１）の設定値は、経路探索のモードに応じて変化する。距離に対する評価が比較的低い探索モード、換言すれば、探索結果として得られる経路が距離的には最短といえない場合でも許容される探索モードの場合には、リンク距離に関わらず距離（Ｃ１）の設定値は１となる。本実施例では、「距離無視モード」、および「繁華街優先モード」の時に、この設定を用いるものとした。

一方、距離を考慮する場合には、リンク距離、性別補正、年齢補正、障害補正の積を用いる。性別補正は女性に対しては、男性よりも高い値が設定される。年齢補正は、ユーザの年齢が１０〜２０代を下限値として１０代よりも年齢が低くなるにつれ、また２０代よりも年齢が高くなるにつれて徐々に大きくなるよう設定される。障害補正とは、例えば、足をけがしている場合、車いすなどを用いる障害者である場合などに、それぞれ歩行の困難性に応じて高い値が設定される。これらの各補正値は任意に設定可能であるため、ここでは定性的な傾向のみを示すにとどめる。これらの各項目の補正値に代えて、リンク距離に乗ずべき係数を直接、ユーザが指定するようにしてもよい。

所用時間係数（Ｃ２）も、経路探索のモードに応じて変化する。「所要時間無視モード」、即ち所要時間に対する要望がない探索モードでは、係数Ｃ２は値１となる。一方、所要時間に対する要望が存在する場合には、係数Ｃ２には、ユーザの移動速度の逆数「６０／移動速度」に相当する値が設定される。この値は、１ｍを移動するのに要する所要時間（分）を表している。ここで、移動速度としては、「４ｋｍ／時」という標準値に、性別補正、年齢補正、障害補正を施して設定するものとした。これらの補正値は、距離（Ｃ１）で用いた値と同じである必要はない。具体的な補正値は任意に設定可能であるが、各補正値は移動速度に対する補正であるから、定性的には距離（Ｃ１）に対する補正とは逆の傾向となる。

困難性係数（Ｃ３）は、各通路を歩行する際の困難性を表す係数である。本実施例では、基準値１．０に対して、段差による補正Ｃ３１、および勾配による補正Ｃ３２を施して係数Ｃ３を設定するものとした。これらの補正Ｃ３１、Ｃ３２は、各経路の状況と、ユーザの許容度との相関によって定まる。従って、本実施例では、それぞれ図中に示す二次元マップを用いて設定するものとした。

二次元マップの見方について説明する。「Ｃ３１＝１．０」は、この直線上およびこの直線よりも下の領域で、補正Ｃ３１が値１．０となることを意味している。「Ｃ３１＝３．０」はこの直線上で補正Ｃ３１が値３．０となることを意味している。「Ｃ３１＝１．０」と「Ｃ３１＝３．０」との間の領域は、両者を補間することでＣ３１が求められる。「Ｃ３１＝３．０」よりも上の領域については、一律に補正Ｃ３１を値３．０としてもよいし、これよりも大きい値に設定してもよい。

本実施例では、先に図３に示したように階段についての許容範囲をユーザが設定する。例えば、階段について「支障なし」が設定されている場合には、図４中の「支障なし」の破線に従って補正Ｃ３１が定まる。従って、階段に対して補正Ｃ３１が値１．０となる他、図中の点ｐ３１［１］に対応する段差に対しても補正Ｃ３１は値１．０となる。これに対し、階段についての許容度を「不可」と「支障なし」の中間に設定している場合、階段に対しては点ｐ３１［３］に示すように補正Ｃ３１が値３．０となり、段差に対しては点ｐ３１［２］に示すように補正Ｃ３１は１．０よりも若干大きい値に設定される。

このように二次元マップを用いることにより、補正Ｃ３１の値は、ユーザの設定および通路の状況に応じて相関的に定めることが可能となる。ここではマップを用いた例を示したが、図中の横軸、縦軸をそれぞれ変数とする二変数関数によって補正Ｃ３１を設定するようにしてもよい。

勾配に対する補正Ｃ３２も同様に、ユーザの設定と通路の状況に応じて、二次元マップにより相関的に定めることができる。そして、両者の積により、通路の通行困難性に関する係数Ｃ３を設定することができる。困難性係数Ｃ３は、ここで例示した要素、即ち階段および勾配の評価、以外にも種々の要素を考慮可能であり、例えば、通路の幅、舗装の有無などを加味して設定するようにしても良い。

安全性係数Ｃ４は、基準となる係数Ｃ４１に対して性別補正および年齢補正を施すことで設定する。係数Ｃ４１は、安全性に対するユーザの設定（図３参照）、および安全性指標の二次元マップに基づき両者の相関で決定される。安全性指標とは、通路に設けられた安全設備の数に基づいて設定される指標である。例えば、ガードレールの有無、信号機の有無、街灯の有無などを、それぞれ点数化し、その総計を安全性指標とすることができる。

安全性に対するユーザの要望が「高」に設定されている場合は、図中の「高」に対応した破線上を見ればよい。安全性指標が十分に高い場合、即ち安全性に関する設備が中程度の通路に対しては、図中の点ｐ４１［１］で示すように係数Ｃ４１は値３．０よりも若干低い程度の値となる。これに対し、ユーザの要望が中程度の場合には、同じ安全性指標の通路に対し、図中の点ｐ４１［２］に示すように係数Ｃ４１は値１．０となる。このように、二次元マップを用いることにより係数Ｃ４１はユーザの要望と安全性指標との相関で設定することができる。

こうして設定された係数Ｃ４１に対して、性別補正、年齢補正が施される。これらの補正値は、安全性に対する要望の強さを反映させるための補正であり、具体的な値は任意に設定可能である。例えば、性別補正は、女性に対しては男性に対するよりも高い値に設定することが好ましい。年齢補正は、２０〜３０代程度を下限値として、年齢が若いほど、また年齢が高いほど、高い値に設定することが好ましい。安全性係数Ｃ４に対しては、更に種々の要素を考慮することも可能である。例えば、経路探索を行う時間帯に応じた補正を考慮するようにしてもよい。

周辺設備係数（Ｃ５）として、ここでは屋根の有無のみを例示した。経路探索について、「屋根あり」という要望が出されている時、屋根付きの通路に対しては、係数Ｃ５は０．５と設定され、そうでない通路に対しては値１．０と設定される。屋根が有用となるのが雨天時であることを考慮して、「屋根ありの通路、かつ雨天」である時にのみ係数Ｃ５を値０．５に設定するようにしてもよい。周辺設備係数は、屋根だけでなく、種々の周辺設備の有無に応じて設定可能である。例えば、図３のグループ２で示した「遊び」用の設定で経路探索を行う場合には、指定された周辺設備、飲食店、百貨店が存在する通路に対しては係数Ｃ５を０．５に設定し、存在しない通路に対しては１．０と設定するようにしてもよい。また、先に説明した安全性指標のように、要望された周辺設備の数に応じて、周辺設備指標を設定し、係数Ｃ４１で示したのと同様の二次元マップによって係数Ｃ５を設定するようにしてもよい。

わかり易さ係数Ｃ６については、図示を省略したが、例えば、幅の広い通路ほど係数Ｃ６が小さくなるように設定したり、案内板がある通路に対してはそうでない通路よりも係数Ｃ６を低く設定したり、右左折を伴うノードに対しては直進するノードよりも高く係数Ｃ６を設定するなどの方法で設定することができる。

Ｅ．ユーザ属性登録処理：
図５はユーザ属性登録処理のフローチャートである。携帯電話１００からの指示に応じて主としてサーバ２００のユーザＤＢ管理部（図１参照）が実行する処理であり、ハードウェア的にはサーバ２００のＣＰＵが実行する処理である。

処理を開始すると、ＣＰＵはユーザ属性登録用の画面を携帯電話１００に提示する（ステップＳ１０）。図中に画面例Ｖ１を示した。携帯電話１００には、このように氏名、住所などユーザＤＢ２３２に登録すべき情報（図３参照）を入力するためのボックスが表示される。ユーザは、携帯電話１００を操作して、各ボックスに登録すべき情報を入力する。サーバ２００のＣＰＵは、このユーザ属性の入力を受け付け、ユーザＤＢ２３２に登録する（ステップＳ１１）。

次に、ＣＰＵはカスタマイズ登録の要否を判断する（ステップＳ１２）。カスタマイズ登録とは、ユーザ固有の経路探索条件の登録（図３のグループ１〜３参照）を意味する。ユーザが、カスタマイズ登録を指示していない時は、ＣＰＵはユーザ属性の入力および登録が終わった時点でユーザ属性登録処理を完了する。

カスタマイズ登録が指示されている場合には、ＣＰＵはカスタマイズ登録画面を表示する（ステップＳ１３）。図中に画面例Ｖ２を示した。この画面例Ｖ２は、名称、経路探索モード、および経路探索に関する要望を登録する状態を示している。要望としては、例えば、距離が短い経路を優先的に探索するか、距離を無視するかの指定、屋根がある経路を優先するか否かの指定、経路の安全性に対する要望などが挙げられる。

ここで、本実施例では、カスタマイズ登録時には、ＣＰＵはユーザ属性に基づいて設定可能な項目についてはデフォルト設定を行う（ステップＳ１３）。例えば、ユーザが２０代の男性の場合には、距離に対する要望として「距離無視」をデフォルト設定にしたり、２０代の若い女性の場合には、安全性に対する要望を「高い」に設定したりする。ユーザ属性と、デフォルト設定との関係は、システム設計時に任意に設定可能である。上述のように年齢と性別の双方が寄与する項目に対してデフォルト設定を実現するためには、二次元的なマップまたはテーブルを予め用意しておけばよい。

このように、カスタマイズ登録の一部の項目をデフォルトで設定することにより、ユーザが入力すべき項目が削減でき、探索条件指定の負荷を軽減することができる。デフォルト設定は、全ユーザに共通の設定としてもよいし、各ユーザに固有の設定としてもよい。後者の例として、例えば、ユーザが複数の探索条件（図３のグループ）を登録する場合には、他のグループで登録されている探索条件の一部をデフォルト設定として流用する方法を採ることができる。デフォルト設定の対象となる項目については、ユーザによる変更を受け付けないようにしてもよいし、デフォルト設定の内容をユーザに提示した後、変更を受け付けるようにしてもよい。

ＣＰＵは携帯電話１００からカスタマイズ登録の内容を入力すると（ステップＳ１４）、これをコスト算出用の係数（図４参照）に変換して登録する（ステップＳ１５）。この変換は、経路探索時に行うようにしてもよいが、登録時に行っておけば、経路探索時の処理負荷を軽減でき、経路探索の所要時間を短縮できる利点がある。ＣＰＵは、ユーザが終了を指示するまで、以上の処理を繰り返し実行する（ステップＳ１６）。

Ｆ．経路探索処理：
図６は経路探索処理のフローチャートである。携帯電話１００からの指示に従って、主としてサーバ２００のコスト算出部２５０および経路探索部２４０（図１参照）が実行する処理であり、ハードウェア的にはサーバ２００のＣＰＵが実行する処理である。

処理を開始すると、ＣＰＵはまずユーザのログインを受け付ける（ステップＳ２０）。ログインは、ユーザＩＤとパスワードなどによるユーザ認証である。これによって、ユーザＤＢ２３２に登録されたユーザ属性の中から、経路探索処理で使用すべきデータを特定することができる。

次に、ＣＰＵは、携帯電話１００に対するユーザの操作を介して、経路探索の出発地、目的地を入力する（ステップＳ２１）。また、同様にして、経路探索条件を入力する（ステップＳ２２）。経路探索条件は種々の方法で入力可能である。第１に、先にカスタマイズ登録（図３，５）で例示した項目や、コスト算出に使用する係数（図４参照）を直接指定する方法を採ることができる。この方法を採る場合には、カスタマイズ登録で設定したデフォルト設定（図５のステップＳ１３）と同様の方法を採ってもよい。つまり、経路探索条件として指定可能な項目のうち、ユーザ属性に基づいて設定可能な項目については、予め用意されたデフォルト設定を適用するようにしてもよい。また、デフォルト設定を一旦提示した後、ユーザの変更を受け付けるようにしてもよい。

経路探索条件の入力は、上述した方法の他、ユーザが予めカスタマイズ登録した探索条件（図３の各グループ）から選択する方法を採っても良い。こうすることにより、経路探索条件の指定に要する手間を大幅に削減することができ、経路案内システムの利便性を向上させることができる。カスタマイズ登録で指定されていない項目については、予め用意されたデフォルト設定を適用するようにしてもよいし、かかる項目についてのみ個別にユーザの入力を受け付けるようにしてもよい。

経路探索条件の入力は、第３に、ネットワークＩＮＴ上の他のサーバ３００から取得する方法を採ることもできる。例えば、ユーザが「雨天時には屋根付きの経路を優先する」という探索条件を設定した場合を考える（図５の画面例Ｖ２参照）。かかる場合には、経路探索条件を特定するためには、天候に関する情報が必要となる。この情報をユーザが入力する方法を採ることも可能ではあるが、ネットワークＩＮＴ上に設けられた他のサーバ３００から取得する方法を採ってもよい。こうすることにより、ユーザの入力負荷を減らすことができる。この情報入力を実現するためには、要求すべき情報と対応づけて、情報を取得すべきサーバ３００の所在（アドレス情報またはＵＲＬなど）を予め登録しておけばよい。外部のサーバから取得する情報としては、天候の他、通路の工事状況などが挙げられる。繁華街優先モード（図３のグループ２参照）においては、周辺設備に関する情報の一環として、各種イベント情報を外部サーバから取得し、活用するようにしてもよい。

こうして経路探索に必要な情報の入力が完了すると、ＣＰＵは次に、出発地と目的地間の距離Ｄｓｔを算出する（ステップＳ２３）。そして、この距離Ｄｓｔが所定値Ｔｈ以上である場合（ステップＳ２４）、ユーザが「距離無視モード」を指定していれば、これを解除する（ステップＳ２６）。逆に、距離Ｄｓｔが所定値Ｔｈに満たない場合には、距離無視モードを設定する（ステップＳ２５）。

出発地と目的地が比較的近接している時には、探索される経路間の距離の差は比較的小さいため、多少距離の長い経路を提示したとしても、ユーザの要望に大きく反する可能性は低い。従って、かかる場合には、仮にユーザが距離を考慮する探索モードを指定している場合であっても、距離以外の要望を重視して経路探索を行った方が、結果としてユーザの要望により適合した経路を提示することができる。本実施例では、かかる観点から、出発地と目的地の距離Ｄｓｔが所定値Ｔｈに満たない場合には距離無視モードを用いるものとした。距離Ｄｓｔが所定値Ｔｈ以上の時には、これとは逆に、距離を十分考慮に入れて経路を提示することが好ましいため、距離無視モードを解除するものとした。所定値Ｔｈは、かかる観点から、経路探索結果に対する距離の寄与度が小さいと判断される範囲で任意に設定可能である。

もっとも、上述の処理は一例に過ぎず、距離無視モードの設定（ステップＳ２５）、または距離無視モード解除（ステップＳ２６）の一方のみを適用するようにしてもよいし、双方とも省略してもよい。距離を完全に無視または考慮という二者択一で考えるのではなく、距離の影響（図４の係数Ｃ１）に対して、出発地と目的地の距離Ｄｓｔに応じた係数を乗じることによって、コストに与える「距離の寄与度」を連続的に変化させるようにしてもよい。

ＣＰＵは以上で設定された条件に基づいて経路探索を実行し、結果をユーザの携帯電話１００に表示する（ステップＳ２６、Ｓ２７）。本実施例ではダイクストラ法を用いて経路探索を行う。即ち、各ノードから経路となり得る候補リンクを特定し、これらに対して図４に示した方法でコストを計算する。そして、そのノードに至るまでの経路上の総コストを考慮して、コストが最小となる経路を探索するのである。本実施例では、候補リンクを特定する度に、コストを算出するが、予め出発地と目的地を含む一定範囲内の全リンクに対するコストを算出してから経路探索を行うようにしてもよい。ただし、候補リンクを特定する度にコストを算出した方が、コスト算出に要する負荷が小さく、所要時間の短縮を図ることができる利点がある。

サーバ２００は、ユーザが終了を指示するまで（ステップＳ２９）、以上の処理を繰り返し実行する。ユーザは自己の要望に合う経路が見つかるまで、経路探索条件等を変更しながら経路探索を行うことができる。

Ｇ．効果および変形例：
図７は経路探索結果を示す説明図である。図の上方に示した通路を対象として種々の条件で経路探索を行った結果を示した。図中に示す通り、歩行者が通行可能な通路は、ノードＮ１〜Ｎ４間に存在するリンクＬ１〜Ｌ４である。ノードＮ１は出発地、ノードＮ４は目的地であるものとする。各リンクの距離、勾配、屋根の有無はそれぞれ図中に示す通りである。街灯はリンクＬ２にのみ設置されているものとする。

上述の通路を対象とする場合、出発地Ｎ１から目的地Ｎ４に向かう経路は、リンクＬ１，Ｌ３，Ｌ４を通過する第１経路、リンクＬ２，Ｌ４を通過する第２経路の２通りが候補となる。ダイクストラ法での経路探索は、各ノードから候補経路が枝分かれしながらのびていく動的な処理であるが、ここでは説明の便宜上、上述の２つの経路の総コストの比較を図示した。また、図４に示した種々の係数のうち、距離（Ｃ１）、困難性（Ｃ３）、安全性（Ｃ４）、周辺設備係数（Ｃ５）のみを考慮するものとし、その他の係数は全て値１であるものとした。

ケースＡは、２０歳の男性のユーザによる好天時の経路探索結果である。男性および２０歳の場合には、図４の距離Ｃ１に対する性別補正、年齢補正はそれぞれ１．０とした。困難性は、急勾配となっているリンクＬ２に対してのみ１．２とし、その他のリンクについては１．０とした。これは、図４中のＣ３２のマップにおいて、ユーザが急勾配を若干回避したいという要望を設定している状態に相当する。安全性、周辺設備については、考慮不要という条件であり、全リンクに対して係数は１．０に設定した。

この状態では、第１経路（リンクＬ１、Ｌ３、Ｌ４）の総コストは１３０となり、第２経路（リンクＬ２、Ｌ４）の総コストは８４となる。従って、急勾配のリンクＬ２を含むものの、総合的に評価して第２経路が最適な経路として提示される。

ケースＢは、同じ男性による雨天時の経路探索結果である。雨天時には屋根付きの経路が要望されているものとする。従って、リンクＬ１、Ｌ３については周辺設備の係数が０．５に設定され、リンクＬ２、Ｌ４に対しては１．０と設定されている。

この状態では、第１経路（リンクＬ１、Ｌ３、Ｌ４）の総コストは８０となり、第２経路（リンクＬ２、Ｌ４）の総コストは８４となる。従って、総合的に評価して遠回りでも屋根付きの第１経路が最適な経路として提示される。

ケースＣは６０歳の男性のユーザによる好天時の経路探索結果である。距離に対する年齢補正係数を１．５と設定した。また、急勾配のリンクｌ２に対する困難性係数を２．５と設定した。この状態では、第１経路（リンクＬ１、Ｌ３、Ｌ４）の総コストは１８５となり、第２経路（リンクＬ２、Ｌ４）の総コストは２１３．７５となる。従って、総合的に評価して急勾配を回避した第１経路が最適な経路として提示される。

ケースＤは２０歳の女性による好天時の経路探索結果である。距離に対する性別補正を１．５と設定し、急勾配のリンクＬ２に対する困難性係数を２．３と設定した。この状態では、第１経路（リンクＬ１、Ｌ３、Ｌ４）の総コストは１９５となり、第２経路（リンクＬ２、Ｌ４）の総コストは２００．２５となる。従って、総合的に評価して急勾配を回避した第１経路が最適な経路として提示される。

ケースＥは２０歳の女性による夜間時の経路探索結果である。安全性に対する高い要望があるものとする。従って、街灯のあるリンクＬ２の安全性係数が１．０とされ、街灯が存在しない他のリンクの安全性係数は１．５と設定されている。この状態では、第１経路（リンクＬ１、Ｌ３、Ｌ４）の総コストは２９２．５となり、第２経路（リンクＬ２、Ｌ４）の総コストは２２２．７５となる。従って、急勾配ではあっても街灯があるリンクＬ２を通過する第２経路が総合的に評価して最適な経路として提示される。

以上で説明した本実施例の経路案内システムによれば、上述の具体例にも示したように、ユーザの属性、および種々の経路探索条件をより柔軟に反映させて、経路探索に用いるコストを算出・設定することが可能である。従って、ユーザの要望により即した経路を提示することが可能となる。また、探索条件のカスタマイズ登録（図５）や、ユーザ属性に基づくデフォルト設定（図５のステップＳ１３）などを利用することにより、ユーザによる入力項目を削減することができ、利便性を向上させることができる。

本実施例は、上述した他、種々の係数を考慮することが可能である。第１に、経路探索システムにユーザの行動スケジュールを登録可能なスケジュール機能が付加されている場合、その登録されたスケジュールの内容を経路探索条件に加味するようにしてもよい。例えば、ある目的地で特定の時刻に会議などの重要な用事が設定されている場合を考える。目的地までの移動手段としてバス、電車の２通りが考えられるものとする。かかる場合には、スケジュールにおける用事の「重要性」に応じて、各移動手段に対応したコストを算出する際に、不測の要因で遅れる危険性を表す係数を用いるようにしてもよい。上述の例では、バスに対しては、電車よりも高い係数を設定することになる。こうすることによって、重要な用事が予定されている場合には、交通費や距離などの要素よりも、遅刻の危険回避という要素を重視した経路探索を行うことが可能となる。

経路探索条件に加味するスケジュールの内容は、単数に限られず、複数であってもよい。この場合、ユーザがどの項目を加味するかを選択するようにしてもよい。また、係数の設定にはある程度の推測が働くため、係数が設定された段階でその値をユーザに提示し、事前に了解を得るようにしてもよい。毎回了解が得られる項目に関しては、以後提示を省略する旨の了解を得た後、その了解を省略するようにしてもよい。

第２に、ユーザに同伴者がいる場合には、両者のユーザ属性を考慮した経路探索を行うようにしてもよい。この場合、各項目ごとにいずれか一方のユーザ属性を選択して使用するようにしてもよいし、両者のユーザ属性を考慮した平均的な設定を用いるようにしてもよい。前者の例としては、例えば、男性の歩行者と女性の歩行者とが連れ添って移動する場合に、距離等に対する性別補正として「女性」の設定を用いる態様が挙げられる。後者の例としては、例えば、段差に対する許容度が「支障なし」に設定されているユーザと、中間的な設定がなされているユーザとが連れ添って移動する場合に、両者の中間に相当する許容度を用いる態様が挙げられる。同伴者の有無は、ユーザの指定によって判断するようにしてもよいし、上述したスケジュールから、同伴者の有無を判断するようにしてもよい。例えば、スケジュール自体に、同伴者を予め登録しておくようにしてもよい。また、同伴者の指定がなされていない場合であっても、同じ時間帯に同じ目的地に向かうユーザ同士を同伴者と自動的に判定するようにしてもよい。

本実施例および変形例では、種々の算出条件に応じて、コストの算出方法を柔軟に変更し、経路探索を行うシステムについて説明した。算出条件や経路探索結果などの情報は、図１に示すように、通信を介して授受する方法が実用的である。ただし、通信時には、これらの情報を不正に傍受される可能性があるため、セキュリティを施すことが好ましい。

特に、算出条件や経路探索結果は、次の意味で、ユーザの個人情報としての秘匿性が非常に高い情報であると言える。第１に、算出条件については、単に性別等の情報のみならず、車いす利用者であるというような身体障害に関する情報が含まれる。また、算出条件を分析することにより、「夜間であっても街灯が少ない通路を厭わない」など比較的危機意識が低いユーザか否かを判断することが可能となり、犯罪を企てる者が対象者を選択するのに有用な情報を提供することになる可能性もある。

第２に、経路探索結果はユーザの行動を表すという点で、スケジュールよりも信憑性が高い情報であると言える。出張や会議などの予定を記録したスケジュールは、行動を表すデータではあるが、予定変更が生じる可能性がある点で必ずしも信憑性が高いとは言えない。また、スケジュールとして登録されない内容については、ユーザの行動を第三者が知ることはできない。これに対し、経路探索は、まさにある目的地に向かおうとする時点でなされるものであるから、ユーザの行動を相当程度高い信憑性で表すデータであると言える。しかも、その目的地まで向かう経路までが特定されることとなり、悪事を企てる者にとっては、非常に有用な情報となると言える。

上述した種々の事情を考慮すると、コストの算出条件や経路探索の結果に対する秘匿の要請は非常に高いと言える。かかる要請に応えるため、上述の実施例および変形例では、種々のセキュリティを施すことが好ましい。セキュリティとしては、例えば、通信時に情報の暗号化を行う方法、経路探索時にパスワードの入力を求める方法などを採ることができる。ユーザが使用する端末が携帯電話などＣＰＵの処理能力が十分とは言えない場合には、暗号化された情報の復号に要する負荷を軽減するための対策を講じても良い。かかる対策としては、例えば、経路探索情報については暗号化せずにサーバから端末に提供するという方法をとりつつ、全経路の情報を一括して送付するのではなく、ユーザの現在地から所定範囲内の経路探索結果のみを提供するという方法を採ることができる。また、ユーザの現在地を原点とする相対的な座標で経路探索結果を送るようにしてもよい。この態様では、経路探索結果を傍受したとしても、ユーザの現在地が分からない限り、何ら意味のあるデータとはならないため、比較的軽い負荷でセキュリティを向上させることが可能となる。情報のセキュリティは、上述した方法に限るものではなく、種々の方法を採りうることは言うまでもない。

また、経路探索システムに経路を案内する経路誘導機能が付加されている場合、経路誘導に使用される経路誘導情報に対し、送信する前に暗号化等のセキュリティを施すようにしてもよい。この場合、セキュリティの強度は、必ずしも経路探索情報と同等である必要はなく、たとえば、暗号化や復号化、通信速度が重要な場面では、セキュリティの強度をやや低下させ、逆の場面ではやや上げるようにしてもよい。

以上、本発明の種々の実施例について説明したが、本発明はこれらの実施例に限定されず、その趣旨を逸脱しない範囲で種々の構成を採ることができることはいうまでもない。本発明は携帯電話１００を端末として用いる場合を例示したが、汎用のコンピュータを端末として用いて経路探索を行うものとしてもよい。また、サーバ２００で処理する構成に限らず、スタンドアロンの装置として構成することも可能である。

実施例としての経路案内システムの概略構成を示す説明図である。 ネットワークデータの構造を示す説明図である。 ユーザＤＢ２３２のデータ構造を示す説明図である。 コスト算出方法を示す説明図である。 ユーザ属性登録処理のフローチャートである。 経路探索処理のフローチャートである。 経路探索結果を示す説明図である。

符号の説明

１００…携帯電話
１１０…主制御部
１２０…通信部
１３０…ＧＰＳ
１４０…コマンド入力部
１５０…表示制御部
１６０…時刻管理部
２００…サーバ
２１０…主制御部
２１２…ネットワークＤＢ
２１２Ｐ…属性
２２０…通信部
２３２…ユーザデータベース
２４０…経路探索部
２５０…コスト算出部
２５０ｔ…係数テーブル
３００…サーバ

Claims (11)

1. 歩行者の経路探索を行う経路探索装置であって、
   歩行者の通路をノード、リンクで表したデータと、該ノード、リンクの形状および通行規制の少なくとも一部を表す複数項目の属性とを格納したネットワークデータを参照する参照部と、
   前記複数項目の属性のうち少なくとも一部の属性について、前記経路探索で用いるコストの算出に使用すべき属性、および該属性と前記コストとの関係の少なくとも一部を直接または間接に指定する算出条件を入力する算出条件入力部と、
   前記算出条件に基づき、前記属性に応じて、前記リンクおよびノードについてのコストを算出するコスト算出部と、
   前記算出されたコストを用いて経路探索を行う経路探索部とを備える経路探索装置。
2. 請求項１記載の経路探索装置であって、
   前記算出条件は、前記属性のいずれの項目に対しても変更が許容されている経路探索装置。
3. 請求項１または２記載の経路探索装置であって、
   歩行者の属性および経路探索方法についての希望の少なくとも一部についての指定を受け付ける歩行者属性入力部と、
   前記歩行者の属性および希望の少なくとも一方と、前記算出条件を規定するパラメータの少なくとも一部との対応関係を予め記憶するパラメータ記憶部とを備え、
   前記コスト算出部は、前記パラメータ記憶部を参照して前記コストを算出する経路探索装置。
4. 請求項１〜３いずれか記載の経路探索装置であって、
   前記歩行者からの指示に応じて、前記算出条件を予め設定し、登録するユーザデータベースを有し、
   前記コスト算出部は、前記ユーザデータベースに登録された算出条件に基づいて前記コストの算出を行う経路探索装置。
5. 請求項１〜４いずれか記載の経路探索装置であって、
   前記属性には、前記リンクの距離が含まれており、
   前記コスト算出部は、前記経路探索の出発地および目的地の間の距離が所定値以下の場合には、その他の場合に比較して、前記コストに対する前記距離による寄与分を低減させる経路探索装置。
6. 歩行者の経路探索を行う経路探索装置であって、
   歩行者の通路をノード、リンクで表したデータと、該ノード、リンクの形状および通行規制の少なくとも一部を表す複数項目の属性とを格納したネットワークデータを参照する参照部と、
   前記経路探索で用いるコストの算出に使用すべき属性、および該属性と前記コストとの関係の少なくとも一部を直接または間接に指定する算出条件を入力する算出条件入力部と、
   前記算出条件に基づき、前記属性に応じて、前記リンクおよびノードについてのコストを算出するコスト算出部と、
   前記算出されたコストを用いて経路探索を行う経路探索部とを備え、
   更に、前記歩行者の属性および希望の少なくとも一方と、前記算出条件を規定するパラメータの少なくとも一部との対応関係を予め記憶するパラメータ記憶部を有し、
   前記算出条件入力部は、前記パラメータ記憶部に記憶されたパラメータについては、歩行者の属性および経路探索方法についての希望の少なくとも一部についての指定を受け付け、
   前記コスト算出部は前記対応関係を参照して前記算出条件を設定する経路探索装置。
7. 請求項６記載の経路探索装置であって、
   前記歩行者の属性および経路探索方法についての希望の少なくとも一部についての指定を予め登録しておくユーザデータベースを有し、
   前記算出条件入力部は、前記経路探索時には、前記算出条件を規定するパラメータのうち、前記ユーザデータベースの登録内容によって設定不能なパラメータについての入力を受け付ける経路探索装置。
8. 歩行者の経路探索を行う経路探索方法であって、
   コンピュータが実行する工程として、
   歩行者の通路をノード、リンクで表したデータと、該ノード、リンクの形状および通行規制の少なくとも一部を表す複数項目の属性とを格納したネットワークデータを参照する参照工程と、
   前記複数項目の属性のうち少なくとも一部の属性について、前記経路探索で用いるコストの算出に使用すべき属性、および該属性と前記コストとの関係の少なくとも一部を直接または間接に指定する算出条件を入力する算出条件入力工程と、
   前記算出条件に基づき、前記属性に応じて、前記リンクおよびノードについてのコストを算出するコスト算出工程と、
   前記算出されたコストを用いて経路探索を行う経路探索工程とを備える経路探索方法。
9. 歩行者の経路探索を行う経路探索方法であって、
   コンピュータが実行する工程として、
   歩行者の通路をノード、リンクで表したデータと、該ノード、リンクの形状および通行規制の少なくとも一部を表す複数項目の属性とを格納したネットワークデータを参照する参照工程と、
   前記経路探索で用いるコストの算出に使用すべき属性、および該属性と前記コストとの関係の少なくとも一部を直接または間接に指定する算出条件を入力する算出条件入力工程と、
   前記算出条件に基づき、前記属性に応じて、前記リンクおよびノードについてのコストを算出するコスト算出工程と、
   前記算出されたコストを用いて経路探索を行う経路探索工程とを備え、
   更に、前記歩行者の属性および希望の少なくとも一方と、前記算出条件を規定するパラメータの少なくとも一部との対応関係を予め記憶するパラメータ記憶工程を有し、
   前記算出条件入力工程においては、前記パラメータ記憶部に記憶されたパラメータについては、歩行者の属性および経路探索方法についての希望の少なくとも一部についての指定を受け付け、
   前記コスト算出工程においては前記対応関係を参照して前記算出条件を設定する経路探索方法。
10. 歩行者の経路探索を行うためのコンピュータプログラムであって、
    歩行者の通路をノード、リンクで表したデータと、該ノード、リンクの形状および通行規制の少なくとも一部を表す複数項目の属性とを格納したネットワークデータを参照する参照プログラムコードと、
    前記複数項目の属性のうち少なくとも一部の属性について、前記経路探索で用いるコストの算出に使用すべき属性、および該属性と前記コストとの関係の少なくとも一部を直接または間接に指定する算出条件を入力する算出条件入力プログラムコードと、
    前記算出条件に基づき、前記属性に応じて、前記リンクおよびノードについてのコストを算出するコスト算出プログラムコードと、
    前記算出されたコストを用いて経路探索を行う経路探索プログラムコードとを備えるコンピュータプログラム。
11. 歩行者の経路探索を行うためのコンピュータプログラムであって、
    歩行者の通路をノード、リンクで表したデータと、該ノード、リンクの形状および通行規制の少なくとも一部を表す複数項目の属性とを格納したネットワークデータを参照する参照プログラムコードと、
    前記経路探索で用いるコストの算出に使用すべき属性、および該属性と前記コストとの関係の少なくとも一部を直接または間接に指定する算出条件を入力する算出条件入力プログラムコードと、
    前記算出条件に基づき、前記属性に応じて、前記リンクおよびノードについてのコストを算出するコスト算出プログラムコードと、
    前記算出されたコストを用いて経路探索を行う経路探索プログラムコードとを備え、
    更に、前記歩行者の属性および希望の少なくとも一方と、前記算出条件を規定するパラメータの少なくとも一部との対応関係を予め記憶するパラメータ記憶プログラムコードを有し、
    前記算出条件入力プログラムコードは、前記パラメータ記憶部に記憶されたパラメータについては、歩行者の属性および経路探索方法についての希望の少なくとも一部についての指定を受け付け可能であり、
    前記コスト算出プログラムコードは前記対応関係を参照して前記算出条件を設定可能であるコンピュータプログラム。